LinuxTV Patchwork [v1,1/1] media: atmel-isc: Add safety checks for NULL isc->raw_fmt struct

login
register
mail settings
Submitter Ken Sloat
Date Nov. 20, 2018, 8:43 p.m.
Message ID <20181120204309.42339-1-ksloat@aampglobal.com>
Download mbox | patch
Permalink /patch/53052/
State Changes Requested
Delegated to: Hans Verkuil
Headers show

Comments

Ken Sloat - Nov. 20, 2018, 8:43 p.m.
From: Ken Sloat <ksloat@aampglobal.com>

In some usages isc->raw_fmt will not be initialized. If this
is the case, it is very possible that a NULL struct de-reference
will occur, as this member is referenced many times.

To prevent this, add safety checks for this member and handle
situations accordingly.

Signed-off-by: Ken Sloat <ksloat@aampglobal.com>
---
 drivers/media/platform/atmel/atmel-isc.c | 64 ++++++++++++++++--------
 1 file changed, 44 insertions(+), 20 deletions(-)
Eugen Hristev - Nov. 21, 2018, 7:36 a.m.
On 20.11.2018 22:43, Ken Sloat wrote:
> From: Ken Sloat <ksloat@aampglobal.com>

> 

> In some usages isc->raw_fmt will not be initialized. If this

> is the case, it is very possible that a NULL struct de-reference

> will occur, as this member is referenced many times.


Hello  Ken,

Do you have any confidence that just by avoiding the NULL situation, 
this fix makes things right for adding new sensors that for example, do 
not offer a raw format ?

The check that actually sets the raw_fmt comes from an iteration through 
the formats, and the one having the RAW flag gets put into this 
variable. One could just alter the formats table and get the raw_fmt 
that is needed.
My feeling is that the method of adding this variable (raw_fmt) is very 
unfortunate, and I did not completely understand the situations where 
it's needed.

Look inline about what I mean...

> 

> To prevent this, add safety checks for this member and handle

> situations accordingly.

> 

> Signed-off-by: Ken Sloat <ksloat@aampglobal.com>

> ---

>   drivers/media/platform/atmel/atmel-isc.c | 64 ++++++++++++++++--------

>   1 file changed, 44 insertions(+), 20 deletions(-)

> 

> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c

> index 50178968b8a6..4cccaa4f2ce9 100644

> --- a/drivers/media/platform/atmel/atmel-isc.c

> +++ b/drivers/media/platform/atmel/atmel-isc.c

> @@ -902,6 +902,15 @@ static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)

>   		!isc_fmt->isc_support;

>   }

>   

> +static inline u32 get_preferred_mbus_code(const struct isc_device *isc,

> +		const struct isc_format *isc_fmt)

> +{

> +	if (sensor_is_preferred(isc_fmt) || !isc->raw_fmt)

> +		return isc_fmt->mbus_code;


For example here, if we do _not_ have a raw format, what makes us 
believe that the right format is the one from the mbus_code from the 
isc_fmt ? Is there anything useful there at all ?


> +	else

> +		return isc->raw_fmt->mbus_code;

> +}

> +

>   static struct fmt_config *get_fmt_config(u32 fourcc)

>   {

>   	struct fmt_config *config;

> @@ -955,7 +964,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)

>   {

>   	struct regmap *regmap = isc->regmap;

>   	struct isc_ctrls *ctrls = &isc->ctrls;

> -	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);

> +	struct fmt_config *config;

>   	u32 val, bay_cfg;

>   	const u32 *gamma;

>   	unsigned int i;

> @@ -969,7 +978,12 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)

>   	if (!pipeline)

>   		return;

>   

> -	bay_cfg = config->cfa_baycfg;

> +	if (isc->raw_fmt) {

> +		config = get_fmt_config(isc->raw_fmt->fourcc);

> +		bay_cfg = config->cfa_baycfg;

> +	} else {

> +		bay_cfg = 0;

> +	}


Having bay_cfg zero, in the case when we do not have a raw format, is 
the real proper way to do this ? it is possible that this bay cfg is 
required at a different value, or corresponding to different formats in 
the pipeline of the ISC.

>   

>   	regmap_write(regmap, ISC_WB_CFG, bay_cfg);

>   	regmap_write(regmap, ISC_WB_O_RGR, 0x0);

> @@ -1022,12 +1036,20 @@ static void isc_set_histogram(struct isc_device *isc)

>   {

>   	struct regmap *regmap = isc->regmap;

>   	struct isc_ctrls *ctrls = &isc->ctrls;

> -	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);

> +	struct fmt_config *config;

> +	u32	cfa_baycfg;

> +

