| Message ID | 200904181804.AHC13042.VHFFOOJOFLSQMt@I-love.SAKURA.ne.jp |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Sat, 18 Apr 2009 18:04:24 +0900 > If it is harmful to call lock_sock() for protocols which don't > support global socket memory accounting, I need to make > lock_sock(sk);/release_ sock(sk); calls conditional. Great, more complexity in the kernel for the sake of TOMOYO :-( -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller wrote: > > If it is harmful to call lock_sock() for protocols which don't > > support global socket memory accounting, I need to make > > lock_sock(sk);/release_ sock(sk); calls conditional. > > Great, more complexity in the kernel for the sake of TOMOYO > :-( > You meant that I should leave lock_sock(sk);/release_sock(sk); calls unconditional? This error path is not frequently called. If there are no problems but performance, I'll leave them unconditional. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Sat, 18 Apr 2009 21:23:35 +0900 > David Miller wrote: >> > If it is harmful to call lock_sock() for protocols which don't >> > support global socket memory accounting, I need to make >> > lock_sock(sk);/release_ sock(sk); calls conditional. >> >> Great, more complexity in the kernel for the sake of TOMOYO >> :-( >> > You meant that I should leave lock_sock(sk);/release_sock(sk); calls > unconditional? > This error path is not frequently called. If there are no problems but > performance, I'll leave them unconditional. I mean you should not make generic so no longer generic. We worked so hard to split out this common code, it is simply a non-starter for anyone to start putting protocol specific test into here, or even worse to move this code back to being locally copied into every protocol implementation. You may want to think about how you can achieve your goals by putting these unpleasant hooks into some other location. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- security-testing-2.6.git.orig/net/core/datagram.c +++ security-testing-2.6.git/net/core/datagram.c @@ -55,6 +55,7 @@ #include <net/checksum.h> #include <net/sock.h> #include <net/tcp_states.h> +#include <linux/security.h> /* * Is a socket 'connection oriented' ? @@ -179,8 +180,13 @@ struct sk_buff *__skb_recv_datagram(stru } spin_unlock_irqrestore(&sk->sk_receive_queue. lock, cpu_flags); - if (skb) + if (skb) { + error = security_socket_post_recv_datagram(sk, skb, + flags); + if (error) + goto force_dequeue; return skb; + } /* User doesn't want to wait */
Hello. David Miller wrote: > RAW does not support those things, so doesn't need the locking. I see. Thanks. It is harmless to call lock_sock() for protocols which don't support global socket memory accounting, isn't it? I want to introduce a new LSM hook which is called after picking up a datagram. Below is a patch. error = -EAGAIN; @@ -191,6 +197,19 @@ struct sk_buff *__skb_recv_datagram(stru return NULL; +force_dequeue: + if (flags & MSG_PEEK) { + unsigned long cpu_flags; + spin_lock_irqsave(&sk->sk_receive_queue.lock, cpu_flags); + if (skb == skb_peek(&sk->sk_receive_queue)) { + __skb_unlink(skb, &sk->sk_receive_queue); + atomic_dec(&skb->users); + } + spin_unlock_irqrestore(&sk->sk_receive_queue. lock, cpu_flags); + } + lock_sock(sk); + skb_free_datagram(sk, skb); + release_sock(sk); no_packet: *err = error; return NULL; If it is harmful to call lock_sock() for protocols which don't support global socket memory accounting, I need to make lock_sock(sk);/release_ sock(sk); calls conditional. Regards. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html