Re: [PATCH] ntfs: use page allocation for resident attribute inline data

Namjae Jeon
2026-04-22T14:35:46Z

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.