From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753613AbbE1LfN (ORCPT ); Thu, 28 May 2015 07:35:13 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:33903 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752325AbbE1LfK (ORCPT ); Thu, 28 May 2015 07:35:10 -0400 Date: Thu, 28 May 2015 14:35:07 +0300 From: Cyrill Gorcunov To: Alexey Dobriyan Cc: Andrew Morton , Linux Kernel , Jarod Wilson , Jan Stancek Subject: Re: [PATCH 2/2] proc: fix PAGE_SIZE limit of /proc/$PID/cmdline Message-ID: <20150528113507.GK17625@uranus.sw.swsoft.com> References: <20150527214757.GA12863@p183.telecom.by> <20150527214953.GB12863@p183.telecom.by> <20150527221435.GG17625@uranus.sw.swsoft.com> <20150527222941.GA28699@p183.telecom.by> <20150527224825.GI17625@uranus.sw.swsoft.com> <20150527231207.GA29641@p183.telecom.by> <20150528065957.GJ17625@uranus.sw.swsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2015 at 02:14:41PM +0300, Alexey Dobriyan wrote: > >> > >> It is snapshot w.r.t getting both pairs not snapshot w.r.t atomicity or > >> something (unsigned long access is atomic after all). Once down_write() > >> is used in the other place, it even becomes obviously correct code! > > > > Not at all. It is correct if and only if you're operating under lock > > taken, once you fetch the pair and left the lock it simply local copies > > of values the descriptor had when lock was taken. > > Yes, and? > > You do not complain that signal statistics is collected > under sighand lock but printed for /proc/*/status without, do you? They are different, in signal statistics we fetch the _complete_ entries, ie full copies of data. In turn you fetch only pointers to data. Don't you see the difference? IOW, prctl modifies members under the lock testing both the pointers and the data they points to are valid _under_ the lock, but you instead fetch the addresses under the lock, leave lock and continue operating with addresses, which is wrong imho. (I don't see some serious problem here because in worst scenario (if someone set up bad pointers here) we simply get page fault or some related error for application, not the kernel itself, so I won't insist).