> +	if (isc->raw_fmt) {

> +		config = get_fmt_config(isc->raw_fmt->fourcc);

> +		cfa_baycfg = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;

> +	} else {

> +		cfa_baycfg = 0;

> +	}


Ditto

>   

>   	if (ctrls->awb && (ctrls->hist_stat != HIST_ENABLED)) {

>   		regmap_write(regmap, ISC_HIS_CFG,

>   			     ISC_HIS_CFG_MODE_R |

> -			     (config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT) |

> +				 cfa_baycfg |

>   			     ISC_HIS_CFG_RAR);

>   		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_EN);

>   		regmap_write(regmap, ISC_INTEN, ISC_INT_HISDONE);

> @@ -1075,7 +1097,7 @@ static int isc_configure(struct isc_device *isc)

>   	struct regmap *regmap = isc->regmap;

>   	const struct isc_format *current_fmt = isc->current_fmt;

>   	struct fmt_config *curfmt_config = get_fmt_config(current_fmt->fourcc);

> -	struct fmt_config *rawfmt_config = get_fmt_config(isc->raw_fmt->fourcc);

> +	struct fmt_config *rawfmt_config;

>   	struct isc_subdev_entity *subdev = isc->current_subdev;

>   	u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;

>   

> @@ -1085,7 +1107,12 @@ static int isc_configure(struct isc_device *isc)

>   		isc_get_param(current_fmt, &rlp_mode, &dcfg);

>   		isc->ctrls.hist_stat = HIST_INIT;

>   	} else {

> -		pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;

> +		if (isc->raw_fmt) {

> +			rawfmt_config = get_fmt_config(isc->raw_fmt->fourcc);

> +			pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;

> +		} else {

> +			pfe_cfg0 = curfmt_config->pfe_cfg0_bps;

> +		}

>   		pipeline = curfmt_config->bits_pipeline;

>   		rlp_mode = curfmt_config->rlp_cfg_mode;

>   		dcfg = curfmt_config->dcfg_imode |

> @@ -1315,10 +1342,7 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,

>   	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)

>   		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;

>   

> -	if (sensor_is_preferred(isc_fmt))

> -		mbus_code = isc_fmt->mbus_code;

> -	else

> -		mbus_code = isc->raw_fmt->mbus_code;

> +	mbus_code = get_preferred_mbus_code(isc, isc_fmt);

>   

>   	v4l2_fill_mbus_format(&format.format, pixfmt, mbus_code);

