system_nrt_wq, system suspend, and the freezer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Folks:

I recently uncovered a bug in the block layer.  It uses a workqueue to
periodically probe removable drives for media or other state changes,
and the workqueue it uses is system_nrt_wq.

The bug is that system_nrt_wq is not freezable, so it keeps on running
even while the system is in the process of suspending or hibernating.  
Doing I/O to a suspended drive doesn't work well and in some cases
causes nasty problems.  Obviously these polls need to stop during a 
suspend transition.

A search through the kernel shows that system_nrt_wq is also used in a
few other subsystems:

./fs/cifs/cifssmb.c:	queue_work(system_nrt_wq, &rdata->work);
./fs/cifs/cifssmb.c:	queue_work(system_nrt_wq, &wdata->work);
./fs/cifs/misc.c:				queue_work(system_nrt_wq,
./fs/cifs/connect.c:	queue_delayed_work(system_nrt_wq, &server->echo, SMB_ECHO_INTERVAL);
./fs/cifs/connect.c:	queue_delayed_work(system_nrt_wq, &tcp_ses->echo, SMB_ECHO_INTERVAL);
./fs/cifs/connect.c:	queue_delayed_work(system_nrt_wq, &cifs_sb->prune_tlinks,
./fs/cifs/connect.c:	queue_delayed_work(system_nrt_wq, &cifs_sb->prune_tlinks,

./drivers/mmc/core/host.c:		queue_work(system_nrt_wq, &host->clk_gate_work);

./drivers/gpu/drm/drm_crtc_helper.c:		queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
./drivers/gpu/drm/drm_crtc_helper.c:		queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
./drivers/gpu/drm/drm_crtc_helper.c:		queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, 0);

./security/keys/gc.c:		queue_work(system_nrt_wq, &key_gc_work);
./security/keys/gc.c:	queue_work(system_nrt_wq, &key_gc_work);
./security/keys/gc.c:	queue_work(system_nrt_wq, &key_gc_work);
./security/keys/gc.c:		queue_work(system_nrt_wq, &key_gc_work);
./security/keys/key.c:			queue_work(system_nrt_wq, &key_gc_work);

My question to all of you: Should system_nrt_wq be made freezable, or 
should I create a new workqueue that is both freezable and 
non-reentrant?  And if I do, which of the usages above should be 
converted to the new workqueue?

Thanks,

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux