From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 D4B3732C937 for ; Tue, 24 Mar 2026 21:15:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774386943; cv=none; b=nQ6vWo6uEupa/kk3qRSR/AR0AAUlogusuUPSbD5Szal27DtAn9kXPP3aqFSQ0qeO5lKktV6uIxaLQhRjeOYsfRqsD4lQ1nCzmwOur94lXviV3w8v04iQoZ71DzvWqIvQjfj27ZFVBFhQif0lrMauo7buKw6JyEJYdyaXKZZT3lA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774386943; c=relaxed/simple; bh=Xkz6r9H06X0qgaEAss9nJxzuijUCCMeksGW7uXzVq6o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a3pwiInUlhMNOnBx6FpHjtOSRjignssz6AYyGsrAA446RLN9lwfliMG/SkqgZFDFfCbEUdONsrUXjpJsfwJWNEUJF/TZYgGGMf2TGRp2vV/1dnLAmIldqpR4TYE1hH02oh4I3tBMaAHbPYBrbgixzLnZEMYRN3Rwjg/IjuS/JhY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dTWtlpKm; arc=none smtp.client-ip=209.85.216.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dTWtlpKm" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-35a1230c60eso2123469a91.3 for ; Tue, 24 Mar 2026 14:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774386941; x=1774991741; 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=MLDhxrVQ3JPNzGwHxdK1b/M6GFU5OnGRZQ4Lon9SeW4=; b=dTWtlpKm3ZTT8d8Mv3VvMQZrGuCcsD63oSkNh8VHyXM2X3Z3eZvIWdgfABijrJNs+X 6vH1Z8Rl0KR81w8clc0yGpBY3aWHn1Y6hYn36vLeYRfnPZz0B4VSE8KqOjhnfM1rwmdJ fxrHO4tN5riZA3Ojmw/C7Bz4lgHl7v2ZT2egOrvHz46afIIXQwkDtTpa0hNCRraw/j+s 6cHXvNiUfTx4gXgO4+9WOo/o53tb8fge3DkqREh1MwbHtUa9rSWHUBHlvISbRsUYGHHj WpqpOhMPI+cdFhihRG2sI43BLYDjNl2dAmC4kJtR69uDVrspy7an29uNjnjlJ3QBhMyO wGLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774386941; x=1774991741; 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=MLDhxrVQ3JPNzGwHxdK1b/M6GFU5OnGRZQ4Lon9SeW4=; b=q+mCVOIRe+IOrS2vlxPt1EdLiV7Los1R6x7iSrw9I1wp6B0ZyNK3jt1257iralQYbq E9mzXtodniCUGGWRQcaVdf2FPG5yeOqtQRVcHeC58pLE2H9pFPe9m4q3CkWzfWePoLHb ies7khfxpzUQ3gO++YNCUvjMiPkPehLQVbETt6sxXzS/FSn8hDggwIU3w+FsHpePWEb1 xnJpovr2jyyzd7egABUld15jeb4QDRP/lHqd/+adsoZF7kZV7Xv4r5w6oDV5YZ43cIWv lTP8MwxTa6Tqjln+ugFxaAP6V9R/1W5i7bj8HX+dsWS0844hvM62oJ4ugyOb012g9VIY wYcg== X-Forwarded-Encrypted: i=1; AJvYcCWn+gYejx59txkB74EXaUhX6b7uZ3j9BKQjPUBqrHh42DKoeQgq5vXwGp7Gkr0MKZeiT5mg8UsMzpViLvU=@vger.kernel.org X-Gm-Message-State: AOJu0YyHHEWGJkT1yZOULHqx5VDJTbFrZagwZolSZWEgHDS82/Q5Ls/E Z+7MXYQyYXZ6hMSnJwLushZ7I976krIeUxC+/V5VQiEa4JnloqHvBNmTUsl9JpvQPPbKGySfjA9 5XTk6k6q4 X-Gm-Gg: ATEYQzxHdfkHyBk7JxzCRL/MvZxEMBWwEx0Qf0NO0b3kg/tDwXqXouXKjyQRQZzzy/z JXn6pNVVhDrATdD6eSLyEAuOZQbXQSjaw/ATAB/2MZsv41rG8jnGjPExeHY+NzZRqwLuqOZj30P cObHmzPQu8ScLyymhsEj+UBxWefxowYp+n6XvM1YXdDMfV9m1seazplCI8gLFYBKmJ9R0LZBH64 0TCdRmQNpO2KJfD1P7XBhuXPDVIGbKHrAqmoeMv/7FpdNRGaID/lWQ8C4E6FFAAjRwIeQmfAQ5K VHwzTU83UJmga1FRbQa0nS8i9pHShcKzhDW69/dhZVCqmbycEyPoJ5Ytiu0WHKwKdtyGu1CFWn6 Lr5ONQmRYHr5hFosJjSbZScgKW5Nz/Es5I7ohqsIU8Zh1zdcBhqpD4gC+l5A4x6+1YLvHDsJkc7 ZlL/aKcev9p6U89IJzAYYPbOgNiX57UIBsN5stREtOb7cvBL95MQ9wnRtVDuD7ZsYazcOH0uvY X-Received: by 2002:a17:90b:1647:b0:35b:9958:4edd with SMTP id 98e67ed59e1d1-35c0ddb0222mr711393a91.30.1774386940708; Tue, 24 Mar 2026 14:15:40 -0700 (PDT) Received: from google.com (239.23.105.34.bc.googleusercontent.com. [34.105.23.239]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35c0312f1a5sm3248479a91.3.2026.03.24.14.15.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2026 14:15:39 -0700 (PDT) Date: Tue, 24 Mar 2026 21:15:35 +0000 From: David Matlack To: Pasha Tatashin Cc: rppt@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, pratyush@kernel.org Subject: Re: [PATCH v2 3/8] liveupdate: Remove file handler module refcounting Message-ID: References: <20260318141637.1870220-10-pasha.tatashin@soleen.com> <20260318141637.1870220-13-pasha.tatashin@soleen.com> 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: <20260318141637.1870220-13-pasha.tatashin@soleen.com> On 2026-03-18 10:16 AM, Pasha Tatashin wrote: > File handlers do not need to pin modules indefinitely or during active > live update sessions. The VFS 'struct file' pins the file handler's module > via f_op->owner during active sessions, making dynamic reference counting > unnecessary for handlers. > > When a file is preserved, the live update core obtains a 'struct file' > via fdget(). As long as the file is kept open within the live update > session, the module is pinned by the VFS and cannot be unloaded. > > Similarly, during deserialization, file handlers are matched based on > the compatible string. Because the handler list is protected by > luo_file_handler_lock, there is no race that requires dynamic > module refcounting. Sashiko found a potential bug here when reviewing my VFIO patch series: . If luo_file_deserialize() reconstructs preserved file structures and . assigns the handler to luo_file->fh without calling try_module_get() . to lock the module in memory, could the module be unloaded before the . file descriptor is actually retrieved? . . This would cause liveupdate_unregister_file_handler() to run on module exit. . If userspace subsequently calls luo_retrieve_file(), could it result . in a use-after-free by dereferencing the dangling luo_file->fh->ops pointer? https://sashiko.dev/#/patchset/20260323235817.1960573-1-dmatlack%40google.com?patch=7973 I think LUO would need to take a module reference in luo_file_deserialize() and drop it once the file is retrieved. At that point LUO can rely on the file's reference to the module to keep it from being unloaded while LUO still has references to it.