>   	ret = v4l2_subdev_call(isc->current_subdev->sd, pad, set_fmt,

> @@ -1442,10 +1466,7 @@ static int isc_enum_framesizes(struct file *file, void *fh,

>   	if (!isc_fmt)

>   		return -EINVAL;

>   

> -	if (sensor_is_preferred(isc_fmt))

> -		fse.code = isc_fmt->mbus_code;

> -	else

> -		fse.code = isc->raw_fmt->mbus_code;

> +	fse.code = get_preferred_mbus_code(isc, isc_fmt);

>   

>   	ret = v4l2_subdev_call(isc->current_subdev->sd, pad, enum_frame_size,

>   			       NULL, &fse);

> @@ -1476,10 +1497,7 @@ static int isc_enum_frameintervals(struct file *file, void *fh,

>   	if (!isc_fmt)

>   		return -EINVAL;

>   

> -	if (sensor_is_preferred(isc_fmt))

> -		fie.code = isc_fmt->mbus_code;

> -	else

> -		fie.code = isc->raw_fmt->mbus_code;

> +	fie.code = get_preferred_mbus_code(isc, isc_fmt);

>   

>   	ret = v4l2_subdev_call(isc->current_subdev->sd, pad,

>   			       enum_frame_interval, NULL, &fie);

> @@ -1668,7 +1686,7 @@ static void isc_awb_work(struct work_struct *w)

>   	struct isc_device *isc =

>   		container_of(w, struct isc_device, awb_work);

>   	struct regmap *regmap = isc->regmap;

> -	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);

> +	struct fmt_config *config;

>   	struct isc_ctrls *ctrls = &isc->ctrls;

>   	u32 hist_id = ctrls->hist_id;

>   	u32 baysel;

> @@ -1686,7 +1704,13 @@ static void isc_awb_work(struct work_struct *w)

>   	}

>   

>   	ctrls->hist_id = hist_id;

> -	baysel = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;

> +

> +	if (isc->raw_fmt) {

> +		config = get_fmt_config(isc->raw_fmt->fourcc);

> +		baysel = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;

> +	} else {

> +		baysel = 0;

> +	}

>   

>   	pm_runtime_get_sync(isc->dev);

>   

> 


So , in short, I am not convinced that this is a proper way to solve it, 
so we have to dig in further to see if this is OK or not.
Which sensors do you have and how did you test this, which board and setup?

Thanks for your help,

Eugen
Ken Sloat - Nov. 21, 2018, 2:50 p.m.
>> From: Ken Sloat <ksloat@aampglobal.com>

>>

>> In some usages isc->raw_fmt will not be initialized. If this is the 

>> case, it is very possible that a NULL struct de-reference will occur, 

>> as this member is referenced many times.


> Hello  Ken,


> Do you have any confidence that just by avoiding the NULL situation, this fix makes things right for adding new sensors that for example, do not offer a raw format ?


Hi Eugen,

Thanks for your comments. The primary goal of my patch is to the solve the immediate issue of NULL de-reference of the that struct member. My current sensors actually do not offer a RAW format, which is why this bug happens in my case (see more details below).

> My feeling is that the method of adding this variable (raw_fmt) is very unfortunate, and I did not completely understand the situations where it's needed.


I agree that the current method of setting a struct member based on a RAW flag is flawed and ideally there needs to be a more fundamental change to the architecture of the driver so that this situation would never possibly occur, however I will present one below that can very likely happen as it does for me:

> The check that actually sets the raw_fmt comes from an iteration through the formats, and the one having the RAW flag gets put into this variable. One could just alter the formats table and get the raw_fmt that is needed.


Right, so in the initial iteration in isc_formats_init() the driver calls the sub-device/sensor enum_mbus_code function to step through all its supported formats and try and find them in the list of supported ISC formats. If none of the formats in the sub-device/sensor are of RAW type, then isc-raw_fmt will not be set. This is the fundamental flaw in using this member.

Following this, the driver will attempt to set a default format for the ISC in isc_set_default_fmt(). This appears to be based on the first format in the list of ISC formats. The driver then does a check to see if the sensor is preferred to the ISC. If the default format is not supported by the sub-device/sensor, it will not be preferred and we will get a resulting crash because it will assume that we must use the raw_fmt member that never got set.

>> 

>> To prevent this, add safety checks for this member and handle 

>> situations accordingly.

>> 

>> Signed-off-by: Ken Sloat <ksloat@aampglobal.com>

>> ---

>>   drivers/media/platform/atmel/atmel-isc.c | 64 ++++++++++++++++--------

>>   1 file changed, 44 insertions(+), 20 deletions(-)

>> 

>> diff --git a/drivers/media/platform/atmel/atmel-isc.c 

>> b/drivers/media/platform/atmel/atmel-isc.c

>> index 50178968b8a6..4cccaa4f2ce9 100644

>> --- a/drivers/media/platform/atmel/atmel-isc.c

>> +++ b/drivers/media/platform/atmel/atmel-isc.c

>> @@ -902,6 +902,15 @@ static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)

>>   		!isc_fmt->isc_support;

>>   }

>>   

>> +static inline u32 get_preferred_mbus_code(const struct isc_device *isc,

>> +		const struct isc_format *isc_fmt)

>> +{

>> +	if (sensor_is_preferred(isc_fmt) || !isc->raw_fmt)

>> +		return isc_fmt->mbus_code;


> For example here, if we do _not_ have a raw format, what makes us believe that the right format is the one from the mbus_code from the isc_fmt ? Is there anything useful there at all ?


It's more of a safe case for where this occurs in my example above. As you mentioned yourself, raw_fmt could possibly set to any of the RAW flag formats supported by the sub-device.  Assuming the sub-device did indeed support a RAW format of some sort, but did not necessarily support the current format, the driver as of today would be referencing this alternative mbus code anyways. In the example above, this occurred while setting the default format, and then subsequently will always occur when setting the pipeline in isc_set_pipeline() as this function always de-references this member to set the pointer even if a RAW format isn't necessarily being used (and so do others as seen in my patch). 

>> +	else

>> +		return isc->raw_fmt->mbus_code;

>> +}

>> +

>>   static struct fmt_config *get_fmt_config(u32 fourcc)

>>   {

>>   	struct fmt_config *config;

>> @@ -955,7 +964,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)

>>   {

>>   	struct regmap *regmap = isc->regmap;

>>   	struct isc_ctrls *ctrls = &isc->ctrls;

>> -	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);

>> +	struct fmt_config *config;

>>   	u32 val, bay_cfg;

>>   	const u32 *gamma;

>>   	unsigned int i;

>> @@ -969,7 +978,12 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)

>>   	if (!pipeline)

>>   		return;

>>   

>> -	bay_cfg = config->cfa_baycfg;

>> +	if (isc->raw_fmt) {

>> +		config = get_fmt_config(isc->raw_fmt->fourcc);

>> +		bay_cfg = config->cfa_baycfg;

>> +	} else {

>> +		bay_cfg = 0;

>> +	}


