linux-kernel - Re: [PATCH, RFC] char dev BKL pushdown

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:	Tue, 20 May 2008 19:21:51 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Jonathan Corbet <corbet@....net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Alexander Viro <viro@....linux.org.uk>,
	linux-kernel@...r.kernel.org, Wim Van Sebroeck <wim@...ana.be>
Subject: Re: [PATCH, RFC] char dev BKL pushdown

On Tuesday 20 May 2008, Jonathan Corbet wrote:
> Arnd Bergmann <arnd@...db.de> wrote:
> 
> > I've given it a try for all the misc drivers that have an open() function.
> > The vast majority of them are actually watchdog drivers, all of which
> > register as a misc device by themselves. 
> 
> OK, it looks like the "misc" misc drivers patch can go into the
> bkl-removal tree, while the watchdog patches should not.  What that
> means, I guess, is that the final misc_open() patch cannot go in at this
> point; Alan's watchdog stuff needs to find its way in first.  Make
> sense? 

Right, unless Alan or Wim are confident enough that removing the
BKL won't break the drivers (more than they are today).
Almost all of the open functions go along the lines of

int open(struct file *f, struct inode *i)
{
	if (wd_is_open)
		return -EBUSY;
	wd_is_open = 1;
	
	start_wd();

	return nonseekable_open(f, i);
}

nonseekable_open doesn't need the BKL by itself, and the wd_is_open
variable is protected by the misc_mtx mutex.
I can't see any scenario in which start_wd() would need the BKL, or
where a watchdog driver needs cycle_kernel_lock(), but I was't confident
enough about that assessment, because I'm not really familiar with
the drivers.

> > You seem to already have a script to turn per-file changes into a
> > patch each, so I'm sending you two patches: one for all the watchdog
> > drivers (maybe Wim can take care of that as well) and one for all the
> > other misc drivers (this one needs to be split).
> 
> Alas, I have no such script.  I just committed each change as I made it
> - each one required individual attention anyway.  The misc changes look
> pretty straightforward, so I could probably hack up such a thing pretty
> quickly if you don't have a tree with broken out patches.

I've done a semi-automated split and applied the patches on top of your
tree. You can pull these from

git://git.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6 bkl-removal

(I guess I should do a separate tree for it, will do that if more stuff
comes up.)

	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/