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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4E9D6D27.8030501@dsn.lapis-semi.com>
Date:	Tue, 18 Oct 2011 21:12:23 +0900
From:	Tomoya MORINAGA <tomoya-linux@....lapis-semi.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Dan Carpenter <dan.carpenter@...cle.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Tomoya MORINAGA <tomoya-linux@....okisemi.com>,
	linux-kernel@...r.kernel.org
Subject: Re: gpio-ml-ioh: Support interrupt function

(2011/10/18 14:56), David Rientjes wrote:
> On Tue, 18 Oct 2011, Tomoya MORINAGA wrote:
>
>>> The linux-next patch 54be566317b6 "gpio-ml-ioh: Support interrupt
>>> function" generates a Sparse warning.
>>>
>>> +               irq_base = irq_alloc_descs(-1, IOH_IRQ_BASE, num_ports[j],
>>> +                                          GFP_KERNEL);
>>>                                              ^^^^^^^^^^
>>>
>>> The last argument should be a NUMA node, not a GFP_ flag.  I'm not
>>> sure what the right fix is.  There are currently 5 callers in my
>>> cscope for this function in linux-next.
>>>
>>> 2 pass GFP_KERNEL which is wrong.
>
> Right, all irq_alloc_descs() allocations are already implicitly
> GFP_KERNEL.
>
>>> 2 pass 0 which maybe should be cpu_to_node(0)?
>>> 1 passes -1 which maybe could be NUMA_NO_NODE?
>>>
>> I can understand your saying.
>> Seeing accepted other drivers, '0' or '-1' is used.
>
> There's actually no guarantee in the kernel that node 0 has memory, so
> unless that is assured in the context then passing 0 would be wrong.
>
>> Focusing on GPIO driver, gpio-pca953x.c uses '-1'.
>>
>
> The slab layer guarantees that passing -1 will allocate on the node that
> is local to the cpu that the code is running on.  Unless there's a
> compelling reason to allocate on a different node, then this is what you
> want to use.
>
> We try not to pass -1 directly, though, we try to use NUMA_NO_NODE
> wherever possible.
> --

Using NUMA_NO_NODE, I confirmed our gpio(gpio-pch) works well.
I will submit the patch both gpio-pch and gpio-ml-ioh soon.

thanks,
-- 
tomoya
ROHM Co., Ltd.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