Re: [PATCH 1/2] xfs: rewrite getbmap using the xfs_iext_* helpers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 21, 2017 at 03:36:10PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 20, 2017 at 04:08:24PM -0700, Darrick J. Wong wrote:
> > > I'm still wondering why we allocate a potentially large getbmapx buffer,
> > > fill it out, and only then format the results to userspace?  I think
> > > getbmap (the ioctl) is now the only user of these functions, so can't
> > > we just call the formatter directly from _getbmap_report_one and
> > > _getbmap_report_hole, like what getfsmap does?
> > > 
> > > (I also feel like I've asked this before, so apologies if I'm merely
> > > forgetting the answer.)
> > 
> > Oh right, it's because we have the inode locked, and copying things to
> > userspace could incur a page fault, which we can't risk with the inode
> > locked because some malicious person could create a fragmented file with
> > a bmap request header at the start of the file, mmap the file, and call
> > bmap on the fragmented file with the pointer being the mmap region.
> 
> Yes.
> 
> Can I get a Reviewed-by: tag now? :)

Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>

> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux