Config Loop

Config Loop

[Alex Elder]

A commit added in the 3.8-rc1 merge window has resulted in
my kernel config entering an infinite loop handling the
"Default SCTP cookie HMAC encoding" option.

    commit 0d0863b02002c25140a1b9e113b81211bcc780e8
    sctp: Change defaults on cookie hmac selection

    http://marc.info/?l=linux-netdev&m\x135553459303505

The problem lies in my config file containing this line:

    CONFIG_SCTP_HMAC_MD5=y

I normally configure my kernel using fixed config file
(occasionally updated) using (roughly) this:

    yes "" | make oldconfig

The result looks like this:

. . .
  DCCP connection probing (NET_DCCPPROBE) [M/n/?] m
*
* The SCTP Protocol (EXPERIMENTAL)
*
The SCTP Protocol (EXPERIMENTAL) (IP_SCTP) [M/y/?] m
  SCTP: Association probing (NET_SCTPPROBE) [M/n/?] m
  SCTP: Debug messages (SCTP_DBG_MSG) [N/y/?] n
  SCTP: Debug object counts (SCTP_DBG_OBJCNT) [N/y/?] n
  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)
  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)
  choice[1-3?]:   Default SCTP cookie HMAC encoding
. . .  and so on.

I find that I can correct this with the patch below.
I expect others will bump into the same problem.  In
particular, I notice my Ubuntu config files contain
that same line.

I don't know how best to handle this, but I thought
I would report it in case someone has a good solution.

					-Alex

 arch/x86/configs/autobuild |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/arch/x86/configs/autobuild
=================================--- a/arch/x86/configs/autobuild
+++ b/arch/x86/configs/autobuild
@@ -940,7 +940,7 @@ CONFIG_NET_SCTPPROBE=m
 # CONFIG_SCTP_DBG_OBJCNT is not set
 # CONFIG_SCTP_HMAC_NONE is not set
 # CONFIG_SCTP_HMAC_SHA1 is not set
-CONFIG_SCTP_HMAC_MD5=y
+CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
 CONFIG_RDS=m
 CONFIG_RDS_RDMA=m
 CONFIG_RDS_TCP=m

Re: Config Loop

[Neil Horman]

On Thu, Jan 03, 2013 at 09:57:13AM -0600, Alex Elder wrote:
> A commit added in the 3.8-rc1 merge window has resulted in
> my kernel config entering an infinite loop handling the
> "Default SCTP cookie HMAC encoding" option.
> 
>     commit 0d0863b02002c25140a1b9e113b81211bcc780e8
>     sctp: Change defaults on cookie hmac selection
> 
>     http://marc.info/?l=linux-netdev&m\x135553459303505
> 
> The problem lies in my config file containing this line:
> 
>     CONFIG_SCTP_HMAC_MD5=y
> 
> I normally configure my kernel using fixed config file
> (occasionally updated) using (roughly) this:
> 
>     yes "" | make oldconfig
> 
> The result looks like this:
> 
> . . .
>   DCCP connection probing (NET_DCCPPROBE) [M/n/?] m
> *
> * The SCTP Protocol (EXPERIMENTAL)
> *
> The SCTP Protocol (EXPERIMENTAL) (IP_SCTP) [M/y/?] m
>   SCTP: Association probing (NET_SCTPPROBE) [M/n/?] m
>   SCTP: Debug messages (SCTP_DBG_MSG) [N/y/?] n
>   SCTP: Debug object counts (SCTP_DBG_OBJCNT) [N/y/?] n
>   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)
>   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)
>   choice[1-3?]:   Default SCTP cookie HMAC encoding
> . . .  and so on.
> 
> I find that I can correct this with the patch below.
> I expect others will bump into the same problem.  In
> particular, I notice my Ubuntu config files contain
> that same line.
> 
> I don't know how best to handle this, but I thought
> I would report it in case someone has a good solution.
> 
Thats odd.  It looks like your selection of a defaut value for the sctp cookie
hmac algorithm isn't taking at all.  I just added the old CONFIG_SCTP_HMAC_MD5=y
option to my config and used your:
yes "" | make oldconfig 
setup, and it worked fine for me.  And you say if you remove the old config
option first, you get no loop?

