All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Michael Kelley <mhklinux@outlook.com>
Cc: Will Deacon <will@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Petr Tesarik <petr.tesarik1@huawei-partners.com>,
	"kernel-team@android.com" <kernel-team@android.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Dexuan Cui <decui@microsoft.com>,
	Nicolin Chen <nicolinc@nvidia.com>
Subject: Re: [PATCH v5 6/6] swiotlb: Remove pointless stride adjustment for allocations >= PAGE_SIZE
Date: Thu, 29 Feb 2024 14:33:46 +0100	[thread overview]
Message-ID: <20240229133346.GA7177@lst.de> (raw)
In-Reply-To: <SN6PR02MB41577D09E97B1D9645369D58D45F2@SN6PR02MB4157.namprd02.prod.outlook.com>

On Thu, Feb 29, 2024 at 07:36:05AM +0000, Michael Kelley wrote:
> If there *is* a requirement for page alignment of page-size-or-greater
> requests, even when alloc_align_mask and min_align_mask are zero,
> we need to think about how to do that correctly, as that requirement
> is no longer met after Patch 1 of this series.

It has been historical behavior that all dma allocations are page
aligned (including in fact smaller than page sized ones that get
rounded up to a page size).  The documentation actually (incorretly)
states an even stronger guarantee:

"The CPU virtual address and the DMA address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size.  This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary."


  reply	other threads:[~2024-02-29 13:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-28 13:39 [PATCH v5 0/6] Fix double allocation in swiotlb_alloc() Will Deacon
2024-02-28 13:39 ` [PATCH v5 1/6] swiotlb: Fix double-allocation of slots due to broken alignment handling Will Deacon
2024-02-29  5:44   ` Michael Kelley
2024-02-28 13:39 ` [PATCH v5 2/6] swiotlb: Enforce page alignment in swiotlb_alloc() Will Deacon
2024-02-28 13:39 ` [PATCH v5 3/6] swiotlb: Honour dma_alloc_coherent() " Will Deacon
2024-02-28 13:39 ` [PATCH v5 4/6] swiotlb: Fix alignment checks when both allocation and DMA masks are present Will Deacon
2024-02-28 13:39 ` [PATCH v5 5/6] iommu/dma: Force swiotlb_max_mapping_size on an untrusted device Will Deacon
2024-02-29  5:57   ` Michael Kelley
2024-02-28 13:39 ` [PATCH v5 6/6] swiotlb: Remove pointless stride adjustment for allocations >= PAGE_SIZE Will Deacon
2024-02-29  6:07   ` Michael Kelley
2024-02-29  7:36     ` Michael Kelley
2024-02-29 13:33       ` Christoph Hellwig [this message]
2024-02-29 15:44         ` Michael Kelley
2024-02-29 15:47           ` Christoph Hellwig
2024-03-01 15:39             ` Petr Tesařík
2024-03-01 16:38               ` Robin Murphy
2024-03-01 17:33                 ` Petr Tesařík
2024-03-01 17:08               ` Petr Tesařík
2024-03-01 17:54                 ` Robin Murphy
2024-03-01 18:42                   ` Petr Tesařík
2024-03-04  3:31                     ` Michael Kelley
2024-03-04 11:00                       ` Petr Tesařík
2024-03-04 13:37                         ` Robin Murphy
2024-03-04 15:55                           ` Petr Tesařík
2024-03-04 16:02                             ` Will Deacon
2024-03-04 16:10                               ` Michael Kelley
2024-03-04 16:53                                 ` Robin Murphy
2024-03-04 18:22                                   ` Michael Kelley
2024-03-05 11:20                                     ` Robin Murphy
2024-03-05 15:15                                       ` Petr Tesařík
2024-03-04 19:04                                 ` Petr Tesařík
2024-03-05 14:08                                   ` Christoph Hellwig
2024-03-04 16:04                             ` Michael Kelley
2024-03-04 17:11                               ` Robin Murphy
2024-03-04 18:08                                 ` Michael Kelley
2024-03-05 14:05                           ` Christoph Hellwig
2024-03-04 15:32     ` Will Deacon

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=20240229133346.GA7177@lst.de \
    --to=hch@lst.de \
    --cc=decui@microsoft.com \
    --cc=iommu@lists.linux.dev \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mhklinux@outlook.com \
    --cc=nicolinc@nvidia.com \
    --cc=petr.tesarik1@huawei-partners.com \
    --cc=robin.murphy@arm.com \
    --cc=will@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.