All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Peter Rajnoha <prajnoha@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kobject: record and send PREV_SEQNUM with uevents
Date: Mon, 16 Oct 2017 16:49:03 +0200	[thread overview]
Message-ID: <20171016144903.GA8410@kroah.com> (raw)
In-Reply-To: <f187f732-11fd-9a96-8771-62151861754d@redhat.com>

On Mon, Oct 16, 2017 at 04:00:26PM +0200, Peter Rajnoha wrote:
> On 10/16/2017 03:55 PM, Greg KH wrote:
> > On Mon, Oct 16, 2017 at 02:35:44PM +0200, Peter Rajnoha wrote:
> >> Record last uevent seqnum that was used with kobject's uevent and send
> >> it with next uevent as PREV_SEQNUM=<num> variable.
> >>
> >> This enhances the way we are able to track and handle uevents in userspace
> >> if we are trying to catch up with all the uevents that were generated
> >> while we were not listening or the uevents which were not delivered.
> >> This may happen if the userspace listener is not running yet when the
> >> uevent is triggered or there's a period of time when it's not listening
> >> (e.g. because the userspace listener is being restarted while a new
> >> uevent fires).
> >>
> >> A userspace listener can compare the last uevent seqnum it knows about
> >> with the last uevent seqnum the kernel reports through uevents delivered
> >> to userspace, both genuine and synthetic ones (the ones generated by
> >> writing uevent action name to /sys/.../uevent file). Then, if needed,
> >> userspace may execute appropriate actions based on that. We don't need
> >> to reevaluate and recheck all items, instead, we can concentrate only
> >> on items for which we really and actually need to reflect changed state
> >> in kernel while the userspace listener was not listening for uevents.
> >>
> >> Signed-off-by: Peter Rajnoha <prajnoha@redhat.com>
> >> ---
> >>  include/linux/kobject.h |  1 +
> >>  lib/kobject.c           |  1 +
> >>  lib/kobject_uevent.c    | 15 +++++++++++++--
> >>  3 files changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> >> index e0a6205caa71..ee6db28b6186 100644
> >> --- a/include/linux/kobject.h
> >> +++ b/include/linux/kobject.h
> >> @@ -73,6 +73,7 @@ struct kobject {
> >>  #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
> >>  	struct delayed_work	release;
> >>  #endif
> >> +	u64			last_uevent_seqnum;
> >>  	unsigned int state_initialized:1;
> >>  	unsigned int state_in_sysfs:1;
> >>  	unsigned int state_add_uevent_sent:1;
> >> diff --git a/lib/kobject.c b/lib/kobject.c
> >> index 763d70a18941..2cc809f10ae7 100644
> >> --- a/lib/kobject.c
> >> +++ b/lib/kobject.c
> >> @@ -190,6 +190,7 @@ static void kobject_init_internal(struct kobject *kobj)
> >>  		return;
> >>  	kref_init(&kobj->kref);
> >>  	INIT_LIST_HEAD(&kobj->entry);
> >> +	kobj->last_uevent_seqnum = 0;
> >>  	kobj->state_in_sysfs = 0;
> >>  	kobj->state_add_uevent_sent = 0;
> >>  	kobj->state_remove_uevent_sent = 0;
> >> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> >> index f237a09a5862..f1cbed06a395 100644
> >> --- a/lib/kobject_uevent.c
> >> +++ b/lib/kobject_uevent.c
> >> @@ -454,8 +454,19 @@ int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
> >>  	}
> >>  
> >>  	mutex_lock(&uevent_sock_mutex);
> >> -	/* we will send an event, so request a new sequence number */
> >> -	retval = add_uevent_var(env, "SEQNUM=%llu", (unsigned long long)++uevent_seqnum);
> >> +	/*
> >> +	 * We will send an event, so request a new sequence number.
> >> +	 * Also, record the number for next uevent's PREV_SEQNUM.
> >> +	 */
> >> +	kobj->last_uevent_seqnum = ++uevent_seqnum;
> >> +	retval = add_uevent_var(env, "SEQNUM=%llu",
> >> +				(unsigned long long)uevent_seqnum);
> >> +	if (retval) {
> >> +		mutext_unlock(&uevent_sock_mutex);
> >> +		goto exit;
> >> +	}
> >> +	retval = add_uevent_var(env, "PREV_SEQNUM=%llu",
> >> +				(unsigned long long)kobj->last_uevent_seqnum);
> > 
> > I'm confused, why are we storing "last_uevent_seqnum" here at all, if it
> > is only just the current one-1?  What else do you do with that value?
> I'm sorry, I've sent incorrect patch by mistake. This is the correct one:

Ok, this is a bit better (but it's not in a format I could apply it in,
if I wanted to...)

> From 91fa0d0f5c52b959a5ca4cc79d1a4f5970db75e2 Mon Sep 17 00:00:00 2001
> From: Peter Rajnoha <prajnoha@redhat.com>
> Date: Thu, 12 Oct 2017 11:33:48 +0200
> Subject: [PATCH] kobject: record and send PREV_SEQNUM with uevents
> 
> Record last uevent seqnum that was used with kobject's uevent and send
> it with next uevent as PREV_SEQNUM=<num> variable.
> 
> This enhances the way we are able to track and handle uevents in userspace
> if we are trying to catch up with all the uevents that were generated
> while we were not listening or the uevents which were not delivered.
> This may happen if the userspace listener is not running yet when the
> uevent is triggered or there's a period of time when it's not listening
> (e.g. because the userspace listener is being restarted while a new
> uevent fires).
> 
> A userspace listener can compare the last uevent seqnum it knows about
> with the last uevent seqnum the kernel reports through uevents delivered
> to userspace, both genuine and synthetic ones (the ones generated by
> writing uevent action name to /sys/.../uevent file). Then, if needed,
> userspace may execute appropriate actions based on that. We don't need
> to reevaluate and recheck all items, instead, we can concentrate only
> on items for which we really and actually need to reflect changed state
> in kernel while the userspace listener was not listening for uevents.
> 
> Signed-off-by: Peter Rajnoha <prajnoha@redhat.com>

I don't really understand what userspace can do with this.  Why does it
matter what the sequence number was for a specific kobject?  What can
happen because of this?

Do you have any example libudev code changes to show this in action so I
can maybe understand the need?

thanks,

greg k-h

  reply	other threads:[~2017-10-16 14:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-16 12:35 [PATCH] kobject: record and send PREV_SEQNUM with uevents Peter Rajnoha
2017-10-16 13:55 ` Greg KH
2017-10-16 14:00   ` Peter Rajnoha
2017-10-16 14:49     ` Greg KH [this message]
2017-10-17 10:04       ` Peter Rajnoha
2017-10-17 13:26         ` Greg KH
2017-10-18  7:21           ` Peter Rajnoha
2017-10-18  9:42             ` Peter Rajnoha

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=20171016144903.GA8410@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prajnoha@redhat.com \
    /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.