> Having bay_cfg zero, in the case when we do not have a raw format, is the real proper way to do this ? it is possible that this bay cfg is required at a different value, or corresponding to different formats in the pipeline of the ISC.

I should probably make config point to the current_fmt in the else case here so that it uses its bay_cfg, however I believe the WB module would be disabled anyways in this case. Regarding if this would be proper or useful, similar comments to above.

> So , in short, I am not convinced that this is a proper way to solve it, so we have to dig in further to see if this is OK or not.

> Which sensors do you have and how did you test this, which board and setup?


> Thanks for your help,


> Eugen


My sensor inputs a ITU-R 656 interface to the ISC, so this would be the format:

{
	.fourcc		= V4L2_PIX_FMT_YUYV,
	.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
	.flags		= FMT_FLAG_FROM_CONTROLLER |
			  FMT_FLAG_FROM_SENSOR,
	.bpp		= 16,
},

Note that the driver as of today does not support ITU-R 656 without modifications but rather ITU-R 601. However, this is as simple as setting some additional bits and I plan to submit a separate patch soon that allows this to occur from device tree in a standard way.
I am using a custom board that is based on the SAMA5D27-SOM1-EK1 board so I tested my sensor with this board using gstreamer to direct the image to the display. Happy to help out as I am able, let me know what you think.

Thanks,
Ken
Eugen Hristev - Nov. 23, 2018, 1:49 p.m.
On 21.11.2018 16:50, Ken Sloat wrote:
>>> From: Ken Sloat <ksloat@aampglobal.com>

>>>

>>> In some usages isc->raw_fmt will not be initialized. If this is the

>>> case, it is very possible that a NULL struct de-reference will occur,

>>> as this member is referenced many times.

> 

>> Hello  Ken,

> 

>> Do you have any confidence that just by avoiding the NULL situation, this fix makes things right for adding new sensors that for example, do not offer a raw format ?

> 

> Hi Eugen,

> 

> Thanks for your comments. The primary goal of my patch is to the solve the immediate issue of NULL de-reference of the that struct member. My current sensors actually do not offer a RAW format, which is why this bug happens in my case (see more details below).


I am not sure if I am correct, but your sensor surely provides data in 
some format. This format might be the 'raw' one that ISC receives. So, 
adjustments to the format list might solve this.

> 

>> My feeling is that the method of adding this variable (raw_fmt) is very unfortunate, and I did not completely understand the situations where it's needed.

> 

> I agree that the current method of setting a struct member based on a RAW flag is flawed and ideally there needs to be a more fundamental change to the architecture of the driver so that this situation would never possibly occur, however I will present one below that can very likely happen as it does for me:

> 

>> The check that actually sets the raw_fmt comes from an iteration through the formats, and the one having the RAW flag gets put into this variable. One could just alter the formats table and get the raw_fmt that is needed.

> 

> Right, so in the initial iteration in isc_formats_init() the driver calls the sub-device/sensor enum_mbus_code function to step through all its supported formats and try and find them in the list of supported ISC formats. If none of the formats in the sub-device/sensor are of RAW type, then isc-raw_fmt will not be set. This is the fundamental flaw in using this member.

> 

> Following this, the driver will attempt to set a default format for the ISC in isc_set_default_fmt(). This appears to be based on the first format in the list of ISC formats. The driver then does a check to see if the sensor is preferred to the ISC. If the default format is not supported by the sub-device/sensor, it will not be preferred and we will get a resulting crash because it will assume that we must use the raw_fmt member that never got set.


I saw this part of the code as well. I was thinking to rewrite it to 
have it iterate through all formats until a suitable one is found 
(instead of just taking the first and win or fail directly).

> 

>>>

>>> To prevent this, add safety checks for this member and handle

>>> situations accordingly.

>>>

>>> Signed-off-by: Ken Sloat <ksloat@aampglobal.com>

>>> ---

>>>    drivers/media/platform/atmel/atmel-isc.c | 64 ++++++++++++++++--------

>>>    1 file changed, 44 insertions(+), 20 deletions(-)

>>>

>>> diff --git a/drivers/media/platform/atmel/atmel-isc.c

>>> b/drivers/media/platform/atmel/atmel-isc.c

>>> index 50178968b8a6..4cccaa4f2ce9 100644

>>> --- a/drivers/media/platform/atmel/atmel-isc.c

>>> +++ b/drivers/media/platform/atmel/atmel-isc.c

>>> @@ -902,6 +902,15 @@ static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)

>>>    		!isc_fmt->isc_support;

>>>    }

>>>    

