| Message ID | 20201112151334.32167-1-nuno.sa@analog.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Sanity check buffer callback | expand |
On Thu, 12 Nov 2020 16:13:33 +0100 Nuno Sá <nuno.sa@analog.com> wrote: > When going through the code of the buffer-cb interface and all it's > users, I realized that the stm32_adfsdm driver is calling > `iio_channel_get_all_cb()` with NULL for the cb. After going a bit > trough the stm drivers, it looks like this is actually intentional. > However, it is clear that we have a clear/direct route here for a NULL > pointer dereference. I'm being lazy in this RFC and just doing a > sanity check in the `iio_buffer_cb_store_to()` so that we don't have to > change the stm driver... The point is just to bring this up and see if > we want to do something about this. > > To be clear, the way I think this should go is just to return -EINVAL in > `iio_channel_get_all_cb()` if a NULL ptr is passed. Whats the point of a > buffer-cb if cb is NULL, right? This would naturally break the stm > driver, but I guess we could just define a dummy handler there that > would not be used (or could the HW consumer be an option here?)... > > Thoughts? Good description thanks. I think you are right and better option is to return -EINVAL in iio_channel_get_all_cb() and add a dummy handler to the stm driver. cc Arnaud and Olivier to see if they are fine with the dummy handler. (with appropriate comment on why it is there). Jonathan > > Nuno Sá (1): > iio: buffer: Sanity check buffer callback > > drivers/iio/buffer/industrialio-buffer-cb.c | 4 ++++ > 1 file changed, 4 insertions(+) >
On 11/14/20 5:33 PM, Jonathan Cameron wrote: > On Thu, 12 Nov 2020 16:13:33 +0100 > Nuno Sá <nuno.sa@analog.com> wrote: > >> When going through the code of the buffer-cb interface and all it's >> users, I realized that the stm32_adfsdm driver is calling >> `iio_channel_get_all_cb()` with NULL for the cb. After going a bit >> trough the stm drivers, it looks like this is actually intentional. >> However, it is clear that we have a clear/direct route here for a NULL >> pointer dereference. I'm being lazy in this RFC and just doing a >> sanity check in the `iio_buffer_cb_store_to()` so that we don't have to >> change the stm driver... The point is just to bring this up and see if >> we want to do something about this. >> >> To be clear, the way I think this should go is just to return -EINVAL in >> `iio_channel_get_all_cb()` if a NULL ptr is passed. Whats the point of a >> buffer-cb if cb is NULL, right? This would naturally break the stm >> driver, but I guess we could just define a dummy handler there that >> would not be used (or could the HW consumer be an option here?)... >> >> Thoughts? > > Good description thanks. I think you are right and better option is > to return -EINVAL in iio_channel_get_all_cb() and add a dummy handler to the > stm driver. > > cc Arnaud and Olivier to see if they are fine with the dummy handler. > (with appropriate comment on why it is there). > > Jonathan > > Hi Jonathan, Thanks for your notice. Arnaud and myself agree with this solution. I attach to this mail a patch which implements this dummy handler and can be added to Nuno's patchset, to avoid a regression on stm driver. Regards, Olivier >> >> Nuno Sá (1): >> iio: buffer: Sanity check buffer callback >> >> drivers/iio/buffer/industrialio-buffer-cb.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >