Re: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate
On Fri, 1 Dec 2017, Yu Chen wrote: > BTW, is nfs able to be included in this set? I also encountered a > freeze() failure due to nfs access during that stage recently. The freezer usage in NFS is magnitudes more complicated, so it makes sense to first go after the lower hanging fruit to figure out the viability of the whole aproach in practice. -- Jiri Kosina SUSE Labs
Re: [RFC 5/5] pm: remove kernel thread freezing
On Tue, 3 Oct 2017, Pavel Machek wrote: > > Again, I agree that the (rare) kthreads that are actually "creating" new > > I/O have to be somehow frozen and require special care. > > Agreed. Was any effort made to identify those special kernel threads? I don't think there is any other way than just inspecting all the try_to_freeze() instances in the kernel, and understanding what that particular kthread is doing. I've cleaned up most of the low-hanging fruit already, where the try_to_freeze() was obviously completely pointless, but a lot more time needs to be invested into this. -- Jiri Kosina SUSE Labs
Re: [RFC 5/5] pm: remove kernel thread freezing
On Tue, 3 Oct 2017, Jiri Kosina wrote: > > What about the many drivers outside filesystems that use the > > set_freezable() / try_to_freeze() / wait_event_freezable() API? > > Many/most of them are just completely bogus and pointless. More specifically -- they don't really care at all whether they get scheduled out exactly at the try_to_freeze() point; they are perfectly happy being scheduled out at any other scheduling point, and land on runqueue after the resume has been completed. Sure, certain drivers need to take action when system is undergoing hibernation/suspend. But that's what PM callbacks are for, not kthread hibernation. -- Jiri Kosina SUSE Labs
Re: [RFC 5/5] pm: remove kernel thread freezing
On Tue, 3 Oct 2017, Pavel Machek wrote: > > This point I don't understand. What exactly do you mean? > > Hibernation: > > We freeze, do system snapshot, unfreeze, and write image to > disk. Where/why do you unfreeze between creating the snapshot and writing it out? Again, I agree that the (rare) kthreads that are actually "creating" new I/O have to be somehow frozen and require special care. -- Jiri Kosina SUSE Labs
Re: [RFC 5/5] pm: remove kernel thread freezing
On Tue, 3 Oct 2017, Bart Van Assche wrote: > If just a single driver would use that API to prevent that I/O occurs while > processes are frozen then this patch will break that driver. I would like to > know your opinion about the following patch in particular: "[PATCH v4 1/7] md: > Make md resync and reshape threads freezable" > (https://www.spinics.net/lists/linux-block/msg17854.html). Alright, if there are kthreads which are actually *creating* new I/O (contrary to kthreads being I/O completion helpers) -- which apparently is the md case here, then those definitely have to be frozen in some form. -- Jiri Kosina SUSE Labs
Re: [RFC 5/5] pm: remove kernel thread freezing
On Tue, 3 Oct 2017, Bart Van Assche wrote: > What about the many drivers outside filesystems that use the > set_freezable() / try_to_freeze() / wait_event_freezable() API? Many/most of them are just completely bogus and pointless. I've killed a lot of those in the past, but the copy/paste programming is just too strong enemy to fight against. -- Jiri Kosina SUSE Labs
Re: [RFC 5/5] pm: remove kernel thread freezing
On Tue, 3 Oct 2017, Pavel Machek wrote: > Can knfsd be a problem? It'd actually be useful to walk through all the 'try_to_freeze()' instances in kthreads, and analyze those. I've started this effort, and as a result I removed most of them; but there are still quite a few remaining. And knfsd is one of those. > Can memory management doing background writes be a problem? This point I don't understand. What exactly do you mean? -- Jiri Kosina SUSE Labs
Re: [RFC 2/5] fs: freeze on suspend and thaw on resume
On Tue, 3 Oct 2017, Luis R. Rodriguez wrote: > This uses the existing filesystem freeze and thaw callbacks to > freeze each filesystem on suspend/hibernation and thaw upon resume. > > This is needed so that we properly really stop IO in flight without > races after userspace has been frozen. Without this we rely on > kthread freezing and its semantics are loose and error prone. > For instance, even though a kthread may use try_to_freeze() and end > up being frozen we have no way of being sure that everything that > has been spawned asynchronously from it (such as timers) have also > been stopped as well. > > A long term advantage of also adding filesystem freeze / thawing > supporting durign suspend / hibernation is that long term we may > be able to eventually drop the kernel's thread freezing completely > as it was originally added to stop disk IO in flight as we hibernate > or suspend. > > This also implies that many kthread users exist which have been > adding freezer semantics onto its kthreads without need. These also > will need to be reviewed later. > > This is based on prior work originally by Rafael Wysocki and later by > Jiri Kosina. > > Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> Thanks a lot for picking this up; I never found time to actually finalize it. Acked-by: Jiri Kosina <jkos...@suse.cz> for patches 2 and 5 (the fs agnostic code), which were in the core of my original work. -- Jiri Kosina SUSE Labs
Re: [PATCH 3/6] hid: make device_attribute const
On Mon, 21 Aug 2017, Bhumika Goyal wrote:
> Make this const as it is only passed as an argument to the
> function device_create_file and device_remove_file and the corresponding
> arguments are of type const.
> Done using Coccinelle
>
> Signed-off-by: Bhumika Goyal <bhumi...@gmail.com>
> ---
> drivers/hid/hid-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9bc9116..24e929c 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1662,7 +1662,7 @@ static bool hid_hiddev(struct hid_device *hdev)
> .size = HID_MAX_DESCRIPTOR_SIZE,
> };
>
> -static struct device_attribute dev_attr_country = {
> +static const struct device_attribute dev_attr_country = {
> .attr = { .name = "country", .mode = 0444 },
> .show = show_country,
Applied, thanks.
--
Jiri Kosina
SUSE Labs
[GIT PULL] minor floppy fix
Jens, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/linux-block.git for-jens (based on your current for-next branch) to get minor memory allocation fix for floppy driver, from Vlastimil Babka. Thanks. Vlastimil Babka (1): floppy: replace wrong kmalloc(GFP_USER) with GFP_KERNEL drivers/block/floppy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
