linux-kernel - Re: [PATCH RFC 0/4] change sb_writers to use percpu_rw

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]

Date:	Sat, 18 Jul 2015 08:40:15 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Jan Kara <jack@...e.cz>, Dave Hansen <dave.hansen@...ux.intel.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Daniel Wagner <daniel.wagner@...-carit.de>,
	Davidlohr Bueso <dave@...olabs.net>,
	Ingo Molnar <mingo@...hat.com>, Tejun Heo <tj@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/4] change sb_writers to use percpu_rw_semaphore

On Fri, Jul 17, 2015 at 07:31:17PM +0200, Oleg Nesterov wrote:
> On 07/17, Dave Chinner wrote:
> >
> > On Thu, Jul 16, 2015 at 07:32:56PM +0200, Oleg Nesterov wrote:
> > >
> > > 	#ifdef CONFIG_LOCKDEP
> > > 		/*
> > > 		 * We want lockdep to tell us about possible deadlocks with freezing but
> > > 		 * it's it bit tricky to properly instrument it. Getting a freeze protection
> > > 		 * works as getting a read lock but there are subtle problems. XFS for example
> > > 		 * gets freeze protection on internal level twice in some cases, which is OK
> >
> > Sorry, I've missed something here - where is XFS nesting
> > sb_start_intwrite() calls?
> 
> Heh ;) I too tried to understand thi but failed. I was not surprized,
> I know nothing about fs/.
> 
> Dave, I didn't write this comment. Please look at acquire_freeze_lock().
> If we can remove this logic - great! but this needs a separate change.

Oh, I think I know what it was - when we duplicate a transaction for
a rolling commit, we do it before committing the current transaction
is committed. I *think* that used to take a second freeze reference,
which only existed until the first transaction was committed. We do
things a bit differently now - we hold a state flag on the
transaction to indicate it needs to release the freeze reference
when it is freed and we pass it to the new transaction so that the
first transaction commit doesn't release it.

So, yes, it may well be a stale comment now.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/