linux-kernel - Re: [NFS] 2.6.23-rc1-mm2

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: <1186528107.6625.71.camel@heimdal.trondhjem.org>
Date:	Tue, 07 Aug 2007 19:08:27 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Neil Brown <neilb@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marc Dietrich <Marc.Dietrich@...physik.uni-giessen.de>,
	Johannes Berg <johannes@...solutions.net>,
	nfs@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [NFS] 2.6.23-rc1-mm2

On Wed, 2007-08-08 at 02:20 +0400, Oleg Nesterov wrote:

> But. nfs4_renew_state() checks list_empty(&clp->cl_superblocks) under
> clp->cl_sem? So, if it is possible that clp->cl_renewd was scheduled
> at the time when nfs4_kill_renewd(), we can deadlock, no? Because
> nfs4_renew_state() needs clp->cl_sem to complete, but nfs4_kill_renewd()
> holds this sem, and waits for nfs4_renew_state() completion.

They both take read locks, which means that they can take them
simultaneously. AFAICS, the deadlock can only occur if something manages
to insert a request for a write lock after nfs4_kill_renewd() takes its
read lock, but before nfs4_renew_state() takes its read lock:

1) nfs4_kill_renewd()		2) nfs4_renew_state()		3) somebody else
-------------------             ------------------		-------------
read lock
wait on (2) to complete
								write lock <waits on (1)>
				read lock <waits on (3),
					because rw_semaphores
					don't allow a read lock
					request to jump a write
					lock request>

however as I explained earlier, the only process that can take a write
lock is the reclaimer daemon, but we _know_ that cannot be running (for
one thing, the reference count on nfs_client is zero, for the other,
there are no superblocks).

Cheers
  Trond

-
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/