>>> +static inline u32 get_preferred_mbus_code(const struct isc_device *isc,

>>> +		const struct isc_format *isc_fmt)

>>> +{

>>> +	if (sensor_is_preferred(isc_fmt) || !isc->raw_fmt)

>>> +		return isc_fmt->mbus_code;

> 

>> For example here, if we do _not_ have a raw format, what makes us believe that the right format is the one from the mbus_code from the isc_fmt ? Is there anything useful there at all ?

> 

> It's more of a safe case for where this occurs in my example above. As you mentioned yourself, raw_fmt could possibly set to any of the RAW flag formats supported by the sub-device.  Assuming the sub-device did indeed support a RAW format of some sort, but did not necessarily support the current format, the driver as of today would be referencing this alternative mbus code anyways. In the example above, this occurred while setting the default format, and then subsequently will always occur when setting the pipeline in isc_set_pipeline() as this function always de-references this member to set the pointer even if a RAW format isn't necessarily being used (and so do others as seen in my patch).


I tend to disagree, the driver of today will fail if the sensor does not 
provide a RAW format of some sort, so it will not use alternative mbus code.

> 

>>> +	else

>>> +		return isc->raw_fmt->mbus_code;

>>> +}

>>> +

>>>    static struct fmt_config *get_fmt_config(u32 fourcc)

>>>    {

>>>    	struct fmt_config *config;

>>> @@ -955,7 +964,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)

>>>    {

>>>    	struct regmap *regmap = isc->regmap;

>>>    	struct isc_ctrls *ctrls = &isc->ctrls;

>>> -	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);

>>> +	struct fmt_config *config;

>>>    	u32 val, bay_cfg;

>>>    	const u32 *gamma;

>>>    	unsigned int i;

>>> @@ -969,7 +978,12 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)

>>>    	if (!pipeline)

>>>    		return;

>>>    

>>> -	bay_cfg = config->cfa_baycfg;

>>> +	if (isc->raw_fmt) {

>>> +		config = get_fmt_config(isc->raw_fmt->fourcc);

>>> +		bay_cfg = config->cfa_baycfg;

>>> +	} else {

>>> +		bay_cfg = 0;

>>> +	}

> 

>> Having bay_cfg zero, in the case when we do not have a raw format, is the real proper way to do this ? it is possible that this bay cfg is required at a different value, or corresponding to different formats in the pipeline of the ISC.

> I should probably make config point to the current_fmt in the else case here so that it uses its bay_cfg, however I believe the WB module would be disabled anyways in this case. Regarding if this would be proper or useful, similar comments to above.


I am not sure that the current_fmt is the actual format that the sensor 
is set to use, and if this format is OK, however you may be right that 
the bay_cfg is not needed

> 

>> So , in short, I am not convinced that this is a proper way to solve it, so we have to dig in further to see if this is OK or not.

>> Which sensors do you have and how did you test this, which board and setup?

> 

>> Thanks for your help,

> 

>> Eugen

> 

> My sensor inputs a ITU-R 656 interface to the ISC, so this would be the format:

> 

> {

> 	.fourcc		= V4L2_PIX_FMT_YUYV,

> 	.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,

> 	.flags		= FMT_FLAG_FROM_CONTROLLER |

> 			  FMT_FLAG_FROM_SENSOR,

> 	.bpp		= 16,

> },


If this format is added with a RAW flag, how does this affect your output ?

> 

> Note that the driver as of today does not support ITU-R 656 without modifications but rather ITU-R 601. However, this is as simple as setting some additional bits and I plan to submit a separate patch soon that allows this to occur from device tree in a standard way.

> I am using a custom board that is based on the SAMA5D27-SOM1-EK1 board so I tested my sensor with this board using gstreamer to direct the image to the display. Happy to help out as I am able, let me know what you think.

Which sensor is it?
You managed to get it working OK with just this patch?

My general feeling is that this workaround patch will hide the problem, 
and not solve the issue we are having here, we add more code to cope 
around with this raw_fmt NULL issue.

Anyway I am thinking to get more opinions on this issue, about which is 
the best way we can go further with it.

Thanks,
Eugen

> 

> Thanks,

> Ken

>
Ken Sloat - Nov. 26, 2018, 1:35 p.m.
> On 21.11.2018 16:50, Ken Sloat wrote:

> >>> From: Ken Sloat <ksloat@aampglobal.com>

> >>>

> >>> In some usages isc->raw_fmt will not be initialized. If this is the

> >>> case, it is very possible that a NULL struct de-reference will

> >>> occur, as this member is referenced many times.

> >

> >> Hello  Ken,

> >

> >> Do you have any confidence that just by avoiding the NULL situation, this fix

> makes things right for adding new sensors that for example, do not offer a raw

