All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	jeyu@kernel.org, jikos@kernel.org, lpechacek@suse.cz,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andy Lutomirski <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Oleg Nesterov <oleg@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 0/3] livepatch: Introduce force sysfs attribute
Date: Mon, 2 Oct 2017 13:18:14 +0200	[thread overview]
Message-ID: <20171002111814.GE8637@pathway.suse.cz> (raw)
In-Reply-To: <alpine.LSU.2.21.1708301449270.6379@san.suse.cz>

On Wed 2017-08-30 14:51:16, Miroslav Benes wrote:
> On Wed, 16 Aug 2017, Josh Poimboeuf wrote:
> 
> > On Wed, Aug 16, 2017 at 04:50:07PM +0200, Petr Mladek wrote:
> > > On Fri 2017-08-11 16:11:31, Josh Poimboeuf wrote:
> > > > On Thu, Aug 10, 2017 at 12:48:12PM +0200, Miroslav Benes wrote:
> > > > > Now there is a sysfs attribute called "force", which provides two
> > > > > functionalities, "signal" and "force" (previously "unmark"). I haven't
> > > > > managed to come up with better names. Proposals are welcome. On the
> > > > > other hand I do not mind it much.
> > > > 
> > > > Now "force" has two meanings, which is a little confusing.  What do you
> > > > think about just having two separate write-only sysfs flags?
> > > > 
> > > >   echo 1 > /sys/kernel/livepatch/signal
> > > >   echo 1 > /sys/kernel/livepatch/force
> > > 
> > > I like the simplicity but I wonder if there might be more actions
> > > that need to be forced in the future. Then this might cause
> > > confusion.
> > > 
> > > For example, we have force_module_load attribute in kGraft.
> > > It allows to load a module even when it is refused by a livepatch.
> > > It is handy when there is a harmless bug in the patch.
> 
> We can add force_module_load attribute too in that case. But I see your 
> point, I just don't think it would be that serious as far as confusion is 
> concerned.
> 
> > What if we put the flags in the per-patch dir?
> > 
> >   /sys/kernel/livepatch/<patch>/signal
> >   /sys/kernel/livepatch/<patch>/force
> > 
> > That seems pretty unambiguous.  The "force" is specific to the patch, it
> > clearly means we are forcing the patch.
> 
> Petr, would this solve your worries?

I like it.

Best Regards,
Petr

  reply	other threads:[~2017-10-02 11:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-10 10:48 [PATCH v2 0/3] livepatch: Introduce force sysfs attribute Miroslav Benes
2017-08-10 10:48 ` [PATCH v2 1/3] livepatch: Add " Miroslav Benes
2017-08-11 21:13   ` Josh Poimboeuf
2017-08-14 14:03     ` Miroslav Benes
2017-08-16 13:15   ` Petr Mladek
2017-08-28 14:58     ` Miroslav Benes
2017-10-02 11:05       ` Petr Mladek
2017-08-10 10:48 ` [PATCH v2 2/3] livepatch: send a fake signal to all blocking tasks Miroslav Benes
2017-08-11 21:30   ` Josh Poimboeuf
2017-08-12 20:03     ` Jiri Kosina
2017-08-14 14:29     ` Miroslav Benes
2017-08-16 14:37   ` Petr Mladek
2017-08-10 10:48 ` [PATCH v2 3/3] livepatch: force transition process to finish Miroslav Benes
2017-08-30  7:24   ` Pavel Machek
2017-08-30 12:48     ` Miroslav Benes
2017-08-30 15:29       ` Josh Poimboeuf
2017-08-11 21:11 ` [PATCH v2 0/3] livepatch: Introduce force sysfs attribute Josh Poimboeuf
2017-08-14  8:49   ` Miroslav Benes
2017-08-16 14:50   ` Petr Mladek
2017-08-16 15:26     ` Josh Poimboeuf
2017-08-30 12:51       ` Miroslav Benes
2017-10-02 11:18         ` Petr Mladek [this message]
2017-08-16 13:31 ` Petr Mladek
2017-08-30 12:52   ` Miroslav Benes

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=20171002111814.GE8637@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=hpa@zytor.com \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=lpechacek@suse.cz \
    --cc=luto@kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=oleg@redhat.com \
    --cc=tglx@linutronix.de \
    /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.