From: Andi Kleen <ak@suse.de>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [BUG] x86_64 pci_map_sg modifies sg list - fails multiple map/unmaps
Date: 05 Jan 2004 21:58:24 +0100 [thread overview]
Message-ID: <p73fzeu15an.fsf@verdi.suse.de> (raw)
In-Reply-To: <2997092704.1073333041@aslan.btc.adaptec.com.suse.lists.linux.kernel>
"Justin T. Gibbs" <gibbs@scsiguy.com> writes:
> > "Justin T. Gibbs" <gibbs@scsiguy.com> writes:
> >
> >> Berkley Shands recently tripped over this problem. The 2.6.X pci_map_sg
> >> code for x86_64 modifies the passed in S/G list to compact it for mapping
> >> by the GART. This modification is not reversed when pci_unmap_sg is
> >> called. In the case of a retried SCSI command, this causes any attempt
> >
> > Qlogic has the same bug.
>
> Which bug is this? Not updating use_sg, or mapping the command the
> second time when it is retried? If the latter, I don't think this is an
> HBA bug. The HBA driver doesn't know that the command has been mapped in
> the past, so it will blindly map/unmap it again.
In some cases x86-64 pci_map_sg causes a BUG() when you pass it an already
mapped list. I've got reports of that happening with Qlogic.
I haven't analyzed it in detail, whether the mid layer or the driver
or someone else is to blame.
> ...
>
> >> DMA-API.txt doesn't seem to cover this issue.
> >
> > It does actually, but not very clearly. I've suggested changes of wording
> > recently to make this more clear, but it hasn't gotten in.
>
> Can you point to the section of the document you believe applies?
It documents that pci_map_sg rewrites the sg list and never guarantees
that the rewriting is undone on pci_unmap_sg.
> > You should never remap an already mapped sg list.
>
> But the sg list is no longer mapped. The HBA driver did call pci_unmap_sg
> on it. Did you mean to say, "Never map an sg list again that has been
> mapped in the past"?
Yep. While it would be in theory possible to reconstruct the list at
unmap time it would be extremly costly (require lots of uncached
memory access on x86-64) and is not done.
>
> > Either reuse the already mapped list or keep a copy of the original list
> > around. First is better because the later may have problems with the page
> > reference counts.
>
> The mid-layer doesn't map the list. The HBA drivers do. So you're saying
> that either the mid-layer or the HBA drivers need to copy the list so it
> can be restored just in case the command will be retried?
I'm just pointing out the requirements of pci_map_sg.
Either you can keep a flag around somewhere that says if the list is
mapped or not and skip the remapping and don't do a unmap in
between. Or copy and make sure the page reference counts are correctly
maintained. I'm not very intimate with the SCSI/block code so you
guys have to decide what is more convenient.
-Andi
next parent reply other threads:[~2004-01-05 20:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2938942704.1073325455@aslan.btc.adaptec.com.suse.lists.linux.kernel>
[not found] ` <m3brpi41q0.fsf@averell.firstfloor.org.suse.lists.linux.kernel>
[not found] ` <2997092704.1073333041@aslan.btc.adaptec.com.suse.lists.linux.kernel>
2004-01-05 20:58 ` Andi Kleen [this message]
2004-01-07 16:33 [BUG] x86_64 pci_map_sg modifies sg list - fails multiple map/unmaps Berkley Shands
-- strict thread matches above, loose matches on Subject: below --
2004-01-07 15:35 Berkley Shands
2004-01-07 19:19 ` badari
[not found] <200401051929.i05JTsM0000014248@mudpuddle.cs.wustl.edu.suse.lists.linux.kernel>
[not found] ` <20040105112800.7a9f240b.davem@redhat.com.suse.lists.linux.kernel>
2004-01-05 21:02 ` Andi Kleen
2004-01-05 21:01 ` David S. Miller
2004-01-05 21:31 ` Andi Kleen
2004-01-06 0:05 ` James Bottomley
2004-01-06 3:06 ` Andi Kleen
2004-01-06 3:04 ` David S. Miller
2004-01-06 3:14 ` James Bottomley
2004-01-05 20:00 Berkley Shands
2004-01-05 19:29 Berkley Shands
2004-01-05 19:28 ` David S. Miller
2004-01-05 17:57 Justin T. Gibbs
2004-01-05 19:22 ` David S. Miller
2004-01-05 19:41 ` Badari Pulavarty
2004-01-05 19:47 ` Andi Kleen
2004-01-05 20:04 ` Justin T. Gibbs
2004-01-05 20:35 ` David S. Miller
2004-01-05 21:10 ` Andi Kleen
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=p73fzeu15an.fsf@verdi.suse.de \
--to=ak@suse.de \
--cc=gibbs@scsiguy.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox