Commit 1a35ca80 authored by Eric Dumazet's avatar Eric Dumazet Committed by David S. Miller

packet: dont call sleeping functions while holding rcu_read_lock()

commit 654d1f8a (packet: less dev_put() calls)
introduced a problem, calling potentially sleeping functions from a
rcu_read_lock() protected section.

Fix this by releasing lock before the sock_wmalloc()/memcpy_fromiovec() calls.

After skb allocation and copy from user space, we redo device
lookup and appropriate tests.
Reported-and-tested-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 81e839ef
...@@ -415,7 +415,7 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock, ...@@ -415,7 +415,7 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock,
{ {
struct sock *sk = sock->sk; struct sock *sk = sock->sk;
struct sockaddr_pkt *saddr = (struct sockaddr_pkt *)msg->msg_name; struct sockaddr_pkt *saddr = (struct sockaddr_pkt *)msg->msg_name;
struct sk_buff *skb; struct sk_buff *skb = NULL;
struct net_device *dev; struct net_device *dev;
__be16 proto = 0; __be16 proto = 0;
int err; int err;
...@@ -437,6 +437,7 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock, ...@@ -437,6 +437,7 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock,
*/ */
saddr->spkt_device[13] = 0; saddr->spkt_device[13] = 0;
retry:
rcu_read_lock(); rcu_read_lock();
dev = dev_get_by_name_rcu(sock_net(sk), saddr->spkt_device); dev = dev_get_by_name_rcu(sock_net(sk), saddr->spkt_device);
err = -ENODEV; err = -ENODEV;
...@@ -456,58 +457,48 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock, ...@@ -456,58 +457,48 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock,
if (len > dev->mtu + dev->hard_header_len) if (len > dev->mtu + dev->hard_header_len)
goto out_unlock; goto out_unlock;
err = -ENOBUFS; if (!skb) {
skb = sock_wmalloc(sk, len + LL_RESERVED_SPACE(dev), 0, GFP_KERNEL); size_t reserved = LL_RESERVED_SPACE(dev);
unsigned int hhlen = dev->header_ops ? dev->hard_header_len : 0;
/*
* If the write buffer is full, then tough. At this level the user rcu_read_unlock();
* gets to deal with the problem - do your own algorithmic backoffs. skb = sock_wmalloc(sk, len + reserved, 0, GFP_KERNEL);
* That's far more flexible. if (skb == NULL)
*/ return -ENOBUFS;
/* FIXME: Save some space for broken drivers that write a hard
if (skb == NULL) * header at transmission time by themselves. PPP is the notable
goto out_unlock; * one here. This should really be fixed at the driver level.
*/
/* skb_reserve(skb, reserved);
* Fill it in skb_reset_network_header(skb);
*/
/* Try to align data part correctly */
/* FIXME: Save some space for broken drivers that write a if (hhlen) {
* hard header at transmission time by themselves. PPP is the skb->data -= hhlen;
* notable one here. This should really be fixed at the driver level. skb->tail -= hhlen;
*/ if (len < hhlen)
skb_reserve(skb, LL_RESERVED_SPACE(dev)); skb_reset_network_header(skb);
skb_reset_network_header(skb); }
err = memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len);
/* Try to align data part correctly */ if (err)
if (dev->header_ops) { goto out_free;
skb->data -= dev->hard_header_len; goto retry;
skb->tail -= dev->hard_header_len;
if (len < dev->hard_header_len)
skb_reset_network_header(skb);
} }
/* Returns -EFAULT on error */
err = memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len);
skb->protocol = proto; skb->protocol = proto;
skb->dev = dev; skb->dev = dev;
skb->priority = sk->sk_priority; skb->priority = sk->sk_priority;
skb->mark = sk->sk_mark; skb->mark = sk->sk_mark;
if (err)
goto out_free;
/*
* Now send it
*/
dev_queue_xmit(skb); dev_queue_xmit(skb);
rcu_read_unlock(); rcu_read_unlock();
return len; return len;
out_free:
kfree_skb(skb);
out_unlock: out_unlock:
rcu_read_unlock(); rcu_read_unlock();
out_free:
kfree_skb(skb);
return err; return err;
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment