xfs
[Top] [All Lists]

Re: [3.0-stable PATCH 35/36] xfs: zero allocation_args on the kernel sta

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [3.0-stable PATCH 35/36] xfs: zero allocation_args on the kernel stack
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sun, 16 Dec 2012 08:31:08 +1100
Cc: stable@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <50C8A232.8060401@xxxxxxx>
References: <20121203144208.143464631@xxxxxxx> <20121203144312.044410710@xxxxxxx> <20121211235643.GR16353@dastard> <50C8A232.8060401@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Dec 12, 2012 at 09:26:42AM -0600, Mark Tinguely wrote:
> On 12/11/12 17:56, Dave Chinner wrote:
> >On Mon, Dec 03, 2012 at 05:42:43PM -0600, Mark Tinguely wrote:
> >>From: Mark Tinguely<tinguely@xxxxxxx>
> >>
> >>Upstream commit: a00416844b8f4b0106344bdfd90fe45a854b1d05
> >>
> >>     xfs: zero allocation_args on the kernel stack
> >>
> >>     Zero the kernel stack space that makes up the xfs_alloc_arg structures.
> >
> >Without the stack switching patches in the tree, this doesn't fix
> >any real problem.
> >
> >Cheers,
> >
> >Dave.
> 
> There are other users of the xfs_alloc_arg.userdata other than the
> former version of the allocation worker.

Sure, but it only has a minor effect on behaviour if it is wrong - I
think the only thing it will cause is an extra log force if we try
to allocate a busy extent or invalidation of a the buffer before it
gets reusued.

Neither are issues that cause user-visible problems, and the
behaviour has been like this for many, many years without anyone
seeing adverse behaviour. As such, it's not a problem that needs to
be fixed in a stable kernel.

Now, if you were backporting the stack overflow fixes, that would be
a different matter....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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