On Tue, 3 May 2016, Miroslav Benes wrote:
> > > Currently we do not allow patch module to unload since there is no
> > > method to determine if a task is still running in the patched code.
> > >
> > > The consistency model gives us the way because when the patching
> > > finishes we know that all
On Thu, 5 May 2016, Josh Poimboeuf wrote:
> I would disagree with the statement that the dynamic kobject doesn't
> scale. We would just need a helper function to get from a kobject to
> its klp_patch.
>
> In fact, to me it seems like the right way to do it. It doesn't make
> sense for the code w
On Thu, May 05, 2016 at 04:25:48PM +0200, Miroslav Benes wrote:
> On Thu, 5 May 2016, Josh Poimboeuf wrote:
>
> > On Thu, May 05, 2016 at 10:28:12AM +0200, Miroslav Benes wrote:
> > > I think it boils down to the following problem.
> > >
> > > 1. CONFIG_DEBUG_KOBJECT_RELEASE=y
> > >
> > > 2. we
On Thu, 5 May 2016, Josh Poimboeuf wrote:
> On Thu, May 05, 2016 at 10:28:12AM +0200, Miroslav Benes wrote:
> > I think it boils down to the following problem.
> >
> > 1. CONFIG_DEBUG_KOBJECT_RELEASE=y
> >
> > 2. we have dynamic kobjects, so there is a pointer in klp_patch to struct
> > kobject
On Thu, May 05, 2016 at 10:28:12AM +0200, Miroslav Benes wrote:
> I think it boils down to the following problem.
>
> 1. CONFIG_DEBUG_KOBJECT_RELEASE=y
>
> 2. we have dynamic kobjects, so there is a pointer in klp_patch to struct
> kobject
>
> 3. it is allocated during klp_init_patch() and all
On Wed, 4 May 2016, Josh Poimboeuf wrote:
> On Wed, May 04, 2016 at 04:35:28PM +0200, Miroslav Benes wrote:
> > On Wed, 4 May 2016, Josh Poimboeuf wrote:
> >
> > > On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote:
> > > > On Tue, 3 May 2016, Josh Poimboeuf wrote:
> > > >
> > > > >
On Wed, May 04, 2016 at 04:35:28PM +0200, Miroslav Benes wrote:
> On Wed, 4 May 2016, Josh Poimboeuf wrote:
>
> > On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote:
> > > On Tue, 3 May 2016, Josh Poimboeuf wrote:
> > >
> > > > On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf
On Wed, 4 May 2016, Josh Poimboeuf wrote:
> On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote:
> > On Tue, 3 May 2016, Josh Poimboeuf wrote:
> >
> > > On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote:
> > > > On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote:
On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote:
> On Tue, 3 May 2016, Josh Poimboeuf wrote:
>
> > On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote:
> > > On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote:
> > > > On Tue, 3 May 2016, Josh Poimboeuf wrote:
> >
On Tue, 3 May 2016, Josh Poimboeuf wrote:
> On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote:
> > On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote:
> > > On Tue, 3 May 2016, Josh Poimboeuf wrote:
> > >
> > > > > 1. Do we really need a completion? If I am not missing somet
On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote:
> On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote:
> > On Tue, 3 May 2016, Josh Poimboeuf wrote:
> >
> > > > 1. Do we really need a completion? If I am not missing something
> > > > kobject_del() always waits for sysfs cal
On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote:
> On Tue, 3 May 2016, Josh Poimboeuf wrote:
>
> > > 1. Do we really need a completion? If I am not missing something
> > > kobject_del() always waits for sysfs callers to leave thanks to kernfs
> > > active protection.
> >
> > What do y
On Tue, 3 May 2016, Josh Poimboeuf wrote:
> > 1. Do we really need a completion? If I am not missing something
> > kobject_del() always waits for sysfs callers to leave thanks to kernfs
> > active protection.
>
> What do you mean by "kernfs active protection"? I see that
> kernfs_remove() gets t
On Mon, May 02, 2016 at 01:57:22PM +0200, Miroslav Benes wrote:
> 1. Do we really need a completion? If I am not missing something
> kobject_del() always waits for sysfs callers to leave thanks to kernfs
> active protection.
What do you mean by "kernfs active protection"? I see that
kernfs_remove
On Mon, 2 May 2016, Josh Poimboeuf wrote:
> On Mon, May 02, 2016 at 01:57:22PM +0200, Miroslav Benes wrote:
> > Currently we do not allow patch module to unload since there is no
> > method to determine if a task is still running in the patched code.
> >
> > The consistency model gives us the way
On Mon, May 02, 2016 at 01:57:22PM +0200, Miroslav Benes wrote:
> Currently we do not allow patch module to unload since there is no
> method to determine if a task is still running in the patched code.
>
> The consistency model gives us the way because when the patching
> finishes we know that al
Currently we do not allow patch module to unload since there is no
method to determine if a task is still running in the patched code.
The consistency model gives us the way because when the patching
finishes we know that all tasks were marked as safe to call a new
patched function. Thus every new
17 matches
Mail list logo