public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Marek <mmarek@suse.cz>, Noam Camus <noamc@ezchip.com>,
	"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: Makefile race between jobs
Date: Mon, 10 Dec 2012 16:53:25 +0530	[thread overview]
Message-ID: <50C5C62D.8080904@synopsys.com> (raw)
In-Reply-To: <201212101059.28161.arnd@arndb.de>

On Monday 10 December 2012 04:29 PM, Arnd Bergmann wrote:
> On Monday 10 December 2012, Vineet Gupta wrote:
>>
>> On Monday 10 December 2012 04:00 PM, Michal Marek wrote:
>>> On 10.12.2012 11:11, Vineet Gupta wrote:
>>>> ARC Port caches current task pointer in a register - thus we have a
>>>> global asm register definition in current.h
>>>> In the past, a customer ran into issue when porting some "really
>>>> portable" code to kernel - such that asm/current.h didn't make it into
>>>> the build of their module - via normal header includes - strange but
>>>> true. Thus forcing current.h via way of -include seemed like a
>>>> safe/sensible way.
>>>
>>> To me that sounds like either an arc header is using the define but
>>> lacking an include of asm/current.h, or the code is lacking asm/current.h.
>>>
>>
>> It was latter - customer code was lacking include of asm/current.h
>> At any rate, independent of above, since we are dealing with a global
>> reg definition, IMHO, forcing the -include for each file built ensures
>> the generated code correctness (gcc reg allocator not fiddling with that
>> reg) - w/o "assuming" it would.
> 
> I'm not convinced that adding the -include to the kernel Makefile
> actually helps here: If a third party module is built outside of
> the kernel sources, it probably also does not use the kernel Makefile,
> and it may not have access to the kernel header files at all.

There might be NDA issues otherwise I would have uploaded the customer
code. It was third party code alright - but built in tree - and
interestingly not using any kernel headers - even linux/types.h. I was
dazzled myself when I found the root cause (due to r25 getting clobbered
mysteriously after some code from that driver had run).
So seriously it was really portable code.


> That aside, can't you just have an arch specific header file that
> reservers the register but does not rely on asm-generic/types.h?
> That would eliminate the need to serialize the build process.

The code in asm/current.h is as follows:

#ifdef CONFIG_ARC_CURR_IN_REG
register struct task_struct *curr_arc asm("r25");
#define current (curr_arc)
#else
#include <asm-generic/current.h>
#endif

The Makefile snippet in 3.2 (which Noam is using) is
LINUXINCLUDE	+=  -include ${src}/arch/arc/include/asm/current.h

I'm ready to change it to anything which helps alleviate the need for
build system change - w/o terribly uglifying this code.

However, in the 3.7 port which I posted to lists, the Makefile fragment
has already been changed due to other reasons.

ifdef CONFIG_ARC_CURR_IN_REG
# Can't do unconditionally because of recursive include
# issues due to <linux/thread_info.h>
LINUXINCLUDE	+=  -include ${src}/arch/arc/include/asm/current.h
endif

Does that make the problem report moot already - since the issue only
seems to happen for !CONFIG_ARC_CURR_IN_REG in which case the header
won't be -include ed

-Vineet

> 
> 	Arnd
> 


      reply	other threads:[~2012-12-10 11:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <264C179F799EF24AB26D5319053335E80CC3049A10@ezexch.ezchip.com>
     [not found] ` <50C4B8F3.6030704@suse.cz>
     [not found]   ` <264C179F799EF24AB26D5319053335E80CC31B9D41@ezexch.ezchip.com>
2012-12-10  9:45     ` Makefile race between jobs Michal Marek
2012-12-10 10:06       ` Noam Camus
2012-12-10 10:11       ` Vineet Gupta
2012-12-10 10:30         ` Michal Marek
2012-12-10 10:36           ` Vineet Gupta
2012-12-10 10:59             ` Arnd Bergmann
2012-12-10 11:23               ` Vineet Gupta [this message]

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=50C5C62D.8080904@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=noamc@ezchip.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox