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]
Date:   Fri, 17 Aug 2018 09:47:45 +0200
From:   Andrzej Pietrasiewicz <andrzej.p@...sung.com>
To:     Bjørn Forsman <bjorn.forsman@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, forney@...gle.com,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Subject: Re: [PATCH] Revert
 "kbuild: create deterministic initramfs directory listings"

Hi Bjørn,

W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
> <andrzej.p@...sung.com> wrote:
>>
>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>
>> The reverted commit introduces broken builds. Even though the cpio archive
>> does contain all the specified files, it seems that the kernel, while
>> populating rootfs, scans the cpio buffer linearly and fails to create
>> files whose parent directories are nonexistent at the moment of this failed
>> creation. As a result, such files are not accessible when kernel boots into
>> initramfs.
>>

<snip>

> 
> I'm unable to reproduce it. On my system the listing is sorted so that
> it works (parent directories appear before files). I tried to run with
> LANG=C and it also sorts correctly. What is your LANG=? I think we
> better add a LANG=C somewhere in the kernel build system, because I
> think you have a LANG= that makes it sort differently. A quick fix
> would of course be to insert it right next to sort, but there may be
> other places that may break due to LANG= settings.
> 

Thanks for the tip. My LANG is pl_PL.UTF-8. Indeed, prefixing the "sort"
invocation in question with LANG=C does solve the problem. I don't feel
competent enough to say whether this is the correct place for the fix,
or if the fix should be made elsewhere. Another option is that it is the
"sort" itself that should be fixed (or the locale, or both).

Would you be able (as the author of the patch in question) to check if
there are other locales which cause the problem?

Thanks,

Andrzej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