linux-kernel - Re: linux-next: manual merge of the sysctl tree with the net tree

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: <m1r5rga54f.fsf@fess.ebiederm.org>
Date:	Sun, 29 Nov 2009 22:39:12 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Américo Wang <xiyou.wangcong@...il.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Vlad Yasevich <vladislav.yasevich@...com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: linux-next: manual merge of the sysctl tree with the net tree

Américo Wang <xiyou.wangcong@...il.com> writes:

> On Mon, Nov 30, 2009 at 1:44 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>> Hi Eric,
>>
>> Today's linux-next merge of the sysctl tree got a conflict in
>> net/sctp/sysctl.c between commit 90f2f5318b3a5b0898fef0fec9b91376c7de7a2c
>> ("sctp: Update SWS avaoidance receiver side algorithm") from the net tree
>> and commit f8572d8f2a2ba75408b97dc24ef47c83671795d7 ("sysctl net: Remove
>> unused binary sysctl code") from the sysctl tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary.  I also
>> removed the strategy member from the new added ctl_table entry.
>> --
>> Cheers,
>> Stephen Rothwell                    sfr@...b.auug.org.au
>>
>> diff --cc net/sctp/sysctl.c
>> index ae03ded,d50a042..0000000
>> --- a/net/sctp/sysctl.c
>> +++ b/net/sctp/sysctl.c
>> @@@ -285,19 -241,7 +242,17 @@@ static ctl_table sctp_table[] =
>>                .extra1         = &zero,
>>                .extra2         = &addr_scope_max,
>>        },
>>  +      {
>> -               .ctl_name       = CTL_UNNUMBERED,
>>  +              .procname       = "rwnd_update_shift",
>>  +              .data           = &sctp_rwnd_upd_shift,
>>  +              .maxlen         = sizeof(int),
>>  +              .mode           = 0644,
>> -               .proc_handler   = &proc_dointvec_minmax,
>> -               .strategy       = &sysctl_intvec,
>> ++              .proc_handler   = proc_dointvec_minmax,
>
> Hey, what's this??

The short version is I am running a git tree that holds all of
the necessary cleanups to remove the support for binary sysctl handlers.

The binary sysctl support continues to be provided in kernel/sysctl_binary.c
with a compatibility wrapper.  This has been reviewed on linux-kernel
and written up in lwn.

In my tree .ctl_name and .strategy have been removed as they exist
only to support binary sysctls and are not strictly needed today.
.ctl_name = CTL_UNNUMBERED is equivalent to .ctl_name = 0, and setting
.strategy on new sysctl table entries without a ctl_name is a harmless
bug.  Since I was in there I also removed all of the unnecessary ampersands
from in front of proc_dointvec_minmax.

Since I have touched practically every sysctl table entry in the kernel
new sysctl additions will almost inevitably cause a small by trivially
to resolve conflict (due to the fact I have almost certainly changed
the proceeding and succeeding sysctl table entries).

Currently this only the second sysctl added this kernel cycle, and it
looks like this work happened in parallel, with my changes, and somehow
David missed this commit in his September pull, so the changes just
showed up in net-next.

It would seem to require talent to mess up the merge conflicts, and
getting it wrong will result in a tree that won't compile so I am not
going to worry about it until Linux pulls one of our trees.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/