Re: [PATCH 06/16] freezer: make exiting tasks properly unfreezable

["Rafael J. Wysocki" <rjw@sisk.pl>]

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