netdev - Re: [PATCH 00/17] ATM fixes for pppoatm/br2684

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]

Message-ID: <1354436040.21562.386.camel@shinybook.infradead.org>
Date:	Sun, 02 Dec 2012 08:14:00 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, chas@....nrl.navy.mil,
	krzysiek@...lesie.net
Subject: Re: [PATCH 00/17] ATM fixes for pppoatm/br2684

On Sat, 2012-12-01 at 20:49 -0500, David Miller wrote:
> 
> I actually prefer what we do now, which is do the BUILD_BUG_ON()
> once in the subsystem specific code, usually the initializer.
> 
> It's part of creating a new SKB cb, adding that assertion somewhere.

Where it's *subsystem* code that's great... but *drivers* get to use the
skb cb too. And driver authors aren't always so reliable :)

Looking just at solos-pci, there was no feedback during the initial
submission that I ought to be using a BUILD_BUG_ON to limit the size of
struct solos_skb_cb. It was just luck, really, that I remembered to do
it — as an afterthought in a later iteration of the patch.

Giving driver authors fewer ways to shoot themselves in the foot always
seems like a good idea... 

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)