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_receive_queue)) {
> > + __skb_unlink(skb, >sk_receive_queue);
> > +
Hello.
Paul Moore wrote:
> My apologies, I mistakenly read the following if statement in your patch:
>
> + if (skb == skb_peek(>sk_receive_queue)) {
> + __skb_unlink(skb, >sk_receive_queue);
> + atomic_dec(>users);
> + }
>
> I read the conditional as
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().
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
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 because
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().
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 than the
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 conditional as
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:
> 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
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 inside
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
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
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
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
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
18 matches
Mail list logo
