Locking and especilly control flow in fs/eventpoll.c is
overcomplicated. As the result, the code has been hard to follow
and easy to fuck up while modifying.
The following series attempts to untangle it; there's more to be done
there, but this should take care of some of the obfus
On Sun, Oct 04, 2020 at 03:36:08AM +0100, Al Viro wrote:
> Locking and especilly control flow in fs/eventpoll.c is
> overcomplicated. As the result, the code has been hard to follow
> and easy to fuck up while modifying.
>
> The following series attempts to untangle it; there's more t
On Sun, Oct 04, 2020 at 03:36:08AM +0100, Al Viro wrote:
> Finally, there's the mess with reverse path check. When we insert
> a new file into a epoll, we need to check that there won't be excessively long
> (or excessively many) wakeup chains. If the target is not an epoll, we need
> to ch
On Sun, Oct 04, 2020 at 01:13:29PM +0100, Matthew Wilcox wrote:
> Have you considered just storing a pointer to each struct file in an
> epoll set in an XArray? Linked lists suck for modern CPUs, and there'd
> be no need to store any additional data in each struct file. Using
> xa_alloc() to sto
On Sat, Oct 3, 2020 at 7:36 PM Al Viro wrote:
>
> Locking and especially control flow in fs/eventpoll.c is
> overcomplicated. As the result, the code has been hard to follow
> and easy to fuck up while modifying.
Scanning through the patches they all look superficially ok to me, but
I'm
On Sun, Oct 04, 2020 at 11:08:11AM -0700, Linus Torvalds wrote:
> On Sat, Oct 3, 2020 at 7:36 PM Al Viro wrote:
> >
> > Locking and especially control flow in fs/eventpoll.c is
> > overcomplicated. As the result, the code has been hard to follow
> > and easy to fuck up while modifying.
>
6 matches
Mail list logo