Re: [PATCH 3.9 and earlier] hpfs: deadlock and race in directory lseek()

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

 



On Mon, 2014-02-10 at 16:34 -0800, Greg KH wrote:
> On Tue, Feb 11, 2014 at 12:06:58AM +0100, Mikulas Patocka wrote:
> > Hi
> > 
> > This is backport of patch 31abdab9c11bb1694ecd1476a7edbe8e964d94ac for 
> > stable kernels 3.9 and earlier.
> > 
> > Mikulas
> > 
> > 
> > commit 31abdab9c11bb1694ecd1476a7edbe8e964d94ac
> > Author: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> > Date:   Sat May 18 02:38:52 2013 -0400
> > 
> >     hpfs: deadlock and race in directory lseek()
> > 
> >     For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex
> >     in hpfs_dir_lseek() - there's a lot of methods that grab the former with
> >     the caller already holding the latter, so it must take i_mutex first.
> > 
> >     For another, locking the damn thing, carefully validating the offset,
> >     then dropping locks and assigning the offset is obviously racy.
> > 
> >     Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c
> >     won't modify the sucker on B-tree surgeries.
> > 
> >     Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> > 
> > 
> > ---
> >  fs/hpfs/dir.c  |   10 ++++++----
> >  fs/hpfs/file.c |   36 ++++++++++++++++++++----------------
> >  2 files changed, 26 insertions(+), 20 deletions(-)
> 
> That diffstat does not match up with the patch below.
> 
> What went wrong?
> 
> I've just picked the original patch to backport to 3.4, if that is
> incorrect, please let me know.
[...]

I've just done the same for 3.2.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]