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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201108271422.33754.rjw@sisk.pl>
Date:	Sat, 27 Aug 2011 14:22:33 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Tejun Heo <tj@...nel.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, menage@...gle.com,
	linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: [PATCH 06/16] freezer: make exiting tasks properly unfreezable

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/