| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <BANLkTim9YdhjY75CzMsSOCVKZWi-WKZ5wA@mail.gmail.com> Date: Sun, 29 May 2011 12:36:39 +0400 From: Dmitry Eremin-Solenikov <dbaryshkov@...il.com> To: David Rientjes <rientjes@...gle.com> Cc: Nicolas Pitre <nicolas.pitre@...aro.org>, Russell King <rmk+kernel@....linux.org.uk>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, linux-kernel <linux-kernel@...r.kernel.org>, Eric Miao <eric.y.miao@...il.com>, Samuel Ortiz <samuel@...tiz.org> Subject: Re: IrDA driver fails on PXA255 Hello, On Sun, May 29, 2011 at 3:34 AM, David Rientjes <rientjes@...gle.com> wrote: > On Sun, 29 May 2011, Dmitry Eremin-Solenikov wrote: > >> Hello, >> >> Since a197b59ae6e8bee56fcef37ea2482dc08414e2ac (mm: fail GFP_DMA >> allocations when ZONE_DMA is not configured), pxaficp_ir.c driver fails >> to probe: pxa_irda_init_iobuf asks for a buffer with GFP_KERNEL | >> GFP_DMA flags, which fail nicely with the following trace: >> >> ------------[ cut here ]------------ >> WARNING: at mm/page_alloc.c:2251 >> __alloc_pages_nodemask+0xa0/0x5ac() >> Modules linked in: >> [<c00385b0>] (unwind_backtrace+0x0/0xf0) from [<c0050b1c>] (warn_slowpath_common+0x4c/0x64) >> [<c0050b1c>] (warn_slowpath_common+0x4c/0x64) from [<c0050b4c>] (warn_slowpath_null+0x18/0x1c) >> [<c0050b4c>] (warn_slowpath_null+0x18/0x1c) from [<c00908ec>] (__alloc_pages_nodemask+0xa0/0x5ac) >> [<c00908ec>] (__alloc_pages_nodemask+0xa0/0x5ac) from [<c0090e74>] (__get_free_pages+0x10/0x3c) >> [<c0090e74>] (__get_free_pages+0x10/0x3c) from [<c01d608c>] (pxa_irda_init_iobuf+0x18/0x48) >> [<c01d608c>] (pxa_irda_init_iobuf+0x18/0x48) from [<c01d61d8>] (pxa_irda_probe+0x11c/0x32c) >> [<c01d61d8>] (pxa_irda_probe+0x11c/0x32c) from [<c019474c>] (platform_drv_probe+0x14/0x18) >> [<c019474c>] (platform_drv_probe+0x14/0x18) from [<c0193508>] (really_probe+0xa0/0x158) >> [<c0193508>] (really_probe+0xa0/0x158) from [<c019360c>] (driver_probe_device+0x4c/0x64) >> [<c019360c>] (driver_probe_device+0x4c/0x64) from [<c0193684>] (__driver_attach+0x60/0x84) >> [<c0193684>] (__driver_attach+0x60/0x84) from [<c0192d78>] (bus_for_each_dev+0x48/0x84) >> [<c0192d78>] (bus_for_each_dev+0x48/0x84) from [<c01926b8>] (bus_add_driver+0xa8/0x220) >> [<c01926b8>] (bus_add_driver+0xa8/0x220) from [<c0193c7c>] (driver_register+0xac/0x13c) >> [<c0193c7c>] (driver_register+0xac/0x13c) from [<c0033440>] (do_one_initcall+0x94/0x16c) >> [<c0033440>] (do_one_initcall+0x94/0x16c) from [<c00083f4>] (kernel_init+0x94/0x140) >> [<c00083f4>] (kernel_init+0x94/0x140) from [<c00348d0>] (kernel_thread_exit+0x0/0x8) >> ---[ end trace 0b8bf08f70147098 ]--- >> > > The driver is attempting to allocate DMA memory and you have > CONFIG_ZONE_DMA disabled, which is the only reason you would get this > warning. If the allocation did not fail as a result of a197b59ae6e8, the > page allocator may return any memory in a higher zone that the driver may > not be expecting. If you had never noticed a problem before, it may be > possible that the driver doesn't actually have any zone restrictions and > GFP_DMA can be removed, but this code is pretty old. Otherwise, it'll > need to depend on ZONE_DMA in the Kconfig. What about changing your patch for less intrusive one (to emit a WARN_ON) for at least one or two major releases and only then changing it back to the current state? -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists