lkml.org 
[lkml]   [2020]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2020-05-29 17:02    [W:0.489 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site