linux-kernel - Re: [PATCH] fs/namei: waiting for mutex during name lookups is "killable"

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] [day] [month] [year] [list]

Message-ID: <20111128123056.GA19907@rabbit.intern.cm-ag>
Date:	Mon, 28 Nov 2011 13:30:57 +0100
From:	Max Kellermann <mk@...all.com>
To:	Matthew Wilcox <matthew@....cx>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs/namei: waiting for mutex during name lookups is
 "killable"

On 2011/11/28 13:19, Matthew Wilcox <matthew@....cx> wrote:
> On Mon, Nov 28, 2011 at 12:39:18PM +0100, Max Kellermann wrote:
> > Use mutex_lock_killable() instead of mutex_lock() during name lookups,
> > to allow killing the process while it's waiting.
> 
> This is cool.  Could you describe what situations this mutex gets held
> for a user-noticable length of time, and how you tested this patch?

I experienced lots of blocked unkillable processes in an environment
that uses NFS mounts extensively.

There seems to be a lot wrong with Linux's NFS client; it waits for
RPC responses synchronously while the VFS layer holds mutexes, a
behaviour that should be avoided.  My patch does not try to address
this core issue.  Instead, it attempts to mitigate a nasty side
effect.

Most blocked processes were hanging inside stat(), in the code
locations that my patch changes.  After this patch, I could verify
that the affected processes could be killed, instead of hanging in the
task list until the one process holding the mutex would give up the
RPC request.

The patch has been in production on a few heavily loaded servers for
nearly a week, and I did not observe any negative side effects.

Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/