From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82D7C26B2D3 for ; Mon, 18 May 2026 23:15:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779146122; cv=none; b=L6/34eOuCzPemhrAC077Zi+4oxjOK3EBq9SUFlHRfGCGl/bRwp5kXW67DpflCy17VY9osEyfNuxK2D2UpB0eZJjF+n2fI9PhPDHEDiEToP2UK5OpQK1B3p2sJT9loyqiXu2kFXYTB9caSTZAhPre1QvuiwGfJxo+7zEu6nAu2Xo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779146122; c=relaxed/simple; bh=7nk9gwyXuDiUVsaNZRS1V7Ms3BjWy7Z/e5DZHNEfDvs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tNOdC0Fx5bGotAnXHCDV1N1o+1Jq45yj2Z/l+C8jaMrtFlOn0+wCyU+aDIORgl8T9dBbprz3xliJng+vrsguUX1GXICtrsxYHmb+Sh77Je9WywnQMIdPin6ixdMB2sLunCNBckkGbVOXe5K6xhEYkX18/R943lGTiwt2dyR+ZUY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com; spf=pass smtp.mailfrom=soleen.com; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b=TsE9tKBf; arc=none smtp.client-ip=209.85.160.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soleen.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b="TsE9tKBf" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-50e63771d91so32004281cf.0 for ; Mon, 18 May 2026 16:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1779146119; x=1779750919; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=7KNTaIG0lsIqN03Ekvf0L0UIuEbXXSLWDvqyaaegcdY=; b=TsE9tKBfpPfLKLrjfyJLXXURkBGA3m8bBOCYZbekBVbCgkf9GutC0SXDg+zKclRJV3 PKM8uGwKlAGuOgxirszXrlzIcoRw/cgt8uGAQeA7nQKja1uwiWZcnAvGvgW1L3lyAztI TO3Wx8TtYdr+RBvJaBhefMZLzLMgA0vkS+9Hu4XRHrgbNiNrSgXrLf0Gd7s2VWAENalj 6hPEWWI+GefGdMOJl9vInxttDaw1zcG6kS7pqFj1KZ+mnXHGoaaYtTX7x+IY1VLVdZjd +gJbHSvbi4Q8/ppGkYW+vwVa4uAPymirVn+X4k6UBVMjOfBqHHWoRRM9SwLrPRarGDn6 uU9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779146119; x=1779750919; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7KNTaIG0lsIqN03Ekvf0L0UIuEbXXSLWDvqyaaegcdY=; b=RnLQqbO2aIHM/SP9dkjUk9KZvS2lFRA12th0vpdAzBd3/es2MI1dMoVraOt+pzWWB8 w5lHTx8Qg52mwhuVicCNFxSHZ/JVmi1hEE5mwfhiOw+HHaQsfRyMtCqo607NsC3/v0kc tU3Rig0lmi4kjXq+XF/CmkESKUzSKm9bUCS6lpRRmCypFT3QxJ/UpyzBjegjF3r9UE80 gmlTyOt/jtyvo9zKRBE0Y49+/d7Fy34lI5fZuN9G8///NBEcyDoDBN6qPeJcGItDeMXT k6btMOE7R2EFo3dqkuor9H8ePFhdwOVAqfQ57s4Waw0kDRPrguLq2F2quZVxbA2uObjk FbhA== X-Forwarded-Encrypted: i=1; AFNElJ9lM3Szq1XIU6JlphSWHCVdm6T3HJSk17Y6FtMTMmI4c0/yStvCM6345LpjskwKb7Qpu9IK0QBQaSBOoOM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz8IEgqggRAkOcUdCbuynUh/RaSd+5Zn013KRot767AbVf6qtwt n8nwW6NqXW+CeiaejgB5XW6XS79F9YETXa0J7maY14HYUuJg4ma74VO07MF7OGIjchg= X-Gm-Gg: Acq92OGtAmS5DJ5kzuTC4juhpc+HX2JHEirQ5wBodikvMZ1rHPCays/K9gX/xr9gtNU r1TXzhMLIf4ww7FjgyNCfyk69gyTES0D0hmm3Gxae32vJ8tS+giAyrVw5G4MUD8VaXJktCsEShl CJjhDSvXF/PiHgBPPgs6fnjY6yMG2P9iYdf9d86KxZBagNp6M/cPdjzBOZ/4E7OYsuy5lM4c4ud /dDE7bfhgBiapiu2SLJzdqqfFTISuJFYAy+eWxYHu/zv9YyXNdZu7/lWG7Yjzg27yyUP+4eO5O/ uRLNl5DfxbEgAlVJ3UYso95dSH/jh4z9KP5gpJzEtbO/0quh4QNGVKhLPG2bt9f08vQ0vgyG2tn mdspk4F32cW4uVS7LbGcxNne2LfwV6VXt1q1Vf5k/ptmS6BAWTJ5VZ68a9askhkHErP2J1BN+vd iW9YKNMC3SHYtCyi1IUZLbuxELgv+K6z4G5WZTQ3+9zMKHpJUc8OE= X-Received: by 2002:ac8:7f8f:0:b0:50f:b3d0:c5ed with SMTP id d75a77b69052e-5165a0e568fmr252479931cf.31.1779146119282; Mon, 18 May 2026 16:15:19 -0700 (PDT) Received: from plex ([71.181.43.54]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-516456df09csm146874721cf.13.2026.05.18.16.15.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 16:15:18 -0700 (PDT) Date: Mon, 18 May 2026 23:15:17 +0000 From: Pasha Tatashin To: Pratyush Yadav Cc: Pasha Tatashin , rppt@kernel.org, sourabhjain@linux.ibm.com, jbouron@amazon.com, akpm@linux-foundation.org, bhe@redhat.com, linux-kernel@vger.kernel.org, dan.carpenter@linaro.org, rafael.j.wysocki@intel.com, piliu@redhat.com, kexec@lists.infradead.org, skhawaja@google.com, graf@amazon.com, mario.limonciello@amd.com Subject: Re: [PATCH v5 3/5] liveupdate: block session mutations during reboot Message-ID: References: <20260518125459.1092373-1-pasha.tatashin@soleen.com> <20260518125459.1092373-4-pasha.tatashin@soleen.com> <2vxzo6ic8ysn.fsf@kernel.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2vxzo6ic8ysn.fsf@kernel.org> On 05-18 18:31, Pratyush Yadav wrote: > On Mon, May 18 2026, Pasha Tatashin wrote: > > > During the reboot() syscall, user processes may still be running > > concurrently and attempting to mutate sessions (e.g., creating, > > retrieving, or releasing sessions). To prevent this, introduce > > luo_session_serialize_rwsem to synchronize mutations with the > > serialization process. > > > > All session mutation operations (create, retrieve, release, ioctl) take > > the read lock. The serialization process (luo_session_serialize) takes > > the write lock and holds it indefinitely on success. This effectively > > freezes the LUO session subsystem during the transition to the new > > kernel. If serialization fails, the lock is released to allow recovery. > > Good idea I think. Hi Pratyush, > > But, do we need a new mutex? Can't we use luo_session_header->rwsem? > Session creation and release take the header rwsem at one point anyway, > so perhaps we can just reuse that? The sh->rwsem is for protecting the the session list. We only take it as a writer when modifying the list (insert/remove) and as a reader when traversing it. Also, we drop sh->rwsem as soon as we've acquired the per-session mutex to allow other list operations to proceed while a session is being modified. Because of this, many session mutation operations (specifically ioctl calls) don't touch sh->rwsem at all—they jump straight to the session state via the file's private_data. To use sh->rwsem to block these mutations, we would be forced to add down_read(&sh->rwsem) to every ioctl path. This would be a layering violation, coupling list management to per-session data mutations, and would introduce a global bottleneck for operations that are otherwise independent. The only other way to prevent mutations without a new global lock would be for the reboot process to acquire every individual session mutex. However, since LUO_SESSION_MAX can be large, this would exceed lockdep's maximum lock tracking limit and trigger failures. The luo_session_serialize_rwsem provides a dedicated signal to freeze the entire subsystem without messing with the existing fine-grained locking logic. > > Also, do we need to block incoming sessions? They won't participate in > serialization, so perhaps we can leave those alone, and all the outgoing > sessions get protected by the outgoing session header rwsem? Incoming sessions don't participate in serialization, but blocking them makes the code more robust. This provides a level of future proofing if new ioctls or operations are added later, we won't accidentally miss a path that should have been frozen during reboot. It's safer to treat the subsystem as a single unit that freezes entirely once the transition begins. Pasha