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:	Tue, 6 Aug 2013 14:45:08 -0600
From:	Jean Sacren <sakiwit@...il.com>
To:	Daniel Borkmann <dborkman@...hat.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 3/3] net: core: fix wrong linkage for ptype_base
 and ptype_all symbols

From: Daniel Borkmann <dborkman@...hat.com>
Date: Tue, 06 Aug 2013 10:13:15 +0200
>
> On 08/06/2013 09:32 AM, Jean Sacren wrote:
> > In commit 900ff8c6 ("net: move procfs code to net/core/net-procfs.c"),
> > it changed the correct linkage of ptype_base and ptype_all symbols to
> > the wrong one in net/core/dev.c, yet failed to change to the correct
> > linkage of those two in net/core/net-procfs.c.
> >
> > Fix the wrong linkage by setting static specifier to both sets of the
> > symbols so that they could have coherent internal linkage by themselves
> > to avoid interference with each other.
> 
> Ho? I do not think this is correct, what makes you think so?

Thank you for the awesome comment.

I'm sorry to tell you but the patch is correct. Both symbols of
ptype_{base,all} were wrongly declared as extern in net-procfs.c in the
first place.

> The net-procfs.c usage of ptype_* is there to show current pf_packet users
> via seq_files in procfs. Your patch will just break this.

I validated it before I submitted the patch that all the symbols of
ptype_{base,all} are used exclusively in net/core/net-procfs.c and
net/core/dev.c but not outside of those two places. Therefore, your
assumption for breakage is groundless.

As a kernel networking guru as you are, you shall have the lab and all
sorts of test cases to validate patches. I'd love to run this type of
testing by myself, but I don't have such resources. If you could test
this patch in any of your setup and prove that I'm wrong, I'd extremely
appreciate it. Thank you in advance.

I'm looking forward to being taught more.

-- 
Jean Sacren
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