forked from luck/tmp_suning_uos_patched
net/rose: Use GFP_ATOMIC
The other calls to kmalloc in the same function use GFP_ATOMIC, and indeed two locks are held within the body of the function. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier f; @@ *f(...,GFP_ATOMIC,...) ... when != spin_unlock(...) when != read_unlock(...) when != write_unlock(...) when != read_unlock_irq(...) when != write_unlock_irq(...) when != read_unlock_irqrestore(...) when != write_unlock_irqrestore(...) when != spin_unlock_irq(...) when != spin_unlock_irqrestore(...) *f(...,GFP_KERNEL,...) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
parent
0fc48c37ff
commit
e2e0c7c9dd
|
@ -109,7 +109,9 @@ static int __must_check rose_add_node(struct rose_route_struct *rose_route,
|
|||
init_timer(&rose_neigh->t0timer);
|
||||
|
||||
if (rose_route->ndigis != 0) {
|
||||
if ((rose_neigh->digipeat = kmalloc(sizeof(ax25_digi), GFP_KERNEL)) == NULL) {
|
||||
rose_neigh->digipeat =
|
||||
kmalloc(sizeof(ax25_digi), GFP_ATOMIC);
|
||||
if (rose_neigh->digipeat == NULL) {
|
||||
kfree(rose_neigh);
|
||||
res = -ENOMEM;
|
||||
goto out;
|
||||
|
|
Loading…
Reference in New Issue
Block a user