From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5EE3C71135 for ; Sun, 15 Jun 2025 18:03:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04DEA6B0088; Sun, 15 Jun 2025 14:03:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F420A6B0089; Sun, 15 Jun 2025 14:03:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E09176B008A; Sun, 15 Jun 2025 14:03:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id CDF556B0088 for ; Sun, 15 Jun 2025 14:03:08 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7AB8881807 for ; Sun, 15 Jun 2025 18:03:08 +0000 (UTC) X-FDA: 83558406456.09.A6D56CE Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf11.hostedemail.com (Postfix) with ESMTP id 88E4D4000A for ; Sun, 15 Jun 2025 18:03:06 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=YokEdtW0; spf=pass (imf11.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750010586; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JNaz1yRvnr0ZspYURl3ABko1+K9vEcbTR/IU/BQQjQA=; b=aWIXX1W0CiQ8aXaehsgbTUxPToupzeenOez/WDr8dZxL64Qk0UVaTxs1SUe+uMEcCdoX+C cQGS7CrFzJ8txV42ZRGBWf/YU7yWw23FXihPkYrKWOOxIm1Tnom9MSWRrUcuC4GyxHbpJ9 eWiafaKmaJltA3EgQlY9SNDyeBMdkew= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=YokEdtW0; spf=pass (imf11.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750010586; a=rsa-sha256; cv=none; b=Ug4qokQl+knBhBYV4kK2P7GxmkjzavjG0P8KiANrOTYVrviS5J+eHKk2FMqG+QMC5h2mFv Ox6459Z5oaIUYLWhRLC64NNBxi0e+YTfMqAhBO4ikfVnfNIc/7p0Z+PVJJoEKJJn9/Wq8b PyVwS4+D/uRJjaD/kB3g9ca8i4QDzEU= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-4a4323fe8caso26636031cf.2 for ; Sun, 15 Jun 2025 11:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1750010585; x=1750615385; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JNaz1yRvnr0ZspYURl3ABko1+K9vEcbTR/IU/BQQjQA=; b=YokEdtW09bqIPoSABRXWGYeeOp4ySgKIi7fKizPw8kv2FdQGNgRolkeSoYos2cuo5s O4gU60ja69qM4K31d8b6hLjsdhmI2ca3K/xKGnn+Jfm1a8lVBVN7mNsrlZ2Ono8poENB A+MOyG97SKsu4dMmCEQlF2Y2T4GhelZtnUNL4LD2llMuBchwvMOKsCTipAJhEDi8j7zp JOxFz8UK/P5mV3rFDQ0UxC6Ki/IPUpheEE6KUuqSdHueqQk83/FczL9ZTCbZD4stHlDq mufGihTzD629/oSgNDl3bx1ekiBNYXstheKwXOs8u/c5pBWD03f832gjRBZ4MkC8cIGD TF7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750010585; x=1750615385; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JNaz1yRvnr0ZspYURl3ABko1+K9vEcbTR/IU/BQQjQA=; b=FOcFtQx13oTuF5iE/5xS8UyHHnlZiA6RZ9CDOWwhcMqhprSsrLO9kJXZQzWzEExN6Z TXxIbhGwafk+UHVp2SEr1w/T0/AUmVvdwGB+iyTD+J2A2A0jlsxDHQgbsLV827BZkU0o YBBEOLqqFjh4jUMGI9xrx7EGqbHCclpmxrxxlHXwpZ5vHuxhgHzzjX5tI3A7OKww0lFK +pokAOIifgNCaIVLeGTTAvGsPQDCEOzb/ZdKs65owzS0BFr2kHQ4jIBb4rN/ddPDJvYM gy++aq4oghCupNeSkfEhVu91sHX+nb/QnXQKhApjb9wC5lFlg1OPcLAMEZyv8wmnJaCH ekaA== X-Forwarded-Encrypted: i=1; AJvYcCUJnXJbKv8VpUIQkmQFi6aM+86eqo5M3TqZhurYFhqLbXhS67akFzZA7RckHtqGGcZa7rJMVbwhqw==@kvack.org X-Gm-Message-State: AOJu0Yw9qqEOhI8xCR4rRhhsFD34wAMxzqiEx0XAamW7juR0y5Q7KR1O EmSe1W52SwdT2ZRUNNqgqfXa4P0dtJf1Qieoq0TNbn99E+Hu7oFVaHq1gLf0ud+2OSlL4wK6nsw A6147bia5PKDgH1CNL9t0KXtPZf3ZDDEGFQMSKgSTpA== X-Gm-Gg: ASbGncuq/e6pPauoW7TdXVQK3WcZCdqABrDKczktepNlryCrfeyQ415CsMCGj4+xYGO yNAZ8LKxOH3OQe3xYKYdvDO5N6vhf7HhaUUZyBmH5F7zISNAfy5z4q/7Y2sN4aLOWkMwZPINYEe ML57qJeL/YPwfK0EEdP4HE3YKWdpWmlv5iXXlJOfhHSt0skO7XUpjNwCj0mY1mMhAjVj604u0tv w== X-Google-Smtp-Source: AGHT+IGGB8+eyL7WTYKqK3xwwDge70EilhWl/70ilTnxzvcGeeGrU4NeKpQh0oWeO/GG4vP2HfwKft+K2iVnAPOKiQI= X-Received: by 2002:ac8:5f0e:0:b0:4a5:912a:7c64 with SMTP id d75a77b69052e-4a73c58f3e9mr111987711cf.30.1750010585395; Sun, 15 Jun 2025 11:03:05 -0700 (PDT) MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-9-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Sun, 15 Jun 2025 14:02:28 -0400 X-Gm-Features: AX0GCFvmDSOv1q3E2SkUC9O11e4zxS3sZ68LrZGy8fBYesVRbqKv1FEcUE3nQ14 Message-ID: Subject: Re: [RFC v2 08/16] luo: luo_files: add infrastructure for FDs To: Pratyush Yadav Cc: jasonmiu@google.com, graf@amazon.com, changyuanl@google.com, rppt@kernel.org, dmatlack@google.com, rientjes@google.com, corbet@lwn.net, rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com, kanie@linux.alibaba.com, ojeda@kernel.org, aliceryhl@google.com, masahiroy@kernel.org, akpm@linux-foundation.org, tj@kernel.org, yoann.congal@smile.fr, mmaurer@google.com, roman.gushchin@linux.dev, chenridong@huawei.com, axboe@kernel.dk, mark.rutland@arm.com, jannh@google.com, vincent.guittot@linaro.org, hannes@cmpxchg.org, dan.j.williams@intel.com, david@redhat.com, joel.granados@kernel.org, rostedt@goodmis.org, anna.schumaker@oracle.com, song@kernel.org, zhangguopeng@kylinos.cn, linux@weissschuh.net, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, rafael@kernel.org, dakr@kernel.org, bartosz.golaszewski@linaro.org, cw00.choi@samsung.com, myungjoo.ham@samsung.com, yesanishhere@gmail.com, Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com, aleksander.lobakin@intel.com, ira.weiny@intel.com, andriy.shevchenko@linux.intel.com, leon@kernel.org, lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org, djeffery@redhat.com, stuart.w.hayes@gmail.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 88E4D4000A X-Stat-Signature: qsp8one88rs7f3buufwyah5k5a8gyut3 X-Rspam-User: X-HE-Tag: 1750010586-284950 X-HE-Meta: U2FsdGVkX1/8deLhfFABaBB9GCKnMn8S4k4PCtKWp9cfBq2iONXY2n1EY6R8CDNhvIgM1n0aUsvz2lgQtR1n4QkN4ldf7Af0Rw43VrCE6LoLvzwGvT4hLCpkOhuccDwsRKgLudYkz5uWo6xnZrKJmw4Q4nU4OQoNkhyllE0baa7m3fsSDWzc/4vKtmsHrdyHUJla5E8uKV44ePm4gZYqKdx5g24qFLkiEoarPeIrgwAQ/o3KRG1/VI2RaShEGECByrihMZg0zGM7TKUKyXQARv6tCqAg1grfkhGNnBP3LNFfUty6tn+XrEFMakzgLkTumWg1X67fpZbfIanO/ElHWRgfVIEheFIg72ddaEK05g1vMMlPm9iShWTexAT/ExzFCWfbo8o6jmzQphi5Dx2TtSQK0paWBmvtkVZ2CQgWCS1sQ3MkrzClRh4fpUu28L5i/I8zwq0R/0obhWE24Uv+r0WgPhD0Na38fw5oNrKh3wEGz6YckEn9Qa+1KROqWoOWTQTJ62nVnOb5g2wepVjn7yFBAGSbnSHB7FOCPm8J+XHUGJ2Il3oLQGdtt70LOwoopDcYVw9nUg3V963kPi456iMpFaazfihSpd8h+fnuy1hNIcK/Q/F9it9xDVA5g5dHkZlNU7Vn88n4ODAh6Vm9gpG4SSmxt/vRYLeG+cC0Q5NIV76EQisIgBV+b16Yuj5uz6MVG6WN1iRIxSymo5p6mk5JY5gZkQW0SLseXWaqZYCQYXh1gc9Abm5H27yEmzw4HuHLuunyltzFQcwbG2Pu6rs+boNMafJeAO+DNGsin2Oxv7Ae3xsLwMlHS/ifq2ZS0yGCSzY2jmXUsxvwZ463xjHX2FTZS1QHoNAuBTtQd5e0DbcVQD58BcyeDTXXs8AVqcH9nFDAOf1B7OaYo4nGlfkt45Jt1czttffaSKCLp15DbLTICwcJxz9fYO7AC0ncsQ0WM/yaoQbFxvR8Zzb 3ACL4pcC YPkExDNhC1uM9juHgZV06//QiD+lYjIDRkA1h+wA0VXtWmYKZANXBMCtKR5n43zUnflcShRMl19mjo4XFX2B+gf7D/GHmHg9RduDdZuzkkMc4RpUGDNHbxQykZt8UPqzZQ0xrRlbbXJeaG0eFUuhZV9gPpGub2+WDox8rUxiMm5gkDsf/eIUqdPjHDOrpIN8M7b+R4lSeerMPWCtcWkWi3dwknbNbR/plTLOK4ARrJeuY2JpraWpKab9RTTQ5b2jOqscjq/ssdb3PGwi235J77s+uHnLvdjGsTVJgwqAa0gXfHeFsYdSZOyVNQRlNEs3clot9dWVbEm4M7PSMWC2nzruh7r8cNeOX1haVJU03a7vjAQnAq9hBE0j+Yg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > This is not safe, the memory might be DMA or owned by a sensetive > > process, and if we proceed liveupdate reboot without properly handling > > memory, we can get corruptions, and memory leaks. Therefore, during > > liveupdate boot if there are exceptions, we should panic. > > I don't get how it would result in memory leaks or corruptions, since > KHO would have marked that memory as preserved, and the new kernel won't > touch it until someone restores it. > > So it can at most lead to loss of data, and in that case, userspace can > very well decide if it can live with that loss or not. > > Or are you assuming here that even data in KHO is broken? In that case, > it would probably be a good idea to panic early. A broken LUO format is a catastrophic failure. It's unclear at this point in boot whether the problem lies with KHO, LUO itself, or mismatched interface assumptions between kernel versions. Regardless, falling back to a cold reboot is the safest course of action, rather than attempting to boot into a potentially broken environment. Since VMs or any preserved userspace won't survive, the additional delay of a full reboot should not significantly worsen the impact. > > [...] > >> > + } > >> > + > >> > + luo_file = kmalloc(sizeof(*luo_file), > >> > + GFP_KERNEL | __GFP_NOFAIL); > >> > + luo_file->fs = fs; > >> > + luo_file->file = NULL; > >> > + memcpy(&luo_file->private_data, data_ptr, sizeof(u64)); > >> > >> Why not make sure data_ptr is exactly sizeof(u64) when we parse it, and > >> then simply do luo_file->private_data = (u64)*data_ptr ? > > > > Because FDT alignment is 4 bytes, we can't simply assign it. > > Hmm, good catch. Didn't think of that. > > > > >> Because if the previous kernel wrote more than a u64 in data, then > >> something is broken and we should catch that error anyway. > >> > >> > + luo_file->reclaimed = false; > >> > + mutex_init(&luo_file->mutex); > >> > + luo_file->state = LIVEUPDATE_STATE_UPDATED; > >> > + ret = xa_err(xa_store(&luo_files_xa_in, token, luo_file, > >> > + GFP_KERNEL | __GFP_NOFAIL)); > >> > [...] > >> > +struct liveupdate_filesystem { > >> > + int (*prepare)(struct file *file, void *arg, u64 *data); > >> > + int (*freeze)(struct file *file, void *arg, u64 *data); > >> > + void (*cancel)(struct file *file, void *arg, u64 data); > >> > + void (*finish)(struct file *file, void *arg, u64 data, bool reclaimed); > >> > + int (*retrieve)(void *arg, u64 data, struct file **file); > >> > + bool (*can_preserve)(struct file *file, void *arg); > >> > + const char *compatible; > >> > + void *arg; > >> > >> What is the use for this arg? I would expect one file type/system to > >> register one set of handlers. So they can keep their arg in a global in > >> their code. I don't see why a per-filesystem arg is needed. > > > > I think, arg is useful in case we support a subsystem is registered > > multiple times with some differences: i.e. based on mount point, or > > file types handling. Let's keep it for now, but if needed, we can > > remove that in future revisions. > > > >> What I do think is needed is a per-file arg. Each callback gets 'data', > >> which is the serialized data, but there is no place to store runtime > >> state, like some flags or serialization metadata. Sure, you could make > >> place for it somewhere in the inode, but I think it would be a lot > >> cleaner to be able to store it in struct luo_file. > >> > >> So perhaps rename private_data in struct luo_file to say > >> serialized_data, and have a field called "private" that filesystems can > >> use for their runtime state? > > > > I am not against this, but let's make this change when it is actually > > needed by a registered filesystem. > > Okay, fair enough. > > -- > Regards, > Pratyush Yadav