linux-kernel - Re: [fs] inode_lru_isolate(): Move counter increment into spinlock section

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: <alpine.DEB.2.10.1312201149410.13718@nuc>
Date:	Fri, 20 Dec 2013 11:52:36 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Dave Chinner <david@...morbit.com>
cc:	Dave Chinner <dchinner@...hat.com>, linux-kernel@...r.kernel.org,
	Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [fs] inode_lru_isolate(): Move counter increment into spinlock
 section

On Fri, 20 Dec 2013, Dave Chinner wrote:

> > Moving the code is IMHO the simplest solution. count_vm_events
> > will have to disable interrupts on platforms that do not support fast RMV
> > operations otherwise.
>
> If count_vm_events requires irqs to be disabled to behave correctly,
> then putting __count_vm_events under a spin lock is still not irq
> safe. Either way, this isn't in a performance critical path, so I'd
> much prefer the simpler, safer option be used rather than leave a
> landmine for other unsuspecting developers.

What we need is just preempt safeness. But there are no operations that
are just preempt safe and not interrupt safe (operations were removed
since seen as too excessive). So we fall back to interrupt
safe.

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