Neil

> 					-Alex
> 
>  arch/x86/configs/autobuild |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: b/arch/x86/configs/autobuild
> =================================> --- a/arch/x86/configs/autobuild
> +++ b/arch/x86/configs/autobuild
> @@ -940,7 +940,7 @@ CONFIG_NET_SCTPPROBE=m
>  # CONFIG_SCTP_DBG_OBJCNT is not set
>  # CONFIG_SCTP_HMAC_NONE is not set
>  # CONFIG_SCTP_HMAC_SHA1 is not set
> -CONFIG_SCTP_HMAC_MD5=y
> +CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
>  CONFIG_RDS=m
>  CONFIG_RDS_RDMA=m
>  CONFIG_RDS_TCP=m
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Config Loop

[Alex Elder]

[-- Attachment #1: Type: text/plain, Size: 3633 bytes --]

On 01/03/2013 10:52 AM, Neil Horman wrote:
> On Thu, Jan 03, 2013 at 09:57:13AM -0600, Alex Elder wrote:
>> A commit added in the 3.8-rc1 merge window has resulted in
>> my kernel config entering an infinite loop handling the
>> "Default SCTP cookie HMAC encoding" option.
>>
>>     commit 0d0863b02002c25140a1b9e113b81211bcc780e8
>>     sctp: Change defaults on cookie hmac selection
>>
>>     http://marc.info/?l=linux-netdev&m=135553459303505
>>
>> The problem lies in my config file containing this line:
>>
>>     CONFIG_SCTP_HMAC_MD5=y
>>
>> I normally configure my kernel using fixed config file
>> (occasionally updated) using (roughly) this:
>>
>>     yes "" | make oldconfig
>>
>> The result looks like this:
>>
>> . . .
>>   DCCP connection probing (NET_DCCPPROBE) [M/n/?] m
>> *
>> * The SCTP Protocol (EXPERIMENTAL)
>> *
>> The SCTP Protocol (EXPERIMENTAL) (IP_SCTP) [M/y/?] m
>>   SCTP: Association probing (NET_SCTPPROBE) [M/n/?] m
>>   SCTP: Debug messages (SCTP_DBG_MSG) [N/y/?] n
>>   SCTP: Debug object counts (SCTP_DBG_OBJCNT) [N/y/?] n
>>   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)
>>   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)
>>   choice[1-3?]:   Default SCTP cookie HMAC encoding
>> . . .  and so on.
>>
>> I find that I can correct this with the patch below.
>> I expect others will bump into the same problem.  In
>> particular, I notice my Ubuntu config files contain
>> that same line.
>>
>> I don't know how best to handle this, but I thought
>> I would report it in case someone has a good solution.
>>
> Thats odd.  It looks like your selection of a defaut value for the sctp cookie
> hmac algorithm isn't taking at all.  I just added the old CONFIG_SCTP_HMAC_MD5=y
> option to my config and used your:
> yes "" | make oldconfig 
> setup, and it worked fine for me.  And you say if you remove the old config
> option first, you get no loop?

I say that when I apply the patch (below) there is no loop.

I noticed the loop with v3.8-rc1 and it's still happening
with v3.8-rc2.  I've attached the working config I'm now
using to this message.  The only difference between the
looping one and the working one is that this:
    CONFIG_SCTP_HMAC_MD5=y
has been replaced with this:
    CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y

					-Alex
]
> Neil
> 
>> 					-Alex
>>
>>  arch/x86/configs/autobuild |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: b/arch/x86/configs/autobuild
>> ===================================================================
>> --- a/arch/x86/configs/autobuild
>> +++ b/arch/x86/configs/autobuild
>> @@ -940,7 +940,7 @@ CONFIG_NET_SCTPPROBE=m
>>  # CONFIG_SCTP_DBG_OBJCNT is not set
>>  # CONFIG_SCTP_HMAC_NONE is not set
>>  # CONFIG_SCTP_HMAC_SHA1 is not set
>> -CONFIG_SCTP_HMAC_MD5=y
>> +CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
>>  CONFIG_RDS=m
>>  CONFIG_RDS_RDMA=m
>>  CONFIG_RDS_TCP=m
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>


[-- Attachment #2: kernel-config.gz --]
[-- Type: application/x-gzip, Size: 28902 bytes --]

Re: Config Loop

[Neil Horman]

On Thu, Jan 03, 2013 at 10:59:02AM -0600, Alex Elder wrote:
> On 01/03/2013 10:52 AM, Neil Horman wrote:
> > On Thu, Jan 03, 2013 at 09:57:13AM -0600, Alex Elder wrote:
> >> A commit added in the 3.8-rc1 merge window has resulted in
> >> my kernel config entering an infinite loop handling the
> >> "Default SCTP cookie HMAC encoding" option.
> >>
> >>     commit 0d0863b02002c25140a1b9e113b81211bcc780e8
> >>     sctp: Change defaults on cookie hmac selection
> >>
> >>     http://marc.info/?l=linux-netdev&m\x135553459303505
> >>
> >> The problem lies in my config file containing this line:
> >>
> >>     CONFIG_SCTP_HMAC_MD5=y
> >>
> >> I normally configure my kernel using fixed config file
> >> (occasionally updated) using (roughly) this:
> >>
> >>     yes "" | make oldconfig
> >>
> >> The result looks like this:
> >>
> >> . . .
> >>   DCCP connection probing (NET_DCCPPROBE) [M/n/?] m
> >> *
> >> * The SCTP Protocol (EXPERIMENTAL)
> >> *
> >> The SCTP Protocol (EXPERIMENTAL) (IP_SCTP) [M/y/?] m
> >>   SCTP: Association probing (NET_SCTPPROBE) [M/n/?] m
> >>   SCTP: Debug messages (SCTP_DBG_MSG) [N/y/?] n
> >>   SCTP: Debug object counts (SCTP_DBG_OBJCNT) [N/y/?] n
> >>   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)
> >>   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)
> >>   choice[1-3?]:   Default SCTP cookie HMAC encoding
> >> . . .  and so on.
> >>
> >> I find that I can correct this with the patch below.
> >> I expect others will bump into the same problem.  In
> >> particular, I notice my Ubuntu config files contain
> >> that same line.
> >>
> >> I don't know how best to handle this, but I thought
> >> I would report it in case someone has a good solution.
> >>
> > Thats odd.  It looks like your selection of a defaut value for the sctp cookie
> > hmac algorithm isn't taking at all.  I just added the old CONFIG_SCTP_HMAC_MD5=y
> > option to my config and used your:
> > yes "" | make oldconfig 
> > setup, and it worked fine for me.  And you say if you remove the old config
> > option first, you get no loop?
> 
> I say that when I apply the patch (below) there is no loop.
> 
> I noticed the loop with v3.8-rc1 and it's still happening
> with v3.8-rc2.  I've attached the working config I'm now
> using to this message.  The only difference between the
> looping one and the working one is that this:
>     CONFIG_SCTP_HMAC_MD5=y
> has been replaced with this:
>     CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
> 
Oh, I think I see what happened.  When I converted the Kconfig file to have a
choice statement, it created a conflict with your old config that the the config
mechanism didn't know how to resolve.  The Choice statement selects
CONFIG_SCTP_HMAC_MD5 as a default value, but your old config explicitly has
CONFIG_SCTP_HMAC_MD5 turned off.  Since your command:
yes "" | make oldconfig
just takes whatever the default value is, it tries to select
CONFIG_SCTP_HMAC_MD5, but since its already turned off, the config utilty
doesn't know what to do, so it responds by just asking you again what you want
the default to be.

I don't think theres actually a bug here, at least not one that we can do
anything about that won't result in other people complaining about the opposite
effect.  The old config you have, when applied to the latest kernel, puts you in
a situation where you have both hmac options already disabled, but you need to
select a default value for your hmac cookie generator (one of md5/sha1/none), so
selecting the default effectively creates a situation where you're asking the
config to have CONFIG_SCTP_HMAC_MD5 both on and off at the same time.

Things that could be done as I see it:

1) We could teach the config utility to recognize when options are disabled in
the old config and migrate the default away to the next in line that is not
already disabled

2) We could make the config utility override the old config value when the input
value input at the prompt conflicts with the old config

3) We could print a helpful message indicating that the conflict is taking place


Truthfully though I don't really like any of these a whole lot (save for the
third).  1 is unpleasant in my view as they change what would otherwise
be the default coded value silently, while 2 overrides the previously selected
configuration option.  Both of these may be completely unexpected by the user.


Option 3 seems reasonable to me, although I'm not sure its going to be that
useful.  I'm sorry this happened to you, but it seems like this is something
that will only occur very rarely if/when we convert a previously existing set of
options to a choice submenu.  Let me know if you have other thoughts.
Neil

Re: Config Loop

[Alex Elder]

On 01/03/2013 01:06 PM, Neil Horman wrote:
> On Thu, Jan 03, 2013 at 10:59:02AM -0600, Alex Elder wrote:
>> On 01/03/2013 10:52 AM, Neil Horman wrote:
>>> On Thu, Jan 03, 2013 at 09:57:13AM -0600, Alex Elder wrote:
>>>> A commit added in the 3.8-rc1 merge window has resulted in
>>>> my kernel config entering an infinite loop handling the
>>>> "Default SCTP cookie HMAC encoding" option.
>>>>
>>>>     commit 0d0863b02002c25140a1b9e113b81211bcc780e8
>>>>     sctp: Change defaults on cookie hmac selection
>>>>
>>>>     http://marc.info/?l=linux-netdev&m\x135553459303505
>>>>
>>>> The problem lies in my config file containing this line:
>>>>
>>>>     CONFIG_SCTP_HMAC_MD5=y
>>>>
>>>> I normally configure my kernel using fixed config file
>>>> (occasionally updated) using (roughly) this:
>>>>
>>>>     yes "" | make oldconfig
>>>>
>>>> The result looks like this:
>>>>
>>>> . . .
>>>>   DCCP connection probing (NET_DCCPPROBE) [M/n/?] m
>>>> *
>>>> * The SCTP Protocol (EXPERIMENTAL)
>>>> *
>>>> The SCTP Protocol (EXPERIMENTAL) (IP_SCTP) [M/y/?] m
>>>>   SCTP: Association probing (NET_SCTPPROBE) [M/n/?] m
>>>>   SCTP: Debug messages (SCTP_DBG_MSG) [N/y/?] n
>>>>   SCTP: Debug object counts (SCTP_DBG_OBJCNT) [N/y/?] n
>>>>   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)
>>>>   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)
>>>>   choice[1-3?]:   Default SCTP cookie HMAC encoding
>>>> . . .  and so on.
>>>>
>>>> I find that I can correct this with the patch below.
>>>> I expect others will bump into the same problem.  In
>>>> particular, I notice my Ubuntu config files contain
>>>> that same line.
>>>>
>>>> I don't know how best to handle this, but I thought
>>>> I would report it in case someone has a good solution.
>>>>
>>> Thats odd.  It looks like your selection of a defaut value for the sctp cookie
>>> hmac algorithm isn't taking at all.  I just added the old CONFIG_SCTP_HMAC_MD5=y
>>> option to my config and used your:
>>> yes "" | make oldconfig 
>>> setup, and it worked fine for me.  And you say if you remove the old config
>>> option first, you get no loop?
>>
>> I say that when I apply the patch (below) there is no loop.
>>
>> I noticed the loop with v3.8-rc1 and it's still happening
>> with v3.8-rc2.  I've attached the working config I'm now
>> using to this message.  The only difference between the
>> looping one and the working one is that this:
>>     CONFIG_SCTP_HMAC_MD5=y
>> has been replaced with this:
>>     CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
>>
> Oh, I think I see what happened.  When I converted the Kconfig file to have a
> choice statement, it created a conflict with your old config that the the config
> mechanism didn't know how to resolve.  The Choice statement selects
> CONFIG_SCTP_HMAC_MD5 as a default value, but your old config explicitly has
> CONFIG_SCTP_HMAC_MD5 turned off.  Since your command:
> yes "" | make oldconfig
> just takes whatever the default value is, it tries to select
> CONFIG_SCTP_HMAC_MD5, but since its already turned off, the config utilty
> doesn't know what to do, so it responds by just asking you again what you want
> the default to be.

OK, I was in the middle of writing a nice detailed response to
this.  But in the process of verifying what I was saying I believe
I found the bug.

I'll be sending the fix in a separate message.

Here are a couple of notes anyway:
- I found that combinations of 0, 1, 2, or 3 of the _MD5, _SHA1, and
  _NONE config options set to "=y" produced the same infinite loop.
- I found that another commit, 3c68198e7, changed the names of these
  config options to include "_COOKIE", so my old config file was not
  actually defining *any* of the new names.
- Nevertheless, combinations of 0-3 of those config options produced
  the same infinite loop.

So apparently you must have either not tested "make oldconfig" or
your old config contained a line like I had:
    CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y

					-Alex

> I don't think theres actually a bug here, at least not one that we can do
> anything about that won't result in other people complaining about the opposite
> effect.  The old config you have, when applied to the latest kernel, puts you in
> a situation where you have both hmac options already disabled, but you need to
> select a default value for your hmac cookie generator (one of md5/sha1/none), so
> selecting the default effectively creates a situation where you're asking the
> config to have CONFIG_SCTP_HMAC_MD5 both on and off at the same time.
> 
> Things that could be done as I see it:
> 
> 1) We could teach the config utility to recognize when options are disabled in
> the old config and migrate the default away to the next in line that is not
> already disabled
> 
> 2) We could make the config utility override the old config value when the input
> value input at the prompt conflicts with the old config
> 
> 3) We could print a helpful message indicating that the conflict is taking place
> 
> 
> Truthfully though I don't really like any of these a whole lot (save for the
> third).  1 is unpleasant in my view as they change what would otherwise
> be the default coded value silently, while 2 overrides the previously selected
> configuration option.  Both of these may be completely unexpected by the user.
> 
> 
> Option 3 seems reasonable to me, although I'm not sure its going to be that
> useful.  I'm sorry this happened to you, but it seems like this is something
> that will only occur very rarely if/when we convert a previously existing set of
> options to a choice submenu.  Let me know if you have other thoughts.
> Neil
> 
> 

Re: Config Loop

[Neil Horman]

On Mon, Jan 07, 2013 at 10:47:28AM -0600, Alex Elder wrote:
> On 01/03/2013 01:06 PM, Neil Horman wrote:
> > On Thu, Jan 03, 2013 at 10:59:02AM -0600, Alex Elder wrote:
> >> On 01/03/2013 10:52 AM, Neil Horman wrote:
> >>> On Thu, Jan 03, 2013 at 09:57:13AM -0600, Alex Elder wrote:
> >>>> A commit added in the 3.8-rc1 merge window has resulted in
> >>>> my kernel config entering an infinite loop handling the
> >>>> "Default SCTP cookie HMAC encoding" option.
> >>>>
> >>>>     commit 0d0863b02002c25140a1b9e113b81211bcc780e8
> >>>>     sctp: Change defaults on cookie hmac selection
> >>>>
> >>>>     http://marc.info/?l=linux-netdev&m\x135553459303505
> >>>>
> >>>> The problem lies in my config file containing this line:
> >>>>
> >>>>     CONFIG_SCTP_HMAC_MD5=y
> >>>>
> >>>> I normally configure my kernel using fixed config file
> >>>> (occasionally updated) using (roughly) this:
> >>>>
> >>>>     yes "" | make oldconfig
> >>>>
> >>>> The result looks like this:
> >>>>
> >>>> . . .
> >>>>   DCCP connection probing (NET_DCCPPROBE) [M/n/?] m
> >>>> *
> >>>> * The SCTP Protocol (EXPERIMENTAL)
> >>>> *
> >>>> The SCTP Protocol (EXPERIMENTAL) (IP_SCTP) [M/y/?] m
> >>>>   SCTP: Association probing (NET_SCTPPROBE) [M/n/?] m
> >>>>   SCTP: Debug messages (SCTP_DBG_MSG) [N/y/?] n
> >>>>   SCTP: Debug object counts (SCTP_DBG_OBJCNT) [N/y/?] n
> >>>>   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)
> >>>>   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)
> >>>>   choice[1-3?]:   Default SCTP cookie HMAC encoding
> >>>> . . .  and so on.
> >>>>
> >>>> I find that I can correct this with the patch below.
> >>>> I expect others will bump into the same problem.  In
> >>>> particular, I notice my Ubuntu config files contain
> >>>> that same line.
> >>>>
> >>>> I don't know how best to handle this, but I thought
> >>>> I would report it in case someone has a good solution.
> >>>>
> >>> Thats odd.  It looks like your selection of a defaut value for the sctp cookie
> >>> hmac algorithm isn't taking at all.  I just added the old CONFIG_SCTP_HMAC_MD5=y
> >>> option to my config and used your:
> >>> yes "" | make oldconfig 
> >>> setup, and it worked fine for me.  And you say if you remove the old config
> >>> option first, you get no loop?
> >>
> >> I say that when I apply the patch (below) there is no loop.
> >>
> >> I noticed the loop with v3.8-rc1 and it's still happening
> >> with v3.8-rc2.  I've attached the working config I'm now
> >> using to this message.  The only difference between the
> >> looping one and the working one is that this:
> >>     CONFIG_SCTP_HMAC_MD5=y
> >> has been replaced with this:
> >>     CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
> >>
> > Oh, I think I see what happened.  When I converted the Kconfig file to have a
> > choice statement, it created a conflict with your old config that the the config
> > mechanism didn't know how to resolve.  The Choice statement selects
> > CONFIG_SCTP_HMAC_MD5 as a default value, but your old config explicitly has
> > CONFIG_SCTP_HMAC_MD5 turned off.  Since your command:
> > yes "" | make oldconfig
> > just takes whatever the default value is, it tries to select
> > CONFIG_SCTP_HMAC_MD5, but since its already turned off, the config utilty
> > doesn't know what to do, so it responds by just asking you again what you want
> > the default to be.
> 
> OK, I was in the middle of writing a nice detailed response to
> this.  But in the process of verifying what I was saying I believe
> I found the bug.
> 
> I'll be sending the fix in a separate message.
> 
> Here are a couple of notes anyway:
> - I found that combinations of 0, 1, 2, or 3 of the _MD5, _SHA1, and
>   _NONE config options set to "=y" produced the same infinite loop.
> - I found that another commit, 3c68198e7, changed the names of these
>   config options to include "_COOKIE", so my old config file was not
>   actually defining *any* of the new names.
> - Nevertheless, combinations of 0-3 of those config options produced
>   the same infinite loop.
> 
Didn't feel like I needed to test oldconfig in great depth, as these are all new
options. In that vein, I did test make oldconfig without any of the options set,
and with all the defaults set, and it works fine (i.e. no loop)

As for your testing, are you saying that you tried testing with
SCTP_DEFAULT_COOKIE_HMAC_{NONE|MD5|SHA1] all set to y or n?  If so, thats an
invalid config. What would you expect make oldconfig to do?

>     CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
It doesn't.  The Kconfig file holds this default, so if you have no entry in the
.config, it will add this.


If you think you have a fix however, one that removes the infinite loop and
doesn't override the existing config option, I'll gladly look at it.
Neil

> 
> 					-Alex
> 
> > I don't think theres actually a bug here, at least not one that we can do
> > anything about that won't result in other people complaining about the opposite
> > effect.  The old config you have, when applied to the latest kernel, puts you in
> > a situation where you have both hmac options already disabled, but you need to
> > select a default value for your hmac cookie generator (one of md5/sha1/none), so
> > selecting the default effectively creates a situation where you're asking the
> > config to have CONFIG_SCTP_HMAC_MD5 both on and off at the same time.
> > 
> > Things that could be done as I see it:
> > 
> > 1) We could teach the config utility to recognize when options are disabled in
> > the old config and migrate the default away to the next in line that is not
> > already disabled
> > 
> > 2) We could make the config utility override the old config value when the input
> > value input at the prompt conflicts with the old config
> > 
> > 3) We could print a helpful message indicating that the conflict is taking place
> > 
> > 
> > Truthfully though I don't really like any of these a whole lot (save for the
> > third).  1 is unpleasant in my view as they change what would otherwise
> > be the default coded value silently, while 2 overrides the previously selected
> > configuration option.  Both of these may be completely unexpected by the user.
> > 
> > 
> > Option 3 seems reasonable to me, although I'm not sure its going to be that
> > useful.  I'm sorry this happened to you, but it seems like this is something
> > that will only occur very rarely if/when we convert a previously existing set of
> > options to a choice submenu.  Let me know if you have other thoughts.
> > Neil
> > 
> > 
> 
> 

