linux-kernel - Re: [PATCH] mm: PageLRU can be non-atomic bit operation

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: <462D6FD3.2090805@yahoo.com.au>
Date:	Tue, 24 Apr 2007 12:47:47 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Hisashi Hifumi <hifumi.hisashi@....ntt.co.jp>
CC:	Hugh Dickins <hugh@...itas.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: PageLRU can be non-atomic bit operation

Hisashi Hifumi wrote:
> 
> At 22:42 07/04/23, Hugh Dickins wrote:
>  >On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
>  >> >No.  The PG_lru flag bit is just one bit amongst many others:
>  >> >what of concurrent operations changing other bits in that same
>  >> >unsigned long e.g. trying to lock the page by setting PG_locked?
>  >> >There are some places where such micro-optimizations can be made
>  >> >(typically while first allocating the page); but in general, no.
>  >>
>  >> In i386 and x86_64, btsl is used to change page flag. In this case, 
> if btsl
>  >> without lock prefix
>  >> set PG_locked and PG_lru flag concurrently, does only one operation
>  >> succeed ?
>  >
>  >That's right: on an SMP machine, without the lock prefix, the operation
>  >is no longer atomic: what's stored back may be missing the result of
>  >one or the other of the racing operations.
>  >
> 
> In the case that changing the same bit concurrently, lock prefix or other
> spinlock is needed. But, I think that concurrent bit operation on 
> different bits
> is just like OR operation , so lock prefix is not needed.
> 
> AMD instruction manual says about bts that ,
> 
> "Copies a bit, specified by bit index in a register or 8-bit immediate 
> value (second operand), from a bit
> string (first operand), also called the bit base, to the carry flag (CF) 
> of the rFLAGS register, and then
> sets the bit in the bit string to 1."
> 
> BTS instruction is read-modify-write instruction on bit unit. So 
> concurrent bit operation on different
> bits may be possible.


No matter what actual instruction is used, the SetPageLRU operation (ie.
without the double underscore prefix) must be atomic, and the __SetPageLRU
operation *can* be non-atomic if that would be faster.

As Hugh points out, we must have atomic ops here, so changing the generic
code to use the __ version is wrong. However if there is a faster way that
i386 can perform the atomic variant, then doing so will speed up the generic
code without breaking other architectures.

-- 
SUSE Labs, Novell Inc.
-
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/