From: Joerg Roedel <joerg.roedel@amd.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: Dave Jones <davej@redhat.com>, <tglx@linuxtronix.de>,
<mingo@redhat.com>, <hpa@zytor.com>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>
Subject: Re: [Bug 487894] New: sky2 0000:06:00.0: DMA-API: device driver frees DMA memory with different size
Date: Thu, 2 Apr 2009 12:54:15 +0200 [thread overview]
Message-ID: <20090402105415.GD21083@amd.com> (raw)
In-Reply-To: <20090401110245.4d1ddf72@nehalam>
On Wed, Apr 01, 2009 at 11:02:45AM -0700, Stephen Hemminger wrote:
>
> The sky2 driver uses pci_unmap_len and pci_unmap_len_set which on 32 bit
> platforms are meaningless so they are stubbed out.
> Basically, DMA-API checks are wrong/bogus to enforce on 32bit x86 as is.
As far as I know the VT-d driver is available on 32 bit x86 too. So this should
not always be a nop.
The other question is why pci_unmap_* functions are not defined as a nop too
and call dma_unmap_* instead? This looks inconsisent to me.
> ========================================================
> Unstub pci_unmap macros if doing DMA-API checks
>
> If doing device driver DMA-API tests then need to keep track of address/length
> even on 32-bit x86 where the information is not normally needed.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>
> --- a/arch/x86/include/asm/pci_32.h 2009-04-01 10:52:07.117504355 -0700
> +++ b/arch/x86/include/asm/pci_32.h 2009-04-01 10:56:02.249066174 -0700
> @@ -17,16 +17,25 @@ struct pci_dev;
> */
> #define PCI_DMA_BUS_IS_PHYS (1)
>
> +#ifdef CONFIG_DMA_API_DEBUG
> +/* keep real values */
> +#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) dma_addr_t ADDR_NAME;
> +#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) __u32 LEN_NAME;
> +#define pci_unmap_addr(PTR, ADDR_NAME) ((PTR)->ADDR_NAME)
> +#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) (((PTR)->ADDR_NAME) = (VAL))
> +#define pci_unmap_len(PTR, LEN_NAME) ((PTR)->LEN_NAME)
> +#define pci_unmap_len_set(PTR, LEN_NAME, VAL) (((PTR)->LEN_NAME) = (VAL))
> +#else
> /* pci_unmap_{page,single} is a nop so... */
> #define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) dma_addr_t ADDR_NAME[0];
> -#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) unsigned LEN_NAME[0];
> -#define pci_unmap_addr(PTR, ADDR_NAME) sizeof((PTR)->ADDR_NAME)
> +#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) __u32 LEN_NAME[0];
> +#define pci_unmap_addr(PTR, ADDR_NAME) sizeof((PTR)->ADDR_NAME)
> #define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) \
> do { break; } while (pci_unmap_addr(PTR, ADDR_NAME))
> #define pci_unmap_len(PTR, LEN_NAME) sizeof((PTR)->LEN_NAME)
> #define pci_unmap_len_set(PTR, LEN_NAME, VAL) \
> do { break; } while (pci_unmap_len(PTR, LEN_NAME))
> -
> +#endif
I think we need another solution which takes into account that there might be
VT-d enabled and which defines the pci_unmap_* functions also as a nop when it
is not. I suggest to make a CONFIG option for these functions nit being a nop
and let DMA_API_DEBUG select it on x86. So we get proper checking for drivers
on 32bit x86 too which helps other architectures where these drivers can be
used.
Joerg
--
| Advanced Micro Devices GmbH
Operating | Karl-Hammerschmidt-Str. 34, 85609 Dornach bei München
System |
Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
| Registergericht München, HRB Nr. 43632
next prev parent reply other threads:[~2009-04-02 10:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090401172708.GA11941@redhat.com>
2009-04-01 18:02 ` [Bug 487894] New: sky2 0000:06:00.0: DMA-API: device driver frees DMA memory with different size Stephen Hemminger
2009-04-02 10:54 ` Joerg Roedel [this message]
2009-04-02 11:06 ` FUJITA Tomonori
2009-04-02 11:18 ` Joerg Roedel
2009-04-02 14:03 ` FUJITA Tomonori
2009-04-02 14:31 ` Joerg Roedel
2009-04-02 15:08 ` Stephen Hemminger
2009-04-02 15:29 ` Joerg Roedel
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=20090402105415.GD21083@amd.com \
--to=joerg.roedel@amd.com \
--cc=davej@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=shemminger@vyatta.com \
--cc=tglx@linuxtronix.de \
--cc=x86@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.