From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:40415 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752232AbdK1WRU (ORCPT ); Tue, 28 Nov 2017 17:17:20 -0500 From: NeilBrown To: paulmck@linux.vnet.ibm.com, Florian Weimer Date: Wed, 29 Nov 2017 09:17:09 +1100 Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Triplett Subject: Re: [PATCH] VFS: use synchronize_rcu_expedited() in namespace_unlock() In-Reply-To: <20171127144125.GF3624@linux.vnet.ibm.com> References: <87y3nyd4pu.fsf@notabene.neil.brown.name> <20171026122743.GX3659@linux.vnet.ibm.com> <20171127144125.GF3624@linux.vnet.ibm.com> Message-ID: <87induxd3u.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, Nov 27 2017, Paul E. McKenney wrote: > On Mon, Nov 27, 2017 at 12:27:04PM +0100, Florian Weimer wrote: >> On 10/26/2017 02:27 PM, Paul E. McKenney wrote: >> >But just for completeness, one way to make this work across the board >> >might be to instead use call_rcu(), with the callback function kicking >> >off a workqueue handler to do the rest of the unmount. Of course, >> >in saying that, I am ignoring any mutexes that you might be holding >> >across this whole thing, and also ignoring any problems that might arise >> >when returning to userspace with some portion of the unmount operation >> >still pending. (For example, someone unmounting a filesystem and then >> >immediately remounting that same filesystem.) >>=20 >> You really need to complete all side effects of deallocating a >> resource before returning to user space. Otherwise, it will never >> be possible to allocate and deallocate resources in a tight loop >> because you either get spurious failures because too many >> unaccounted deallocations are stuck somewhere in the system (and the >> user can't tell that this is due to a race), or you get an OOM >> because the user manages to queue up too much state. >>=20 >> We already have this problem with RLIMIT_NPROC, where waitpid etc. >> return before the process is completely gone. On some >> kernels/configurations, the resulting race is so wide that parallel >> make no longer works reliable because it runs into fork failures. > > Or alternatively, use rcu_barrier() occasionally to wait for all > preceding deferred deallocations. And there are quite a few other > ways to take on this problem. So, supposing we could package up everything that has to happen after the current synchronize_rcu() and put it in an call_rcu() call back, then instead of calling synchronize_rcu_expedited() at the end of namespace_unlock(), we could possibly call call_rcu() there and rcu_barrier() at the start of namespace_lock()..... That would mean a single unmount would have low impact, but it would still slow down a sequence of 1000 consecutive unmounts. Maybe we would only need the rcu_barrier() before select namespace_lock() calls. I would need to study the code closely to form an opinion. Interesting idea though. Hopefully the _expedited() patch will be accepted - I haven't had a "nak" yet... thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlod4GUACgkQOeye3VZi gbmzWQ//WXjwfTJXPfZ+AQenE9fVd797iqhEnYgzzxUzlnjHIXXtEA3q1+C+yR+Q lOAUYu1NJoKm+veml7glZOJyCQg78OSf4gyMsAhBK1J/Avdl7xypGWw5oIE6l7zp 3VTtTJHQczCsZPWMNYgRisAvnJYaK4PvvJG2F7EysV3zveBmyriDb/5xwHEijvGl Htm8G6ziJPbYt3LHoL2vW9CQvPHnYkOsZDtH4+K/GNc4tm1DOCDpaqrn6xkOLepw 8l9uwo++l8qIgm+ViOeUmppNM1YuJDjc/VRfMSctWOJ8crs9KbjW3Qo5p//W5xts dG7k0bcvH+YRgkCNLj0Y2unFVGcma3Ww08g2rIWDhIiRm17b7UrSXr9MsgoTXPqy eGTqisa2bW0sK8QgQbiZz3M7dU+/mfnL0m6Dae4RkrenHJ1sove+O+X6YL/GZe9r LOtgEI88AIjrh9mBqgbb2syZT7rb9nT/jEdbEJUhhOyd2h+3DIlEj4rwcadg9B6z 0DdwYqFx3H21S5Fz2g2fVxWHkep4UKL0Ka1+/4ZWZUA6WkwSUBoTpaWLGQzDAvBI X7tRVgYyvcKHB7oRTSGFjGgIruilnMB22Y7Qg1OKcoWRvDhWTkbvbpN2MzgMqVjM 4odeDkBYybnh5Z+baBxEVnHaRa5fTSAe91r56NwFcCxtG3ZsNL4= =sKHY -----END PGP SIGNATURE----- --=-=-=--