> format ?

> >

> > Hi Eugen,

> >

> > Thanks for your comments. The primary goal of my patch is to the solve the

> immediate issue of NULL de-reference of the that struct member. My current

> sensors actually do not offer a RAW format, which is why this bug happens in

> my case (see more details below).

> 

> I am not sure if I am correct, but your sensor surely provides data in some

> format. This format might be the 'raw' one that ISC receives. So, adjustments to

> the format list might solve this.


I think this flag is referring specifically to RAW bayer formats, so that the ISC can set registers properly for other modules in the pipeline in those cases - see comments in code for this flag:

/* Indicate a Raw Bayer format */
#define FMT_FLAG_RAW_FORMAT		BIT(2)

> >> My feeling is that the method of adding this variable (raw_fmt) is very

> unfortunate, and I did not completely understand the situations where it's

> needed.

> >

> > I agree that the current method of setting a struct member based on a RAW

> flag is flawed and ideally there needs to be a more fundamental change to the

> architecture of the driver so that this situation would never possibly occur,

> however I will present one below that can very likely happen as it does for me:

> >

> >> The check that actually sets the raw_fmt comes from an iteration through

> the formats, and the one having the RAW flag gets put into this variable. One

> could just alter the formats table and get the raw_fmt that is needed.

> >

> > Right, so in the initial iteration in isc_formats_init() the driver calls the sub-

> device/sensor enum_mbus_code function to step through all its supported

> formats and try and find them in the list of supported ISC formats. If none of

> the formats in the sub-device/sensor are of RAW type, then isc-raw_fmt will

> not be set. This is the fundamental flaw in using this member.

> >

> > Following this, the driver will attempt to set a default format for the ISC in

> isc_set_default_fmt(). This appears to be based on the first format in the list of

> ISC formats. The driver then does a check to see if the sensor is preferred to

> the ISC. If the default format is not supported by the sub-device/sensor, it will

> not be preferred and we will get a resulting crash because it will assume that

> we must use the raw_fmt member that never got set.

> 

> I saw this part of the code as well. I was thinking to rewrite it to have it iterate

> through all formats until a suitable one is found (instead of just taking the first

> and win or fail directly).

> 

> >

> >>>

> >>> To prevent this, add safety checks for this member and handle

> >>> situations accordingly.

> >>>

> >>> Signed-off-by: Ken Sloat <ksloat@aampglobal.com>

> >>> ---

> >>>    drivers/media/platform/atmel/atmel-isc.c | 64 ++++++++++++++++--------

> >>>    1 file changed, 44 insertions(+), 20 deletions(-)

> >>>

> >>> diff --git a/drivers/media/platform/atmel/atmel-isc.c

> >>> b/drivers/media/platform/atmel/atmel-isc.c

> >>> index 50178968b8a6..4cccaa4f2ce9 100644

> >>> --- a/drivers/media/platform/atmel/atmel-isc.c

> >>> +++ b/drivers/media/platform/atmel/atmel-isc.c

> >>> @@ -902,6 +902,15 @@ static inline bool sensor_is_preferred(const struct

> isc_format *isc_fmt)

> >>>    		!isc_fmt->isc_support;

> >>>    }

> >>>

> >>> +static inline u32 get_preferred_mbus_code(const struct isc_device *isc,

> >>> +		const struct isc_format *isc_fmt) {

> >>> +	if (sensor_is_preferred(isc_fmt) || !isc->raw_fmt)

> >>> +		return isc_fmt->mbus_code;

> >

> >> For example here, if we do _not_ have a raw format, what makes us believe

> that the right format is the one from the mbus_code from the isc_fmt ? Is there

> anything useful there at all ?

> >

> > It's more of a safe case for where this occurs in my example above. As you

> mentioned yourself, raw_fmt could possibly set to any of the RAW flag formats

> supported by the sub-device.  Assuming the sub-device did indeed support a

> RAW format of some sort, but did not necessarily support the current format,

> the driver as of today would be referencing this alternative mbus code

> anyways. In the example above, this occurred while setting the default format,

> and then subsequently will always occur when setting the pipeline in

> isc_set_pipeline() as this function always de-references this member to set the

> pointer even if a RAW format isn't necessarily being used (and so do others as

> seen in my patch).

> 

> I tend to disagree, the driver of today will fail if the sensor does not provide a

> RAW format of some sort, so it will not use alternative mbus code.

> 

> >

> >>> +	else

> >>> +		return isc->raw_fmt->mbus_code;

> >>> +}

> >>> +

> >>>    static struct fmt_config *get_fmt_config(u32 fourcc)

