Hi,
On 5/25/22 07:48, Amadeusz Sławiński wrote:
As per asm-generic definition and other architectures __fls should
return unsigned long.
No functional change is expected as return value should fit in unsigned
long.
Signed-off-by: Amadeusz Sławiński
Applied to for-curr.
Thx,
-Vineet
On 5/24/22 16:45, Peter Xu wrote:
I observed that for each of the shared file-backed page faults, we're very
likely to retry one more time for the 1st write fault upon no page. It's
because we'll need to release the mmap lock for dirty rate limit purpose
with
Hi Linus,
Please pull.
Thx,
-Vineet
--->
The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b:
Linux 5.18-rc4 (2022-04-24 14:51:22 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/
As per asm-generic definition and other architectures __fls should
return unsigned long.
No functional change is expected as return value should fit in unsigned
long.
Signed-off-by: Amadeusz Sławiński
---
arch/arc/include/asm/bitops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Apparently on few architectures __fls is defined incorrectly. Fix this
by adjusting declarations to asm-generic ones.
As far as I can tell there should be no functional changes, but I don't
have devices to test it, so it was only compile tested.
Amadeusz Sławiński (2):
ARC: bitops: Change
As per asm-generic definition and other architectures __fls should
return and accept unsigned long as its parameter.
Signed-off-by: Amadeusz Sławiński
---
arch/m68k/include/asm/bitops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/include/asm/bitops.h
On Tue, May 24, 2022 at 07:45:31PM -0400, Peter Xu wrote:
> I observed that for each of the shared file-backed page faults, we're very
> likely to retry one more time for the 1st write fault upon no page. It's
> because we'll need to release the mmap lock for dirty rate limit purpose
> with
On Tue, May 24, 2022 at 07:45:31PM -0400, Peter Xu wrote:
> I observed that for each of the shared file-backed page faults, we're very
> likely to retry one more time for the 1st write fault upon no page. It's
> because we'll need to release the mmap lock for dirty rate limit purpose
> with
On Wed, May 25, 2022 at 1:45 AM Peter Xu wrote:
> I observed that for each of the shared file-backed page faults, we're very
> likely to retry one more time for the 1st write fault upon no page. It's
> because we'll need to release the mmap lock for dirty rate limit purpose
> with
