On Wed, 13 Mar 2013, Jeff Layton wrote:
> Of course, this is all a lot of work, and not something we can shove
> into the kernel for 3.9 at this point. In the meantime, while Mandeep's
> warning is correctly pointing out a problem, I think we ought to back
> it out until we can fix this properly.
On Wed, 6 Mar 2013 13:40:16 -0800
Tejun Heo wrote:
> On Wed, Mar 06, 2013 at 01:36:36PM -0800, Tejun Heo wrote:
> > On Wed, Mar 06, 2013 at 01:31:10PM -0800, Linus Torvalds wrote:
> > > So I do agree that we probably have *too* many of the stupid "let's
> > > check if we can freeze", and I suspec
* Linus Torvalds wrote:
> - the "freeezer for suspend/resume on a laptop"
>
> [...]
>
> The second one is unlikely to really use NFS anyway. [...]
Incidentally I use NFS to a file server on my laptop, over wifi, and I close
the lid
for the night. It's NFS mounted soft.
If it was mounted
On Thu, 7 Mar 2013 17:16:12 +
"Myklebust, Trond" wrote:
> On Thu, 2013-03-07 at 09:03 -0800, Linus Torvalds wrote:
> > On Thu, Mar 7, 2013 at 8:45 AM, Myklebust, Trond
> > wrote:
> > >
> > > The problem there is that we get into the whole 'hard' vs 'soft' mount
> > > problem. We're supposed
On Thursday, March 07, 2013 08:25:10 AM Linus Torvalds wrote:
> On Thu, Mar 7, 2013 at 7:59 AM, Myklebust, Trond
> wrote:
> >
> > It _shouldn't_ be an interruption unless the filesystem can't make
> > progress.
>
> So how can we tell? Calling "freezable_schedule()" if you're not ready
> to be fro
On Thu, 2013-03-07 at 09:03 -0800, Linus Torvalds wrote:
> On Thu, Mar 7, 2013 at 8:45 AM, Myklebust, Trond
> wrote:
> >
> > The problem there is that we get into the whole 'hard' vs 'soft' mount
> > problem. We're supposed to guarantee data integrity for 'hard' mounts,
> > so no funny business is
On Thu, Mar 7, 2013 at 8:45 AM, Myklebust, Trond
wrote:
>
> The problem there is that we get into the whole 'hard' vs 'soft' mount
> problem. We're supposed to guarantee data integrity for 'hard' mounts,
> so no funny business is allowed. OTOH, 'soft' mounts time out and return
> EIO to the applic
On Thu, 2013-03-07 at 08:25 -0800, Linus Torvalds wrote:
> On Thu, Mar 7, 2013 at 7:59 AM, Myklebust, Trond
> wrote:
> >
> > It _shouldn't_ be an interruption unless the filesystem can't make
> > progress.
>
> So how can we tell? Calling "freezable_schedule()" if you're not ready
> to be frozen i
On Thu, Mar 7, 2013 at 7:59 AM, Myklebust, Trond
wrote:
>
> It _shouldn't_ be an interruption unless the filesystem can't make
> progress.
So how can we tell? Calling "freezable_schedule()" if you're not ready
to be frozen is not good. And nobody but the NFS code can know.
You might want to intr
Hello, Linus.
On Thu, Mar 07, 2013 at 07:55:39AM -0800, Linus Torvalds wrote:
> In other words, that suggestion not only introduces new problems (a),
> it's fundamentally broken anyway (b) *AND* it doesn't even solve
> anything, it just moves it around.
I don't think it's gonna solve the problems
On Thu, 2013-03-07 at 07:55 -0800, Linus Torvalds wrote:
> On Thu, Mar 7, 2013 at 3:41 AM, Jeff Layton wrote:
> >
> > I think Trond may be on the right track. We probably need some
> > mechanism to quiesce the filesystem ahead of any sort of freezer
> > event.
>
> No, guys. That cannot work. It's
On Thu, Mar 7, 2013 at 3:41 AM, Jeff Layton wrote:
>
> I think Trond may be on the right track. We probably need some
> mechanism to quiesce the filesystem ahead of any sort of freezer
> event.
No, guys. That cannot work. It's a completely moronic idea. Let me
count the way:
(a) it's just anoth
Hello, Jeff.
On Thu, Mar 07, 2013 at 06:41:40AM -0500, Jeff Layton wrote:
> Suppose I call unlink("somefile"); on an NFS mount. We take all of the
> VFS locks, go down into the NFS layer. That marshals up the UNLINK
> call, sends it off to the server, and waits for the reply. While we're
> waiting
On Wed, 6 Mar 2013 13:36:36 -0800
Tejun Heo wrote:
> On Wed, Mar 06, 2013 at 01:31:10PM -0800, Linus Torvalds wrote:
> > So I do agree that we probably have *too* many of the stupid "let's
> > check if we can freeze", and I suspect that the NFS code should get
> > rid of the "freezable_schedule()
On Wed, Mar 06, 2013 at 01:36:36PM -0800, Tejun Heo wrote:
> On Wed, Mar 06, 2013 at 01:31:10PM -0800, Linus Torvalds wrote:
> > So I do agree that we probably have *too* many of the stupid "let's
> > check if we can freeze", and I suspect that the NFS code should get
> > rid of the "freezable_sche
On Wed, Mar 06, 2013 at 01:31:10PM -0800, Linus Torvalds wrote:
> So I do agree that we probably have *too* many of the stupid "let's
> check if we can freeze", and I suspect that the NFS code should get
> rid of the "freezable_schedule()" that is causing this warning
> (because I also agree that y
On Wed, Mar 6, 2013 at 1:24 PM, Tejun Heo wrote:
>
> With syscall paths out of the way, the surface is reduced a lot.
So the issue is syscalls that don't react to signals, and that can
potentially wait a long time.
Like NFS with a network hickup. Which is not at all unlikely. Think
wireless netw
Hello, Linus.
On Wed, Mar 06, 2013 at 01:00:02PM -0800, Linus Torvalds wrote:
> > Oh yeah, we don't need another signal. We just need sigpending state
> > and a wakeup. I wasn't really going into details. The important
> > point is that for code paths outside signal/ptrace, freezing could
> > l
On Wed, Mar 6, 2013 at 10:53 AM, Tejun Heo wrote:
> Hello, Oleg.
>
> On Wed, Mar 06, 2013 at 07:16:08PM +0100, Oleg Nesterov wrote:
>> And how SIGFREEZE can help? If we want to interrupt the sleeps in NFS/RPC
>> layer we can simply add TASK_WAKEFREEZE (can be used with TASK_KILLABLE)
>> and change
On Wed, Mar 6, 2013 at 10:37 AM, Myklebust, Trond
wrote:
> On Wed, 2013-03-06 at 13:23 -0500, Jeff Layton wrote:
>> On Wed, 6 Mar 2013 07:59:01 -0800
>> Mandeep Singh Baines wrote:
>> > In general, holding a lock and freezing can cause a deadlock if:
>> >
>> > 1) you froze via the cgroup_freezer
Hello, Oleg.
On Wed, Mar 06, 2013 at 07:16:08PM +0100, Oleg Nesterov wrote:
> And how SIGFREEZE can help? If we want to interrupt the sleeps in NFS/RPC
> layer we can simply add TASK_WAKEFREEZE (can be used with TASK_KILLABLE)
> and change freeze_task() to do signal_wake_up_state(TASK_WAKEFREEZE).
Hello,
On Wed, Mar 06, 2013 at 01:40:04PM -0500, Jeff Layton wrote:
> Though when I said that, it was before Tejun mentioned hooking this up
> to ptrace. I'll confess that I don't fully understand what he's
> proposing either though...
Oh, they're all just pretty closely related. All signal and
On Wed, 6 Mar 2013 19:17:35 +0100
Oleg Nesterov wrote:
> On 03/05, Jeff Layton wrote:
> >
> > Anyone up for working out how to handle a freeze event on a process
> > that already has a pending signal, while it's being ptraced?
>
> Could you explain the problem?
>
Not very well. I was just sayi
On Wed, 2013-03-06 at 13:23 -0500, Jeff Layton wrote:
> On Wed, 6 Mar 2013 07:59:01 -0800
> Mandeep Singh Baines wrote:
> > In general, holding a lock and freezing can cause a deadlock if:
> >
> > 1) you froze via the cgroup_freezer subsystem and a task in another
> > cgroup tried to acquire the
On Wed, 6 Mar 2013 07:59:01 -0800
Mandeep Singh Baines wrote:
> On Wed, Mar 6, 2013 at 4:06 AM, Jeff Layton wrote:
> > On Wed, 6 Mar 2013 10:09:14 +0100
> > Ingo Molnar wrote:
> >
> >>
> >> * Mandeep Singh Baines wrote:
> >>
> >> > On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote:
> >> > > On
On 03/05, Jeff Layton wrote:
>
> Anyone up for working out how to handle a freeze event on a process
> that already has a pending signal, while it's being ptraced?
Could you explain the problem?
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On 03/05, Tejun Heo wrote:
>
> Oleg, are you still opposed to the idea of making freezer share trap
> points with ptrace?
My memory can fool me, but iirc I wasn't actually opposed... I guess
you mean the previous discussion about vfork/ptrace/etc which I forgot
completely.
But I can recall the ma
On Wed, Mar 6, 2013 at 4:06 AM, Jeff Layton wrote:
> On Wed, 6 Mar 2013 10:09:14 +0100
> Ingo Molnar wrote:
>
>>
>> * Mandeep Singh Baines wrote:
>>
>> > On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote:
>> > > On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote:
>> > >> If it's real
On Wed, 6 Mar 2013 10:09:14 +0100
Ingo Molnar wrote:
>
> * Mandeep Singh Baines wrote:
>
> > On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote:
> > > On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote:
> > >> If it's really just a 2-line patch to try_to_freeze(), could it just be
>
On Wed, 6 Mar 2013 01:10:07 +
"Myklebust, Trond" wrote:
> On Tue, 2013-03-05 at 14:03 -0500, Jeff Layton wrote:
> > On Tue, 5 Mar 2013 09:49:54 -0800
> > Tejun Heo wrote:
> >
> > > On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> > > > So, I think this is why implementing freeze
* Mandeep Singh Baines wrote:
> On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote:
> > On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote:
> >> If it's really just a 2-line patch to try_to_freeze(), could it just be
> >> carried out-of-tree by people that are specifically working on
On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote:
> On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote:
>> If it's really just a 2-line patch to try_to_freeze(), could it just be
>> carried out-of-tree by people that are specifically working on tracking
>> down these problems?
>>
>> Bu
On Tue, Mar 05, 2013 at 05:14:23PM -0800, Tejun Heo wrote:
> Then, the operation simply isn't freezable while in progress and
> should be on the receiving end of failed-to-freeze error message and
> users who depend on suspend/hibernation working properly should be
> advised away from using nfs.
>
On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote:
> If it's really just a 2-line patch to try_to_freeze(), could it just be
> carried out-of-tree by people that are specifically working on tracking
> down these problems?
>
> But I don't have strong feelings about it--as long as it d
Hello, Trond.
On Wed, Mar 06, 2013 at 01:10:07AM +, Myklebust, Trond wrote:
> Not all RPC calls can just be interrupted and restarted. Something like
> an exclusive file create, unlink, file locking attempt, etc may give
> rise to different results when replayed in the above scenario.
> Interr
On Tue, 2013-03-05 at 14:03 -0500, Jeff Layton wrote:
> On Tue, 5 Mar 2013 09:49:54 -0800
> Tejun Heo wrote:
>
> > On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> > > So, I think this is why implementing freezer as a separate blocking
> > > mechanism isn't such a good idea. We're ef
On Tue, Mar 05, 2013 at 04:59:00PM -0800, Mandeep Singh Baines wrote:
> On Tue, Mar 5, 2013 at 3:11 PM, J. Bruce Fields wrote:
> > On Tue, Mar 05, 2013 at 09:49:54AM -0800, Tejun Heo wrote:
> >> On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> >> > So, I think this is why implementing
On Tue, Mar 5, 2013 at 3:11 PM, J. Bruce Fields wrote:
> On Tue, Mar 05, 2013 at 09:49:54AM -0800, Tejun Heo wrote:
>> On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
>> > So, I think this is why implementing freezer as a separate blocking
>> > mechanism isn't such a good idea. We're e
On Tuesday, March 05, 2013 06:11:10 PM J. Bruce Fields wrote:
> On Tue, Mar 05, 2013 at 09:49:54AM -0800, Tejun Heo wrote:
> > On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> > > So, I think this is why implementing freezer as a separate blocking
> > > mechanism isn't such a good idea.
Hello, Jeff.
On Tue, Mar 05, 2013 at 06:39:41PM -0500, Jeff Layton wrote:
> Al was in the middle of his signal handling/execve rework though and I
> ran the idea past him. He pointedly told me that I was crazy for even
> considering it. This is rather non-trivial to handle since it means
> mucking
On Tue, 5 Mar 2013 11:09:23 -0800
Tejun Heo wrote:
> Hello, Jeff.
>
> On Tue, Mar 05, 2013 at 02:03:12PM -0500, Jeff Layton wrote:
> > Sounds intriguing...
> >
> > I'm not sure what this really means for something like NFS though. How
> > would you envision this working when we have long runnin
On Tue, Mar 05, 2013 at 09:49:54AM -0800, Tejun Heo wrote:
> On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> > So, I think this is why implementing freezer as a separate blocking
> > mechanism isn't such a good idea. We're effectively introducing a
> > completely new waiting state to
Hello, Jeff.
On Tue, Mar 05, 2013 at 02:03:12PM -0500, Jeff Layton wrote:
> Sounds intriguing...
>
> I'm not sure what this really means for something like NFS though. How
> would you envision this working when we have long running syscalls that
> might sit waiting in the kernel indefinitely?
I
On Tue, 5 Mar 2013 09:49:54 -0800
Tejun Heo wrote:
> On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> > So, I think this is why implementing freezer as a separate blocking
> > mechanism isn't such a good idea. We're effectively introducing a
> > completely new waiting state to a lot
On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> So, I think this is why implementing freezer as a separate blocking
> mechanism isn't such a good idea. We're effectively introducing a
> completely new waiting state to a lot of unsuspecting paths which
> generates a lot of risks and ev
Hello, guys.
On Tue, Mar 05, 2013 at 08:23:08AM -0500, Jeff Layton wrote:
> So, not a deadlock per-se in this case but it does prevent the freezer
> from running to completion. I don't see any way to solve it though w/o
> making all mutexes freezable. Note that I don't think this is really
> limit
On Mon, 4 Mar 2013 22:08:34 +
"Myklebust, Trond" wrote:
> On Mon, 2013-03-04 at 21:53 +0100, Oleg Nesterov wrote:
> > On 03/04, Mandeep Singh Baines wrote:
> > >
> > > The problem is that freezer_count() calls try_to_freeze(). In this
> > > case, try_to_freeze() is not really adding any value
On Mon, 2013-03-04 at 21:53 +0100, Oleg Nesterov wrote:
> On 03/04, Mandeep Singh Baines wrote:
> >
> > The problem is that freezer_count() calls try_to_freeze(). In this
> > case, try_to_freeze() is not really adding any value.
>
> Well, I tend to agree.
>
> If a task calls __refrigerator() hold
On 03/04, Mandeep Singh Baines wrote:
>
> The problem is that freezer_count() calls try_to_freeze(). In this
> case, try_to_freeze() is not really adding any value.
Well, I tend to agree.
If a task calls __refrigerator() holding a lock which another freezable
task can wait for, this is not freeze
On Mon, Mar 4, 2013 at 12:09 PM, Mandeep Singh Baines wrote:
> On Mon, Mar 4, 2013 at 7:53 AM, Myklebust, Trond
> wrote:
>> On Mon, 2013-03-04 at 23:33 +0800, Ming Lei wrote:
>>> Hi,
>>>
>>> CC guys who introduced the lockdep change.
>>>
>>> On Mon, Mar 4, 2013 at 11:04 PM, Jeff Layton wrote:
>>
On Mon, Mar 4, 2013 at 7:53 AM, Myklebust, Trond
wrote:
> On Mon, 2013-03-04 at 23:33 +0800, Ming Lei wrote:
>> Hi,
>>
>> CC guys who introduced the lockdep change.
>>
>> On Mon, Mar 4, 2013 at 11:04 PM, Jeff Layton wrote:
>>
>> >
>> > I don't get it -- why is it bad to hold a lock across a freez
+ rjw, akpm, tejun, mingo, oleg
On Mon, Mar 4, 2013 at 6:23 AM, Jeff Layton wrote:
> On Mon, 4 Mar 2013 14:14:23 +
> "Myklebust, Trond" wrote:
>
>> On Mon, 2013-03-04 at 21:57 +0800, Ming Lei wrote:
>> > Hi,
>> >
>> > The below warning can be triggered each time when mount.nfs is
>> > runnin
On Mon, 2013-03-04 at 23:33 +0800, Ming Lei wrote:
> Hi,
>
> CC guys who introduced the lockdep change.
>
> On Mon, Mar 4, 2013 at 11:04 PM, Jeff Layton wrote:
>
> >
> > I don't get it -- why is it bad to hold a lock across a freeze event?
>
> At least this may deadlock another mount.nfs durin
Hi,
CC guys who introduced the lockdep change.
On Mon, Mar 4, 2013 at 11:04 PM, Jeff Layton wrote:
>
> I don't get it -- why is it bad to hold a lock across a freeze event?
At least this may deadlock another mount.nfs during freezing, :-)
See detailed explanation in the commit log:
commit 6a
On Mon, 4 Mar 2013 22:40:02 +0800
Ming Lei wrote:
> On Mon, Mar 4, 2013 at 10:14 PM, Myklebust, Trond
> wrote:
> > On Mon, 2013-03-04 at 21:57 +0800, Ming Lei wrote:
> >> Hi,
> >>
> >> The below warning can be triggered each time when mount.nfs is
> >> running on 3.9-rc1.
> >>
> >> Not sure if f
On Mon, Mar 4, 2013 at 10:14 PM, Myklebust, Trond
wrote:
> On Mon, 2013-03-04 at 21:57 +0800, Ming Lei wrote:
>> Hi,
>>
>> The below warning can be triggered each time when mount.nfs is
>> running on 3.9-rc1.
>>
>> Not sure if freezable_schedule() inside rpc_wait_bit_killable should
>> be changed
On Mon, 4 Mar 2013 14:14:23 +
"Myklebust, Trond" wrote:
> On Mon, 2013-03-04 at 21:57 +0800, Ming Lei wrote:
> > Hi,
> >
> > The below warning can be triggered each time when mount.nfs is
> > running on 3.9-rc1.
> >
> > Not sure if freezable_schedule() inside rpc_wait_bit_killable should
>
On Mon, 2013-03-04 at 21:57 +0800, Ming Lei wrote:
> Hi,
>
> The below warning can be triggered each time when mount.nfs is
> running on 3.9-rc1.
>
> Not sure if freezable_schedule() inside rpc_wait_bit_killable should
> be changed to schedule() since nfs_clid_init_mutex is held in the path.
Cc:
Hi,
The below warning can be triggered each time when mount.nfs is
running on 3.9-rc1.
Not sure if freezable_schedule() inside rpc_wait_bit_killable should
be changed to schedule() since nfs_clid_init_mutex is held in the path.
[ 41.387939] =
[ 41.392913]
59 matches
Mail list logo
