Message ID | 20200509234557.1124086-4-viro@ZenIV.linux.org.uk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | None | expand |
On Sun, May 10, 2020 at 12:45:41AM +0100, Al Viro wrote: > From: Al Viro <viro@zeniv.linux.org.uk> > > we use copy_to_user() on that thing anyway (and always had). I already have this patch in this series: https://lore.kernel.org/linux-fsdevel/20200507145924.GA28854@lst.de/T/#t which is waiting to be picked up [1], and also has some chance for conflicts due to changes next to the access_ok. [1] except for the first two patches, which Ted plans to send for 5.7
On Sun, May 10, 2020 at 12:02:41AM -0700, Christoph Hellwig wrote: > On Sun, May 10, 2020 at 12:45:41AM +0100, Al Viro wrote: > > From: Al Viro <viro@zeniv.linux.org.uk> > > > > we use copy_to_user() on that thing anyway (and always had). > > I already have this patch in this series: > > https://lore.kernel.org/linux-fsdevel/20200507145924.GA28854@lst.de/T/#t > > which is waiting to be picked up [1], and also has some chance for conflicts > due to changes next to the access_ok. > > [1] except for the first two patches, which Ted plans to send for 5.7 I can drop this commit, of course, it's not a prereq for anything else in there. Or I could pick your series into never-rebased branch, but it would complicate the life wrt ext4 tree - up to you and Ted...
On Wed, May 13, 2020 at 08:02:07PM +0100, Al Viro wrote: > > https://lore.kernel.org/linux-fsdevel/20200507145924.GA28854@lst.de/T/#t > > > > which is waiting to be picked up [1], and also has some chance for conflicts > > due to changes next to the access_ok. > > > > [1] except for the first two patches, which Ted plans to send for 5.7 > > I can drop this commit, of course, it's not a prereq for anything else in there. > Or I could pick your series into never-rebased branch, but it would complicate > the life wrt ext4 tree - up to you and Ted... I really don't care - the first two really need to go in ASAP and Ted promised to pick them up, but I've not seen them in linux-next yet. The rest can go wherever once the first ones hit mainline.
On Wed, May 13, 2020 at 12:38:01PM -0700, Christoph Hellwig wrote: > On Wed, May 13, 2020 at 08:02:07PM +0100, Al Viro wrote: > > > https://lore.kernel.org/linux-fsdevel/20200507145924.GA28854@lst.de/T/#t > > > > > > which is waiting to be picked up [1], and also has some chance for conflicts > > > due to changes next to the access_ok. > > > > > > [1] except for the first two patches, which Ted plans to send for 5.7 > > > > I can drop this commit, of course, it's not a prereq for anything else in there. > > Or I could pick your series into never-rebased branch, but it would complicate > > the life wrt ext4 tree - up to you and Ted... > > I really don't care - the first two really need to go in ASAP and > Ted promised to pick them up, but I've not seen them in linux-next > yet. The rest can go wherever once the first ones hit mainline. OK, dropped
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index bfc1281fc4cb..a0afd0338722 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -784,11 +784,6 @@ static int ext4_ioctl_get_es_cache(struct file *filp, unsigned long arg) fieinfo.fi_extents_max = fiemap.fm_extent_count; fieinfo.fi_extents_start = ufiemap->fm_extents; - if (fiemap.fm_extent_count != 0 && - !access_ok(fieinfo.fi_extents_start, - fieinfo.fi_extents_max * sizeof(struct fiemap_extent))) - return -EFAULT; - if (fieinfo.fi_flags & FIEMAP_FLAG_SYNC) filemap_write_and_wait(inode->i_mapping); diff --git a/fs/ioctl.c b/fs/ioctl.c index 282d45be6f45..f8181e2c2168 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -215,11 +215,6 @@ static int ioctl_fiemap(struct file *filp, struct fiemap __user *ufiemap) fieinfo.fi_extents_max = fiemap.fm_extent_count; fieinfo.fi_extents_start = ufiemap->fm_extents; - if (fiemap.fm_extent_count != 0 && - !access_ok(fieinfo.fi_extents_start, - fieinfo.fi_extents_max * sizeof(struct fiemap_extent))) - return -EFAULT; - if (fieinfo.fi_flags & FIEMAP_FLAG_SYNC) filemap_write_and_wait(inode->i_mapping);