Messages in this thread | | | Date | Fri, 29 May 2020 17:01:09 +0200 | From | Mauro Carvalho Chehab <> | Subject | Re: please revert "Revert "media: staging: atomisp: Remove driver"" |
| |
Em Fri, 29 May 2020 16:09:07 +0200 Christoph Hellwig <hch@lst.de> escreveu:
> Hi Mauro and Greg, > > the commit mentioned in the subject (commit id ad85094b293e in > linux-next) contains the grave offense of adding a new set_fs address > space override in "new" code. It also doesn't have an Ack from Greg > despite showing up in drives/staging, which looks very suspicious. > > Please don't just add crap like this back if it doesn't pass the > most basic sanity tests.
Hi Christoph,
Thanks for the tip about set_fs().
The part of the driver which calls set_fs() is under the compat32 handler.
This code is commented-out at the commit which reverted it:
const struct v4l2_file_operations atomisp_fops = { .owner = THIS_MODULE, .open = atomisp_open, .release = atomisp_release, .mmap = atomisp_mmap, .unlocked_ioctl = video_ioctl2, #ifdef CONFIG_COMPAT /* * There are problems with this code. Disable this for now. .compat_ioctl32 = atomisp_compat_ioctl32, */ #endif .poll = atomisp_poll, };
So, there's not risk of calling it. Also, instead of calling an atomisp-specific compat32, the driver should, instead, use the standard V4L2 handler for it, once we can get rid of all those new driver-specific ioctls. Most of which can probably be replaced by the already existing ones.
But yeah, you're right, we should get rid of the places that have set_fs() there. I'll add an additional patch for it to get rid of the set_fs(), adding a FIXME there.
I'll send a patch for it in a few.
Thanks, Mauro
| |