From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 C47D525B0BF for ; Tue, 12 May 2026 20:13:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778616786; cv=none; b=C/80bxUv4BrsBtJ0YwiiR84hc/F/NW+z/d8Xg2ceb0VsupcVOubcPps2sivObtS8yiA88sw5qxnB9iZWCGWBxEYrGGgu9QrZdhjcS61b9K9RQjtoIpZdtgI4cIF+2LIGcJGYUUSK/6bJkPscj/fP77CXLJ3mzFY4Id3zY4Vn5I8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778616786; c=relaxed/simple; bh=VbuSSS++NYVPZ+f4EE021rODkOHPnmVtE4jyTtZ4G6E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZXk7cVv7pURstEtf3rLjBjaq7Ed9O38UozzSd1lVmpxsMaA6WPCqIeg49gb4VmbS068zRokRCJKUdbqPE6dvMkGpTkugIo160G9Y3YOaI1vWbUSKkLh1vuFGCf5pHFpLZFeqlYdyzYzZ/aqQkS7fPjyQ6IiotOSvd2QZHoSf73A= 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=UwH3NpjQ; arc=none smtp.client-ip=209.85.160.172 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="UwH3NpjQ" Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-50e5eb0fabaso57690391cf.0 for ; Tue, 12 May 2026 13:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1778616784; x=1779221584; 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=DIIRS0CpXrVK8EEE9qFLP9/pCIOhI1EfpJW18IQe0rY=; b=UwH3NpjQVY1Z4wgFbw+hbv/nlKseNSvKIRcvChDMzJMIB/M63tMoAeXUSA6bldrsLu u++b8NyElc1GLwKpew/c594ZEc+MVzHCPLW8nkTjJyTgoiTuZLaw5uRH9Utr0jEtEhSO EHOdeHChT/ZlDBtsEqgBb7uMghrMbwzycxVRgN6HzuqQOJGu2zyUBWym86UXD+2cT79S sWz/W9ZvpcvKt/tqpCrpqRtYK1CB8tvdEVqW0dtZqRJhHR3A8+RrR8AtbaNuiK6VTDP0 Kzm2Zhb3/nxinz6jyrqSwmgGmeNhRhRJ0/chHzeFZn3NNAnN5hwvTS7pIx2P9py4NtS9 LEqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778616784; x=1779221584; 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=DIIRS0CpXrVK8EEE9qFLP9/pCIOhI1EfpJW18IQe0rY=; b=jHcdYjKc+KudPK4o2PZl9K4nctO1S7ueSkNBhtf5SPv46IbYbJvcNoYh/OPzzAlUId 8nQxxnxH8RhqkuBmK9gs8dst5i3kq1GKw7/RvSq7i03tYbBLIm6OJp3tMAdAFsaW+K8f H1/+vA+hqvjBs3sOAO1kHmeZhG1arcMw3edMbDYPVlfKrPTmIQSAe+kn6EBqqLGfIKwk rpJZqZeWcqal6z1jK7Xt1n1QR2Ie1W/3ykLtD3irg7IacK5Po4bFnNDI9Bk6VbhE+STg FCZNP3oWyknR42ShGR50tAOvfiFOywDl4k1HrNpo+zh4/0Q77A0vkbS7TIVDCjlsZeb1 91zQ== X-Forwarded-Encrypted: i=1; AFNElJ8pZIsi0NCP1IaCIWOuUcruNfpBukLxejBVkPeD7kjVVZ1lTigUJ3lfjHHD5kofZbwMmpgAVwfAxmBnS6w=@vger.kernel.org X-Gm-Message-State: AOJu0YwUbsgV7Gyf3TfA7+2ODS3bBgmAXyGodtrQyvGHsN6BxsY3njJU BxSX1OH67tophGXO14EjmaRs6iT6arrldYT0UOW2TzaUPcAJ7IfPJ964Yf6jA2b47eM= X-Gm-Gg: Acq92OF/fktb0hm2w6WHrWDDi/OhWeHQH79qdy4gipd2EjH7rySns7DfC16+tc8UGrT z/KMO9cS5GADa+Xc2AGyAjOht0evWV7kcz04IHMiWJTvoeTbQHt1Q3SZhGpMSGSJEFD5qFuW8gR EQ7/331H9iYNxOvlUf3033C+H3ibkCY8hKV6XHOcU0JpUE9ywjf24wKvnUNwwXlQ2/BrpeZWE4E 6plFcbhanlUo66enUUbjEv3lGoYg9BmaejaZ1BX8K5gABHBnfw98ePWSwSzhYBaVIQXwlGjr8gU jZ6weEY0wDZhxtGJMWhMlN/B+F5Kvpm5o+dRA7IvHYZO7euw9fKQeNVg8Oi4v+QN81G14rj/Yk+ nSHr/En0BKQpii826XsMVNWARymG+L1uzZJ25crhSzB+hgdlwuWBoYxjYwWdPX6OejY9Ic4KuDw QJhqpYIA8r5XNaZaWj3gTN4TaUZLNVozTDhp3K74SGL97khKSjg6Y= X-Received: by 2002:a05:622a:92:b0:514:9ece:a15a with SMTP id d75a77b69052e-5162f5fedb6mr2218391cf.45.1778616783708; Tue, 12 May 2026 13:13:03 -0700 (PDT) Received: from plex ([71.181.43.54]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5148e675b9csm125582881cf.11.2026.05.12.13.13.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 13:13:03 -0700 (PDT) Date: Tue, 12 May 2026 20:13:02 +0000 From: Pasha Tatashin To: Pratyush Yadav Cc: Pasha Tatashin , linux-kselftest@vger.kernel.org, rppt@kernel.org, shuah@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, dmatlack@google.com, kexec@lists.infradead.org, skhawaja@google.com, graf@amazon.com Subject: Re: [PATCH 3/5] selftests/liveupdate: Test session and file limit removal Message-ID: References: <20260414200237.444170-1-pasha.tatashin@soleen.com> <20260414200237.444170-4-pasha.tatashin@soleen.com> <2vxzse7wafmo.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: <2vxzse7wafmo.fsf@kernel.org> On 05-12 16:04, Pratyush Yadav wrote: > On Tue, Apr 14 2026, Pasha Tatashin wrote: > > > With the removal of static limits on the number of sessions and files per > > session, the orchestrator now uses dynamic allocation. > > > > Add new test cases to verify that the system can handle a large number of > > sessions and files. These tests ensure that the dynamic block allocation > > and reuse logic for session metadata and outgoing files work correctly > > beyond the previous static limits. > > > > Signed-off-by: Pasha Tatashin > > --- > > .../testing/selftests/liveupdate/liveupdate.c | 99 +++++++++++++++++++ > > 1 file changed, 99 insertions(+) > > > > diff --git a/tools/testing/selftests/liveupdate/liveupdate.c b/tools/testing/selftests/liveupdate/liveupdate.c > > index 37c808fbe1e9..0eaf97b19267 100644 > > --- a/tools/testing/selftests/liveupdate/liveupdate.c > > +++ b/tools/testing/selftests/liveupdate/liveupdate.c > > @@ -22,6 +22,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #include > > @@ -386,4 +387,102 @@ TEST_F(liveupdate_device, prevent_double_preservation) > > ASSERT_EQ(close(session_fd2), 0); > > } > > > > +static void ensure_nofile_limit(struct __test_metadata *_metadata, > > + long min_limit) > > +{ > > + struct rlimit hl; > > + > > + if (getrlimit(RLIMIT_NOFILE, &hl) < 0) > > + ksft_exit_fail_msg("getrlimit failed: %s\n", strerror(errno)); > > + > > + if (hl.rlim_cur >= min_limit) > > + return; > > + > > + hl.rlim_cur = min_limit; > > + if (hl.rlim_cur > hl.rlim_max) > > + hl.rlim_max = hl.rlim_cur; > > + > > + if (setrlimit(RLIMIT_NOFILE, &hl) < 0) { > > + if (errno == EPERM) { > > + SKIP(return, "Insufficient privileges to set RLIMIT_NOFILE to %ld", > > + hl.rlim_cur); > > + } > > + ksft_exit_fail_msg("setrlimit to %ld failed: %s\n", > > + hl.rlim_cur, strerror(errno)); > > + } > > +} > > + > > +/* > > + * Test Case: Manage Many Sessions > > + * > > + * Verifies that a large number of sessions can be created and then > > + * destroyed during normal system operation. This specifically tests the > > + * dynamic block allocation and reuse logic for session metadata management > > + * without preserving any files. > > + */ > > +TEST_F(liveupdate_device, preserve_many_sessions) > > +{ > > +#define MANY_SESSIONS 2000 > > + int session_fds[MANY_SESSIONS]; > > + int i; > > + > > + self->fd1 = open(LIVEUPDATE_DEV, O_RDWR); > > + if (self->fd1 < 0 && errno == ENOENT) > > + SKIP(return, "%s does not exist", LIVEUPDATE_DEV); > > + ASSERT_GE(self->fd1, 0); > > + > > + ensure_nofile_limit(_metadata, MANY_SESSIONS + 10); > > + if (_metadata->exit_code == KSFT_SKIP) > > + return; > > Nit: This is strange. Why not just return errno in ensure_nofile_limit() > and handle the skipping here? Same below. > > LGTM otherwise. Good suggestion. Done.