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 6C770C43334 for ; Fri, 1 Jul 2022 00:29:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C90F98E0002; Thu, 30 Jun 2022 20:29:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C40B18E0001; Thu, 30 Jun 2022 20:29:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B30FE8E0002; Thu, 30 Jun 2022 20:29:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A4B7C8E0001 for ; Thu, 30 Jun 2022 20:29:07 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 764F335957 for ; Fri, 1 Jul 2022 00:29:07 +0000 (UTC) X-FDA: 79636646334.09.FD29C12 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf21.hostedemail.com (Postfix) with ESMTP id 0A3321C002E for ; Fri, 1 Jul 2022 00:29:06 +0000 (UTC) Received: by mail-qv1-f52.google.com with SMTP id c1so2248304qvi.11 for ; Thu, 30 Jun 2022 17:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5pzzbEZN82yYBiH28KrESM17Q5R6f4zuLNwiNZW+NmA=; b=pCisyGOaSS5InYxtFLG3l/n6tnJYb//s8x2SIEcIpJ0zyfedIKUNpAeDDg1SwvIQug VIps9dZKWovLaHvEJdcQP0sms4LlfD6ejTyeiSKQybqmgVgcACXShmTMdG6uQCxXIM1Y tjEgNKx4wTnODcTGGzD1uMyvx/U2OgcclrjN6/pMGdcezkmAKSNZvGw1pqFR7146y1A0 ri2qQzum9A2LBQ86TtOVtA3jXyy0Gv1EqGLb05meyi//N6XHBvOoX+v2NbYXgxy/dod1 ATSwcpZwfxU1ksuyaEPTJIs7fCGgGl7hToYNFFEA6dwE6OHxTu+Jh4/u3uJp5Vls0bfB EfHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5pzzbEZN82yYBiH28KrESM17Q5R6f4zuLNwiNZW+NmA=; b=KAHCkaqjxPYJn86t1sLhOo8Bb6uG/JVshblGgs2cQgIFIlpy1v43OVar5RyilDtn/Y PiOP7dWfCsgP4OjgXzUDrsM/baojrzN7GKqC6zhyU6z2KrtEMFKhij8W+wu9B65LAc3e QPHGJ2K7QrldQ4DW6oOIYnOEv2qGOTz5mKaQ+37ap+lcG7ewwvDeVv3TWfngNeT7MIZO cIqDvtKY57AnxT3bvjsdgARzWiTzqOlbLHW7GlsI3Rw5qCzBJtVHO7UmisnhNjF5w1cr mwRldztgON7pEc4LMPy/iFtagmgifZrD1bFeIQM1tn6RoG0TzF/TDluxCZjA8Spmo/9m eOVw== X-Gm-Message-State: AJIora+jSD9BXLK70F75DVAcIDJM3aXnyIBCUz7wsFEyZM+mzsnX6DiK XhgXWZyYpPFpxdNVFAAbUnTPRA== X-Google-Smtp-Source: AGRyM1ulaMcqFbN6QciqGHav5qwFzXOqXZME/0QP2HTlqd1K8hea7mrMdDKHT5IWVXVMXH/kQ5X9Ug== X-Received: by 2002:ad4:5312:0:b0:470:4c4b:9263 with SMTP id y18-20020ad45312000000b004704c4b9263mr15266003qvr.61.1656635346189; Thu, 30 Jun 2022 17:29:06 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id hh10-20020a05622a618a00b003154e7466casm13289123qtb.51.2022.06.30.17.29.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jun 2022 17:29:05 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1o74Wu-004ZNg-G8; Thu, 30 Jun 2022 21:29:04 -0300 Date: Thu, 30 Jun 2022 21:29:04 -0300 From: Jason Gunthorpe To: Linus Walleij Cc: Andrew Morton , linux-mm@kvack.org Subject: Re: [PATCH 4/5] mm: gup: Pass a pointer to virt_to_page() Message-ID: <20220701002904.GX23621@ziepe.ca> References: <20220630084124.691207-1-linus.walleij@linaro.org> <20220630084124.691207-5-linus.walleij@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220630084124.691207-5-linus.walleij@linaro.org> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656635347; a=rsa-sha256; cv=none; b=lv/7M2Z90aM3dL/3YJKYN96d3maSVOSIfkTvSRSGavzhkH/Qqv6siC3/6tD9aX8KpagRJa 4lC2aoa1BjetBEqbjXFs/BHcEDXb791I2bi7Kmnj5qePx3VUODgiKokl2Nwf9vkYbauX/Z W8+wPU9pNdjj/70OOS2ZdUVkBJnG5XI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=pCisyGOa; dmarc=none; spf=pass (imf21.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.52 as permitted sender) smtp.mailfrom=jgg@ziepe.ca ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656635347; 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=5pzzbEZN82yYBiH28KrESM17Q5R6f4zuLNwiNZW+NmA=; b=NuHYBeCEkBn/ceJg4epwNyhaXPB+qCJQmRfVfX/HArP2NIARvUGAf7i7k6OmNhjTNtLqhP jx+FsQCWmKaUW5ZSPJp77AwlxTQ+LzwgixdcrhAr/P5Zp3BeaZ6qM2eXtQEagxsY0+zPeg AhKFm4NDGPnkxWl66MZ6qY2rzyUyVI4= X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0A3321C002E Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=pCisyGOa; dmarc=none; spf=pass (imf21.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.52 as permitted sender) smtp.mailfrom=jgg@ziepe.ca X-Rspam-User: X-Stat-Signature: rf5zgquosimo96uji1gm3gyeu1yttz9p X-HE-Tag: 1656635346-269966 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: On Thu, Jun 30, 2022 at 10:41:23AM +0200, Linus Walleij wrote: > Functions that work on a pointer to virtual memory such as > virt_to_pfn() and users of that function such as > virt_to_page() are supposed to pass a pointer to virtual > memory, ideally a (void *) or other pointer. However since > many architectures implement virt_to_pfn() as a macro, > this function becomes polymorphic and accepts both a > (unsigned long) and a (void *). I wonder if there is merit to convert x86 to use an inline after this goes in to prevent this polymorphic mistake? > If we instead implement a proper virt_to_pfn(void *addr) > function the following happens (occurred on arch/arm): > > mm/gup.c: In function '__get_user_pages_locked': > mm/gup.c:1599:49: warning: passing argument 1 of 'virt_to_pfn' > makes pointer from integer without a cast [-Wint-conversion] > pages[i] = virt_to_page(start); > > Fix this with an explicit cast. > > Cc: Andrew Morton > Cc: linux-mm@kvack.org > Signed-off-by: Linus Walleij > --- > mm/gup.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/gup.c b/mm/gup.c > index 551264407624..543c68da65f1 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -1672,7 +1672,7 @@ static long __get_user_pages_locked(struct mm_struct *mm, unsigned long start, > goto finish_or_fault; > > if (pages) { > - pages[i] = virt_to_page(start); > + pages[i] = virt_to_page((void *)start); That 'start' is actually a userspace addres so it technically is a __user pointer, but the missing context here is that this is a NOMMU special function, so I guess it is right as is? Still, it is NOP to what it is now so: Reviewed-by: Jason Gunthorpe Jason