From: Xi Wang <xi.wang@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kukjin Kim <kgene.kim@samsung.com>,
Thomas Dahlmann <dahlmann.thomas@arcor.de>,
Felipe Balbi <balbi@ti.com>, Krzysztof Halasa <khc@pm.waw.pl>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2] mm: fix null dev in dma_pool_create()
Date: Wed, 14 Nov 2012 00:50:53 -0500 [thread overview]
Message-ID: <50A3313D.1000809@gmail.com> (raw)
In-Reply-To: <20121113165847.4dcf968c.akpm@linux-foundation.org>
On 11/13/12 7:58 PM, Andrew Morton wrote:
> I'm not sure that I really suggested doing this :(
You suggested WARN_ON_ONCE(!dev); I changed it to WARN_ON(!dev) and
kept the NULL check..
> We know there are a few scruffy drivers which are passing in dev==0.
>
> Those drivers don't oops because nobody is testing them on NUMA
> systems.
>
> With this patch, the kernel will now cause runtime warnings to be
> emitted from those drivers. Even on non-NUMA systems.
>
> This is a problem! What will happen is that this code will get
> released by Linus and will propagate to users mainly via distros and
> eventually end-user bug reports will trickle back saying "hey, I got
> this warning". Slowly people will fix the scruffy drivers and those
> fixes will propagate out from Linus's tree into -stable and then into
> distros and then into the end-users hands.
>
> This is *terribly* inefficient! It's a lot of work for a lot of people
> and it involves long delays.
>
> So let's not do any of that! Let us try to get those scruffy drivers
> fixed up *before* we add this warning.
>
> As a nice side-effect of that work, we can then clean up the dmapool
> code so it doesn't need to worry about handling the dev==0 special
> case.
>
> So. To start this off, can you please generate a list of the offending
> drivers? Then we can hunt down the maintainers and we'll see what can be
> done.
I like this plan.
Here's the list of drivers that invoke dma_pool_create() with NULL dev,
as well as possible fixes, from previous emails.
* arch/arm/mach-s3c64xx/dma.c
Use dmac->dev for dma_pool_create() in s3c64xx_dma_init1()? Probably
need to add ->dma_pool to struct s3c64xx_dmac.
* drivers/usb/gadget/amd5536udc.c (2)
Use dev->gadget.dev or dev->pdev->dev for dma_pool_create()? Also move
the init_dma_pools() call after the assignments in udc_pci_probe().
* drivers/net/wan/ixp4xx_hss.c
* drivers/net/ethernet/xscale/ixp4xx_eth.c
Use port->netdev->dev for dma_pool_create()?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Xi Wang <xi.wang@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kukjin Kim <kgene.kim@samsung.com>,
Thomas Dahlmann <dahlmann.thomas@arcor.de>,
Felipe Balbi <balbi@ti.com>, Krzysztof Halasa <khc@pm.waw.pl>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2] mm: fix null dev in dma_pool_create()
Date: Wed, 14 Nov 2012 00:50:53 -0500 [thread overview]
Message-ID: <50A3313D.1000809@gmail.com> (raw)
In-Reply-To: <20121113165847.4dcf968c.akpm@linux-foundation.org>
On 11/13/12 7:58 PM, Andrew Morton wrote:
> I'm not sure that I really suggested doing this :(
You suggested WARN_ON_ONCE(!dev); I changed it to WARN_ON(!dev) and
kept the NULL check..
> We know there are a few scruffy drivers which are passing in dev==0.
>
> Those drivers don't oops because nobody is testing them on NUMA
> systems.
>
> With this patch, the kernel will now cause runtime warnings to be
> emitted from those drivers. Even on non-NUMA systems.
>
> This is a problem! What will happen is that this code will get
> released by Linus and will propagate to users mainly via distros and
> eventually end-user bug reports will trickle back saying "hey, I got
> this warning". Slowly people will fix the scruffy drivers and those
> fixes will propagate out from Linus's tree into -stable and then into
> distros and then into the end-users hands.
>
> This is *terribly* inefficient! It's a lot of work for a lot of people
> and it involves long delays.
>
> So let's not do any of that! Let us try to get those scruffy drivers
> fixed up *before* we add this warning.
>
> As a nice side-effect of that work, we can then clean up the dmapool
> code so it doesn't need to worry about handling the dev==0 special
> case.
>
> So. To start this off, can you please generate a list of the offending
> drivers? Then we can hunt down the maintainers and we'll see what can be
> done.
I like this plan.
Here's the list of drivers that invoke dma_pool_create() with NULL dev,
as well as possible fixes, from previous emails.
* arch/arm/mach-s3c64xx/dma.c
Use dmac->dev for dma_pool_create() in s3c64xx_dma_init1()? Probably
need to add ->dma_pool to struct s3c64xx_dmac.
* drivers/usb/gadget/amd5536udc.c (2)
Use dev->gadget.dev or dev->pdev->dev for dma_pool_create()? Also move
the init_dma_pools() call after the assignments in udc_pci_probe().
* drivers/net/wan/ixp4xx_hss.c
* drivers/net/ethernet/xscale/ixp4xx_eth.c
Use port->netdev->dev for dma_pool_create()?
next prev parent reply other threads:[~2012-11-14 5:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 6:46 [PATCH] mm: fix NULL checking in dma_pool_create() Xi Wang
2012-11-05 6:46 ` Xi Wang
2012-11-05 20:37 ` Andrew Morton
2012-11-05 20:37 ` Andrew Morton
2012-11-05 20:50 ` Xi Wang
2012-11-05 20:50 ` Xi Wang
2012-11-05 21:26 ` Andrew Morton
2012-11-05 21:26 ` Andrew Morton
2012-11-06 20:48 ` Xi Wang
2012-11-06 20:48 ` Xi Wang
2012-11-13 21:39 ` [PATCH v2] mm: fix null dev " Xi Wang
2012-11-13 21:39 ` Xi Wang
2012-11-13 23:01 ` David Rientjes
2012-11-13 23:01 ` David Rientjes
2012-11-14 0:47 ` Andrew Morton
2012-11-14 0:47 ` Andrew Morton
2012-11-14 0:58 ` Andrew Morton
2012-11-14 0:58 ` Andrew Morton
2012-11-14 5:50 ` Xi Wang [this message]
2012-11-14 5:50 ` Xi Wang
2012-11-14 14:17 ` Felipe Balbi
2012-11-14 14:17 ` Felipe Balbi
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=50A3313D.1000809@gmail.com \
--to=xi.wang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=balbi@ti.com \
--cc=dahlmann.thomas@arcor.de \
--cc=gregkh@linuxfoundation.org \
--cc=kgene.kim@samsung.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.