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 6FF1BC47258 for ; Thu, 25 Jan 2024 23:17:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C89B28D0003; Thu, 25 Jan 2024 18:17:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C12C18D0001; Thu, 25 Jan 2024 18:17:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A90608D0003; Thu, 25 Jan 2024 18:17:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8F6868D0001 for ; Thu, 25 Jan 2024 18:17:34 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 47F1EC0EAB for ; Thu, 25 Jan 2024 23:17:34 +0000 (UTC) X-FDA: 81719397228.13.91946CC Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf15.hostedemail.com (Postfix) with ESMTP id 5FE55A0005 for ; Thu, 25 Jan 2024 23:17:31 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2Odvz4kv; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706224651; a=rsa-sha256; cv=none; b=hFIeZyUKn04Pqr0BoGJQ82NVxjzi4w+lOX7UHoXWiDB4bZMQzDK1y39EIgViqLFi5L8O6M IlXcVGnFIhpIw8GFwPLV12kAwbqFL8Wrmv191AEIaNjTWOkpIuOaaGIlYSMNYFnznYXBmZ 1Kl/76jGzooL3HMG7nLSsrxAJa3XzI0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2Odvz4kv; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706224651; 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=HfnVGOohXDcV+59QsJtkNm9xelbrtdNZwr+64tiF+f8=; b=WJMP1ffJuzZluGvmWf+yUm+PuHaDHIuzkOyIGYxjcylfeFxcfYQvrKYNUuHxu53yUAJ5wR YNyvxqY1YMlUR2pHyykiUFzRGHMJjQHECUk0E/x8EVZN07XqpgqFlFcN9S2btzOI44ucSI dU1vJFdz+5Bv+5sMnXAe3Jm6+90WISE= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-5f2d4aaa2fdso75464337b3.1 for ; Thu, 25 Jan 2024 15:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706224650; x=1706829450; 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=HfnVGOohXDcV+59QsJtkNm9xelbrtdNZwr+64tiF+f8=; b=2Odvz4kvF4bI/KJtcfg5jo1gfwa/CEntnflGu8oGjDNUxKMlIbyXhhLWbq2lpKqpiD 5L6QD52QYbtql6HQYdGnkDJ+ge2977bmSOW0QzeglRqbYFuoo8AiTxc66amsvz/rXzi0 yA0LoG0g/nI3q1KM2bTeLVMWbHPn4w9grc1vv0brZLitnjTTbs1aICxRK2+mWl6c3q7+ zAqitNI6VJiJ0QkSbgUO5tsE764svzJ2cSlMpdxRjPaLykNan5suC7JyLY1W3ZbrX6JK DJqAmfq069jXD4frRqITMb7K0pipFenamS9XtI7l770vRsLAzm6te3yqRxfrLKYiO7b5 ygkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706224650; x=1706829450; 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=HfnVGOohXDcV+59QsJtkNm9xelbrtdNZwr+64tiF+f8=; b=VoNYCy9kcV9zUMSM4SIqKslc/XWlgNUV9DZuHw/bpzDnnQbk2qW7Jbjfu8nXSwbfhK Rj+dbXP0+0QHMCA1rb0pObDxPVlVB0va7uMWcSWfyb2qCsber7TwvzjtlvWkg7LmgYim vRSPKTciHsCVDNVDA4h5R5wtDrCMOw72gQTexWJeck88fNb3rKHF1xes7wSe6L4BEkVU V7HujHl0si/Qgmp+7JkppftiBBbY783CwVOta99cl/2wVd/ylWJcJzv7qZiT/XbeNXME yaqOL8H1oskw9d9oIU8w1Ty9VjTS9QgUnV5znguWk9s6tSWImbUYGGgebaoC9ukw7Tre onHg== X-Gm-Message-State: AOJu0YxFJvJX0gxC5lzClnvVbjDwykeSorept5RMfOMPjJKbjcn8M0dw IKHXDhjWiAZ1Q/XCz5RphcNFNCXb4zrJ9zNV/4yAnpxMCmzJvJcT1PT2rID4jmte1Ty9AIpUhmv 7oQ75hyiRRhA3xJ3NWUPlkvBSKXT//YeF4xkR X-Google-Smtp-Source: AGHT+IHK7AxOxgse4iT4ETu9J+bHsU0DPuQpdovV/6ajzEFWcqKsDafdjuSf3zlh7zNpPfElvxRO6aeZaA7/eU+naGI= X-Received: by 2002:a81:48cc:0:b0:5fb:16e6:cc01 with SMTP id v195-20020a8148cc000000b005fb16e6cc01mr632261ywa.71.1706224650095; Thu, 25 Jan 2024 15:17:30 -0800 (PST) MIME-Version: 1.0 References: <202401251829.0m6Eo4LI-lkp@intel.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 25 Jan 2024 15:17:17 -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-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5FE55A0005 X-Stat-Signature: oj6ngfedrm9bx1ni8a9d11ysbtrztqu5 X-Rspam-User: X-HE-Tag: 1706224651-761309 X-HE-Meta: U2FsdGVkX19rrHy4+nFfMnfcsXmGwUNzHSGt7dOY6DpFI9R/FbeAiUqVIkq1PTzldZ8DXb5pznNrVHEHzPJbchuXw1iNA1ZufkdwJg95F2i3aOpt5nsA61kCPdx7lslBtqteK1B2VMEWhonTRHP8mxBDWz1GJ1KlrIPuv5WH+RsGjWNNA8TVmx2ZRldBHgLWu2XikSHK1XKVyZ7eA0I8jpJAEgad0U0EpLf346LcajJfV0JFStoEivVo1BwOmozy+/qPFh09uxO7qRa4GYxZj1Hzj8pD3F8qfReg44TcN/dqM3o00YDVGwoQZbn5eoU53qzUqzFuz+yVo9RJ5MAlRDbIbr+HSluwhagIizlXHp8ymx9U3YjHPc4uCA3E4zKIPRCuLcPjhMDyM4Frjd4+VX9P2zwVyDXcHyNOpyXA/ZjSJLSlhuNZiVyfClP47cyGJs/NNyJaD+ScX0GUI86S0Hpgcp/hGsthaIHDHFlH+1HQ5FQpOWkjqylJQks8efnGrnDOd3rygguVCGpBMrQWJmOPLSPMaoCWJqmEcdyP0GHyFE8f9x2zTNE0c/BTWauqLC+9oyok7wZmLMOvhKUcJIIg+zcI/aVcW1jIHCqMnqipm/95iAHCuU8/jxB8qTQ6qJ8adqIbARNDQ0bDRn4d6tqKRPL+M4uyCSenTraZ09/j363YNVI1wJ6XYqIeUy0ni1buHSL2QCtSR19+J2Uk3WLxRrZRMMqd84thoEWAITedSAotRUSV48t5JLckiSTrsJTqXaV+X8x+OLYlO/1FvY0GkUV9wYGzdPL7Y2Wm+9jZgPsNnsga1MGJi65gWv16+cSsla1iPxDeo2CE50OOx/GE/rickj9Tm/vxD9y6b6NGFg4gcPm3MqHqJjJXX48mw1dkXKCVm6B9PryHkuYZ6lcxSFpolX2kXt9XSJG86UtNy6+++KzcYkeLY2h6xoad0ZGV7bI/FEU+TXmgypp QNdmFS6o kLehwIERS1m8IMP/VOX6GnOnO5Zkw5ssuUOLVmhLmPnKLpDGzOzc/Xd9lgac0z/Xq/R7Kxs/VnrpOS0f/zZZREs8WKPvldAyIRN1pEFFsOVSfg5vAl3JwS79fbmk/JljmLprEU0bp4fQm5zKzPtDh4fbQxol4Ye2gzu8DEUCfp1MryjnuIj5DFQK30iCTU6RhJuWpfqkixns7+vjTuaL/FalFnzYY6CxDGtBHRu56SiG1xpKli6kmM1PWxxryeV8Wak9jtykEETwxtPTkWh9MkRiGALIIN6QvslnbeW9oCgN4WOdrruAbNJACngBHkuHGHqTqJQEO9VDds7cRxSREbylBrxQCwiXRBA0Dku6ojryqaT2GoK/PDMTuipB0mUBEiDC5wS7j4a7sbuOqEmJTRenOyv1qNpy9s2xnjaAF6MISuXHi/nim+kxLTA== 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 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 wrote: > > 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-ne= xt.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.org/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/0day-ci/a= rchive/20240125/202401251829.0m6Eo4LI-lkp@intel.com/reproduce) > > > > > > If you fix the issue in a separate patch/commit (i.e. not just 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 argum= ent 1 (different address spaces) @@ expected struct file [noderef] __rc= u **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 fput() > > which schedules its freeing using schedule_delayed_work(..., 1) but I > > don't think that constitutes RCU grace period. Paul, Matthew, could > > 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 period. > > There is a queue_rcu_work() that schedules work after a grace period, > which could be combined with a timer to get the delay. > > Another approach would be to use get_state_synchronize_rcu() before > the schedule_delayed_work() in fput(), then do cond_synchronize_rcu() > in delayed_fput(). This would require adding an unsigned long to > struct file to keep track of which grace period a given struct file > 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_RE= SUME)) > return; > /* > * After this task has run exit_task_work(), > * task_work_add() will fail. Fall through to de= layed > * 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_list); > 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 almost all th= e > time, actually blocking at most about every once per every few jiffies. > 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 given > 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 size > 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. 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? > > Thanx, Paul > > > > fs/proc/task_mmu.c:143:45: sparse: expected struct file [noder= ef] __rcu **f > > > fs/proc/task_mmu.c:143:45: sparse: got struct file ** > > > fs/proc/task_mmu.c: note: in included file (through include/linux/= rbtree.h, include/linux/mm_types.h, include/linux/mmzone.h, ...): > > > include/linux/rcupdate.h:781:9: sparse: sparse: context imbalance = in 'get_vma_snapshot' - unexpected unlock > > > fs/proc/task_mmu.c:264:22: sparse: sparse: context imbalance in 'm= _start' - different lock contexts for basic block > > > include/linux/rcupdate.h:781:9: sparse: sparse: context imbalance = in 'm_stop' - unexpected unlock > > > include/linux/rcupdate.h:781:9: sparse: sparse: context imbalance = in 'smaps_pte_range' - unexpected unlock > > > include/linux/rcupdate.h:781:9: sparse: sparse: context imbalance = in 'clear_refs_pte_range' - unexpected unlock > > > include/linux/rcupdate.h:781:9: sparse: sparse: context imbalance = in 'pagemap_pmd_range' - unexpected unlock > > > include/linux/rcupdate.h:781:9: sparse: sparse: context imbalance = in 'pagemap_scan_pmd_entry' - unexpected unlock > > > fs/proc/task_mmu.c: note: in included file (through arch/x86/inclu= de/asm/uaccess.h, include/linux/uaccess.h, include/linux/sched/task.h, ...)= : > > > arch/x86/include/asm/uaccess_64.h:88:24: sparse: sparse: cast remo= ves address space '__user' of expression > > > arch/x86/include/asm/uaccess_64.h:88:24: sparse: sparse: cast remo= ves 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 ar= e used by > > > 135 * show_map_vma. > > > 136 */ > > > 137 static int get_vma_snapshot(struct proc_maps_private *priv, s= truct vm_area_struct *vma) > > > 138 { > > > 139 struct vm_area_struct *copy =3D &priv->vma_copy; > > > 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_read(priv->= mm)) > > > 150 return 0; > > > 151 > > > 152 /* Address space got modified, vma might be stale. Wa= it 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 re= try */ > > > 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