All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.