[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874j4w4o1f.ffs@tglx>
Date: Mon, 28 Oct 2024 09:41:48 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Hugh Dickins <hughd@...gle.com>, Alexander Viro <viro@...iv.linux.org.uk>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Christian Brauner
<brauner@...nel.org>, Matthew Wilcox <willy@...radead.org>, Christoph
Hellwig <hch@....de>, Kent Overstreet <kent.overstreet@...ux.dev>,
"Darrick J. Wong" <djwong@...nel.org>, Peter Zijlstra
<peterz@...radead.org>, linux-fsdevel@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Linus Torvalds <torvalds@...uxfoundation.org>
Subject: Re: [PATCH] iov_iter: fix copy_page_from_iter_atomic() if
KMAP_LOCAL_FORCE_MAP
On Sun, Oct 27 2024 at 15:23, Hugh Dickins wrote:
> generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem,
> on huge=always tmpfs, issues a warning and then hangs (interruptibly):
>
> WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9
> CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2
> ...
> copy_page_from_iter_atomic+0xa6/0x5ec
> generic_perform_write+0xf6/0x1b4
> shmem_file_write_iter+0x54/0x67
>
> Fix copy_page_from_iter_atomic() by limiting it in that case
> (include/linux/skbuff.h skb_frag_must_loop() does similar).
>
> But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too
> surprising, has outlived its usefulness, and should just be removed?
It has caught real problems and as long as we have highmem support, it
should stay IMO to provide test coverage.
Thanks,
tglx
Powered by blists - more mailing lists