From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 9CA004C9560 for ; Mon, 7 Sep 2026 13:41:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788788492; cv=none; b=n+kSJavreHgQ6+jMDJt2QeGV9qsYWrrJWRP0mF4vVB4t2lxItsP0wjoYUthvQ/8blEkX45OOLKdNmdW2EriY0YctHzGuZ0TIfWtcUW6FSN2PHWzz1w7/NmLQ4+aNbf7dIZjg5kvLJMSOV/Ytm1uOXXvR8hbv1EPYORjvlxOciLE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788788492; c=relaxed/simple; bh=reyY/SSEkR1hnlm27/oBWU/HkTc3wy99JVkrYnF7+Ro=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hm+uQfySc5ZqJIywGqWHz0+FHk5noqHY8iLyg1Kg3HOCAENk8mYciP5IXWbtBjLa7lJayES6lXQeWlt0Ow9wDHAac6FilZq0f/OQXyz1lYNmUGT54sQDr1twX4HXMA/Y/VFlP9uJ+MQ7LmCRO62qtozzTMiO12qqX3ACi2lr/m8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=exG3ufYi; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="exG3ufYi" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48589798dbbso2939117f8f.3 for ; Mon, 07 Sep 2026 06:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788788489; x=1789393289; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JdqenWViU/7DdrPY02Ze4qYR4l7SaizSPWmzY+qOqso=; b=exG3ufYiFIIwXt3jURMEzeZgTYsK3Z65iqYzEr/rVOfHMDC9OI94A0jy2eS7nW4ONi gQ0m595vzrD+Up4219Dzd57XMet9jOPTaf2m3f1RvBHMcM/ZXZ/5rzdxYNoH4etFMdrR nNPSJ73W4CBV7Q1N7PxgCEItLctTeeWJCMnNBxEf0JkaSZsoebjodE8RiD8bhkLlFWCS NS+Um/pr0gZY+w+hxCx87bmFey1wq0kzErJn4dc19P1h7BvaC2HF30FJxwJR1LFJ8h4R 3Sf9iLMXHvHC8uZlin49cJIVLWcBGDE+339DQyCmkfgTdfxldD3FfJ7j57uukBVCKwCr /0pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788788489; x=1789393289; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=JdqenWViU/7DdrPY02Ze4qYR4l7SaizSPWmzY+qOqso=; b=lGJ9aILHxxfASyz4vsHcgnJ6ZYdjbPg1/X3N5P+7/+dqHoPh9Amd36HVHlPyRFJzaz diAq9qZVvDet1G90PSRgEsC06FR9w+760ZHi/YdFyfW0ycxgqSRsJjNf+gMxN+MPJrVk 7C/7707AtLzzuZj5CCOXrRXKtCebipT8RZe92Pcew8vvC7HpObUWX+CbkCXO2Io4awDR /zYZg9Xyh69q3WlbOG7U7oC3qi/8lEk3jlOkpfMIC3I4jcQwrsOaGzrWkREtCAvMNjtF sNc1Y4wLg0aMMs6eIawurMcGNCF3OVk4JzQiCvd5XKs/ZiuIqZEXX0S5WUurebv/pZfJ Zlsw== X-Forwarded-Encrypted: i=1; AKwUvBxTPOneXbTbj0timcwCcAGsaMyPRZmBZjyRA7T++BYzoX7hFdZC0UD6y20WDTI89e+hLD/gO06ZcYrR3wo=@vger.kernel.org X-Gm-Message-State: AFuF++lYbJyzUpVqzakBsqkdqAPEAgHf9SMkvkEgGngS/ck8U1ozm7ZO Q2/0zGV+qzp18mCVv4NhG6KPN5mSOrHzGNVZ4fcB/NH90zeDOkFYQ5Wa X-Gm-Gg: AYBFou00he+rVh/0Pu8H+4yPEtWtt6M+k8WntIslK14/Agb1eZZiGMVL359QE1sx0OU mCFm46mtXPXA1IrbtZgzJeiZmJEJhMFgm9k/1LQj61s3gL+FvgTKu2t9IkcUDH0NjBBbdeTAyk8 J1ZMfxyBaNG4p7T2t3kSSCZGKCs+GJDE1D11yot2LJ8Ixjh1AUswvY31AToeeKS4gA6vteFDcwq DO+xZTkORyV122LbGxUBY4jY1EcAVI9/RYVKYqbdg28oEyol21Y4FTwLRj5HpwUEsVOY7KQDAyT 61YdXGrr41TF7CDZf5XiFutjjsJOD35lqHLJ0TDl/7XSXW1nOYkgwWYQlgVwk9/QtYy+YvY8njw DdyCNGF5O6DWBH4XTtpflz6df9EIxkP8pOPYBJI549DpKJ+bhG2q3rlLpKkpEttJrOmJSaACrDA /BmsfhR2M7+O5kXQGoujXahV/5G4ZGANaOHNuwhD0nZjLHhvgRBN4gcYGsBit8PWCb+eIKPDLoP Q== X-Received: by 2002:a05:6000:41d3:b0:485:8e90:bf55 with SMTP id ffacd0b85a97d-4858e90c0a6mr18822569f8f.47.1788788488633; Mon, 07 Sep 2026 06:41:28 -0700 (PDT) Received: from dell-desktop ([2a02:587:4b5f:900:ef25:2f4:1792:4e6f]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4858d312ca0sm28655087f8f.4.2026.09.07.06.41.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Sep 2026 06:41:28 -0700 (PDT) From: Anastasios Papagiannis To: david@kernel.org Cc: akpm@linux-foundation.org, andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org, brauner@kernel.org, daniel@iogearbox.net, eddyz87@gmail.com, kpsingh@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org, matt@bobrowski.net, memxor@gmail.com, song@kernel.org, sun.jian.kdev@gmail.com, tasos.papagiannnis@gmail.com, utilityemal77@gmail.com, viro@zeniv.linux.org.uk Subject: Re: [PATCH bpf-next v4 1/7] mm: Add copy_remote_mm_str() Date: Mon, 7 Sep 2026 16:41:01 +0300 Message-ID: <20260907134101.424017-1-tasos.papagiannnis@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <0e4edfd3-0c82-42e0-ad09-19ff8b8d1511@kernel.org> References: <0e4edfd3-0c82-42e0-ad09-19ff8b8d1511@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > We have this check in copy_remote_vm_str(). Why are we performing the check now > twice? > It should either go only into __copy_remote_mm_str(), or if there a reason to > have it before get_task_mm(), it should go into copy_remote_mm_str(). Same > applies to the memory.c case. Yes, this makes sense. I will fix that. > What's more annoying is that both implementations of copy_remote_vm_str() are > identical, and both implementations of copy_remote_mm_str() are nearly identical > (just dropping the gup_flags for nommu). I'd like to avoid duplicating code for > nommu. > If we could export __copy_remote_vm_str(mm, addr, buf, len, gup_flags) for both > cases, we could instead provide a single implementation for copy_remote_vm_str() > and copy_remote_mm_str() e.g., in mm.h? (I'd prefer somewhere else, but we don't > seem to have a good git for memory.c + nommu.c shared stuff) Another idea can be: mm/memory.c: MMU implementation of __copy_remote_mm_str() mm/nommu.c: NOMMU implementation of __copy_remote_mm_str() mm/internal.h: declaration of __copy_remote_mm_str() include/linux/mm.h: declaration of copy_remote_mm_str() and copy_remote_vm_str() mm/util.c: shared implementation for copy_remote_mm_str() and copy_remote_vm_str() This allows us to remove the duplicate code. Does this sound reasonable? > Now, that's also not completely nice, as I don't want us to EXPORT > __copy_remote_vm_str() ... given that these functions are "#ifdef > CONFIG_BPF_SYSCALL" could we EXPORT_SYMBOL_FOR_MODULES? Now copy_remote_vm_str() is EXPORT_SYMBOL_GPL. In this series, we use copy_remote_mm_str() without the need to export that. Why do we need to consider exporting __copy_remote_vm_str()? -- Thanks, -Anastasios