linux-kernel - Re: [PATCH, RFC] Remove fasync() BKL usage, take 3325

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: <20090122221500.4c62aa54@tpl>
Date:	Thu, 22 Jan 2009 22:15:00 -0700
From:	Jonathan Corbet <corbet@....net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, andi@...stfloor.org,
	viro@...IV.linux.org.uk, oleg@...hat.com,
	linux-api@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH, RFC] Remove fasync() BKL usage, take 3325

On Thu, 22 Jan 2009 06:51:04 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:

> OK, replacing a lock_kernel() with a spin_lock(&global_lock) is pretty
> straightforwad.  But it's really really sad.  It basically leaves a
> great big FIXME in there.  It'd be better to fix it.
> 
> We don't have a handy lock in struct file which could be borrowed.

Yeah, I noticed that too.

> - We could add one

The problem there is that this bloats struct file, and that seemed like
something worth avoiding.  It could easily be done, but I don't know
why we would before knowing that the global spinlock is a problem. 

But... it's *already* protected by a global spinlock (the BKL) which is
(still) more widely used.

> - We could borrow file->f_path.dentry->d_inode->i_lock

I didn't think of that one.  Using a lock which is three indirections
away seems a little obscure; again, I guess we could do that if the
global spinlock actually turns out to be a problem.

> - We could convert that field to long and use bitops (sounds nice?)

I did think of that one.  Reasons not to include growing struct file
and the fact that there are places which set more than one flag at
once.  So we'd replace assignments with loops - and we still don't
solve the fasync() problem.

So that was my thinking.

I'll address your other comments when I get back home.

Thanks,

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