From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Mark Brown <broonie@kernel.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>,
linux-spi <linux-spi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] spi: Fix hung task timeout when initialization fails
Date: Thu, 1 May 2014 16:33:58 +0200 [thread overview]
Message-ID: <CAMuHMdUeFJDq8TMQn=D+y_nWVy-puZDYekV3cPhHTnDF+ebKJA@mail.gmail.com> (raw)
In-Reply-To: <20140501141156.GV3245@sirena.org.uk>
On Thu, May 1, 2014 at 4:11 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, May 01, 2014 at 07:53:58AM +0200, Ricardo Ribalda Delgado wrote:
>
>> Thanks for your comments. This fix does not avoid the task being
>> killed (which is not an error). What it does is that IF the task is
>> killed or we are out of memory we will exit with all the resources
>> properly released and no locks helds, giving the user a chance to
>> reload/rebind the module instead of getting and unstable system that
>> cannot even reboot without a powercycle.
>
> How does it ensure that? What's to stop the task being killed after we
> check to see if the task was killed.
master->kworker_task is set like this:
master->kworker_task = kthread_run(...)
so it just contains the status of the creation of the kthread, not if it was
killed, right? Hence we don't check if it was killed.
So Ricardo's patch prevents the stopping and destruction of the thread
if it failed to be _created_.
What if it is killed? I suppose the kthread API handles that internally, as it
could happen to any thread (e.g. OOM)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Ricardo Ribalda Delgado
<ricardo.ribalda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] spi: Fix hung task timeout when initialization fails
Date: Thu, 1 May 2014 16:33:58 +0200 [thread overview]
Message-ID: <CAMuHMdUeFJDq8TMQn=D+y_nWVy-puZDYekV3cPhHTnDF+ebKJA@mail.gmail.com> (raw)
In-Reply-To: <20140501141156.GV3245-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Thu, May 1, 2014 at 4:11 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, May 01, 2014 at 07:53:58AM +0200, Ricardo Ribalda Delgado wrote:
>
>> Thanks for your comments. This fix does not avoid the task being
>> killed (which is not an error). What it does is that IF the task is
>> killed or we are out of memory we will exit with all the resources
>> properly released and no locks helds, giving the user a chance to
>> reload/rebind the module instead of getting and unstable system that
>> cannot even reboot without a powercycle.
>
> How does it ensure that? What's to stop the task being killed after we
> check to see if the task was killed.
master->kworker_task is set like this:
master->kworker_task = kthread_run(...)
so it just contains the status of the creation of the kthread, not if it was
killed, right? Hence we don't check if it was killed.
So Ricardo's patch prevents the stopping and destruction of the thread
if it failed to be _created_.
What if it is killed? I suppose the kthread API handles that internally, as it
could happen to any thread (e.g. OOM)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-05-01 14:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 10:36 [PATCH] spi: Fix hung task timeout when initialization fails Ricardo Ribalda Delgado
2014-05-01 1:34 ` Mark Brown
2014-05-01 1:34 ` Mark Brown
2014-05-01 5:53 ` Ricardo Ribalda Delgado
2014-05-01 5:53 ` Ricardo Ribalda Delgado
2014-05-01 14:11 ` Mark Brown
2014-05-01 14:11 ` Mark Brown
2014-05-01 14:33 ` Geert Uytterhoeven [this message]
2014-05-01 14:33 ` Geert Uytterhoeven
2014-05-01 16:03 ` Mark Brown
2014-05-01 16:03 ` Mark Brown
2014-05-01 8:15 Ricardo Ribalda Delgado
2014-05-01 8:15 ` Ricardo Ribalda Delgado
2014-05-01 16:09 ` Mark Brown
2014-05-01 16:09 ` Mark Brown
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='CAMuHMdUeFJDq8TMQn=D+y_nWVy-puZDYekV3cPhHTnDF+ebKJA@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=ricardo.ribalda@gmail.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.