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 7F9EFC47422 for ; Fri, 26 Jan 2024 16:55:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CEB36B0096; Fri, 26 Jan 2024 11:55:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 054926B0098; Fri, 26 Jan 2024 11:55:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DECE16B009A; Fri, 26 Jan 2024 11:55:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CA73C6B0096 for ; Fri, 26 Jan 2024 11:55:54 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5B0AD1A02E8 for ; Fri, 26 Jan 2024 16:55:53 +0000 (UTC) X-FDA: 81722064186.18.5B6A062 Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf24.hostedemail.com (Postfix) with ESMTP id 4E47F180012 for ; Fri, 26 Jan 2024 16:55:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="j/+9Jmo0"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706288151; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=w8rw/iPSfUXc8CrWwX/sJp+21BLZIVLO5m8R/6gbDJg=; b=b7LV7a/vYob1fDhtIpR1FSkUkRGjckOSySwvEZcdDp7biuMPzvIyH73Uvkm5oRik72fdgu XKxtkL9g8v42Ctr9Ut9Mfj+38X6YYSb9bLakfxwDxgDjZ+oEwia8DNO6sp+8vlJ55cwusY iEC5XGUMYtl0rlpcLC5Hqr0pUjbuszc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="j/+9Jmo0"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706288151; a=rsa-sha256; cv=none; b=p9xIlTRD5uJVlNYIGCcuz15FGSorbs4JSAf/mx6ddy/yhtG0FB1+ClEqBXdkL9N1T0BZmZ VJvrlIK2UCTnoQ4qfMXRGie6vYOZU2NbxxYDfo0hFYuePLLbqlfxrjuje9e/zDMQ9n/G8x N1Em+5rJnI6hMVNpT29kbmGm5YnW11Y= Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-5ff7ec8772dso10074437b3.0 for ; Fri, 26 Jan 2024 08:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706288150; x=1706892950; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=w8rw/iPSfUXc8CrWwX/sJp+21BLZIVLO5m8R/6gbDJg=; b=j/+9Jmo0htdKNmp+iLx5zdqGtt3az3vPU41BCHXP5973jcqE4wDeImzLcWVpM/67D/ ZGNprZ67NQAwak6ML43TwjeC2dcQJDAcHsPDD0EGg33DKl7TBr6k7texWwpasje8c2rR ikO5RqE9yXcuBXH3lXH/1OKLsgP91ROBmj2nvCZKdj8pY6C9p0n4SSzhut2nB+2S5sIQ gETyCQtJ7eNJlZ08AlSBVg4DKpT11oJyzxSJky3t+k4syrBa8qZaq3t0r9HWLu0nVbcW q3mCtD4Fr7LgrBEPqFFI+2dmEsS2wgfNcwAiWKIJphXpdSra4+p8n3bgGSqof07FOT2/ q/Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706288150; x=1706892950; h=content-transfer-encoding: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=w8rw/iPSfUXc8CrWwX/sJp+21BLZIVLO5m8R/6gbDJg=; b=QhSMLp/5JOSoEb9t1ZvpNsMult++93M5T9Z+e2bh9rPC2GkLfnfu96vgPQ67XBMuiY PJ92WZbXg4vIb2nOf44IYTpAHtQ11vmMLUIvk1zwKhuQPFK+P708PO6ponK9Ym98w1hp NaR5TfnFDiH8pOkK25W+9Vi3EKb6Bc2LbyrF4QyqJu8JshBaRXMohauV8cYald8qIX0b PaNQNZGzMZ6tTT0MKwrXe49uycoEI/Pu2LRisQR/pNBpBCVlwMXpvHIKEaWkssXWlUoL AZIWmaxslIlI3Y7Ghi8Leb9+IHflcCJwOiOz/obKWKHsSWNZgldBuxkWxloUe93Fyyho 9m+A== X-Gm-Message-State: AOJu0Yxx7mPgjGzJU5AraAn9xLt1Brl2rByuOdZ7Gq4aNziT45peoEPa c0gYi5I/ewYfNiQP2YQozEbm9o3mPOu+DXTwxmQAvgWv8WhkKefT9FWN4BJVuOuDKYavCmUWFjX aWZRu5/0hOsKY1EKY0BwHFyaGem4zLDxwcOMo4bM5b7K9CzNnTvNV X-Google-Smtp-Source: AGHT+IH0IU9vwcPtiNseWBkpyVDvUe92JB7thEvXdpSsJnzGY2i5ssIzAh+1r52QtqCIrlvs5bqB05jZvP4qOTLDrh0= X-Received: by 2002:a0d:db4b:0:b0:5ff:842a:cb77 with SMTP id d72-20020a0ddb4b000000b005ff842acb77mr71742ywe.90.1706288150026; Fri, 26 Jan 2024 08:55:50 -0800 (PST) MIME-Version: 1.0 References: <202401251829.0m6Eo4LI-lkp@intel.com> <68dc8592-6a5d-4cbe-bb8c-e0f4b5517684@paulmck-laptop> In-Reply-To: <68dc8592-6a5d-4cbe-bb8c-e0f4b5517684@paulmck-laptop> From: Suren Baghdasaryan Date: Fri, 26 Jan 2024 08:55:38 -0800 Message-ID: Subject: Re: [linux-next:master 1589/1892] fs/proc/task_mmu.c:143:45: sparse: sparse: incorrect type in argument 1 (different address spaces) To: paulmck@kernel.org Cc: kernel test robot , Matthew Wilcox , oe-kbuild-all@lists.linux.dev, Linux Memory Management List , Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4E47F180012 X-Stat-Signature: 3j76cmuww6rn8u9b484aby469g9eq6w3 X-HE-Tag: 1706288151-649144 X-HE-Meta: U2FsdGVkX1/z+5mGEERtEHFYQ058pJgL+cNa99u276fDN97hYN3tjVs9xzvc8tOxfsQvxfMPZCy6I10mvaud/kI8VQq+y5XWD/5kotqFmNeBXZ4PgAZQ9RS9cghg1WzDqabNv3QYMuP3WzUPsTSljtZYO5GnXQ4Iq0pNqZC/wYa/jTspKCz+cm3hhGeTmX4wt3d62X9IPmKbFSGlVJcpAGcqXqWWFZOdIYlmm6pWlpcHhgSa/c57KZd9YVHda5WEqF3wI/ofAzCYYupWvvlneRjVE00rUZF0SAH/ECZIesWXQgKHP5b8aNO/14W0ghdGkWhCFBnNkbfo1FUAmHvr0IGAZbYN9ldx4CNIOAzGrCcpf3KJ69xokQSyRS/wMHqF72Ono/jaqF4/ZwziK1cXaZxLn6/LgbvKlG9V0PZwuMtqDhP3oP9P+pmkLXQP7yv8BN1YBix5HJ8Yi9VLXV+oOu/XMHL9MBJIbZbMXLskcgsos/9iYArrWT0m2IsIvNob5UIfJD4Gg2c7PW0ymX6AM26JSLhesoaG1kl30wvZoosX/AuzYPqgKvv+ivurs4ycz5UtW1VBPwLNBGkyaJzz5PZQTQF03wBGjwIFzKFCZI1ClacSahQR2T6Iq24GyFlCVkfCkB0T3KJ81oOtRhxrVGDJQ4LNJUFt4O5A4/YlPcNj6d2+FuzpZUdloFkbMM/NKpaVG/+C8NLvuEA718LVytXhzXGGBKJ23gM1mbQqKBMwBPJ4jbnOi+GPI0PLiszP9hq9YXO7nsu16miQw5PlLwRQX05lGzIX0q/GLV3dFshVWzX1SXBZU1D8kSEmX6yOhwBnCANu1ZZ7W0BadaTHalRaNvKpuSgOfgPVKaAT2GDtZOwAPwdywOhD8yEpQkuY/u9tjpJ9p2/r3Wg1yWCje0F864z1Ry8cGEZVO9br+ey/xjP4KqhukrrRH2haOwyNfU8Jrvh4asf9op/JCHx 5NdUKSe3 ZE7CgVzs9GDyFQu9HJILjvauFhX9j9o+nrHF38kCtNhAOcwU8PJYVJAldQJdkTwvNWIx6MAGRL5Wh20XoAj9hP3RoJEF8RLqbbisPBBd3hY9E2CgSg/lboeVZDxzTbzQwjyme/J5kTbGeT8qAFqJO8mFleNwPIH+eIplQyBs2QDcFdmkL7Tr9jcdwmVhLGklvyXP4epqzf+SQvkCnBoHrL3RHtZvZtyeuUw8u+MCtB5suwbKtAJGlWcHVFkoXrX0HWO2b/9eWg/JURMtgaqPX+5eTsPkDAolCiobGFIB9WSzM1un9RBqD9YWXnCA6fCrWkVJ/gAYxTjnMLkTNFujULa06Ra/HPUTsE39MC7IsyauaOapm7VtI+5sOeiOKJFAftDH2E+uSXlJbCz8XZex8L39eSwPZrsq15DYIvZSCgR4sKf71dSLq/xRKTg== 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: On Fri, Jan 26, 2024 at 2:22=E2=80=AFAM Paul E. McKenney wrote: > > On Thu, Jan 25, 2024 at 06:24:05PM -0800, Suren Baghdasaryan wrote: > > On Thu, Jan 25, 2024 at 4:35=E2=80=AFPM Paul E. McKenney wrote: > > > > > > On Thu, Jan 25, 2024 at 03:17:17PM -0800, Suren Baghdasaryan wrote: > > > > On Thu, Jan 25, 2024 at 2:44=E2=80=AFPM Paul E. McKenney wrote: > > > > > > > > > > On Thu, Jan 25, 2024 at 01:27:34PM -0800, Suren Baghdasaryan wrot= e: > > > > > > On Thu, Jan 25, 2024 at 2:23=E2=80=AFAM kernel test robot wrote: > > > > > > > > > > > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/= linux-next.git master > > > > > > > head: 01af33cc9894b4489fb68fa35c40e9fe85df63dc > > > > > > > commit: 0c30c4cd953025979b7689e49844837f762303ec [1589/1892] = mm/maps: read proc/pid/maps under RCU > > > > > > > config: x86_64-randconfig-121-20240125 (https://download.01.o= rg/0day-ci/archive/20240125/202401251829.0m6Eo4LI-lkp@intel.com/config) > > > > > > > compiler: clang version 17.0.6 (https://github.com/llvm/llvm-= project 6009708b4367171ccdbf4b5905cb6a803753fe18) > > > > > > > reproduce (this is a W=3D1 build): (https://download.01.org/0= day-ci/archive/20240125/202401251829.0m6Eo4LI-lkp@intel.com/reproduce) > > > > > > > > > > > > > > If you fix the issue in a separate patch/commit (i.e. not jus= t a new version of > > > > > > > the same patch/commit), kindly add following tags > > > > > > > | Reported-by: kernel test robot > > > > > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202401251829.= 0m6Eo4LI-lkp@intel.com/ > > > > > > > > > > > > > > sparse warnings: (new ones prefixed by >>) > > > > > > > >> fs/proc/task_mmu.c:143:45: sparse: sparse: incorrect type = in argument 1 (different address spaces) @@ expected struct file [noder= ef] __rcu **f @@ got struct file ** @@ > > > > > > > > > > > > Uh, this is a problem. > > > > > > I missed that get_file_rcu() is used only with mm->exe_file and > > > > > > vma->vm_file is not really RCU-safe. It's freed via a call to f= put() > > > > > > which schedules its freeing using schedule_delayed_work(..., 1)= but I > > > > > > don't think that constitutes RCU grace period. Paul, Matthew, c= ould > > > > > > you please confirm? In the meantime I'm going to ask Andrew to = remove > > > > > > my patchset from mm-unstable to be safe. > > > > > > > > > > Sadly, no, schedule_delayed_work() does not imply an RCU grace pe= riod. > > > > > > > > > > There is a queue_rcu_work() that schedules work after a grace per= iod, > > > > > which could be combined with a timer to get the delay. > > > > > > > > > > Another approach would be to use get_state_synchronize_rcu() befo= re > > > > > the schedule_delayed_work() in fput(), then do cond_synchronize_r= cu() > > > > > in delayed_fput(). This would require adding an unsigned long to > > > > > struct file to keep track of which grace period a given struct fi= le > > > > > needed to wait for. > > > > > > > > > > Perhaps something like this: > > > > > > > > > > -----------------------------------------------------------------= ------- > > > > > > > > > > void fput(struct file *file) > > > > > { > > > > > if (atomic_long_dec_and_test(&file->f_count)) { > > > > > struct task_struct *task =3D current; > > > > > > > > > > if (likely(!in_interrupt() && !(task->flags & PF_= KTHREAD))) { > > > > > init_task_work(&file->f_rcuhead, ____fput= ); > > > > > if (!task_work_add(task, &file->f_rcuhead= , TWA_RESUME)) > > > > > return; > > > > > /* > > > > > * After this task has run exit_task_work= (), > > > > > * task_work_add() will fail. Fall throu= gh to delayed > > > > > * fput to avoid leaking *file. > > > > > */ > > > > > } > > > > > > > > > > file->f_rcu_seq =3D get_state_synchronize_rcu(); > > > > > if (llist_add(&file->f_llist, &delayed_fput_list)= ) > > > > > schedule_delayed_work(&delayed_fput_work,= 1); > > > > > } > > > > > } > > > > > > > > > > -----------------------------------------------------------------= ------- > > > > > > > > > > And this: > > > > > > > > > > -----------------------------------------------------------------= ------- > > > > > > > > > > static void delayed_fput(struct work_struct *unused) > > > > > { > > > > > struct llist_node *node =3D llist_del_all(&delayed_fput_l= ist); > > > > > struct file *f, *t; > > > > > > > > > > llist_for_each_entry_safe(f, t, node, f_llist) { > > > > > cond_synchronize_rcu(f->f_rcu_seq); > > > > > __fput(f); > > > > > } > > > > > } > > > > > > > > > > -----------------------------------------------------------------= ------- > > > > > > > > > > Note that if you called fput() on a long sequence of struct file > > > > > structures, the cond_synchronize_rcu() would be a near-noop almos= t all the > > > > > time, actually blocking at most about every once per every few ji= ffies. > > > > > After all, once a grace period has been waited for, it covers all= of > > > > > the struct file structures that were passed to fput() during a gi= ven > > > > > RCU grace period. > > > > > > > > > > Still, it would add the occasional delay. And it would increase = the > > > > > size of struct file, though there are workarounds for that, if si= ze > > > > > is an issue. > > > > > > > > > > Thoughts? > > > > > > > > Thanks for the suggestion, Paul. I'm worried about this occasional > > > > delay but otherwise this seems like a nice and simple approach. > > > > > > One potential saving grace is that the more heavily loaded the mechan= ism, > > > the smaller a fraction of the cond_synchronize_rcu() calls will do > > > a delay. > > > > > > > Do = you > > > > guys think that making *all* files RCU-safe with this approach is > > > > warranted? For my particular case I need only vma->vm_file to be > > > > RCU-safe but maybe there are other cases which would benefit from > > > > this? > > > > > > To this, I can only give an unqualified "I don't know". :-( > > > > > > But if there is some condition that can be sampled on a per-file-stru= cture > > > basis, you could use that to invoke cond_synchronize_rcu() only when > > > needed. Or send only those file structures that need the extra delay > > > through queue_rcu_work(), perhaps by accumulating a list of them. > > > > Thanks Paul! You gave me enough food for thought. Let me see if I can > > come up with something usable. > > Do we have the same problem with the task_work_add() path in fput()? Yes, I think so. It's called with TWA_RESUME, so the file will be freed when the task returns to user mode, but that again does not guarantee that RCU grace period is over. > > Thanx, Paul > > > Cheers, > > Suren. > > > > > > > > Thanx, Paul > > > > > > > > > > fs/proc/task_mmu.c:143:45: sparse: expected struct fil= e [noderef] __rcu **f > > > > > > > fs/proc/task_mmu.c:143:45: sparse: got struct file ** > > > > > > > fs/proc/task_mmu.c: note: in included file (through includ= e/linux/rbtree.h, include/linux/mm_types.h, include/linux/mmzone.h, ...): > > > > > > > include/linux/rcupdate.h:781:9: sparse: sparse: context im= balance in 'get_vma_snapshot' - unexpected unlock > > > > > > > fs/proc/task_mmu.c:264:22: sparse: sparse: context imbalan= ce in 'm_start' - different lock contexts for basic block > > > > > > > include/linux/rcupdate.h:781:9: sparse: sparse: context im= balance in 'm_stop' - unexpected unlock > > > > > > > include/linux/rcupdate.h:781:9: sparse: sparse: context im= balance in 'smaps_pte_range' - unexpected unlock > > > > > > > include/linux/rcupdate.h:781:9: sparse: sparse: context im= balance in 'clear_refs_pte_range' - unexpected unlock > > > > > > > include/linux/rcupdate.h:781:9: sparse: sparse: context im= balance in 'pagemap_pmd_range' - unexpected unlock > > > > > > > include/linux/rcupdate.h:781:9: sparse: sparse: context im= balance in 'pagemap_scan_pmd_entry' - unexpected unlock > > > > > > > fs/proc/task_mmu.c: note: in included file (through arch/x= 86/include/asm/uaccess.h, include/linux/uaccess.h, include/linux/sched/task= .h, ...): > > > > > > > arch/x86/include/asm/uaccess_64.h:88:24: sparse: sparse: c= ast removes address space '__user' of expression > > > > > > > arch/x86/include/asm/uaccess_64.h:88:24: sparse: sparse: c= ast removes address space '__user' of expression > > > > > > > > > > > > > > vim +143 fs/proc/task_mmu.c > > > > > > > > > > > > > > 132 > > > > > > > 133 /* > > > > > > > 134 * Take VMA snapshot and pin vm_file and anon_name as= they are used by > > > > > > > 135 * show_map_vma. > > > > > > > 136 */ > > > > > > > 137 static int get_vma_snapshot(struct proc_maps_private = *priv, struct vm_area_struct *vma) > > > > > > > 138 { > > > > > > > 139 struct vm_area_struct *copy =3D &priv->vma_co= py; > > > > > > > 140 int ret =3D -EAGAIN; > > > > > > > 141 > > > > > > > 142 memcpy(copy, vma, sizeof(*vma)); > > > > > > > > 143 if (copy->vm_file && !get_file_rcu(©->vm_= file)) > > > > > > > 144 goto out; > > > > > > > 145 > > > > > > > 146 if (!anon_vma_name_get_if_valid(copy)) > > > > > > > 147 goto put_file; > > > > > > > 148 > > > > > > > 149 if (priv->mm_wr_seq =3D=3D mmap_write_seq_rea= d(priv->mm)) > > > > > > > 150 return 0; > > > > > > > 151 > > > > > > > 152 /* Address space got modified, vma might be s= tale. Wait and retry. */ > > > > > > > 153 rcu_read_unlock(); > > > > > > > 154 ret =3D mmap_read_lock_killable(priv->mm); > > > > > > > 155 mmap_write_seq_record(priv->mm, &priv->mm_wr_= seq); > > > > > > > 156 mmap_read_unlock(priv->mm); > > > > > > > 157 rcu_read_lock(); > > > > > > > 158 > > > > > > > 159 if (!ret) > > > > > > > 160 ret =3D -EAGAIN; /* no other errors, = ok to retry */ > > > > > > > 161 > > > > > > > 162 anon_vma_name_put_if_valid(copy); > > > > > > > 163 put_file: > > > > > > > 164 if (copy->vm_file) > > > > > > > 165 fput(copy->vm_file); > > > > > > > 166 out: > > > > > > > 167 return ret; > > > > > > > 168 } > > > > > > > 169 > > > > > > > > > > > > > > -- > > > > > > > 0-DAY CI Kernel Test Service > > > > > > > https://github.com/intel/lkp-tests/wiki