From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) (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 3C83D421EF4 for ; Wed, 6 May 2026 15:25:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778081147; cv=none; b=RO8DuOtICNKbkyzecz9pSa5X5cdR2tDojZ8dSCtl9Kot1BFDwrT73iSTs+13d/0fFIWi2tEiy0j0QcHeEfJZGOtyXdyWThH2FKdqLhsOnsj5LlOEqCXyTB2KuU8YFsoL+KgLdU8TOq+1lc/FLycH9dpbtunp0jryV2OA/phFPJ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778081147; c=relaxed/simple; bh=8hJ+rd9H89n+e7QuHPDAFlx/J/6fQpEpqRmXkeM4tH0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gFQ5OBiO4inGm0D4YM5ETLK3VI+BL9J6kgKIhdKmKGDxayxEOtStoi12sG3Ui7VesCow/PSYQDaESIuQQ9FtQkkfzH4/fCik0t/i5nBbW8I31B8BEq2YacFppx71q5ScbBGrhNPVwvUhIKPpC40Db30Vv1V3dkAt1TtRl0zoCP4= 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=RxOLs8fF; arc=none smtp.client-ip=209.85.128.176 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="RxOLs8fF" Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-7bd65714dcaso57225047b3.3 for ; Wed, 06 May 2026 08:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1778081145; x=1778685945; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vmP5Cnx0QocTDrzF4aQm1ITmtTww9O7YQ/iIm+fw4/E=; b=RxOLs8fFvX0zNPKBH5CVBV7IBCk8PyTaTMTArazhpflFNzxcNU5ftca9+y6JaHqLaW OIQiMBviDUoZ6QO/16Q8rZy7nE/0AzJITFVprho2wXpn/kFJjb6iOVoF9rpRq69gm67o FoHRk5iFgIWyTBj6CFWGZS0hPK/Xwxy4QYtPD+T4awRDora9jY1r/f5cZQN/Fyw7CJey 31QaJnFon9j8LAtCw7cRlDCpLZ3ROSZg6WbZCB/8chXlTe9DIA2Qf6TamskTpGFA4AZl kdxd+MvTP9zPYjpDXdZtLlxcMMGy23q/ptgADP7IBVFEnv4l40ji/MxossnLANkXICuH emzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778081145; x=1778685945; h=in-reply-to: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=vmP5Cnx0QocTDrzF4aQm1ITmtTww9O7YQ/iIm+fw4/E=; b=q/9vQd+Sgz+X1ipWBIEF6eUldxuEYjh9l1o5u2dibTISc7loWORzyY6RtH7Hd6WDBL zpgtdHL0bzP4+/DKamL8mpI2tLAAfTV5kQrVqUPKZGdjuqR5ln/cD422BBV4tHKQaSS4 J7qnXQYSltRBuj4cixOj44M6lHnRoG+5XN6GRsmnFZOaPVeqqc3m2uQ5JVS59NQSI57f BimH4JNgeLNbI6m26uqGlXZA/mY+75se6XpZ1w071ksYuMtx1F6ze8IEY7l+BmgT4aE+ JlWM12b2+iB3h2EviFHiIoPf8yGVljC3NxNj9Q3BuyoXRC4HrlgZeHnT/qOZhIGB3rpm 2Skg== X-Forwarded-Encrypted: i=1; AFNElJ/54Qvvz0HgREma3khOAJE6q9ScPj5e8BWJWWgUmOK0YPEcbjx7l3K/nWggRaE3a52PO+1XgbtFSnECjxM=@vger.kernel.org X-Gm-Message-State: AOJu0YweVuDPiHAON+7YBqqgrdW2ccoNJknfgoKVZSSjcfeYhez0lWWp Kks0tqmgL7CkmzRGgGWXHxm66/+Hs3XkzQtETTmbQFaaZRnByFfAJs6AtPHKDOf7wHU= X-Gm-Gg: AeBDiet2zmYEKhW2OwHBY29oyoBqQHALBBELvoCF2HGdqZm3F4cL1INzQpQe3gKs6L5 WdrIUj3P60bawDq+sVEpwbD456CCJH1UI2dSP4w5BMVV/lV8iQ0ER4rARiBb7glqGaRkm/A5LaK VoYRMAOS/nKvHDwOlCWTaRy/IP7eyPuJxjfEZTewYQ2eGUrMveAIuIjvFPJwIP/Xgmh2TWtuQEH bsTiMi/BK1+4OgUw+BO16NNIsvTtmlgChK0c8LFqJfz6+46aKMgfF3AE0km68ohkW2IzeLyuEKl i57kSHnMYhPMES3SN/r8eoxDFCNpCX8+qQ0qoke49ndayWiFATf0hlCFFSs0Sv7dmciL2RHMfuW eQwMt1Xtnk5wP2R/slhMKbWr7Fo7dMuMDqIAZ11ZHkqoLkS7o3xxMD+gwsvVdIqp8/ZoP+t6qaL Ie30X+d9JzJqNvRHeCNwoIPpJJhmeEKo/xPxe4n1RNHd94Q6+KfWvBljgBTQXydPVwFkRKRnll3 wy2eqM8rVURJOMt+wwflND4XBgDbpnc5ASOr5Wy X-Received: by 2002:a05:690c:12:b0:7bd:5c7d:4b15 with SMTP id 00721157ae682-7bdf5d651ecmr44465647b3.5.1778081145156; Wed, 06 May 2026 08:25:45 -0700 (PDT) Received: from google.com (57.233.150.34.bc.googleusercontent.com. [34.150.233.57]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7bd66885907sm80888937b3.43.2026.05.06.08.25.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 08:25:44 -0700 (PDT) Date: Wed, 6 May 2026 11:25:43 -0400 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, liaoyuanhong@vivo.com, rafael.j.wysocki@intel.com, piliu@redhat.com, kexec@lists.infradead.org, graf@amazon.com, mario.limonciello@amd.com Subject: Re: [PATCH v1 2/3] liveupdate: block outgoing session mutations during serialization Message-ID: References: <20260506043200.2025677-5-pasha.tatashin@soleen.com> <20260506043200.2025677-7-pasha.tatashin@soleen.com> <2vxzy0hwzzym.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=us-ascii Content-Disposition: inline In-Reply-To: <2vxzy0hwzzym.fsf@kernel.org> On 05-06 10:47, Pratyush Yadav wrote: > On Wed, May 06 2026, Pasha Tatashin wrote: > > > Introduce a 'rebooting' flag in the session header to ensure that once > > serialization has started, no new outgoing session mutations (creations > > or file preservations) can occur. > > Would it be a better idea to hold the session header lock and locks of > each session? This would prevent anyone else from getting access to any > of the sessions, and we don't have to worry about all the weird cases > when one might add a file to a serialized session or something similar. > > Once liveupdate_reboot() returns success, there is no going back anyway > so I don't think it matters much that some tasks will be left waiting. Overall, we can do that. The only possible issue I can think of is that we might get some stupid warnings if the shutdown takes too long: INFO: task ... blocked for more than ... seconds followed by a call trace. But that is unlikely, and it also means that userspace has been trying to mutate sessions when it should not have, so I think your approach is workable. Let me update the implementation. Pasha