From: Florian Fainelli <florian@openwrt.org>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Vlad Yasevich <vyasevich@gmail.com>,
linux-sctp@vger.kernel.org
Subject: Re: [PATCH v2] sctp: Change defaults on cookie hmac selection
Date: Mon, 07 Jan 2013 15:15:24 +0000 [thread overview]
Message-ID: <50EAE68C.2050300@openwrt.org> (raw)
In-Reply-To: <20130107144921.GA31577@hmsreliant.think-freely.org>
Le 01/07/13 15:49, Neil Horman a écrit :
> On Mon, Jan 07, 2013 at 02:25:39PM +0100, Florian Fainelli wrote:
>> Hello Neil,
>>
>> Le 12/15/12 02:22, Neil Horman a écrit :
>>> Recently I posted commit 3c68198e75 which made selection of the cookie hmac
>>> algorithm selectable. This is all well and good, but Linus noted that it
>>> changes the default config:
>>> http://marc.info/?l=linux-netdev&m\x135536629004808&w=2
>>>
>>> I've modified the sctp Kconfig file to reflect the recommended way of making
>>> this choice, using the thermal driver example specified, and brought the
>>> defaults back into line with the way they were prior to my origional patch
>>>
>>> Also, on Linus' suggestion, re-adding ability to select default 'none' hmac
>>> algorithm, so we don't needlessly bloat the kernel by forcing a non-none
>>> default. This also led me to note that we won't honor the default none
>>> condition properly because of how sctp_net_init is encoded. Fix that up as
>>> well.
>>>
>>> Tested by myself (allbeit fairly quickly). All configuration combinations seems
>>> to work soundly.
>>>
>>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>>> CC: David Miller <davem@davemloft.net>
>>> CC: Linus Torvalds <torvalds@linux-foundation.org>
>>> CC: Vlad Yasevich <vyasevich@gmail.com>
>>> CC: linux-sctp@vger.kernel.org
>>> ---
>>> net/sctp/Kconfig | 27 +++++++++++++++++++++++++--
>>> net/sctp/protocol.c | 4 ++--
>>> 2 files changed, 27 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
>>> index a9edd2e..c262106 100644
>>> --- a/net/sctp/Kconfig
>>> +++ b/net/sctp/Kconfig
>>> @@ -66,12 +66,36 @@ config SCTP_DBG_OBJCNT
>>> 'cat /proc/net/sctp/sctp_dbg_objcnt'
>>>
>>> If unsure, say N
>>> +choice
>>> + prompt "Default SCTP cookie HMAC encoding"
>>> + default SCTP_COOKIE_HMAC_MD5
>> Should not this be SCTP_DEFAULT_COOKIE_HMAC_MD5? I just tried to
>> update to 3.8-rc2, and I usually build my kernel-headers with:
>>
>> yes '' | ARCH=foo make oldconfig
>>
>> and this just kept asking me for this config symbol because none
>> could be provided.
>> --
>> Florian
>>
> No, the config mechanism is setup to offer the user the ability to choose a
> default cookie hmac, alg, then optionally select any other hmac algs you would
> like to be made available (in the event you want to change the default at run
> time). When you select the default, it eables (via the select directive), the
> corresponding SCTP_COOKIE_HMAC_* config option, which is used in the build, and
> then prompts for the remaining values.
Ok for the explanation, but this still breaks an oldconfig because we do
not actually propose the user with a default choice:
choice[1-3?]: Default SCTP cookie HMAC encoding
1. Enable optional MD5 hmac cookie generation
(SCTP_DEFAULT_COOKIE_HMAC_MD5) (NEW)
2. Enable optional SHA1 hmac cookie generation
(SCTP_DEFAULT_COOKIE_HMAC_SHA1) (NEW)
3. Use no hmac alg in SCTP cookie generation
(SCTP_DEFAULT_COOKIE_HMAC_NONE) (NEW)
I do not see any difference in what I am proposed if the default config
symbol is SCTP_DEFAULT_COOKIE_HMAC_MD5, I can still optionally choose
SHA1 to be supported, and I do have a valid default config for this
choice. While if I keep SCTP_COOKIE_HMAC_MD5 as the default I have to
manually enter which option I want.
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <florian@openwrt.org>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Vlad Yasevich <vyasevich@gmail.com>,
linux-sctp@vger.kernel.org
Subject: Re: [PATCH v2] sctp: Change defaults on cookie hmac selection
Date: Mon, 07 Jan 2013 16:15:24 +0100 [thread overview]
Message-ID: <50EAE68C.2050300@openwrt.org> (raw)
In-Reply-To: <20130107144921.GA31577@hmsreliant.think-freely.org>
Le 01/07/13 15:49, Neil Horman a écrit :
> On Mon, Jan 07, 2013 at 02:25:39PM +0100, Florian Fainelli wrote:
>> Hello Neil,
>>
>> Le 12/15/12 02:22, Neil Horman a écrit :
>>> Recently I posted commit 3c68198e75 which made selection of the cookie hmac
>>> algorithm selectable. This is all well and good, but Linus noted that it
>>> changes the default config:
>>> http://marc.info/?l=linux-netdev&m=135536629004808&w=2
>>>
>>> I've modified the sctp Kconfig file to reflect the recommended way of making
>>> this choice, using the thermal driver example specified, and brought the
>>> defaults back into line with the way they were prior to my origional patch
>>>
>>> Also, on Linus' suggestion, re-adding ability to select default 'none' hmac
>>> algorithm, so we don't needlessly bloat the kernel by forcing a non-none
>>> default. This also led me to note that we won't honor the default none
>>> condition properly because of how sctp_net_init is encoded. Fix that up as
>>> well.
>>>
>>> Tested by myself (allbeit fairly quickly). All configuration combinations seems
>>> to work soundly.
>>>
>>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>>> CC: David Miller <davem@davemloft.net>
>>> CC: Linus Torvalds <torvalds@linux-foundation.org>
>>> CC: Vlad Yasevich <vyasevich@gmail.com>
>>> CC: linux-sctp@vger.kernel.org
>>> ---
>>> net/sctp/Kconfig | 27 +++++++++++++++++++++++++--
>>> net/sctp/protocol.c | 4 ++--
>>> 2 files changed, 27 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
>>> index a9edd2e..c262106 100644
>>> --- a/net/sctp/Kconfig
>>> +++ b/net/sctp/Kconfig
>>> @@ -66,12 +66,36 @@ config SCTP_DBG_OBJCNT
>>> 'cat /proc/net/sctp/sctp_dbg_objcnt'
>>>
>>> If unsure, say N
>>> +choice
>>> + prompt "Default SCTP cookie HMAC encoding"
>>> + default SCTP_COOKIE_HMAC_MD5
>> Should not this be SCTP_DEFAULT_COOKIE_HMAC_MD5? I just tried to
>> update to 3.8-rc2, and I usually build my kernel-headers with:
>>
>> yes '' | ARCH=foo make oldconfig
>>
>> and this just kept asking me for this config symbol because none
>> could be provided.
>> --
>> Florian
>>
> No, the config mechanism is setup to offer the user the ability to choose a
> default cookie hmac, alg, then optionally select any other hmac algs you would
> like to be made available (in the event you want to change the default at run
> time). When you select the default, it eables (via the select directive), the
> corresponding SCTP_COOKIE_HMAC_* config option, which is used in the build, and
> then prompts for the remaining values.
Ok for the explanation, but this still breaks an oldconfig because we do
not actually propose the user with a default choice:
choice[1-3?]: Default SCTP cookie HMAC encoding
1. Enable optional MD5 hmac cookie generation
(SCTP_DEFAULT_COOKIE_HMAC_MD5) (NEW)
2. Enable optional SHA1 hmac cookie generation
(SCTP_DEFAULT_COOKIE_HMAC_SHA1) (NEW)
3. Use no hmac alg in SCTP cookie generation
(SCTP_DEFAULT_COOKIE_HMAC_NONE) (NEW)
I do not see any difference in what I am proposed if the default config
symbol is SCTP_DEFAULT_COOKIE_HMAC_MD5, I can still optionally choose
SHA1 to be supported, and I do have a valid default config for this
choice. While if I keep SCTP_COOKIE_HMAC_MD5 as the default I have to
manually enter which option I want.
--
Florian
next prev parent reply other threads:[~2013-01-07 15:15 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 18:51 [PATCH] sctp: Change defaults on cookie hmac selection Neil Horman
2012-12-14 18:51 ` Neil Horman
2012-12-14 20:01 ` Vlad Yasevich
2012-12-14 20:01 ` Vlad Yasevich
2012-12-14 21:56 ` Linus Torvalds
2012-12-14 21:56 ` Linus Torvalds
2012-12-15 0:38 ` Neil Horman
2012-12-15 0:38 ` Neil Horman
2012-12-15 0:44 ` Linus Torvalds
2012-12-15 0:44 ` Linus Torvalds
2012-12-15 1:12 ` Neil Horman
2012-12-15 1:12 ` Neil Horman
2012-12-15 1:14 ` David Miller
2012-12-15 1:14 ` David Miller
2012-12-15 1:22 ` [PATCH v2] " Neil Horman
2012-12-15 1:22 ` Neil Horman
2012-12-16 1:16 ` David Miller
2012-12-16 1:16 ` David Miller
2013-01-07 13:25 ` Florian Fainelli
2013-01-07 13:25 ` Florian Fainelli
2013-01-07 14:49 ` Neil Horman
2013-01-07 14:49 ` Neil Horman
2013-01-07 15:15 ` Florian Fainelli [this message]
2013-01-07 15:15 ` Florian Fainelli
2013-01-07 15:38 ` Neil Horman
2013-01-07 15:38 ` Neil Horman
2013-01-07 15:48 ` Vlad Yasevich
2013-01-07 15:48 ` Vlad Yasevich
2013-01-08 17:36 ` Florian Fainelli
2013-01-08 17:36 ` Florian Fainelli
2013-01-07 15:32 ` Vlad Yasevich
2013-01-07 15:32 ` Vlad Yasevich
2013-01-07 15:46 ` Neil Horman
2013-01-07 15:46 ` Neil Horman
2013-01-07 16:39 ` Vlad Yasevich
2013-01-07 16:39 ` Vlad Yasevich
2013-01-08 17:48 ` Florian Fainelli
2013-01-08 17:48 ` Florian Fainelli
2013-01-08 18:08 ` Vlad Yasevich
2013-01-08 18:08 ` Vlad Yasevich
2013-01-08 18:20 ` Alex Elder
2013-01-08 18:20 ` Alex Elder
2013-01-08 18:28 ` Vlad Yasevich
2013-01-08 18:28 ` Vlad Yasevich
2013-01-09 9:08 ` Florian Fainelli
2013-01-09 9:08 ` Florian Fainelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50EAE68C.2050300@openwrt.org \
--to=florian@openwrt.org \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=torvalds@linux-foundation.org \
--cc=vyasevich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.