linux-kernel - Re: gpio-ml-ioh: Support interrupt function

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Oct 2011 22:56:15 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Tomoya MORINAGA <tomoya-linux@....lapis-semi.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

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.
--
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/