From: Christoph Hellwig <hch@lst.de>
To: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
Robin Murphy <robin.murphy@arm.com>,
Hannes Reinecke <hare@suse.de>,
Hamza Mahfooz <someguy@effective-light.com>,
Dan Williams <dan.j.williams@intel.com>,
linux-block@vger.kernel.org, io-uring@vger.kernel.org,
linux-raid@vger.kernel.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [Report] annoyed dma debug warning "cacheline tracking EEXIST, overlapping mappings aren't supported"
Date: Tue, 15 Oct 2024 09:54:18 +0200 [thread overview]
Message-ID: <20241015075418.GA25487@lst.de> (raw)
In-Reply-To: <Zw4camcCvclL4Q_6@fedora>
On Tue, Oct 15, 2024 at 03:40:26PM +0800, Ming Lei wrote:
> > Yes, active_cacheline_insert only complains for FROM_DEVICE or
> > BIDIRECTIONAL mappings. I can't see how raid 1 would trigger that
> > given that it only reads from one leg at a time.
> >
> > Ming, can you look a bit more into what is happening here?
>
> All should be READ IO which is FROM_DEVICE, please see my reply:
Yes, reads translate to DMA_FROM_DEVICE.
> https://lore.kernel.org/linux-block/Zw3MZrK_l7DuFfFd@fedora/
>
> And the raid1 warning is actually from raid1_sync_request().
In that case the warnings are perfectly valid because the I/O patterns
will create data corruption on non-coherent architectures. For direct
I/O from userspace the kernel can't prevent it, but for raid1 we should
be able to do something better. As raid1_sync_request is a convoluted
and undocumented mess I don't have a straigh shot answer to what it is
doing (wrong) and how to fix it unfortunately.
>
>
> Thanks,
> Ming
---end quoted text---
next prev parent reply other threads:[~2024-10-15 7:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 1:27 [Report] annoyed dma debug warning "cacheline tracking EEXIST, overlapping mappings aren't supported" Ming Lei
2024-10-14 7:23 ` Hannes Reinecke
2024-10-14 7:41 ` Christoph Hellwig
2024-10-14 7:58 ` Ming Lei
2024-10-14 18:09 ` Robin Murphy
2024-10-15 1:59 ` Ming Lei
2024-10-15 2:22 ` Dan Williams
2024-10-15 4:54 ` Christoph Hellwig
2024-10-15 7:40 ` Ming Lei
2024-10-15 7:54 ` Christoph Hellwig [this message]
2024-10-15 2:31 ` Ming Lei
2024-10-14 15:17 ` Jens Axboe
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=20241015075418.GA25487@lst.de \
--to=hch@lst.de \
--cc=dan.j.williams@intel.com \
--cc=hare@suse.de \
--cc=io-uring@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=robin.murphy@arm.com \
--cc=someguy@effective-light.com \
/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.