From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753425AbdKALIt (ORCPT ); Wed, 1 Nov 2017 07:08:49 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:57146 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752087AbdKALIs (ORCPT ); Wed, 1 Nov 2017 07:08:48 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Nikolay Borisov Cc: Christian Brauner , Linux Containers , tycho@tycho.ws, linux-kernel@vger.kernel.org References: <20171024220441.10235-1-christian.brauner@ubuntu.com> <20171024220441.10235-2-christian.brauner@ubuntu.com> <871sliubhj.fsf_-_@xmission.com> <87k1zaswu6.fsf_-_@xmission.com> <143adb61-fb8e-fc1b-396b-b18836e68766@suse.com> Date: Wed, 01 Nov 2017 06:08:35 -0500 In-Reply-To: <143adb61-fb8e-fc1b-396b-b18836e68766@suse.com> (Nikolay Borisov's message of "Wed, 1 Nov 2017 10:31:25 +0200") Message-ID: <87a806ntn0.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1e9qsy-0007vE-9Y;;;mid=<87a806ntn0.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=174.19.78.123;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+fq8Pbg0shxwH39d3L7h86Fm2jg5tiuWk= X-SA-Exim-Connect-IP: 174.19.78.123 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4998] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Nikolay Borisov X-Spam-Relay-Country: X-Spam-Timing: total 5750 ms - load_scoreonly_sql: 0.09 (0.0%), signal_user_changed: 3.8 (0.1%), b_tie_ro: 2.4 (0.0%), parse: 1.45 (0.0%), extract_message_metadata: 65 (1.1%), get_uri_detail_list: 2.7 (0.0%), tests_pri_-1000: 28 (0.5%), tests_pri_-950: 14 (0.2%), tests_pri_-900: 1.97 (0.0%), tests_pri_-400: 58 (1.0%), check_bayes: 55 (1.0%), b_tokenize: 10 (0.2%), b_tok_get_all: 16 (0.3%), b_comp_prob: 4.1 (0.1%), b_tok_touch_all: 10 (0.2%), b_finish: 0.88 (0.0%), tests_pri_0: 1145 (19.9%), check_dkim_signature: 2.2 (0.0%), check_dkim_adsp: 25 (0.4%), tests_pri_500: 4425 (77.0%), poll_dns_idle: 4391 (76.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 3/5] userns: Don't read extents twice in m_start X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nikolay Borisov writes: > On 1.11.2017 01:48, Eric W. Biederman wrote: >> >> This is important so reading /proc//{uid_map,gid_map,projid_map} while >> the map is being written does not do strange things. >> >> Signed-off-by: "Eric W. Biederman" >> --- >> kernel/user_namespace.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c >> index 563a2981d7c7..4f7e357ac1e2 100644 >> --- a/kernel/user_namespace.c >> +++ b/kernel/user_namespace.c >> @@ -683,11 +683,13 @@ static void *m_start(struct seq_file *seq, loff_t *ppos, >> struct uid_gid_map *map) >> { >> loff_t pos = *ppos; >> + unsigned extents = map->nr_extents; >> + smp_rmb(); > > Barriers need to be paired to work correctly as well as have explicit > comments describing the pairing as per kernel coding style. Checkpatch > will actually produce warning for that particular memory barrier. So please look at the code and read the comment. The fact the barrier was not in m_start earlier is strictly speaking a bug. In practice except for a very narrow window when this data is changing the one time it can, this code does not matter at all. As for checkpatch I have sympathy for it, checkpatch has a hard job, but I won't listen to checkpatch when it is wrong. If you have additional cleanups you would like to make in this area please send patches. Eric >> >> - if (pos >= map->nr_extents) >> + if (pos >= extents) >> return NULL; >> >> - if (map->nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS) >> + if (extents <= UID_GID_MAP_MAX_BASE_EXTENTS) >> return &map->extent[pos]; >> >> return &map->forward[pos]; >>