On Fri, 20 Dec 2013, Dave Chinner wrote:
> 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
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 puttin
On Thu, Dec 19, 2013 at 09:26:12AM -0600, Christoph Lameter wrote:
> On Thu, 19 Dec 2013, Dave Chinner wrote:
>
> > On Wed, Dec 18, 2013 at 07:24:46PM +, Christoph Lameter wrote:
> > > The counter increment in inode_lru_isolate is happening after
> > > spinlocks have been dropped with preempti
On Thu, 19 Dec 2013, Dave Chinner wrote:
> On Wed, Dec 18, 2013 at 07:24:46PM +, Christoph Lameter wrote:
> > The counter increment in inode_lru_isolate is happening after
> > spinlocks have been dropped with preemption on using __count_vm_events
> > making counter increment races possible.
>
On Wed, Dec 18, 2013 at 07:24:46PM +, Christoph Lameter wrote:
> The counter increment in inode_lru_isolate is happening after
> spinlocks have been dropped with preemption on using __count_vm_events
> making counter increment races possible.
That's a nasty, undocumented problem that __count_v
The counter increment in inode_lru_isolate is happening after
spinlocks have been dropped with preemption on using __count_vm_events
making counter increment races possible.
Move the counter increments to be done when the spinlock is
reacquired later so that the counter can be safely incremented.
6 matches
Mail list logo