From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>, Dave Hansen <dave@sr71.net>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH] s390, sched: Fix thread_struct move fallout to __switch_to()
Date: Mon, 20 Jul 2015 10:33:47 +0200 [thread overview]
Message-ID: <20150720103347.38979f15@mschwide> (raw)
In-Reply-To: <20150720082004.GB12468@gmail.com>
On Mon, 20 Jul 2015 10:20:04 +0200
Ingo Molnar <mingo@kernel.org> wrote:
>
> * Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > Unfortunately not true. It breaks the build on s390 since a couple of
> > displacements used in asm code now get too large:
> >
> > arch/s390/kernel/entry.S:181: Error: operand out of range (0x00000000000018a8 is not between 0x0000000000000000 and 0x0000000000000fff)
> > arch/s390/kernel/entry.S:191: Error: operand out of range (0x00000000000018a8 is not between 0x0000000000000000 and 0x0000000000000fff)
> > arch/s390/kernel/entry.S:423: Error: operand out of range (0x0000000000001924 is not between 0x0000000000000000 and 0x0000000000000fff)
> > arch/s390/kernel/entry.S:437: Error: operand out of range (0x00000000000018e8 is not between 0x0000000000000000 and 0x0000000000000fff)
> > arch/s390/kernel/entry.S:438: Error: operand out of range (0x00000000000018e0 is not between 0x0000000000000000 and 0x0000000000000fff)
> > arch/s390/kernel/entry.S:439: Error: operand out of range (0x00000000000018f0 is not between 0x0000000000000000 and 0x0000000000000fff)
> > make[1]: *** [arch/s390/kernel/entry.o] Error 1
> >
> > Let's see how we can fix this.
>
> Sorry about this!
>
> So I looked at the __switch_to() assembly, and the main complication appears to be
> that we have two uses of 'prev':
>
> lg %r4,__THREAD_info(%r2) # get thread_info of prev
>
>
> stg %r15,__THREAD_ksp(%r2) # store kernel stack of prev
>
> the __THREAD_info offset is best expressed relative to task_struct - the
> __THREAD_ksp offset is best expressed relative to thread_struct.
>
> I.e. I think the best fix would be to extend the signature of s390's __switch_to()
> from (prev,next) to (prev,next,prev_thread,next_thread).
>
> Is the C parameter mapping r2,r3,r4,r5? If yes then the patch below should do the
> trick. (Utterly untested.)
>
> Note:
>
> - I renamed __THREAD_info to __TASK_thread_info, to better separate task_struct
> and thread_struct offsets syntactically and visually.
>
> - I removed __THREAD_mm_segment which is unused
>
> I also looked at fixing pgm_check_handler(), but my s390-fu gave up completely on
> that one: task_struct is in 'r14', but this is a hardware entry function it
> appears. So to fix it we'd have to pick a temporary register, put thread_struct
> pointer into it, and fix up these offsets:
>
> arch/s390/kernel/asm-offsets.c: DEFINE(__THREAD_per_address, offsetof(struct task_struct, thread.per_event.address));
> arch/s390/kernel/asm-offsets.c: DEFINE(__THREAD_per_paid, offsetof(struct task_struct, thread.per_event.paid));
> arch/s390/kernel/asm-offsets.c: DEFINE(__THREAD_trap_tdb, offsetof(struct task_struct, thread.trap_tdb));
>
> to be thread_struct relative.
Just use the patch I've sent. No worries :-)
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2015-07-20 8:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-18 3:18 [GIT PULL] x86 fixes Ingo Molnar
2015-07-20 7:20 ` Heiko Carstens
2015-07-20 8:00 ` [PATCH] sched, s390: Fix the fallout of increasing the offset of 'thread_struct' within 'task_struct' Ingo Molnar
2015-07-20 8:12 ` Martin Schwidefsky
2015-07-20 8:38 ` Ingo Molnar
2015-07-20 8:56 ` Martin Schwidefsky
2015-07-20 8:20 ` [PATCH] s390, sched: Fix thread_struct move fallout to __switch_to() Ingo Molnar
2015-07-20 8:33 ` Martin Schwidefsky [this message]
2015-07-20 8:34 ` Ingo Molnar
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=20150720103347.38979f15@mschwide \
--to=schwidefsky@de.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dave@sr71.net \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--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.