* linux-next: build failure after merge of the ecryptfs tree
@ 2019-05-14 0:15 Stephen Rothwell
2019-05-14 0:40 ` Masahiro Yamada
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Rothwell @ 2019-05-14 0:15 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Tyler Hicks, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]
Hi all,
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}).
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 ... :-(
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: linux-next: build failure after merge of the ecryptfs tree 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:03 ` Stephen Rothwell 0 siblings, 2 replies; 8+ messages in thread From: Masahiro Yamada @ 2019-05-14 0:40 UTC (permalink / raw) To: Stephen Rothwell Cc: Tyler Hicks, Linux Next Mailing List, Linux Kernel Mailing List Hi Stephen, On Tue, May 14, 2019 at 9:16 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > 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. Thanks. > 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 ... :-( > > -- > Cheers, > Stephen Rothwell -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: build failure after merge of the ecryptfs tree 2019-05-14 0:40 ` Masahiro Yamada @ 2019-05-14 0:56 ` Stephen Rothwell 2019-05-14 1:22 ` Michael Schmitz 2019-05-14 1:03 ` Stephen Rothwell 1 sibling, 1 reply; 8+ messages in thread From: Stephen Rothwell @ 2019-05-14 0:56 UTC (permalink / raw) To: Masahiro Yamada Cc: Tyler Hicks, Linux Next Mailing List, Linux Kernel Mailing List, Michael Schmitz, David S. Miller [-- Attachment #1: Type: text/plain, Size: 3733 bytes --] 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 ... :-( -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: build failure after merge of the ecryptfs tree 2019-05-14 0:56 ` Stephen Rothwell @ 2019-05-14 1:22 ` Michael Schmitz 2019-05-15 4:28 ` Michael Schmitz 0 siblings, 1 reply; 8+ messages in thread From: Michael Schmitz @ 2019-05-14 1:22 UTC (permalink / raw) To: Stephen Rothwell, Masahiro Yamada Cc: Tyler Hicks, Linux Next Mailing List, Linux Kernel Mailing List, David S. Miller 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? 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 ... :-( ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: build failure after merge of the ecryptfs tree 2019-05-14 1:22 ` Michael Schmitz @ 2019-05-15 4:28 ` Michael Schmitz 0 siblings, 0 replies; 8+ messages in thread From: Michael Schmitz @ 2019-05-15 4:28 UTC (permalink / raw) To: Stephen Rothwell, Masahiro Yamada, David S. Miller Cc: Tyler Hicks, Linux Next Mailing List, Linux Kernel Mailing List 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 ... :-( ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: build failure after merge of the ecryptfs tree 2019-05-14 0:40 ` Masahiro Yamada 2019-05-14 0:56 ` Stephen Rothwell @ 2019-05-14 1:03 ` Stephen Rothwell 2019-05-14 4:16 ` Masahiro Yamada 1 sibling, 1 reply; 8+ messages in thread From: Stephen Rothwell @ 2019-05-14 1:03 UTC (permalink / raw) To: Masahiro Yamada; +Cc: Linux Next Mailing List, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 439 bytes --] Hi Masahiro, Also, this: On Tue, 14 May 2019 09:40:53 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > > 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 Its a bit annoying that the module was even being looked at given nothing it files depend upon had been modified. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: build failure after merge of the ecryptfs tree 2019-05-14 1:03 ` Stephen Rothwell @ 2019-05-14 4:16 ` Masahiro Yamada 2019-05-14 4:49 ` Stephen Rothwell 0 siblings, 1 reply; 8+ messages in thread From: Masahiro Yamada @ 2019-05-14 4:16 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List Hi Stephen, On Tue, May 14, 2019 at 10:04 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Masahiro, > > Also, this: > > On Tue, 14 May 2019 09:40:53 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > > > > 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 > > Its a bit annoying that the module was even being looked at given > nothing it files depend upon had been modified. If you are talking about the rebuild of .tmp_versions/*.mod files, yes, they are cleaned up every time. # Create temporary dir for module support files # clean it up only when building all modules cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \ $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*) I think the reason is that we want to make sure stale modules are not remaining when CONFIG_MY_DRIVER=m is turned into CONFIG_MY_DRIVER=n Rebuilding .mod files is not expensive. I think this behavior can be improved, but that is how it has been working for a long time. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-next: build failure after merge of the ecryptfs tree 2019-05-14 4:16 ` Masahiro Yamada @ 2019-05-14 4:49 ` Stephen Rothwell 0 siblings, 0 replies; 8+ messages in thread From: Stephen Rothwell @ 2019-05-14 4:49 UTC (permalink / raw) To: Masahiro Yamada; +Cc: Linux Next Mailing List, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1177 bytes --] Hi Masahiro, On Tue, 14 May 2019 13:16:37 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > If you are talking about the rebuild of > .tmp_versions/*.mod files, > yes, they are cleaned up every time. > > # Create temporary dir for module support files > # clean it up only when building all modules > cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \ > $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*) > > > I think the reason is that > we want to make sure stale modules are not remaining > when CONFIG_MY_DRIVER=m is turned into CONFIG_MY_DRIVER=n > > > Rebuilding .mod files is not expensive. > > I think this behavior can be improved, but > that is how it has been working for a long time. when you say "not expensive", how long is that? Because an x86_64 allmodconfig build currently produces 7313 of those files, so at .01 seconds each (for example) that would add over a minute to each of my builds ... and I do lots of builds every day. OK, so it may not be that significant (so a millisecond each is obviously not a problem), but just wondering if it can be avoided. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-05-15 4:28 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2019-05-14 1:03 ` Stephen Rothwell 2019-05-14 4:16 ` Masahiro Yamada 2019-05-14 4:49 ` Stephen Rothwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).