From: Jiri Slaby <jslaby@suse.cz>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: live-patching@vger.kernel.org, jpoimboe@redhat.com,
sjenning@redhat.com, jkosina@suse.cz, vojtech@suse.cz,
mingo@redhat.com, linux-kernel@vger.kernel.org,
Miroslav Benes <mbenes@suse.cz>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-s390@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org
Subject: Re: [RFC kgr on klp 4/9] livepatch: add kgr infrastructure
Date: Tue, 05 May 2015 15:27:19 +0200 [thread overview]
Message-ID: <5548C537.4050004@suse.cz> (raw)
In-Reply-To: <20150504142301.1405a5c0@mschwide>
On 05/04/2015, 02:23 PM, Martin Schwidefsky wrote:
> On Mon, 4 May 2015 13:40:20 +0200
> Jiri Slaby <jslaby@suse.cz> wrote:
>
>> This means:
>> * add a per-thread flag to indicate whether a task is in the old or in
>> the new universe,
>> * reset it in _slow_ paths of syscall's entry/exit,
>> * add helpers around the flag to sched.h,
>> * export the status in /proc/<pid>/kgr_in_progress,
>
>> @@ -217,6 +226,7 @@ ENTRY(system_call)
>> mvc __PT_INT_CODE(4,%r11),__LC_SVC_ILC
>> stg %r14,__PT_FLAGS(%r11)
>> .Lsysc_do_svc:
>> + HANDLE_KGRAFT %r12
>> lg %r10,__TI_sysc_table(%r12) # address of system call table
>> llgh %r8,__PT_INT_CODE+2(%r11)
>> slag %r8,%r8,2 # shift and test for svc 0
>
> This is not the slow path, .Lsysc_do_svc is on the main svc path. It is
> "only" two instruction but nevertheless this should be avoided.
Hi,
the commit log says the reset is in the slow path, not the test. But OK,
we can optimize, see below.
> One way is to combine it with the _TIF_TRACE mechanics:
>
> .Lsysc_nr_ok:
> xc __SF_BACKCHAIN(8,%r15),__SF_BACKCHAIN(%r15)
> stg %r2,__PT_ORIG_GPR2(%r11)
> stg %r7,STACK_FRAME_OVERHEAD(%r15)
> lgf %r9,0(%r8,%r10) # get system call add.
> -> tm __TI_flags+6(%r12),_TIF_TRACE>>8
> -> jnz .Lsysc_tracesys
> basr %r14,%r9 # call sys_xxxx
> stg %r2,__PT_R2(%r11) # store return value
>
> Add _TIF_KGR_IN_PROGRESS to _TIF_TRACE and branch to a new label,
> e.g. to .Lsysc_trace. Distinguish between _TIF_KGR_IN_PROGRESS and
> the other trace reasons and either call s390_handle_kgraft or
> do_syscall_trace_enter / do_syscall_trace_exit.
>
> The same for the exit work, add _TIF_KGR_IN_PROGRESS to _TIF_WORK
> and sort out the reason in .Lsysc_work. That avoids another two
> instructions on the main system call path.
I considered this, but there was no space in the word.
_TIF_WORK is:
TIF_NOTIFY_RESUME 0
TIF_SIGPENDING 1
TIF_NEED_RESCHED 2
TIF_UPROBE 7
_TIF_TRACE is:
TIF_SYSCALL_TRACE 3
TIF_SYSCALL_AUDIT 4
TIF_SECCOMP 5
TIF_SYSCALL_TRACEPOINT 6
=====
What I could do is to split them and make this setup:
_TIF_WORK:
TIF_NOTIFY_RESUME 0
TIF_SIGPENDING 1
TIF_NEED_RESCHED 2
TIF_KGR_IN_PROGRESS_W 3
TIF_UPROBE 7
_TIF_TRACE:
TIF_SYSCALL_TRACE 24
TIF_SYSCALL_AUDIT 25
TIF_SECCOMP 26
TIF_SYSCALL_TRACEPOINT 27
TIF_KGR_IN_PROGRESS_T 28
=====
Then make TIF_KGR_IN_PROGRESS_W fire when "tm"-ing _TIF_WORK in
"__TI_flags+7". TIF_KGR_IN_PROGRESS_T will work along with _TIF_TRACE
using "tm" on "__TI_flags+4".
What do you think?
thanks,
--
js
suse labs
next prev parent reply other threads:[~2015-05-05 13:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 11:40 [RFC kgr on klp 1/9] livepatch: make kobject in klp_object statically allocated Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 2/9] livepatch: introduce patch/func-walking helpers Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 3/9] livepatch: add klp_*_to_patch helpers Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 4/9] livepatch: add kgr infrastructure Jiri Slaby
2015-05-04 12:23 ` Martin Schwidefsky
2015-05-05 13:27 ` Jiri Slaby [this message]
2015-05-05 14:34 ` Martin Schwidefsky
2015-05-04 11:40 ` [RFC kgr on klp 5/9] livepatch: teach klp about consistency models Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 6/9] livepatch: do not allow failure while really patching Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 7/9] livepatch: propagate the patch status to functions Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 8/9] livepatch: add kgraft-like patching Jiri Slaby
2015-05-04 11:40 ` [RFC kgr on klp 9/9] livepatch: send a fake signal to all tasks Jiri Slaby
2015-05-04 14:34 ` Oleg Nesterov
2015-05-06 12:58 ` Miroslav Benes
2015-05-04 12:20 ` [RFC kgr on klp 0/9] kGraft on the top of KLP Jiri Slaby
2015-05-04 15:44 ` Josh Poimboeuf
2015-05-04 22:48 ` Jiri Kosina
2015-05-05 3:43 ` Josh Poimboeuf
2015-05-05 6:14 ` Jiri Kosina
2015-05-05 16:24 ` Josh Poimboeuf
2015-05-12 9:45 ` Jiri Kosina
2015-05-12 15:20 ` Josh Poimboeuf
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=5548C537.4050004@suse.cz \
--to=jslaby@suse.cz \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mingo@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=sjenning@redhat.com \
--cc=tglx@linutronix.de \
--cc=vojtech@suse.cz \
--cc=x86@kernel.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 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).