lkml.org 
[lkml]   [2011]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 06/16] freezer: make exiting tasks properly unfreezable
Date
Hi,

On Saturday, August 27, 2011, Tejun Heo wrote:
> Hello,
>
> On Sat, Aug 27, 2011 at 12:51:22PM +0200, Rafael J. Wysocki wrote:
> > It seems that you are confusing two things - the interactions between the
> > drivers and kernel subsystems that can happen at any time, even during suspend
> > and resume, which can be taken care of with the help of various synchronization
> > mechanisms _inside_ of the kernel, and the interactions between the drivers
> > and user space resulting from user space using sysfs, ioctls, mmap,
> > proc, debugfs, sysv IPC, open/close, read/write and so on and so on.
> > The freezer's job is to take the second type of interactions out of the
> > picture for suspend/resume.
>
> So, there are two layers - user <-> driver and driver <-> hardware.
> Quiescing the first layer (user <-> driver) in most cases would
> effectively quiesce the second layer (driver <-> hardware) too and
> some drivers depend on that. What I'm trying to say is that that
> cascading of quiescing can be unreliable. Operations can propagate
> via asynchronous mechanisms.

I agree.

> So, I think it's better to quiesce the kernel <-> device layer like
> SCSI/ATA drivers do.

Well, in general that _should_ be done in addition to the
user <-> driver quiescing. :-)

> For things like direct access to hardware from ioctl, freezing does
> make sense but there were some drivers (I don't remember which
> exactly) which depended on freezing for block IO quiescing (nobody is
> issuing no new IO so it should be safe!), which is quite scary given
> the async nature of block IO processing.

Those are bugs in the majority of cases.

> For block IOs, for example, I think the best way would be put most of
> quiescing logic and responsibilities to block layer directly.

Perhaps.

> > _Some_ drivers may want to use the freezer for their own purposes (e.g.
> > by using a freezable workqueue to avoid their own work items from being
> > executed in parallel with suspend/resume routines), but obviously they
> > have to know what they are doing.
>
> One such driver was thinkpad_acpi. It used the fact that the kthread
> entered freezer as a que to intiate hardware reset. Maybe it's okay
> but I think that really should hang off proper suspend/resume hook.

It's difficult to comment being unfamiliar with the driver's internals,
but definitely using a proper suspend/resume sounds like a good idea.

Thanks,
Rafael


\
 
 \ /
  Last update: 2011-08-27 14:23    [W:0.065 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site