linux-kernel - Re: linux-next: Tree for Apr 26

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: <517B762D.8030409@suse.cz>
Date:	Sat, 27 Apr 2013 08:54:37 +0200
From:	Michal Marek <mmarek@...e.cz>
To:	"Yann E. MORIN" <yann.morin.1998@...e.fr>
Cc:	sedat.dilek@...il.com, Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: linux-next: Tree for Apr 26

Dne 27.4.2013 00:01, Yann E. MORIN napsal(a):
> Michal, Sedat, All,
> 
> On Fri, Apr 26, 2013 at 01:13:33PM +0200, Michal Marek wrote:
>> On 26.4.2013 13:08, Michal Marek wrote:
>>> On 26.4.2013 12:49, Sedat Dilek wrote:
>>>> With reverting all kbuild-next commits I was able to build again.
>>>>
>>>>       Revert "kconfig: implement KCONFIG_PROBABILITY for randconfig"
>>>>       Revert "kconfig: allow specifying the seed for randconfig"
>>>>       Revert "kconfig: fix randomising choice entries in presence of
>>>> KCONFIG_ALLCONFIG"
>>>>       Revert "kconfig: do not override symbols already set"
>>>>       Revert "kconfig: fix randconfig tristate detection"
>>>
>>> I did the same, then applied all the kconfig commits once more and did a
>>> git bisect with this script:
>>>
>>> #!/bin/sh
>>>
>>> cp config-bad .config
>>> make silentoldconfig </dev/null
>>>
>>> This resulted in
>>>
>>> 7ded2624f8988bd22819a60a6000ba6b7091db89 is the first bad commit
>>> commit 7ded2624f8988bd22819a60a6000ba6b7091db89
>>> Author: Yann E. MORIN <yann.morin.1998@...e.fr>
>>> Date:   Sun Mar 10 16:34:10 2013 +0100
>>>
>>>     kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG
>>>
>>> The commit id is different, because it is reverted and applied again. Yann?
>>
>> Commit 422c809 ("kconfig: fix randomising choice entries in presence of
>> KCONFIG_ALLCONFIG") reverts cleanly and reverting it fixes the bug. So
>> there is a plan B.
> 
> I do not understand how reverting 422c809 could have fixed the
> silentoldconfig issue: as I previously reported, it already happens on
> Linus' master.
> 
> I tried again jsut a few minutes ago against:
>     d7d7271: Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> and it is already broken, although 422c809 is not yet in Linus' tree:
> 
>     $ make silentoldconfig </dev/null
>     scripts/kconfig/conf --silentoldconfig Kconfig
>     warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet
>     direct dependencies (COMPAT && BINFMT_ELF)
>     *
>     * Restart config...
>     *
>     *
>     * Paravirtualized guest support
>     *
>     Paravirtualized guest support (PARAVIRT_GUEST) [N/y/?] (NEW) aborted!
> 
>     Console input/output is redirected. Run 'make oldconfig' to update configuration.
> 
>     make[1]: *** [silentoldconfig] Error 1
>     make: *** [silentoldconfig] Error 2
> 
> Or did I miss something?
> 
> However, oldconfig just works (with an error for each new symbol):
>     $ make oldconfig </dev/null
>     [--SNIP--]
>       NOP USB Transceiver Driver (NOP_USB_XCEIV) [N/m/?] (NEW)
>     Error in reading or end of file.
> 
>     #
>     # configuration written to .config
>     #

That (silent)oldconfig with stdin redirection throws an error if it
encounters a new option is expected and correct. The bug here is that
_normal_ oldconfig run apparently does not set all the options. I.e.

$ yes "" | make oldconfig; make silentoldconfig </dev/null

should always pass.

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