linux-kernel - Re: [RFC][PATCH 0/3] Coda: remove BKL

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: <201010211720.28775.arnd@arndb.de>
Date:	Thu, 21 Oct 2010 17:20:28 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Jan Harkes <jaharkes@...cmu.edu>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/3] Coda: remove BKL

On Thursday 21 October 2010, Jan Harkes wrote:
> On 10/21/2010 05:08 AM, Arnd Bergmann wrote:
> > On Wednesday 20 October 2010, Jan Harkes wrote:
> >> The following three patches remove the big kernel lock from the Coda
> >> file system kernel module. We initially add a spinlock to protect the
> >> Coda-specific inode data. After this we can push the BKL all the way
> >> down to where the requests are queued for the userspace Coda cache
> >> manager process and finally we replace the remaining BKL uses with a
> >> mutex that protects the upcall queues.
> > 
> > Very nice!
> > 
> > Are you pushing this to Linus or should I take care of it along with
> > the other file systems?
> > 
> > This patch is larger than most of the others, but I can add it to
> > my bkl/vfs tree if you like.
> 
> In that case it might be better when pushed separately, just to avoid
> any chances on a merge conflict for the bkl/vfs tree. I was thinking of
> letting the initial merges hit, rebase and retest over the weekend if
> there were any Coda related changes, and sending the final version to
> Linus by monday.
> 
> Besides, that gives me a couple of more days to make sure I weed out any
> remaining issues.

Ok, good.

I'll leave everything as is then, to avoid having to rebase myself.

This means you will get the conflict against the pushdown patch into
coda_fill_super, which is trivial to clean up by reverting part of
my patch and applying yours.

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