linux-kernel - Re: [git pull] vfs fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+icZUU=VzD+LM6i9VK6HuJooOj+yKHtJR+MOjaXjs68MGcRPQ@mail.gmail.com>
Date:	Sun, 23 Mar 2014 11:57:16 +0100
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] vfs fixes

On Sun, Mar 23, 2014 at 8:16 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>         Several fixes; first 4 commits are obvious fixes (a couple
> of fdget_pos()-related ones from Eric Biggers, prepend_name() fix, missing
> checks for false negatives from __lookup_mnt() in fs/namei.c), followed
> by 4 commits dealing with the bug found by Max last week - switch of
> mnt_hash to hlist, to avoid the fun with non-terminating __lookup_mnt().
> I'm fairly comfortable with that pile, but whether its second part is OK
> at this point is up to you; it seems to survive everything I'd thrown
> at it, and it's quite straightforward.  If you really feel that it's
> too close to -final, well... alternative variant is to replace the last
> 4 with "if we are spinning too much in __lookup_mnt(), check mount_lock"
> kludge like the one I've posted early in the "don't clobber mnt_hash.next"
> thread.  I'd rather go for "let's just use hlist", obviously...
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
>
> Shortlog:
> Al Viro (6):
>       make prepend_name() work correctly when called with negative *buflen
>       rcuwalk: recheck mount_lock after mountpoint crossing attempts
>       resizable namespace.c hashes
>       keep shadowed vfsmounts together
>       don't bother with propagate_mnt() unless the target is shared
>       switch mnt_hash to hlist
>
> Eric Biggers (2):
>       vfs: atomic f_pos access in llseek()
>       vfs: Don't let __fdget_pos() get FMODE_PATH files
>
> Diffstat:
>  fs/dcache.c     |    4 +-
>  fs/file.c       |   19 ++----
>  fs/mount.h      |    4 +-
>  fs/namei.c      |   29 ++++-----
>  fs/namespace.c  |  177 ++++++++++++++++++++++++++++++++++++-------------------
>  fs/pnode.c      |   26 ++++----
>  fs/pnode.h      |    4 +-
>  fs/read_write.c |    4 +-
>  8 files changed, 155 insertions(+), 112 deletions(-)
>

Your branch on top of Linux v3.14-rc7-66-g774868c7094d is freezing my
Ubuntu/precise AMD64 (WUBI) system when running LTP.

$ cat /opt/ltp/Version
20140115

Vanilla unmodified Linux v3.14-rc7-66-g774868c7094d is OK here.

Dunno how and with which apps you tested, but please verify on your
own with latest LTP release.

My kernel-config and dmesg are attached.
( I have taken a screenshot of the frozen system if you wanna look at. )

Regards,
- Sedat -

View attachment "dmesg_3.14.0-rc7-4-iniza-small.txt" of type "text/plain" (54636 bytes)

Download attachment "config-3.14.0-rc7-4-iniza-small" of type "application/octet-stream" (118275 bytes)