[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090418.212842.163717535.davem@davemloft.net>
Date: Sat, 18 Apr 2009 21:28:42 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: penguin-kernel@...ove.SAKURA.ne.jp
Cc: netdev@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: What is lock_sock() before skb_free_datagram() for?
From: Tetsuo Handa <penguin-kernel@...ove.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists