Re: Config Loop

[Alex Elder <elder@inktank.com>]

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