* Re: [PATCH] ntfs: use page allocation for resident attribute inline data [not found] <20260422104627.8193-1-linkinjeon@kernel.org> @ 2026-04-22 12:55 ` Matthew Wilcox 2026-04-22 14:35 ` Namjae Jeon 2026-04-23 5:49 ` Christoph Hellwig 0 siblings, 2 replies; 6+ messages in thread From: Matthew Wilcox @ 2026-04-22 12:55 UTC (permalink / raw) To: Namjae Jeon Cc: hyc.lee, linux-fsdevel, Christian Brauner, Darrick J. Wong, linux-xfs, Gao Xiang On Wed, Apr 22, 2026 at 07:46:27PM +0900, Namjae Jeon wrote: > The current kmemdup() based allocation for IOMAP_INLINE can result in > inline_data pointer having a non-zero page offset. This causes > iomap_inline_data_valid() to fail the check: > > iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data) > > and triggers the kernel BUG at fs/iomap/buffered-io.c:1061. Hang on, hang on, hang on. First, maybe this check is too strict. I'm sure it's true for EROFS, but I don't see why it should be true for everybody. Perhaps we should delete this check or relax it? Second, why are you calling kmemdup() to begin with? This seems entirely pointless; the iomap code is going to call memcpy() on it. You're supposed to just be pointing into your data structures. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ntfs: use page allocation for resident attribute inline data 2026-04-22 12:55 ` [PATCH] ntfs: use page allocation for resident attribute inline data Matthew Wilcox @ 2026-04-22 14:35 ` Namjae Jeon 2026-04-22 15:28 ` Darrick J. Wong 2026-04-23 5:49 ` Christoph Hellwig 1 sibling, 1 reply; 6+ messages in thread From: Namjae Jeon @ 2026-04-22 14:35 UTC (permalink / raw) To: Matthew Wilcox Cc: hyc.lee, linux-fsdevel, Christian Brauner, Darrick J. Wong, linux-xfs, Gao Xiang On Wed, Apr 22, 2026 at 9:55 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Wed, Apr 22, 2026 at 07:46:27PM +0900, Namjae Jeon wrote: > > The current kmemdup() based allocation for IOMAP_INLINE can result in > > inline_data pointer having a non-zero page offset. This causes > > iomap_inline_data_valid() to fail the check: > > > > iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data) > > > > and triggers the kernel BUG at fs/iomap/buffered-io.c:1061. > > Hang on, hang on, hang on. > > First, maybe this check is too strict. I'm sure it's true for EROFS, > but I don't see why it should be true for everybody. Perhaps we should > delete this check or relax it? I agree that the current check might be unnecessarily strict for general cases. So I will prepare another patch to remove this trap for further discussion with iomap maintainers. > > Second, why are you calling kmemdup() to begin with? This seems > entirely pointless; the iomap code is going to call memcpy() on it. > You're supposed to just be pointing into your data structures. In the initial implementation of NTFS with iomap, I pointed directly to the internal data structures. However, I encountered this BUG_ON trap during testing, so I switched to page allocation to avoid it. Then, during the review process for the NTFS series, I changed it to kmemdup() without much thought. If this BUG_ON trap can be removed, I could have simply pointed to the internal data structures as you said. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ntfs: use page allocation for resident attribute inline data 2026-04-22 14:35 ` Namjae Jeon @ 2026-04-22 15:28 ` Darrick J. Wong 2026-04-22 15:36 ` Gao Xiang 0 siblings, 1 reply; 6+ messages in thread From: Darrick J. Wong @ 2026-04-22 15:28 UTC (permalink / raw) To: Namjae Jeon Cc: Matthew Wilcox, hyc.lee, linux-fsdevel, Christian Brauner, linux-xfs, Gao Xiang On Wed, Apr 22, 2026 at 11:35:32PM +0900, Namjae Jeon wrote: > On Wed, Apr 22, 2026 at 9:55 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > On Wed, Apr 22, 2026 at 07:46:27PM +0900, Namjae Jeon wrote: > > > The current kmemdup() based allocation for IOMAP_INLINE can result in > > > inline_data pointer having a non-zero page offset. This causes > > > iomap_inline_data_valid() to fail the check: > > > > > > iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data) > > > > > > and triggers the kernel BUG at fs/iomap/buffered-io.c:1061. > > > > Hang on, hang on, hang on. > > > > First, maybe this check is too strict. I'm sure it's true for EROFS, > > but I don't see why it should be true for everybody. Perhaps we should > > delete this check or relax it? > I agree that the current check might be unnecessarily strict for > general cases. So I will prepare another patch to remove this trap for > further discussion with iomap maintainers. > > > > Second, why are you calling kmemdup() to begin with? This seems > > entirely pointless; the iomap code is going to call memcpy() on it. > > You're supposed to just be pointing into your data structures. > In the initial implementation of NTFS with iomap, I pointed directly > to the internal data structures. However, I encountered this BUG_ON > trap during testing, so I switched to page allocation to avoid it. > Then, during the review process for the NTFS series, I changed it to > kmemdup() without much thought. If this BUG_ON trap can be removed, I > could have simply pointed to the internal data structures as you said. I think the check is wrong. We rely on the filesystem to point iomap::inline_data to kernel memory that is at least iomap::length bytes in size. If that crosses a PAGE_SIZE boundary that's fine, so long as the caller actually mapped that much memory. IOWs, if you have an iomap: {pos = 0, inline_data = 0xB0000, length = 32768, ...} then we trust that you really did map all of the MDA text mode memory and that memcpy'ing 100 bytes to pos 4090 is ok. (Perhaps this is a relic of the bs<=ps days?) --D ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ntfs: use page allocation for resident attribute inline data 2026-04-22 15:28 ` Darrick J. Wong @ 2026-04-22 15:36 ` Gao Xiang 2026-04-23 5:20 ` Namjae Jeon 0 siblings, 1 reply; 6+ messages in thread From: Gao Xiang @ 2026-04-22 15:36 UTC (permalink / raw) To: Darrick J. Wong, Namjae Jeon Cc: Matthew Wilcox, hyc.lee, linux-fsdevel, Christian Brauner, linux-xfs, Gao Xiang Hi, On 2026/4/22 23:28, Darrick J. Wong wrote: > On Wed, Apr 22, 2026 at 11:35:32PM +0900, Namjae Jeon wrote: >> On Wed, Apr 22, 2026 at 9:55 PM Matthew Wilcox <willy@infradead.org> wrote: >>> >>> On Wed, Apr 22, 2026 at 07:46:27PM +0900, Namjae Jeon wrote: >>>> The current kmemdup() based allocation for IOMAP_INLINE can result in >>>> inline_data pointer having a non-zero page offset. This causes >>>> iomap_inline_data_valid() to fail the check: >>>> >>>> iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data) >>>> >>>> and triggers the kernel BUG at fs/iomap/buffered-io.c:1061. >>> >>> Hang on, hang on, hang on. >>> >>> First, maybe this check is too strict. I'm sure it's true for EROFS, >>> but I don't see why it should be true for everybody. Perhaps we should >>> delete this check or relax it? >> I agree that the current check might be unnecessarily strict for >> general cases. So I will prepare another patch to remove this trap for >> further discussion with iomap maintainers. >>> >>> Second, why are you calling kmemdup() to begin with? This seems >>> entirely pointless; the iomap code is going to call memcpy() on it. >>> You're supposed to just be pointing into your data structures. >> In the initial implementation of NTFS with iomap, I pointed directly >> to the internal data structures. However, I encountered this BUG_ON >> trap during testing, so I switched to page allocation to avoid it. >> Then, during the review process for the NTFS series, I changed it to >> kmemdup() without much thought. If this BUG_ON trap can be removed, I >> could have simply pointed to the internal data structures as you said. > > I think the check is wrong. We rely on the filesystem to point > iomap::inline_data to kernel memory that is at least iomap::length bytes > in size. If that crosses a PAGE_SIZE boundary that's fine, so long as > the caller actually mapped that much memory. IOWs, if you have an > iomap: > > {pos = 0, inline_data = 0xB0000, length = 32768, ...} > > then we trust that you really did map all of the MDA text mode memory > and that memcpy'ing 100 bytes to pos 4090 is ok. > > (Perhaps this is a relic of the bs<=ps days?) Anyway, as said before, I think that particular assertion can be removed too. Thanks, Gao Xiang > > --D ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ntfs: use page allocation for resident attribute inline data 2026-04-22 15:36 ` Gao Xiang @ 2026-04-23 5:20 ` Namjae Jeon 0 siblings, 0 replies; 6+ messages in thread From: Namjae Jeon @ 2026-04-23 5:20 UTC (permalink / raw) To: Gao Xiang Cc: Darrick J. Wong, Matthew Wilcox, hyc.lee, linux-fsdevel, Christian Brauner, linux-xfs, Gao Xiang > > > > I think the check is wrong. We rely on the filesystem to point > > iomap::inline_data to kernel memory that is at least iomap::length bytes > > in size. If that crosses a PAGE_SIZE boundary that's fine, so long as > > the caller actually mapped that much memory. IOWs, if you have an > > iomap: > > > > {pos = 0, inline_data = 0xB0000, length = 32768, ...} > > > > then we trust that you really did map all of the MDA text mode memory > > and that memcpy'ing 100 bytes to pos 4090 is ok. > > > > (Perhaps this is a relic of the bs<=ps days?) > > Anyway, as said before, I think that particular assertion > can be removed too. Okay, I will submit the patch for this. Thanks! ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ntfs: use page allocation for resident attribute inline data 2026-04-22 12:55 ` [PATCH] ntfs: use page allocation for resident attribute inline data Matthew Wilcox 2026-04-22 14:35 ` Namjae Jeon @ 2026-04-23 5:49 ` Christoph Hellwig 1 sibling, 0 replies; 6+ messages in thread From: Christoph Hellwig @ 2026-04-23 5:49 UTC (permalink / raw) To: Matthew Wilcox Cc: Namjae Jeon, hyc.lee, linux-fsdevel, Christian Brauner, Darrick J. Wong, linux-xfs, Gao Xiang On Wed, Apr 22, 2026 at 01:55:40PM +0100, Matthew Wilcox wrote: > On Wed, Apr 22, 2026 at 07:46:27PM +0900, Namjae Jeon wrote: > > The current kmemdup() based allocation for IOMAP_INLINE can result in > > inline_data pointer having a non-zero page offset. This causes > > iomap_inline_data_valid() to fail the check: > > > > iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data) > > > > and triggers the kernel BUG at fs/iomap/buffered-io.c:1061. > > Hang on, hang on, hang on. > > First, maybe this check is too strict. I'm sure it's true for EROFS, > but I don't see why it should be true for everybody. Perhaps we should > delete this check or relax it? I think the current check should just go. ->iomap_inline_data is treated as a normal linear address everywhere, so any offset in page check is weird. > Second, why are you calling kmemdup() to begin with? This seems > entirely pointless; the iomap code is going to call memcpy() on it. > You're supposed to just be pointing into your data structures. Yes. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-04-23 5:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260422104627.8193-1-linkinjeon@kernel.org>
2026-04-22 12:55 ` [PATCH] ntfs: use page allocation for resident attribute inline data Matthew Wilcox
2026-04-22 14:35 ` Namjae Jeon
2026-04-22 15:28 ` Darrick J. Wong
2026-04-22 15:36 ` Gao Xiang
2026-04-23 5:20 ` Namjae Jeon
2026-04-23 5:49 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox