From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH] thread_info: include <current.h> for THREAD_INFO_IN_TASK (WAS: [PATCH 2/3] sched/preempt: include asm/current.h)
Date: Tue, 18 Oct 2016 12:34:40 +0200 [thread overview]
Message-ID: <20161018103440.GA4061@osiris> (raw)
In-Reply-To: <20161017173315.GB23170@leverpostej>
On Mon, Oct 17, 2016 at 06:33:15PM +0100, Mark Rutland wrote:
> On Mon, Oct 17, 2016 at 03:48:13PM +0100, Mark Rutland wrote:
> > On Fri, Oct 14, 2016 at 11:42:25AM +0100, Mark Rutland wrote:
> > > When CONFIG_THREAD_INFO_IN_TASK is selected, the current_thread_info()
> > > macro relies on current having been defined prior to its use. However,
> > > not all users of current_thread_info() include <asm/current.h>, and thus
> > > current is not guaranteed to be defined.
> > >
> > > When CONFIG_THREAD_INFO_IN_TASK is not selected, it's possible that
> > > get_current() / current are based upon current_thread_info(), and
> > > <asm/current.h> includes <asm/thread_info.h>. Thus always including
> > > <asm/current.h> would result in circular dependences on some platforms.
> > >
> > > To ensure both cases work, this patch includes <asm/current.h>, but only
> > > when CONFIG_THREAD_INFO_IN_TASK is selected.
> > >
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > ---
> > > include/linux/thread_info.h | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > As discussed, it would be great if this could go in along with the patch to
> > > make thread_info arch-specific again, to make merging the arch-specific parts
> > > easier (for arm64 and s390).
> >
> > Urrgh; I've just recalled that this patch alone is insufficient. The
> > h8300 arch code has an unfixed bug [1], and relies on some implicit
> > definition ordering that will be broken by this patch.
> >
> > I have a workaround/cleanup for core code that I'll send with an updated
> > version of my arm64 series shortly.
>
> Looks like I spoke too soon. I have another circular include issue with
> raw_smp_processor_id() and task_struct::cpu to solve -- it looks like
> s390 doesn't suffer from that per my reading of your headers.
That's correct.
> In the mean time, I've pushed out a branch [2] with the common patches,
> atop of v4.9-rc1.
I just verified that your branch works fine for s390 (with and without the
THREAD_INFO_IN_TASK conversion).
Thanks,
Heiko
next prev parent reply other threads:[~2016-10-18 10:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 11:57 [PATCH 0/3] THREAD_INFO_IN_TASK_STRUCT vs generic preemption code Heiko Carstens
2016-10-13 11:57 ` [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again Heiko Carstens
2016-10-13 23:41 ` Mark Rutland
2016-10-13 23:51 ` Andy Lutomirski
2016-10-13 11:57 ` [PATCH 2/3] sched/preempt: include asm/current.h Heiko Carstens
2016-10-13 23:25 ` Mark Rutland
2016-10-14 8:16 ` Heiko Carstens
2016-10-14 10:42 ` [PATCH] thread_info: include <current.h> for THREAD_INFO_IN_TASK (WAS: [PATCH 2/3] sched/preempt: include asm/current.h) Mark Rutland
2016-10-17 14:48 ` Mark Rutland
2016-10-17 17:33 ` Mark Rutland
2016-10-18 10:34 ` Heiko Carstens [this message]
2016-10-13 11:57 ` [PATCH 3/3] s390: move thread_info into task_struct Heiko Carstens
2016-10-13 21:52 ` [PATCH 0/3] THREAD_INFO_IN_TASK_STRUCT vs generic preemption code Andy Lutomirski
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=20161018103440.GA4061@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@linux-foundation.org \
/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.