On Tue, 20 Nov 2007, Tetsuo Handa wrote:
> Hello.
>
> Paul Moore wrote:
> > My apologies, I mistakenly read the following if statement in your patch:
> >
> > + if (skb == skb_peek(&sk->sk_receive_queue)) {
> > + __skb_unlink(skb, &sk->sk_receive_queue);
> > +
Hello.
Paul Moore wrote:
> My apologies, I mistakenly read the following if statement in your patch:
>
> + if (skb == skb_peek(&sk->sk_receive_queue)) {
> + __skb_unlink(skb, &sk->sk_receive_queue);
> + atomic_dec(&skb->users);
> + }
>
> I read the con
On Monday 19 November 2007 9:29:52 am Tetsuo Handa wrote:
> Paul Moore wrote:
> > If that is the case then the second call to
> > skb_peek() will return a different skb then the one you passed to
> > security_post_recv_datagram().
>
> Yes. The second call to skb_peek() might return a different skb
Hello.
Paul Moore wrote:
> If that is the case then the second call to
> skb_peek() will return a different skb then the one you passed to
> security_post_recv_datagram().
Yes. The second call to skb_peek() might return a different skb than the one
I passed to security_post_recv_datagram().
skb
On Saturday 17 November 2007 11:00:20 pm Tetsuo Handa wrote:
> Hello.
Hello.
> Paul Moore wrote:
> > Okay, well if that is the case I think you are going to have another
> > problem in that you could end up throwing away skbs that haven't been
> > through your security_post_recv_datagram() hook b
Hello.
Paul Moore wrote:
> Okay, well if that is the case I think you are going to have another problem
> in that you could end up throwing away skbs that haven't been through your
> security_post_recv_datagram() hook because you _always_ throw away the result
> of the second skb_peek(). Once
On Friday 16 November 2007 10:45:32 pm Tetsuo Handa wrote:
> Paul Moore wrote:
> > I might be missing something here, but why do you need to do a skb_peek()
> > again? You already have the skb and the sock, just do the unlink.
>
> The skb might be already dequeued by other thread while I slept ins
Hello.
Thank you for your feedback.
Paul Moore wrote:
> With this patch the 'cpu_flags' variable will be used in two different
> if-blocks in this function and declared locally within each block. Please
> move the 'cpu_flags' declaration to the top of the function so it only needs
> to be dec
On Friday 16 November 2007 12:34:57 pm [EMAIL PROTECTED]
wrote:
> LSM hooks for network accept and recv:
>* socket_post_accept is modified to return int.
>* post_recv_datagram is added in skb_recv_datagram.
>
> You can try TOMOYO Linux without this patch, but in that case, you
> can't use
LSM hooks for sending signal:
* task_kill_unlocked is added in sys_kill
* task_tkill_unlocked is added in sys_tkill
* task_tgkill_unlocked is added in sys_tgkill
LSM hooks for network accept and recv:
* socket_post_accept is modified to return int.
* post_recv_datagram is added in sk
10 matches
Mail list logo
