linux-kernel - Re: [PATCH 1/1] suspend: delete sys

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]

Date:	Tue, 07 Jul 2015 15:42:35 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Dave Chinner <david@...morbit.com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Alan Stern <stern@...land.harvard.edu>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Linux PM list <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: [PATCH 1/1] suspend: delete sys_sync()

At Tue, 7 Jul 2015 11:17:56 +1000,
Dave Chinner wrote:
> 
> > > > Moreover, question is if we really need to carry out the sync on *every*
> > > > suspend even if it is not pointless overall.  That shouldn't really be
> > > > necessary if we suspend and resume often enough or if we resume only for
> > > > a while and then suspend again.  Maybe it should be rate limited somehow
> > > > at least?
> > > 
> > > If you suspend and resume frequently, then the cost of the sync
> > > shoul dbe negliable because the amount of data dirtied between
> > > resume/suspend shoul dbe negliable. hence my questions about where
> > > sync is spending too much time, and whether we've actually fixed
> > > those problems or not. If sync speed on clean filesystems is a
> > > problem then we need to fix sync, not work around it.
> > 
> > Well, say you never suspend, but you also only shut down the system when you
> > need to replace the kernel on it.  How often would you invoke global sync on
> > that system?
> 
> Never, because:
> 
> 	- the kernel does background writeback of dirty data so you
> 	  don't need to run sync while the system is running; and
> 	- unmount during shutdown runs sync_filesystem() internally
> 	  (just like sys_sync does) to ensure the filesystem is
> 	  clean and no data is lost.
> 
> Seriously, stop being making ignorant arguments to justify removing
> sys_sync(). *If* there's a problem sys_sync() we need to *fix it*,
> not ignore it.

This thread remembered me of an old problem I faced: suspend fails
while copying a large file.  So I tried again with 4.2-rc1.

I put a slow USB stick with ext4, started copying a 4GB ISO file, and
triggered the suspend.  It failed.

Then removed sys_sync(), and retested.  It still failed.

The log shows like:

 PM: Preparing system for sleep (freeze)
 Freezing user space processes ... (elapsed 0.002 seconds) done.
 Freezing remaining freezable tasks ... 
 Freezing of tasks failed after 20.003 seconds (0 tasks refusing to freeze, wq_busy=1):
 Restarting kernel threads ... done.
 Restarting tasks ... done.

So, removing sys_sync() will save a small amount of time, but it won't
help always...


Takashi
--
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/