All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	"David S. Miller" <davem@davemloft.net>
Cc: Tyler Hicks <tyhicks@canonical.com>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the ecryptfs tree
Date: Wed, 15 May 2019 16:28:03 +1200	[thread overview]
Message-ID: <b1271af4-42c7-42c2-44ef-8f47b9f5a145@gmail.com> (raw)
In-Reply-To: <c8f0cdf9-7236-30e0-fa11-b6c261bd3250@gmail.com>

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

  reply	other threads:[~2019-05-15  4:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14  0:15 linux-next: build failure after merge of the ecryptfs tree Stephen Rothwell
2019-05-14  0:40 ` Masahiro Yamada
2019-05-14  0:56   ` Stephen Rothwell
2019-05-14  1:22     ` Michael Schmitz
2019-05-15  4:28       ` Michael Schmitz [this message]
2019-05-17 20:25     ` [PATCH 0/3] resolve module name conflict for asix PHY and USB modules Michael Schmitz
2019-05-17 21:20       ` Andrew Lunn
2019-05-18  1:17         ` Michael Schmitz
2019-05-17 20:25     ` [PATCH 1/3] net: phy: new ax88796b.c Asix Electronics PHY driver Michael Schmitz
2019-05-17 20:25     ` [PATCH 2/3] net: 8390: switch X-Surf 100 driver to use ax88796b PHY Michael Schmitz
2019-05-17 20:25     ` [PATCH 3/3] net: phy: remove old Asix Electronics PHY driver Michael Schmitz
2019-05-18  1:14     ` [PATCH v2] net: phy: rename " Michael Schmitz
2019-05-18 14:20       ` Andrew Lunn
2019-05-18 17:48         ` Michael Schmitz
2019-05-18 18:04           ` Andrew Lunn
2019-06-07  5:37     ` [PATCH net v3] " Michael Schmitz
2019-06-07 13:00       ` Andrew Lunn
2019-06-08  1:54         ` Michael Schmitz
2019-06-09 20:24       ` David Miller
2019-05-14  1:03   ` linux-next: build failure after merge of the ecryptfs tree Stephen Rothwell
2019-05-14  4:16     ` Masahiro Yamada
2019-05-14  4:49       ` Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1271af4-42c7-42c2-44ef-8f47b9f5a145@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tyhicks@canonical.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.