On Fri, Mar 06, 2015 at 08:37:26PM +0900, Masami Hiramatsu wrote:
> Actually, we can suppose this module unloading context is
> not changing universe. thus it is expected behavior, isn't it?
In the case of my proposed consistency model RFC, if the module
unloading task gets preempted, or if
On Fri 2015-03-06 20:37:26, Masami Hiramatsu wrote:
> (2015/03/06 19:51), Petr Mladek wrote:
> > On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
> >> (2015/03/05 23:18), Josh Poimboeuf wrote:
> >>> On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
> (2015/03/04 22:17),
(2015/03/06 19:51), Petr Mladek wrote:
> On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
>> (2015/03/05 23:18), Josh Poimboeuf wrote:
>>> On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
> On Tue 2015-03-03 17:02:22, Josh
On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
> (2015/03/05 23:18), Josh Poimboeuf wrote:
> > On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
> >> (2015/03/04 22:17), Petr Mladek wrote:
> >>> On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> It's possible for
On Fri, Mar 06, 2015 at 08:37:26PM +0900, Masami Hiramatsu wrote:
Actually, we can suppose this module unloading context is
not changing universe. thus it is expected behavior, isn't it?
In the case of my proposed consistency model RFC, if the module
unloading task gets preempted, or if
(2015/03/06 19:51), Petr Mladek wrote:
On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
(2015/03/05 23:18), Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's
On Fri 2015-03-06 20:37:26, Masami Hiramatsu wrote:
(2015/03/06 19:51), Petr Mladek wrote:
On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
(2015/03/05 23:18), Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
(2015/03/05 23:18), Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch()
(2015/03/05 23:18), Josh Poimboeuf wrote:
> On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
>> (2015/03/04 22:17), Petr Mladek wrote:
>>> On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier
On Thu 2015-03-05 09:52:41, Masami Hiramatsu wrote:
> (2015/03/04 22:17), Petr Mladek wrote:
> > On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> >> It's possible for klp_register_patch() to see a module before the COMING
> >> notifier is called, or after the GOING notifier is called.
> >>
> >>
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
> (2015/03/04 22:17), Petr Mladek wrote:
> > On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> >> It's possible for klp_register_patch() to see a module before the COMING
> >> notifier is called, or after the GOING notifier is
(2015/03/05 23:18), Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or
On Thu 2015-03-05 09:52:41, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
(2015/03/04 22:17), Petr Mladek wrote:
> On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
>> It's possible for klp_register_patch() to see a module before the COMING
>> notifier is called, or after the GOING notifier is called.
>>
>> That can cause all kinds of ugly races. As Pter Mladek
On Wed, Mar 04, 2015 at 11:02:59PM +0100, Jiri Kosina wrote:
> On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
>
> > Well, we could just get a reference on all patched modules to prevent them
> > from being unloaded.
>
> Is that really a solution for cases where you are unloading a module (it
> has
On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
> Well, we could just get a reference on all patched modules to prevent them
> from being unloaded.
Is that really a solution for cases where you are unloading a module (it
has "just" been switched to MODULE_STATE_GOING) and enable a patch which
On Wed, Mar 04, 2015 at 05:36:11PM +0100, Petr Mladek wrote:
> For example, let's have three patches (P1, P2, P3) for the functions a() and
> b()
> where a() is from vmcore and b() is from a module M. Something like:
>
> a() b()
> P1a1()b1()
> P2a2()b2()
> P3a3()
On Wed 2015-03-04 09:34:15, Josh Poimboeuf wrote:
> On Wed, Mar 04, 2015 at 02:17:52PM +0100, Petr Mladek wrote:
> > On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> > > It's possible for klp_register_patch() to see a module before the COMING
> > > notifier is called, or after the GOING
On Wed, Mar 04, 2015 at 04:51:39PM +0100, Jiri Kosina wrote:
> On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
>
> > > CPU0 CPU1
> > >
> > > delete_module() #SYSCALL
> > >
> > >try_stop_module()
> > > mod->state = MODULE_STATE_GOING;
> > >
> > >
On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
> > CPU0CPU1
> >
> > delete_module() #SYSCALL
> >
> >try_stop_module()
> > mod->state = MODULE_STATE_GOING;
> >
> >mutex_unlock(_mutex);
> >
> >
On Wed, Mar 04, 2015 at 02:17:52PM +0100, Petr Mladek wrote:
> On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> > It's possible for klp_register_patch() to see a module before the COMING
> > notifier is called, or after the GOING notifier is called.
> >
> > That can cause all kinds of ugly
On Wed 2015-03-04 14:17:52, Petr Mladek wrote:
> On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> > It's possible for klp_register_patch() to see a module before the COMING
> > notifier is called, or after the GOING notifier is called.
> >
> > That can cause all kinds of ugly races. As Pter
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> It's possible for klp_register_patch() to see a module before the COMING
> notifier is called, or after the GOING notifier is called.
>
> That can cause all kinds of ugly races. As Pter Mladek reported:
>
> "The problem is that we do not
On Wed, Mar 04, 2015 at 02:17:52PM +0100, Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause all kinds of ugly races. As
On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
CPU0CPU1
delete_module() #SYSCALL
try_stop_module()
mod-state = MODULE_STATE_GOING;
mutex_unlock(module_mutex);
klp_register_patch()
On Wed, Mar 04, 2015 at 04:51:39PM +0100, Jiri Kosina wrote:
On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
CPU0 CPU1
delete_module() #SYSCALL
try_stop_module()
mod-state = MODULE_STATE_GOING;
mutex_unlock(module_mutex);
On Wed, Mar 04, 2015 at 05:36:11PM +0100, Petr Mladek wrote:
For example, let's have three patches (P1, P2, P3) for the functions a() and
b()
where a() is from vmcore and b() is from a module M. Something like:
a() b()
P1a1()b1()
P2a2()b2()
P3a3()b3(3)
On Wed 2015-03-04 09:34:15, Josh Poimboeuf wrote:
On Wed, Mar 04, 2015 at 02:17:52PM +0100, Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is
On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
Well, we could just get a reference on all patched modules to prevent them
from being unloaded.
Is that really a solution for cases where you are unloading a module (it
has just been switched to MODULE_STATE_GOING) and enable a patch which
patches
On Wed, Mar 04, 2015 at 11:02:59PM +0100, Jiri Kosina wrote:
On Wed, 4 Mar 2015, Josh Poimboeuf wrote:
Well, we could just get a reference on all patched modules to prevent them
from being unloaded.
Is that really a solution for cases where you are unloading a module (it
has just been
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause all kinds of ugly races. As Pter Mladek reported:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause all kinds of ugly races. As Pter Mladek reported:
The problem is that we do not keep the
On Wed 2015-03-04 14:17:52, Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause all kinds of ugly races. As Pter Mladek
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause all kinds of ugly races. As Pter Mladek reported:
"The problem is that we do not keep the klp_mutex lock all the time when
the module is being
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause all kinds of ugly races. As Pter Mladek reported:
The problem is that we do not keep the klp_mutex lock all the time when
the module is being
36 matches
Mail list logo
