When a fs is frozen, a process can hang because we wait in
uniterruptible state. We give the user the possibility to kill the process.
Not-signed-off-by: Marco Stornelli <[email protected]>
---
--- fs/super.c.orig 2013-03-24 09:56:33.000000000 +0100
+++ fs/super.c 2013-03-24 09:58:41.000000000 +0100
@@ -1198,7 +1198,7 @@ retry:
if (unlikely(sb->s_writers.frozen >= level)) {
if (!wait)
return 0;
- wait_event(sb->s_writers.wait_unfrozen,
+ wait_event_killable(sb->s_writers.wait_unfrozen,
sb->s_writers.frozen < level);
}
@@ -1248,7 +1248,7 @@ static void sb_wait_write(struct super_b
* of frozen and checking of the counter
*/
prepare_to_wait(&sb->s_writers.wait, &wait,
- TASK_UNINTERRUPTIBLE);
+ TASK_KILLABLE);
writers = percpu_counter_sum(&sb->s_writers.counter[level-1]);
if (writers)
On Sun 24-03-13 10:10:59, Marco Stornelli wrote:
> When a fs is frozen, a process can hang because we wait in
> uniterruptible state. We give the user the possibility to kill the process.
Yes, but it needs slightly more work as you probably know... (bailing out
properly when the signal arrives).
Honza
>
> Not-signed-off-by: Marco Stornelli <[email protected]>
> ---
>
> --- fs/super.c.orig 2013-03-24 09:56:33.000000000 +0100
> +++ fs/super.c 2013-03-24 09:58:41.000000000 +0100
> @@ -1198,7 +1198,7 @@ retry:
> if (unlikely(sb->s_writers.frozen >= level)) {
> if (!wait)
> return 0;
> - wait_event(sb->s_writers.wait_unfrozen,
> + wait_event_killable(sb->s_writers.wait_unfrozen,
> sb->s_writers.frozen < level);
> }
>
> @@ -1248,7 +1248,7 @@ static void sb_wait_write(struct super_b
> * of frozen and checking of the counter
> */
> prepare_to_wait(&sb->s_writers.wait, &wait,
> - TASK_UNINTERRUPTIBLE);
> + TASK_KILLABLE);
>
> writers = percpu_counter_sum(&sb->s_writers.counter[level-1]);
> if (writers)
--
Jan Kara <[email protected]>
SUSE Labs, CR
2013/3/26 Jan Kara <[email protected]>:
> On Sun 24-03-13 10:10:59, Marco Stornelli wrote:
>> When a fs is frozen, a process can hang because we wait in
>> uniterruptible state. We give the user the possibility to kill the process.
> Yes, but it needs slightly more work as you probably know... (bailing out
> properly when the signal arrives).
>
> Honza
>
Of course, indeed, it was only an RFC to start a discussion, not a
patch :) The point was: is this kind of change a behaviour that can
break user-space in some way? IMHO no, but I'd like to have a
discussion about that before to start coding. What do you think?
Marco
On Wed 27-03-13 12:39:10, Marco Stornelli wrote:
> 2013/3/26 Jan Kara <[email protected]>:
> > On Sun 24-03-13 10:10:59, Marco Stornelli wrote:
> >> When a fs is frozen, a process can hang because we wait in
> >> uniterruptible state. We give the user the possibility to kill the process.
> > Yes, but it needs slightly more work as you probably know... (bailing out
> > properly when the signal arrives).
> >
> > Honza
> >
>
> Of course, indeed, it was only an RFC to start a discussion, not a
> patch :) The point was: is this kind of change a behaviour that can
> break user-space in some way? IMHO no, but I'd like to have a
> discussion about that before to start coding. What do you think?
Killable wait is almost always safe WRT to userspace breakage. In this
case I cannot see how it could matter. That's why I agree it's a good thing
to do.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
2013/3/27 Jan Kara <[email protected]>:
> On Wed 27-03-13 12:39:10, Marco Stornelli wrote:
>> 2013/3/26 Jan Kara <[email protected]>:
>> > On Sun 24-03-13 10:10:59, Marco Stornelli wrote:
>> >> When a fs is frozen, a process can hang because we wait in
>> >> uniterruptible state. We give the user the possibility to kill the process.
>> > Yes, but it needs slightly more work as you probably know... (bailing out
>> > properly when the signal arrives).
>> >
>> > Honza
>> >
>>
>> Of course, indeed, it was only an RFC to start a discussion, not a
>> patch :) The point was: is this kind of change a behaviour that can
>> break user-space in some way? IMHO no, but I'd like to have a
>> discussion about that before to start coding. What do you think?
> Killable wait is almost always safe WRT to userspace breakage. In this
> case I cannot see how it could matter. That's why I agree it's a good thing
> to do.
>
> Honza
Yes, I quite agree. I'll try to look at it in a deeply way.
Regards,
Marco