All of lore.kernel.org
 help / color / mirror / Atom feed
From: Libor Pechacek <lpechacek@suse.cz>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>, Miroslav Benes <mbenes@suse.cz>,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v4 00/10] klp-convert livepatch build tooling
Date: Fri, 14 Jun 2019 18:36:55 +0200	[thread overview]
Message-ID: <20190614163655.GC15002@fm.suse.cz> (raw)
In-Reply-To: <a0db1cee-8bba-4093-c3ca-4c2fe61b15ba@redhat.com>

On Fri 14-06-19 10:20:09, Joe Lawrence wrote:
> On 6/14/19 4:34 AM, Petr Mladek wrote:
[...]
> > Anyway, I am curious about one thing. I saw:
> > 
> > function __load_mod() {
> > 	local mod="$1"; shift
> > 
> > 	local msg="% modprobe $mod $*"
> > 	log "${msg%% }"
> > 	ret=$(modprobe "$mod" "$@" 2>&1)
> > 	if [[ "$ret" != "" ]]; then
> > 		die "$ret"
> > 	fi
> > 
> > 	# Wait for module in sysfs ...
> > 	loop_until '[[ -e "/sys/module/$mod" ]]' ||
> > 		die "failed to load module $mod"
> > }
> > 
> > Is the waiting for sysfs really necessary here?
> > 
> > Note that it is /sys/module and not /sys/kernel/livepatch/.
> 
> I can't remember if that was just paranoid-protective-bash coding or
> actually required.  Libor provided great feedback on the initial patch
> series that introduced the self-tests, perhaps he remembers.

I don't recall analyzing this spot in detail but looking at it now I don't see
anything wrong with it. While the check is likely superfluous, I'm not against
keeping it in place.

> > My understanding is that modprobe waits until the module succesfully
> > loaded. mod_sysfs_setup() is called before the module init callback.
> > Therefore the sysfs interface should be read before modprobe returns.
> > Do I miss something?
> >
> > If it works different way then there might be some races because
> > mod_sysfs_setup() is called before the module is alive.
> 
> All of this is called from a single bash script function, so in a call stack
> fashion, something like this would occur when loading a livepatch module:
> 
>   [ mod_sysfs_setup() ]
>   modprobe waits for:         .init complete, MODULE_STATE_LIVE
>   __load_mod() waits for:     /sys/module/$mod
>   load_lp_nowait() waits for: /sys/kernel/livepatch/$mod
>   load_lp() waits for:        /sys/kernel/livepatch/$mod/transition = 0
>   test-script.sh
> 
> So I would think that by calling modprobe, we ensure that the module code is
> ready to go.  The /sys/module/$mod check might be redundant as you say, but
> because modprobe completed, we should be safe, no?
> 
> The only "nowait" function we have is load_lp_nowait(), which would let us
> march onward before the livepatch transition may have completed.

And even that one is waiting for the live patch module name appear under
/sys/kernel/livepatch/. This is IMHO acceptable level of paranoia.

Libor
-- 
Libor Pechacek
SUSE Labs

  reply	other threads:[~2019-06-14 16:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 14:38 [PATCH v4 00/10] klp-convert livepatch build tooling Joe Lawrence
2019-05-09 14:38 ` [PATCH v4 01/10] livepatch: Create and include UAPI headers Joe Lawrence
2019-05-09 14:38 ` [PATCH v4 02/10] kbuild: Support for Symbols.list creation Joe Lawrence
2019-05-21 13:48   ` Masahiro Yamada
2019-05-09 14:38 ` [PATCH v4 03/10] livepatch: Add klp-convert tool Joe Lawrence
2019-07-31  2:50   ` Masahiro Yamada
2019-07-31  3:36     ` Masahiro Yamada
2019-08-09 18:42       ` Joe Lawrence
2019-08-13  1:15         ` Masahiro Yamada
2019-05-09 14:38 ` [PATCH v4 04/10] livepatch: Add klp-convert annotation helpers Joe Lawrence
2019-05-09 14:38 ` [PATCH v4 05/10] modpost: Integrate klp-convert Joe Lawrence
2019-05-09 14:38 ` [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules Joe Lawrence
2019-07-31  5:58   ` Masahiro Yamada
2019-08-12 15:56     ` Joe Lawrence
2019-08-15 15:05       ` Masahiro Yamada
2019-08-16  8:19         ` Miroslav Benes
2019-08-16 12:43           ` Joe Lawrence
2019-08-16 19:01             ` Joe Lawrence
2019-08-19  3:50               ` Masahiro Yamada
2019-08-19 15:55                 ` Joe Lawrence
2019-08-20  7:54                   ` Miroslav Benes
2019-08-19  3:49             ` Masahiro Yamada
2019-08-19  7:31               ` Miroslav Benes
2019-08-19 16:02                 ` Joe Lawrence
2019-08-22  3:35                   ` Masahiro Yamada
2019-08-13 10:26     ` Miroslav Benes
2019-05-09 14:38 ` [PATCH v4 07/10] livepatch: Add sample livepatch module Joe Lawrence
2019-08-16 11:35   ` Masahiro Yamada
2019-08-16 12:47     ` Joe Lawrence
2019-05-09 14:38 ` [PATCH v4 08/10] documentation: Update on livepatch elf format Joe Lawrence
2019-05-09 14:38 ` [PATCH v4 09/10] livepatch/selftests: add klp-convert Joe Lawrence
2019-05-09 14:38 ` [PATCH v4 10/10] livepatch/klp-convert: abort on special sections Joe Lawrence
2019-06-13 13:00 ` [PATCH v4 00/10] klp-convert livepatch build tooling Miroslav Benes
2019-06-13 13:15   ` Joe Lawrence
2019-06-13 20:48     ` Joe Lawrence
2019-06-14  8:34       ` Petr Mladek
2019-06-14 14:20         ` Joe Lawrence
2019-06-14 16:36           ` Libor Pechacek [this message]
2019-06-25 11:36         ` Miroslav Benes
2019-06-25 13:24           ` Joe Lawrence
2019-06-25 19:08           ` Joe Lawrence
2019-06-26 10:27             ` 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=20190614163655.GC15002@fm.suse.cz \
    --to=lpechacek@suse.cz \
    --cc=joe.lawrence@redhat.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.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.