Re: Config Loop

[Alex Elder]

On 01/07/2013 11:22 AM, Neil Horman wrote:
> On Mon, Jan 07, 2013 at 10:47:28AM -0600, Alex Elder wrote:
>> On 01/03/2013 01:06 PM, Neil Horman wrote:
>>> On Thu, Jan 03, 2013 at 10:59:02AM -0600, Alex Elder wrote:
>>>> On 01/03/2013 10:52 AM, Neil Horman wrote:
>>>>> On Thu, Jan 03, 2013 at 09:57:13AM -0600, Alex Elder wrote:
>>>>>> A commit added in the 3.8-rc1 merge window has resulted in
>>>>>> my kernel config entering an infinite loop handling the
>>>>>> "Default SCTP cookie HMAC encoding" option.
>>>>>>
>>>>>>     commit 0d0863b02002c25140a1b9e113b81211bcc780e8
>>>>>>     sctp: Change defaults on cookie hmac selection
>>>>>>
>>>>>>     http://marc.info/?l=linux-netdev&m\x135553459303505
>>>>>>
>>>>>> The problem lies in my config file containing this line:
>>>>>>
>>>>>>     CONFIG_SCTP_HMAC_MD5=y
>>>>>>
>>>>>> I normally configure my kernel using fixed config file
>>>>>> (occasionally updated) using (roughly) this:
>>>>>>
>>>>>>     yes "" | make oldconfig
>>>>>>
>>>>>> The result looks like this:
>>>>>>
>>>>>> . . .
>>>>>>   DCCP connection probing (NET_DCCPPROBE) [M/n/?] m
>>>>>> *
>>>>>> * The SCTP Protocol (EXPERIMENTAL)
>>>>>> *
>>>>>> The SCTP Protocol (EXPERIMENTAL) (IP_SCTP) [M/y/?] m
>>>>>>   SCTP: Association probing (NET_SCTPPROBE) [M/n/?] m
>>>>>>   SCTP: Debug messages (SCTP_DBG_MSG) [N/y/?] n
>>>>>>   SCTP: Debug object counts (SCTP_DBG_OBJCNT) [N/y/?] n
>>>>>>   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)
>>>>>>   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)
>>>>>>   choice[1-3?]:   Default SCTP cookie HMAC encoding
>>>>>> . . .  and so on.
>>>>>>
>>>>>> I find that I can correct this with the patch below.
>>>>>> I expect others will bump into the same problem.  In
>>>>>> particular, I notice my Ubuntu config files contain
>>>>>> that same line.
>>>>>>
>>>>>> I don't know how best to handle this, but I thought
>>>>>> I would report it in case someone has a good solution.
>>>>>>
>>>>> Thats odd.  It looks like your selection of a defaut value for the sctp cookie
>>>>> hmac algorithm isn't taking at all.  I just added the old CONFIG_SCTP_HMAC_MD5=y
>>>>> option to my config and used your:
>>>>> yes "" | make oldconfig 
>>>>> setup, and it worked fine for me.  And you say if you remove the old config
>>>>> option first, you get no loop?
>>>>
>>>> I say that when I apply the patch (below) there is no loop.
>>>>
>>>> I noticed the loop with v3.8-rc1 and it's still happening
>>>> with v3.8-rc2.  I've attached the working config I'm now
>>>> using to this message.  The only difference between the
>>>> looping one and the working one is that this:
>>>>     CONFIG_SCTP_HMAC_MD5=y
>>>> has been replaced with this:
>>>>     CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
>>>>
>>> Oh, I think I see what happened.  When I converted the Kconfig file to have a
>>> choice statement, it created a conflict with your old config that the the config
>>> mechanism didn't know how to resolve.  The Choice statement selects
>>> CONFIG_SCTP_HMAC_MD5 as a default value, but your old config explicitly has
>>> CONFIG_SCTP_HMAC_MD5 turned off.  Since your command:
>>> yes "" | make oldconfig
>>> just takes whatever the default value is, it tries to select
>>> CONFIG_SCTP_HMAC_MD5, but since its already turned off, the config utilty
>>> doesn't know what to do, so it responds by just asking you again what you want
>>> the default to be.
>>
>> OK, I was in the middle of writing a nice detailed response to
>> this.  But in the process of verifying what I was saying I believe
>> I found the bug.
>>
>> I'll be sending the fix in a separate message.
>>
>> Here are a couple of notes anyway:
>> - I found that combinations of 0, 1, 2, or 3 of the _MD5, _SHA1, and
>>   _NONE config options set to "=y" produced the same infinite loop.
>> - I found that another commit, 3c68198e7, changed the names of these
>>   config options to include "_COOKIE", so my old config file was not
>>   actually defining *any* of the new names.
>> - Nevertheless, combinations of 0-3 of those config options produced
>>   the same infinite loop.
>>
> Didn't feel like I needed to test oldconfig in great depth, as these are all new
> options. In that vein, I did test make oldconfig without any of the options set,
> and with all the defaults set, and it works fine (i.e. no loop)

