netdev - Re: What is lock_sock() before skb_free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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