linux-kernel - Re: linux-next: build failure after merge of the ecryptfs tree

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] [day] [month] [year] [list]

Message-ID: <b1271af4-42c7-42c2-44ef-8f47b9f5a145@gmail.com>
Date:   Wed, 15 May 2019 16:28:03 +1200
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Tyler Hicks <tyhicks@...onical.com>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the ecryptfs tree

Hi,

Am 14.05.2019 um 13:22 schrieb Michael Schmitz:
> Stephen,
>
> I wasn't aware of the other asix module when submitting the phy driver.
> The phy module gets autoloaded based on the PHY ID, so there's no reason
> why it couldn't be renamed.
>
> May I suggest ax88796b for the new module name?

I've got a patch series ready to go for this (compile tested).

I suppose this is meant to go through the net tree, Dave?

Cheers,

	Michael


>
> Cheers,
>
>     Michael
>
>
>
> On 14/05/19 12:56 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> [excessive quoting for new CC's]
>>
>> On Tue, 14 May 2019 09:40:53 +0900 Masahiro Yamada
>> <yamada.masahiro@...ionext.com> wrote:
>>> On Tue, May 14, 2019 at 9:16 AM Stephen Rothwell
>>> <sfr@...b.auug.org.au> wrote:
>>>> I don't know why this suddenly appeared after mergeing the ecryptfs
>>>> tree
>>>> since nothin has changed in that tree for some time (and nothing in
>>>> that
>>>> tree seems relevant).
>>>>
>>>> After merging the ecryptfs tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> scripts/Makefile.modpost:112: target '.tmp_versions/asix.mod'
>>>> doesn't match the target pattern
>>>> scripts/Makefile.modpost:113: warning: overriding recipe for target
>>>> '.tmp_versions/asix.mod'
>>>> scripts/Makefile.modpost:100: warning: ignoring old recipe for
>>>> target '.tmp_versions/asix.mod'
>>>> scripts/Makefile.modpost:127: target '.tmp_versions/asix.mod'
>>>> doesn't match the target pattern
>>>> scripts/Makefile.modpost:128: warning: overriding recipe for target
>>>> '.tmp_versions/asix.mod'
>>>> scripts/Makefile.modpost:113: warning: ignoring old recipe for
>>>> target '.tmp_versions/asix.mod'
>>>> make[2]: Circular .tmp_versions/asix.mod <- __modpost dependency
>>>> dropped.
>>>> Binary file .tmp_versions/asix.mod matches: No such file or directory
>>>> make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
>>>> make[1]: *** [Makefile:1290: modules] Error 2
>>>>
>>>> The only clue I can see is that asix.o gets built in two separate
>>>> directories (drivers/net/{phy,usb}).
>>> Module name should be unique.
>>>
>>> If both are compiled as a module,
>>> they have the same module names:
>>>
>>> drivers/net/phy/asix.ko
>>> drivers/net/usb/asix.ko
>>>
>>> If you see .tmp_version directory,
>>> you will see asix.mod
>>>
>>> Perhaps, one overwrote the other,
>>> or it already got broken somehow.
>> So, the latter of these drivers (drivers/net/phy/asix.c) was added in
>> v4.18-rc1 by commit
>>
>>    31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver")
>>
>> If we can't have 2 modules with the same base name, is it too late to
>> change its name?
>>
>> I am sort of suprised that noone else has hit this in the past year.
>>
>>>> I have the following files in the object directory:
>>>>
>>>> ./.tmp_versions/asix.mod
>>>> ./drivers/net/usb/asix.ko
>>>> ./drivers/net/usb/asix.mod.o
>>>> ./drivers/net/usb/asix.o
>>>> ./drivers/net/usb/asix_common.o
>>>> ./drivers/net/usb/asix_devices.o
>>>> ./drivers/net/usb/.asix.ko.cmd
>>>> ./drivers/net/usb/.asix.mod.o.cmd
>>>> ./drivers/net/usb/.asix.o.cmd
>>>> ./drivers/net/usb/asix.mod.c
>>>> ./drivers/net/usb/.asix_common.o.cmd
>>>> ./drivers/net/usb/.asix_devices.o.cmd
>>>> ./drivers/net/phy/asix.ko
>>>> ./drivers/net/phy/asix.o
>>>> ./drivers/net/phy/.asix.ko.cmd
>>>> ./drivers/net/phy/.asix.mod.o.cmd
>>>> ./drivers/net/phy/asix.mod.o
>>>> ./drivers/net/phy/asix.mod.c
>>>> ./drivers/net/phy/.asix.o.cmd
>>>>
>>>> ./.tmp_versions/asix.mod
>>>>
>>>> Looks like this:
>>>>
>>>> ------------------------------------------
>>>> drivers/net/phy/asix.ko
>>>> drivers/net/phy/asix.o
>>>>
>>>>
>>>> ------------------------------------------
>>>>
>>>> What you can't see above are the 256 NUL bytes at the end of the file
>>>> (followed by a NL).
>>>>
>>>> This is from a -j 80 build.  Surely there is a race condition here
>>>> if the
>>>> file in .tmp_versions is only named for the base name of the module and
>>>> we have 2 modules with the same base name.
>>>>
>>>> I removed that file and redid the build and it succeeded.
>>>>
>>>> Mind you, I have no itdea why this file was begin rebuilt, the merge
>>>> only touched these files:
>>>>
>>>> fs/ecryptfs/crypto.c
>>>> fs/ecryptfs/keystore.c
>>>>
>>>> Puzzled ... :-(