please revert "Revert "media: staging: atomisp: Remove driver""

please revert "Revert "media: staging: atomisp: Remove driver""

[Christoph Hellwig]

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.

Re: please revert "Revert "media: staging: atomisp: Remove driver""

[Greg Kroah-Hartman]

On Fri, May 29, 2020 at 04:09:07PM +0200, Christoph Hellwig wrote:
> 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.

Mauro "owns" drivers/staging/media/ which is where this ended up in,
right?  And I thought he had a bunch of follow-on patches that fixed up
crud like set_fs and friends.

Mauro, is your fixes not pushed in your tree as well?

thanks,

greg k-h

Re: please revert "Revert "media: staging: atomisp: Remove driver""

[Mauro Carvalho Chehab]

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

Re: please revert "Revert "media: staging: atomisp: Remove driver""

[Mauro Carvalho Chehab]

Em Fri, 29 May 2020 16:46:15 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:

> On Fri, May 29, 2020 at 04:09:07PM +0200, Christoph Hellwig wrote:
> > 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.  
> 
> Mauro "owns" drivers/staging/media/ which is where this ended up in,
> right?  And I thought he had a bunch of follow-on patches that fixed up
> crud like set_fs and friends.
> 
> Mauro, is your fixes not pushed in your tree as well?

Yes, I'm pushing the fixes on my tree too, after giving them some time
for review at the mailing lists.

In any case, feel free to ping me if you find anything as bad as this
one.

Thanks,
Mauro