From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gray.cherry.relay.mailchannels.net (gray.cherry.relay.mailchannels.net [23.83.223.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 640BF3BAD89 for ; Thu, 30 Jul 2026 20:09:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=23.83.223.76 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785442210; cv=none; b=m560Dy5a/TtJ9kwznMy0tcdVNViYYl4NBa11ebtsLsoDCxQidhSM0wimLXUuTpSswRcT8rkydV3hnM+YuQWktd5dHOWar3LoLuoo9p5xYSN4uWag7plBHsgWiX+GeMIsXDP9QYcNZTmOSTNmJljTgnOwCoHfU/My9ZpCW8HI/jE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785442210; c=relaxed/simple; bh=ckbiKldv3QrAeyy1Ljm8pWq8iYXaahTgTfSIm11/0M0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PQ0dGlv4Wu4jm8mN8TmbnyPrEXBrQrQqzb6fMmuYGL3HO6ZLI/PKeg6LJ7CgJUVydtm/cVNFHUlSznxbxr+Cup7Yuu9SgVlSO0kdzHCn6xv8Sog7LiYiqagnmZ8VveusnBFps+taU6nMSTrSsXshM1JjqMRgfoOd2jC1SeeL/uU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net; spf=fail smtp.mailfrom=stgolabs.net; dkim=pass (2048-bit key) header.d=stgolabs.net header.i=@stgolabs.net header.b=QpUCzXob; arc=none smtp.client-ip=23.83.223.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=stgolabs.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=stgolabs.net header.i=@stgolabs.net header.b="QpUCzXob" X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 884007E2225; Thu, 30 Jul 2026 19:32:40 +0000 (UTC) Received: from pdx1-sub0-mail-a210.dreamhost.com (trex-green-4.trex.outbound.svc.cluster.local [100.108.64.42]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E98707E3220; Thu, 30 Jul 2026 19:32:34 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net X-MC-Relay: Good X-MailChannels-SenderId: dreamhost|x-authsender|dave@stgolabs.net X-MailChannels-Auth-Id: dreamhost X-Gusty-Spicy: 7d74c7703379ff0f_1785439959158_2853620514 X-MC-Loop-Signature: 1785439959158:2483764265 X-MC-Ingress-Time: 1785439959158 Received: from pdx1-sub0-mail-a210.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.108.64.42 (trex/8.0.2); Thu, 30 Jul 2026 19:32:39 +0000 Received: from offworld (unknown [76.167.199.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dave@stgolabs.net) by pdx1-sub0-mail-a210.dreamhost.com (Postfix) with ESMTPSA id 4h9zqk3VMLz26; Thu, 30 Jul 2026 12:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stgolabs.net; s=dreamhost; t=1785439954; bh=K1TXJIWbJ7JBUlKpPuz7P0a2HKHdEbvSj92wtpStaus=; h=Date:From:To:Cc:Subject:Content-Type; b=QpUCzXobe/BLYoItO/wVAlbatdIGnGbAsOUZnBSVyV1lHlPOP1IeWxJNjkMD1zMp2 TVDrbF3nhLANnzXSoF0/pA+HSSQpk6Ncx4faKxTpRNJ8IsNGbWeBVZDT5hH16QA6fD P5f19Sk6L71d1teNX2srRr1j1XhOvxFUc/yZrGEzPtNEp2SWVVsoQj5GuLiiPigNFf Dwg0XZk1FThI/u8y5BY0p7jXDW4r7c343P0PvRw/L2OV8iAxjJ84adl9P3bxy7wHt7 F0fw963XnDU0bYLlu4PtBU31kLy7Wx/d2eiuNf+Haf7H86QvQ0L1WQ3gfneK1hf+Mw LurUuIZYMax3w== Date: Thu, 30 Jul 2026 12:32:31 -0700 From: Davidlohr Bueso To: Andrew Morton Cc: Jianlin Shi , linux-kernel@vger.kernel.org, ebiederm@kernel.org, "Eric W. Biederman" Subject: Re: [PATCH v2] ipc: only destroy orphaned shm segments on sysctl write Message-ID: <20260730193231.h4mj32js6jomitvw@offworld> References: <20260625160601.1a58f7e114be14161e710148@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260625160601.1a58f7e114be14161e710148@linux-foundation.org> User-Agent: NeoMutt/20220429 On Thu, 25 Jun 2026, Andrew Morton wrote: >On Mon, 15 Jun 2026 10:27:41 +0800 Jianlin Shi wrote: > >> proc_ipc_dointvec_minmax_orphans() currently calls >> shm_destroy_orphaned() whenever shm_rmid_forced is set, including on >> sysctl reads. Reading /proc/sys/kernel/shm_rmid_forced should not take >> shm_ids rwsem for write and walk all segments. >> >> Only run the cleanup when the sysctl is written and the forced RMID >> policy is enabled. >> >> When shm_rmid_forced=1, monitoring tools that read >> /proc/sys/kernel/shm_rmid_forced trigger the cleanup on every read. >> >> ... >> >> --- a/ipc/ipc_sysctl.c >> +++ b/ipc/ipc_sysctl.c >> @@ -28,7 +28,7 @@ static int proc_ipc_dointvec_minmax_orphans(const struct ctl_table *table, int w >> >> if (err < 0) >> return err; >> - if (ns->shm_rmid_forced) >> + if (write && ns->shm_rmid_forced) >> shm_destroy_orphaned(ns); >> return err; >> } > >Seems reasonable, I guess. Maybe. It's not backward compatible. > >Nothing in the shm_rmid_forced documentation >(Documentation/admin-guide/sysctl/kernel.rst) indicates that a read has >any such side-effect. > >But there's a risk that users have discovered that a read has this >effect, so they're using reads because that's a lot less hassle than >figuring out what value to write. > >Davidlohr, Eric: any thoughts on this? The only way I can justify this is that the doc is explicit about the write, so users abusing the read can't really complain... and this is also the more intuitive user expectation, and prevents unprivileged users from doing destructive actions. But also, afaict, for multi namespace use cases, this read effect has less impact as of 85b6d24646e4 ("shm: extend forced shm destroy to support objects from several IPC nses"). After that commit the reaping is done per-segment - exit_shm() uses the segment's namespace instead of the exiting task's - so the segment is destroyed by exit_shm() if the creator dies while it is unattached, or by shm_close() on the last detach, leaving a later sysctl read with nothing to find - albeit still grabbing locks. Acked-by: Davidlohr Bueso (but I'm not opposed to dropping this patch and leaving this as is if this is not a real problem/use case) > >btw, the doc says "if you change this from 0 to 1, already created >segments without users and with a dead originative process will be >destroyed" but the implementation will do the destruction for any write >of a non-zero value. It should read "if a non-zero value is written >already created segments without users and with a dead originative >process will be destroyed". Minor detail. Yes that non-zero rewording would match the code, but the doc's explicit 0->1 does suggest doing the reap only when first enabling it, instead of on demand if already enabled. But ultimately I agree with this "non-zero" in the doc. Thanks, Davidlohr