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:	Wed, 28 Aug 2013 16:27:46 +0000
From:	"Yang, Fei" <fei.yang@...el.com>
To:	Michal Marek <mmarek@...e.cz>
CC:	Sam Ravnborg <sam@...nborg.org>,
	"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
	"'linux-kernel@...r.kernel.org' (linux-kernel@...r.kernel.org)" 
	<linux-kernel@...r.kernel.org>
Subject: RE: Can anyone suggest a better fix? Not sure if I understand the
 problem, but the patch fixed it

>>>> From: Fei Yang <fei.yang@...el.com>
>>>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>>>> Subject: [PATCH] FIXDEP: error opening depfile
>>>>  
>>>> Met a kernel build issue where fixdep fails to open a depfile,
>>>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: 
>>>> No such file or directory
>>>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
>>>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the 
>>>> expected file was not created, but the assumption that the file had 
>>>> been created might not be true, so simply return for such failure.
>>> 
>>> I tried to grep:
>>> git grep "driver-name"
>>>
>>> No hits.
>>>
>>> Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?
>>> 
>> Oh, I changed the driver and file name in the error message to avoid 
>> unnecessary confusion

>You achieved quite the opposite :-).
Yes, that appears to be a bad idea.

>> as the driver is not an upstream one. But this issue happens randomly, 
>> not 100% reproducible. And it happens on different driver sometimes.

>Are you able to reproduce this with the vanilla kernel? If so, details please.
I have not tried vanilla kernel.

>If not, then this can be something with your module's build system. Are you using anything fancier than
>
>$ cat Makefile
>obj-m += my-module.o
>$ make -C <kernel build tree> M=$PWD

> Michal

Nothing fancy except the kernel build is triggered by Android build system. And the driver is being built into the kernel with obj-(CONFIG_MY_DRIVER) += my-driver.o, so it's not even a loadable module.
I thought fixdep is about finding module dependency, and it isn't needed for built-in drivers. Please correct me if I'm wrong. I want to understand if the .d file had never been generated or had been generated but deleted by the time fixdep tries to open it.


Fei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