I don't mean to pick on you.  My main concern wasn't this particular
issue (which I've already worked around).  I was really more concerned
about it being possible for a config file to put config into an
infinite loop while doing what I consider routine processing.

I can tell you that with the config file I supplied earlier,
if I comment out this line:
    CONFIG_SCTP_HMAC_MD5=y
it still loops.  (But because of the spelling change this should
be expected--none of the SCTP_COOKIE_HMAC_{MD5,SHA1} nor the
SCTP_DEFAULT_COOKIE_HMAC_{MD5,SHA1,NONE} is set whether or not
this line is present.)

> As for your testing, are you saying that you tried testing with
> SCTP_DEFAULT_COOKIE_HMAC_{NONE|MD5|SHA1] all set to y or n?  If so, thats an
> invalid config. What would you expect make oldconfig to do?

I realize selecting more than one would be invalid.  (But if so
the config should probably be a bool if I understand the config
language right.)  I'm just reporting the result of my testing.

>>     CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
> It doesn't.  The Kconfig file holds this default, so if you have no entry in the
> .config, it will add this.
> 
> 
> If you think you have a fix however, one that removes the infinite loop and
> doesn't override the existing config option, I'll gladly look at it.

While writing this, I now see you did...

Thanks.

					-Alex
> Neil
> 
>>
>> 					-Alex
>>
>>> I don't think theres actually a bug here, at least not one that we can do
>>> anything about that won't result in other people complaining about the opposite
>>> effect.  The old config you have, when applied to the latest kernel, puts you in
>>> a situation where you have both hmac options already disabled, but you need to
>>> select a default value for your hmac cookie generator (one of md5/sha1/none), so
>>> selecting the default effectively creates a situation where you're asking the
>>> config to have CONFIG_SCTP_HMAC_MD5 both on and off at the same time.
>>>
>>> Things that could be done as I see it:
>>>
>>> 1) We could teach the config utility to recognize when options are disabled in
>>> the old config and migrate the default away to the next in line that is not
>>> already disabled
>>>
>>> 2) We could make the config utility override the old config value when the input
>>> value input at the prompt conflicts with the old config
>>>
>>> 3) We could print a helpful message indicating that the conflict is taking place
>>>
>>>
>>> Truthfully though I don't really like any of these a whole lot (save for the
>>> third).  1 is unpleasant in my view as they change what would otherwise
>>> be the default coded value silently, while 2 overrides the previously selected
>>> configuration option.  Both of these may be completely unexpected by the user.
>>>
>>>
>>> Option 3 seems reasonable to me, although I'm not sure its going to be that
>>> useful.  I'm sorry this happened to you, but it seems like this is something
>>> that will only occur very rarely if/when we convert a previously existing set of
>>> options to a choice submenu.  Let me know if you have other thoughts.
>>> Neil
>>>
>>>
>>
>>