Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH 06/16] freezer: make exiting tasks properly unfreezable | Date | Sat, 27 Aug 2011 14:22:33 +0200 |
| |
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
| |