> >>>    {

> >>>    	struct fmt_config *config;

> >>> @@ -955,7 +964,7 @@ static void isc_set_pipeline(struct isc_device *isc,

> u32 pipeline)

> >>>    {

> >>>    	struct regmap *regmap = isc->regmap;

> >>>    	struct isc_ctrls *ctrls = &isc->ctrls;

> >>> -	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);

> >>> +	struct fmt_config *config;

> >>>    	u32 val, bay_cfg;

> >>>    	const u32 *gamma;

> >>>    	unsigned int i;

> >>> @@ -969,7 +978,12 @@ static void isc_set_pipeline(struct isc_device *isc,

> u32 pipeline)

> >>>    	if (!pipeline)

> >>>    		return;

> >>>

> >>> -	bay_cfg = config->cfa_baycfg;

> >>> +	if (isc->raw_fmt) {

> >>> +		config = get_fmt_config(isc->raw_fmt->fourcc);

> >>> +		bay_cfg = config->cfa_baycfg;

> >>> +	} else {

> >>> +		bay_cfg = 0;

> >>> +	}

> >

> >> Having bay_cfg zero, in the case when we do not have a raw format, is the

> real proper way to do this ? it is possible that this bay cfg is required at a

> different value, or corresponding to different formats in the pipeline of the ISC.

> > I should probably make config point to the current_fmt in the else case here

> so that it uses its bay_cfg, however I believe the WB module would be disabled

> anyways in this case. Regarding if this would be proper or useful, similar

> comments to above.

> 

> I am not sure that the current_fmt is the actual format that the sensor is set to

> use, and if this format is OK, however you may be right that the bay_cfg is not

> needed

> 

> >

> >> So , in short, I am not convinced that this is a proper way to solve it, so we

> have to dig in further to see if this is OK or not.

> >> Which sensors do you have and how did you test this, which board and

> setup?

> >

> >> Thanks for your help,

> >

> >> Eugen

> >

> > My sensor inputs a ITU-R 656 interface to the ISC, so this would be the

> format:

> >

> > {

> > 	.fourcc		= V4L2_PIX_FMT_YUYV,

> > 	.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,

> > 	.flags		= FMT_FLAG_FROM_CONTROLLER |

> > 			  FMT_FLAG_FROM_SENSOR,

> > 	.bpp		= 16,

> > },

> 

> If this format is added with a RAW flag, how does this affect your output ?

Doing this will indeed prevent a crash and allow the sensor to function in my use case.

> > Note that the driver as of today does not support ITU-R 656 without

> modifications but rather ITU-R 601. However, this is as simple as setting some

> additional bits and I plan to submit a separate patch soon that allows this to

> occur from device tree in a standard way.

> > I am using a custom board that is based on the SAMA5D27-SOM1-EK1 board

> so I tested my sensor with this board using gstreamer to direct the image to the

> display. Happy to help out as I am able, let me know what you think.

> Which sensor is it?

> You managed to get it working OK with just this patch?

> 

> My general feeling is that this workaround patch will hide the problem, and not

> solve the issue we are having here, we add more code to cope around with this

> raw_fmt NULL issue.

> 

> Anyway I am thinking to get more opinions on this issue, about which is the best

> way we can go further with it.

> 

> Thanks,

> Eugen


Sounds good Eugen, thanks for your help. Let me know how I can be of assistance going forward.

Thanks,
Ken

Patch

diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index 50178968b8a6..4cccaa4f2ce9 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -902,6 +902,15 @@  static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)
 		!isc_fmt->isc_support;
 }
 
