lkml.org 
[lkml]   [2008]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/24] GFS2: Support for FIEMAP ioctl
On Thu, 18 Dec 2008 10:29:04 +0000
Steven Whitehouse <swhiteho@redhat.com> wrote:

> Hi,
>
> On Wed, 2008-12-17 at 17:22 -0800, Andrew Morton wrote:
> > On Wed, 17 Dec 2008 11:30:00 +0000
> > swhiteho@redhat.com wrote:
> >
> > > +static int gfs2_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> > > + u64 start, u64 len)
> > > +{
> > > + struct gfs2_inode *ip = GFS2_I(inode);
> > > + struct gfs2_holder gh;
> > > + int ret;
> > > +
> > > + ret = fiemap_check_flags(fieinfo, FIEMAP_FLAG_SYNC);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(&inode->i_mutex);
> > > +
> > > + ret = gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED, 0, &gh);
> > > + if (ret)
> > > + goto out;
> > > +
> > > + if (gfs2_is_stuffed(ip)) {
> > > + u64 phys = ip->i_no_addr << inode->i_blkbits;
> > > + u64 size = i_size_read(inode);
> >
> > It's actually safe to directly access i_size inside i_mutex. Although
> > not terribly maintainable.
> >
> >
> I did wonder about that at the time, but I'm not quite sure if you are
> suggesting that I should change this now, or leave it as it is?

No strong opinion, really. If it's a performance-sensitive path (it
isn't) then bypassing i_size_read() might be advantageous. Leaving the
i_size_read() there provides some future-safety and sets a good
example.

It would be an easier decision if the SMP, 32-bit version of
i_size_read() wasn't inlined, and tremendously huge :(



\
 
 \ /
  Last update: 2008-12-18 20:07    [W:0.102 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site