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

[Michael Schmitz]

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@xxxxxxxxxxxxx> wrote:
> > > On Tue, May 14, 2019 at 9:16 AM Stephen Rothwell
> > > <sfr@xxxxxxxxxxxxxxxx> 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 ... :-(