All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Wang <liwang@redhat.com>
To: akpm@linux-foundation.org, rppt@kernel.org, david@kernel.org,
	ljs@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org,
	surenb@google.com, mhocko@suse.com, shuah@kernel.org
Cc: aubaker@redhat.com, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3] selftests/mm: skip hugetlb_dio tests when DIO alignment is incompatible
Date: Mon, 30 Mar 2026 17:58:53 +0800	[thread overview]
Message-ID: <acpJXRokicaD5XC1@redhat.com> (raw)
In-Reply-To: <20260330053915.75442-1-liwang@redhat.com>


Reply to Sashiko:

> +	if (start_off % dio_align != 0 || writesize % dio_align != 0) {
> +		ksft_test_result_skip("DIO alignment (%u) incompatible with "
> +				"buf offset %u and writesize %zu\n",
> +				dio_align, start_off, writesize);
> +		return;
> +	}

> Does start_off represent the memory buffer alignment rather than the file
> offset alignment?

> If it represents the memory buffer offset within the page-aligned hugepage,
> should it be validated against stx_dio_mem_align instead of
> stx_dio_offset_align?

Hmm, I don't believe this unless you give me strong evidence here!

After looking though Filesystems for handling the direct IO process, I just
found that Btrfs does the buffer-address alignment check but it uses the
dio_offset_align rather than dio_mem_align.

And, the check_direct_IO() does not actually distinguish between the two
alignments in its fast-path check. It applies dio_offset_align uniformly
to pos, length, and buffer address.

Also, I tried the reproducer on Btrfs, ext2/3/4, xfs, vfat, ntfs, all get
passed with this patch. So I'd keep the patch not check for dio_mem_align.

-- 
Regards,
Li Wang


      parent reply	other threads:[~2026-03-30  9:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30  5:39 [PATCH v3] selftests/mm: skip hugetlb_dio tests when DIO alignment is incompatible Li Wang
2026-03-30  6:02 ` David Hildenbrand (Arm)
2026-03-30  7:23   ` Li Wang
2026-03-30 10:10     ` Li Wang
2026-03-30 10:43       ` David Hildenbrand (Arm)
2026-03-30 11:35         ` Li Wang
2026-03-30 11:57           ` Li Wang
2026-03-30  9:58 ` Li Wang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acpJXRokicaD5XC1@redhat.com \
    --to=liwang@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=aubaker@redhat.com \
    --cc=david@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.