linux-kernel - Re: [PATCH 2/4] Convert epoll to a bitlock

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, 3 Feb 2009 14:53:46 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jonathan Corbet <corbet@....net>
Cc:	mpm@...enic.com, dada1@...mosbay.com, linux-kernel@...r.kernel.org,
	andi@...stfloor.org, oleg@...hat.com, viro@...IV.linux.org.uk,
	davidel@...ilserver.org, davem@...emloft.net, hch@....de,
	linux-api@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH 2/4] Convert epoll to a bitlock

On Tue, 3 Feb 2009 15:37:40 -0700
Jonathan Corbet <corbet@....net> wrote:

> On Tue, 03 Feb 2009 16:22:02 -0600
> Matt Mackall <mpm@...enic.com> wrote:
> 
> > But that re-opens the question of what to do about poor Jon's quest.
> >
> > I got confused halfway through as he went from using a global fasync
> > spinlock to a non-locked but atomic flag bit. Not sure why using a
> > per-file or per-inode lock doesn't work for the fasync code.
> 
> No per-file lock because (1) there is resistance to growing struct
> file, and (2) lockless algorithms are all the rage now.  Additionally,
> solving the fasync-atomicity problem with locks requires the use of a
> mutex (or the BKL) rather than a spinlock.  I suppose we could combine
> a global f_flags lock with the set-FASYNC-in-fasync_helper() bits.
> 
> At this point Poor Jon sees a fork in the road as he contemplates the
> future of his quest:
> 
> - Go with this patch set, perhaps with a bit of cleanup as suggested by
>   Andrew.
> 
> - Go back to the global lock.
> 
> - Go away, leave the BKL in place, and wait for somebody smarter to
>   attack the problem.

Well.  We _could_ whack part of this nut with my usual hammer: protect
f_flags with file->f_dentry->d_inode->i_lock.  IIRC there was some
objection to that - performance?

One problem here seems to be that we're trying to change multiple
things at the same time.  We can blame the BKL for that.

Can we break the problem into manageable chunks?  Your patchset did
that, I guess.  What were those chunks again? ;)
--
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/