+static inline u32 get_preferred_mbus_code(const struct isc_device *isc,
+		const struct isc_format *isc_fmt)
+{
+	if (sensor_is_preferred(isc_fmt) || !isc->raw_fmt)
+		return isc_fmt->mbus_code;
+	else
+		return isc->raw_fmt->mbus_code;
+}
+
 static struct fmt_config *get_fmt_config(u32 fourcc)
 {
 	struct fmt_config *config;
@@ -955,7 +964,7 @@  static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 {
 	struct regmap *regmap = isc->regmap;
 	struct isc_ctrls *ctrls = &isc->ctrls;
-	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);
+	struct fmt_config *config;
 	u32 val, bay_cfg;
 	const u32 *gamma;
 	unsigned int i;
@@ -969,7 +978,12 @@  static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	if (!pipeline)
 		return;
 
-	bay_cfg = config->cfa_baycfg;
+	if (isc->raw_fmt) {
+		config = get_fmt_config(isc->raw_fmt->fourcc);
+		bay_cfg = config->cfa_baycfg;
+	} else {
+		bay_cfg = 0;
+	}
 
 	regmap_write(regmap, ISC_WB_CFG, bay_cfg);
 	regmap_write(regmap, ISC_WB_O_RGR, 0x0);
@@ -1022,12 +1036,20 @@  static void isc_set_histogram(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
 	struct isc_ctrls *ctrls = &isc->ctrls;
-	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);
+	struct fmt_config *config;
+	u32	cfa_baycfg;
+
+	if (isc->raw_fmt) {
+		config = get_fmt_config(isc->raw_fmt->fourcc);
+		cfa_baycfg = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
+	} else {
+		cfa_baycfg = 0;
+	}
 
 	if (ctrls->awb && (ctrls->hist_stat != HIST_ENABLED)) {
 		regmap_write(regmap, ISC_HIS_CFG,
 			     ISC_HIS_CFG_MODE_R |
-			     (config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT) |
+				 cfa_baycfg |
 			     ISC_HIS_CFG_RAR);
 		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_EN);
 		regmap_write(regmap, ISC_INTEN, ISC_INT_HISDONE);
@@ -1075,7 +1097,7 @@  static int isc_configure(struct isc_device *isc)
 	struct regmap *regmap = isc->regmap;
 	const struct isc_format *current_fmt = isc->current_fmt;
 	struct fmt_config *curfmt_config = get_fmt_config(current_fmt->fourcc);
-	struct fmt_config *rawfmt_config = get_fmt_config(isc->raw_fmt->fourcc);
+	struct fmt_config *rawfmt_config;
 	struct isc_subdev_entity *subdev = isc->current_subdev;
 	u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;
 
@@ -1085,7 +1107,12 @@  static int isc_configure(struct isc_device *isc)
 		isc_get_param(current_fmt, &rlp_mode, &dcfg);
 		isc->ctrls.hist_stat = HIST_INIT;
 	} else {
-		pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;
+		if (isc->raw_fmt) {
+			rawfmt_config = get_fmt_config(isc->raw_fmt->fourcc);
+			pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;
+		} else {
+			pfe_cfg0 = curfmt_config->pfe_cfg0_bps;
+		}
 		pipeline = curfmt_config->bits_pipeline;
 		rlp_mode = curfmt_config->rlp_cfg_mode;
 		dcfg = curfmt_config->dcfg_imode |
@@ -1315,10 +1342,7 @@  static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
 		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
 
-	if (sensor_is_preferred(isc_fmt))
-		mbus_code = isc_fmt->mbus_code;
-	else
-		mbus_code = isc->raw_fmt->mbus_code;
+	mbus_code = get_preferred_mbus_code(isc, isc_fmt);
 
 	v4l2_fill_mbus_format(&format.format, pixfmt, mbus_code);
 	ret = v4l2_subdev_call(isc->current_subdev->sd, pad, set_fmt,
@@ -1442,10 +1466,7 @@  static int isc_enum_framesizes(struct file *file, void *fh,
 	if (!isc_fmt)
 		return -EINVAL;
 
-	if (sensor_is_preferred(isc_fmt))
-		fse.code = isc_fmt->mbus_code;
-	else
-		fse.code = isc->raw_fmt->mbus_code;
+	fse.code = get_preferred_mbus_code(isc, isc_fmt);
 
 	ret = v4l2_subdev_call(isc->current_subdev->sd, pad, enum_frame_size,
 			       NULL, &fse);
@@ -1476,10 +1497,7 @@  static int isc_enum_frameintervals(struct file *file, void *fh,
 	if (!isc_fmt)
 		return -EINVAL;
 
-	if (sensor_is_preferred(isc_fmt))
-		fie.code = isc_fmt->mbus_code;
-	else
-		fie.code = isc->raw_fmt->mbus_code;
+	fie.code = get_preferred_mbus_code(isc, isc_fmt);
 
 	ret = v4l2_subdev_call(isc->current_subdev->sd, pad,
 			       enum_frame_interval, NULL, &fie);
@@ -1668,7 +1686,7 @@  static void isc_awb_work(struct work_struct *w)
 	struct isc_device *isc =
 		container_of(w, struct isc_device, awb_work);
 	struct regmap *regmap = isc->regmap;
-	struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);
+	struct fmt_config *config;
 	struct isc_ctrls *ctrls = &isc->ctrls;
 	u32 hist_id = ctrls->hist_id;
 	u32 baysel;
@@ -1686,7 +1704,13 @@  static void isc_awb_work(struct work_struct *w)
 	}
 
 	ctrls->hist_id = hist_id;
-	baysel = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
+
+	if (isc->raw_fmt) {
+		config = get_fmt_config(isc->raw_fmt->fourcc);
+		baysel = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
+	} else {
+		baysel = 0;
+	}
 
 	pm_runtime_get_sync(isc->dev);
 

Privacy Policy