[Top] [All Lists]

Re: [PATCH, RFC] directory offset overflows in 2.6.28

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH, RFC] directory offset overflows in 2.6.28
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 31 Dec 2008 10:34:15 +1100
Cc: xfs@xxxxxxxxxxx, John Stanley <jpsinthemix@xxxxxxxxxxx>
In-reply-to: <20081230155726.GA30568@xxxxxxxxxxxxx>
Mail-followup-to: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, John Stanley <jpsinthemix@xxxxxxxxxxx>
References: <20081229220745.GA12966@xxxxxxxxxxxxx> <20081230001117.GA5220@disturbed> <20081230155726.GA30568@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Dec 30, 2008 at 10:57:26AM -0500, Christoph Hellwig wrote:
> On Tue, Dec 30, 2008 at 11:11:17AM +1100, Dave Chinner wrote:
> > On Mon, Dec 29, 2008 at 05:07:45PM -0500, Christoph Hellwig wrote:
> > > The patch below is a dumb version of just putting back the masking,
> > > to make sure we have the same behavior as in 2.6.27 and earlier.
> > > I think we should at least hide it in a macro that is well-commented,
> > > but I suspect we also need to make sure that we never ever get bigger
> > > offsets in directories in some way.
> > 
> > I think we need that macro sooner rather than later ;)
> > In this case, you can do the masking at the time cook is
> > assigned. I haven't checked, but I suspect the rest will be the
> > same. That will make the patch less invasive and with a macro
> > somewhat cleaner...
> That way we could replace two assignment by one one time each
> in xfs_dir2_leaf.c and xfs_dir2_block.c.
> I started working on the macro, but it seems even more hacky.
> When looking at the big picture we have two problems:
>  - the end of directory marker which always seems to be always too
>    large for 32bit values for 32 bit indices
>  - directories that actually are too large to be represented using
>    32 bit signed offsets.  I guess we just can't support those
>    for apps using the 32bit readdir interface and the EOVERFLOW
>    is valid for those.  The current approach as in < 2.6.28 and
>    with this patch breaks that second case in subtile ways.
> So, I'd just push the first hacky opencoded patch into 2.6.29 and
> -stable now to revert to the old behaviour with all it's faults, and
> in the meantime I'll look into a proper way finding a better end of
> directory indicator.  That should also help Russell's BSD concerns.

Ok, sounds like a plan.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>