On Mon, Aug 18, 2014 at 10:19 AM, Oleg Nesterov wrote:
> And, again, I do not really know which version is better.
In Chicago right now -- feedback was it seems the that generally
splitting up probe from init might be good in the end, if we do this
we won't need a work around for drivers that
On 08/18, Takashi Iwai wrote:
>
> At Mon, 18 Aug 2014 14:22:17 +0200,
> Oleg Nesterov wrote:
> >
> > On 08/18, Takashi Iwai wrote:
> > >
> > > #define module_long_probe_init(initfn)\
> > > static int _long_probe_##initfn(void *arg) \
> > > {
At Mon, 18 Aug 2014 14:22:17 +0200,
Oleg Nesterov wrote:
>
> On 08/18, Takashi Iwai wrote:
> >
> > #define module_long_probe_init(initfn) \
> > static int _long_probe_##initfn(void *arg) \
> > {
On 08/18, Takashi Iwai wrote:
>
> #define module_long_probe_init(initfn)\
> static int _long_probe_##initfn(void *arg) \
> { \
> module_put_and_exit(initfn());
At Sun, 17 Aug 2014 20:21:38 +0200,
Oleg Nesterov wrote:
>
> On 08/17, Luis R. Rodriguez wrote:
> >
> > In the last iteration that I have stress tested for corner cases I just
> > get_task_struct() on the init and then put_task_struct() at the exit, is
> > that
> > fine too or are there reasons
At Sun, 17 Aug 2014 20:21:38 +0200,
Oleg Nesterov wrote:
On 08/17, Luis R. Rodriguez wrote:
In the last iteration that I have stress tested for corner cases I just
get_task_struct() on the init and then put_task_struct() at the exit, is
that
fine too or are there reasons to prefer
On 08/18, Takashi Iwai wrote:
#define module_long_probe_init(initfn)\
static int _long_probe_##initfn(void *arg) \
{ \
module_put_and_exit(initfn()); \
At Mon, 18 Aug 2014 14:22:17 +0200,
Oleg Nesterov wrote:
On 08/18, Takashi Iwai wrote:
#define module_long_probe_init(initfn) \
static int _long_probe_##initfn(void *arg) \
{ \
On 08/18, Takashi Iwai wrote:
At Mon, 18 Aug 2014 14:22:17 +0200,
Oleg Nesterov wrote:
On 08/18, Takashi Iwai wrote:
#define module_long_probe_init(initfn)\
static int _long_probe_##initfn(void *arg) \
{
On Mon, Aug 18, 2014 at 10:19 AM, Oleg Nesterov o...@redhat.com wrote:
And, again, I do not really know which version is better.
In Chicago right now -- feedback was it seems the that generally
splitting up probe from init might be good in the end, if we do this
we won't need a work around for
On 08/17, Luis R. Rodriguez wrote:
>
> In the last iteration that I have stress tested for corner cases I just
> get_task_struct() on the init and then put_task_struct() at the exit, is that
> fine too or are there reasons to prefer the module stuff?
I am fine either way.
I like the Takashi's
On Sun, Aug 17, 2014 at 02:55:05PM +0200, Oleg Nesterov wrote:
> Damn, sorry for noise ;)
>
> I was going to suggest to introduce module_put_and_exit() to simplify
> this and potentially other users, but it already exists. So this code
> can use it too without additional complications.
In the
Damn, sorry for noise ;)
I was going to suggest to introduce module_put_and_exit() to simplify
this and potentially other users, but it already exists. So this code
can use it too without additional complications.
On 08/17, Oleg Nesterov wrote:
> On 08/17, Oleg Nesterov wrote:
> >
> > On 08/17,
On 08/17, Oleg Nesterov wrote:
>
> On 08/17, Takashi Iwai wrote:
> >
> > How about just increasing/decreasing the module count for blocking the
> > exit call? For example:
> >
> > #define module_long_probe_init(initfn) \
> > static int _long_probe_##initfn(void
On 08/17, Takashi Iwai wrote:
>
> How about just increasing/decreasing the module count for blocking the
> exit call? For example:
>
> #define module_long_probe_init(initfn)\
> static int _long_probe_##initfn(void *arg) \
> {
At Sat, 16 Aug 2014 04:50:07 +0200,
Luis R. Rodriguez wrote:
>
> On Fri, Aug 15, 2014 at 04:39:02PM +0200, Oleg Nesterov wrote:
> > On 08/15, Luis R. Rodriguez wrote:
> > >
> > > On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
> > > > On 08/12, Luis R. Rodriguez wrote:
> > > > >
>
At Sat, 16 Aug 2014 04:50:07 +0200,
Luis R. Rodriguez wrote:
On Fri, Aug 15, 2014 at 04:39:02PM +0200, Oleg Nesterov wrote:
On 08/15, Luis R. Rodriguez wrote:
On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
On 08/12, Luis R. Rodriguez wrote:
+/* To be used
On 08/17, Takashi Iwai wrote:
How about just increasing/decreasing the module count for blocking the
exit call? For example:
#define module_long_probe_init(initfn)\
static int _long_probe_##initfn(void *arg) \
{
On 08/17, Oleg Nesterov wrote:
On 08/17, Takashi Iwai wrote:
How about just increasing/decreasing the module count for blocking the
exit call? For example:
#define module_long_probe_init(initfn) \
static int _long_probe_##initfn(void *arg)
Damn, sorry for noise ;)
I was going to suggest to introduce module_put_and_exit() to simplify
this and potentially other users, but it already exists. So this code
can use it too without additional complications.
On 08/17, Oleg Nesterov wrote:
On 08/17, Oleg Nesterov wrote:
On 08/17,
On Sun, Aug 17, 2014 at 02:55:05PM +0200, Oleg Nesterov wrote:
Damn, sorry for noise ;)
I was going to suggest to introduce module_put_and_exit() to simplify
this and potentially other users, but it already exists. So this code
can use it too without additional complications.
In the last
On 08/17, Luis R. Rodriguez wrote:
In the last iteration that I have stress tested for corner cases I just
get_task_struct() on the init and then put_task_struct() at the exit, is that
fine too or are there reasons to prefer the module stuff?
I am fine either way.
I like the Takashi's idea
On Fri, Aug 15, 2014 at 04:39:02PM +0200, Oleg Nesterov wrote:
> On 08/15, Luis R. Rodriguez wrote:
> >
> > On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
> > > On 08/12, Luis R. Rodriguez wrote:
> > > >
> > > > +/* To be used by modules which can take over 30 seconds at probe */
>
On 08/15, Luis R. Rodriguez wrote:
>
> On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
> > On 08/12, Luis R. Rodriguez wrote:
> > >
> > > +/* To be used by modules which can take over 30 seconds at probe */
> >
> > Probably the comment should explain that this hack should only be
>
On 08/15, Luis R. Rodriguez wrote:
On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
On 08/12, Luis R. Rodriguez wrote:
+/* To be used by modules which can take over 30 seconds at probe */
Probably the comment should explain that this hack should only be
used if the
On Fri, Aug 15, 2014 at 04:39:02PM +0200, Oleg Nesterov wrote:
On 08/15, Luis R. Rodriguez wrote:
On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
On 08/12, Luis R. Rodriguez wrote:
+/* To be used by modules which can take over 30 seconds at probe */
Probably
On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
> On 08/12, Luis R. Rodriguez wrote:
> >
> > +/* To be used by modules which can take over 30 seconds at probe */
>
> Probably the comment should explain that this hack should only be
> used if the driver is buggy and is wating for
On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
On 08/12, Luis R. Rodriguez wrote:
+/* To be used by modules which can take over 30 seconds at probe */
Probably the comment should explain that this hack should only be
used if the driver is buggy and is wating for real fix.
On 08/12, Luis R. Rodriguez wrote:
>
> +/* To be used by modules which can take over 30 seconds at probe */
Probably the comment should explain that this hack should only be
used if the driver is buggy and is wating for "real fix".
> +#define module_long_probe_init(initfn)
On 08/12, Luis R. Rodriguez wrote:
+/* To be used by modules which can take over 30 seconds at probe */
Probably the comment should explain that this hack should only be
used if the driver is buggy and is wating for real fix.
+#define module_long_probe_init(initfn)
On Wed, Aug 13, 2014 at 07:59:06AM +0900, Tetsuo Handa wrote:
> Luis R. Rodriguez wrote:
> > Tetsuo bisected and found that commit 786235ee \"kthread: make
> > kthread_create() killable\" modified kthread_create() to bail as
> > soon as SIGKILL is received.
>
> I just wrote commit 786235ee. It is
Luis R. Rodriguez wrote:
> Tetsuo bisected and found that commit 786235ee \"kthread: make
> kthread_create() killable\" modified kthread_create() to bail as
> soon as SIGKILL is received.
I just wrote commit 786235ee. It is not Tetsuo who bisected it.
> @@ -128,4 +129,38 @@ bool
From: "Luis R. Rodriguez"
Tetsuo bisected and found that commit 786235ee "kthread: make
kthread_create() killable" modified kthread_create() to bail as
soon as SIGKILL is received. This is causing some issues with
some drivers and at times boot. Joseph then found that failures
occur as the
From: Luis R. Rodriguez mcg...@suse.com
Tetsuo bisected and found that commit 786235ee kthread: make
kthread_create() killable modified kthread_create() to bail as
soon as SIGKILL is received. This is causing some issues with
some drivers and at times boot. Joseph then found that failures
occur
Luis R. Rodriguez wrote:
Tetsuo bisected and found that commit 786235ee \kthread: make
kthread_create() killable\ modified kthread_create() to bail as
soon as SIGKILL is received.
I just wrote commit 786235ee. It is not Tetsuo who bisected it.
@@ -128,4 +129,38 @@ bool
On Wed, Aug 13, 2014 at 07:59:06AM +0900, Tetsuo Handa wrote:
Luis R. Rodriguez wrote:
Tetsuo bisected and found that commit 786235ee \kthread: make
kthread_create() killable\ modified kthread_create() to bail as
soon as SIGKILL is received.
I just wrote commit 786235ee. It is not Tetsuo
36 matches
Mail list logo
