Hi!
> > Well, it looks like we don't really know why things are done the way they
> > are done at least in some cases, so in my personal view it would be good to
> > go through all of the kernel freezer users just for this reason alone. We
> > can't really say which of them are legitimate without
Hello,
On Thu, Dec 26, 2013 at 09:14:49PM -0500, Alan Stern wrote:
> I can't disagree with this. But the design may well be perfectly
> adequate for some use cases. Given a workqueue or kthread which should
> not operate during system sleep, we have to:
>
> Tell the wq/thread to stop runn
Hello,
On Thu, 26 Dec 2013, Tejun Heo wrote:
> > Maybe it's the other way around: The separate paths are necessary, and
> > the freezer _simplifies_ the system sleep ops.
>
> Again, the point is it's too big a tool given the problem with history
> of abuse. It sure is "convenient" to have tool
On Thursday, December 26, 2013 11:05:17 AM Tejun Heo wrote:
> Hello, Rafael.
Hi Tejun,
> On Thu, Dec 26, 2013 at 04:05:53PM +0100, Rafael J. Wysocki wrote:
> > First, there is a removal-vs-resume deadlock which technically is related to
> > the freezing, but it is not entirely clear to me that us
On Thursday, December 26, 2013 02:01:20 PM Tejun Heo wrote:
> Hey,
>
> On Thu, Dec 26, 2013 at 01:42:29PM -0500, Alan Stern wrote:
> > In the case of hibernation, it's not so simple. We do need to perform
> > I/O, in order to save the memory image. But we also need to avoid
> > unnecessary I/O
Hey,
On Thu, Dec 26, 2013 at 01:42:29PM -0500, Alan Stern wrote:
> In the case of hibernation, it's not so simple. We do need to perform
> I/O, in order to save the memory image. But we also need to avoid
> unnecessary I/O, in order to keep the on-disk data consistent with the
> data in the m
On Thu, 26 Dec 2013, Tejun Heo wrote:
> Hello, Rafael.
>
> On Thu, Dec 26, 2013 at 04:05:53PM +0100, Rafael J. Wysocki wrote:
> > First, there is a removal-vs-resume deadlock which technically is related to
> > the freezing, but it is not entirely clear to me that using a more fine
> > grained
>
Hello, Rafael.
On Thu, Dec 26, 2013 at 04:05:53PM +0100, Rafael J. Wysocki wrote:
> First, there is a removal-vs-resume deadlock which technically is related to
> the freezing, but it is not entirely clear to me that using a more fine
> grained
> mechanism instead of the freezing will actually he
Hi Tejun,
On Wednesday, December 25, 2013 11:18:56 PM Tejun Heo wrote:
> Hello, Alan.
>
> On Wed, Dec 25, 2013 at 10:29:30PM -0500, Alan Stern wrote:
> > Thanks. As I understand it (correct me if this is wrong), the problem
> > is that some subsystems wait for a freezable work queue or kthread t
Hello, Alan.
On Wed, Dec 25, 2013 at 10:29:30PM -0500, Alan Stern wrote:
> Thanks. As I understand it (correct me if this is wrong), the problem
> is that some subsystems wait for a freezable work queue or kthread to
> carry out some job, and they do this as part of their resume pathway.
> Obvi
n Wed, 25 Dec 2013, Rafael J. Wysocki wrote:
> > Is this discussed in more detail somewhere (an email thread, for
> > example)?
>
> This one, more or less: https://lkml.org/lkml/2013/12/13/402
Thanks. As I understand it (correct me if this is wrong), the problem
is that some subsystems wait for
On Wednesday, December 25, 2013 09:57:09 AM Alan Stern wrote:
> On Wed, 25 Dec 2013, Rafael J. Wysocki wrote:
>
> > On Tuesday, December 24, 2013 04:55:46 PM Alan Stern wrote:
> > > On Tue, 24 Dec 2013, Tejun Heo wrote:
> > >
> > > > Hello, Linus.
> > > >
> > > > libata fixes for v3.13-rc5. The
On Wed, 25 Dec 2013, Rafael J. Wysocki wrote:
> On Tuesday, December 24, 2013 04:55:46 PM Alan Stern wrote:
> > On Tue, 24 Dec 2013, Tejun Heo wrote:
> >
> > > Hello, Linus.
> > >
> > > libata fixes for v3.13-rc5. There's one interseting commit - "libata,
> > > freezer: avoid block device remov
On Tuesday, December 24, 2013 04:55:46 PM Alan Stern wrote:
> On Tue, 24 Dec 2013, Tejun Heo wrote:
>
> > Hello, Linus.
> >
> > libata fixes for v3.13-rc5. There's one interseting commit - "libata,
> > freezer: avoid block device removal while system is frozen". It's an
> > ugly hack working ar
On Tue, 24 Dec 2013, Tejun Heo wrote:
> Hello, Linus.
>
> libata fixes for v3.13-rc5. There's one interseting commit - "libata,
> freezer: avoid block device removal while system is frozen". It's an
> ugly hack working around a deadlock condition between driver core
> resume and block layer dev
Hello, Linus.
libata fixes for v3.13-rc5. There's one interseting commit - "libata,
freezer: avoid block device removal while system is frozen". It's an
ugly hack working around a deadlock condition between driver core
resume and block layer device removal paths through freezer which was
made mo
16 matches
Mail list logo
