All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Wenhu <wenhu.wang@hotmail.com>
To: gregkh@linuxfoundation.org, arnd@arndb.de, hao.wu@intel.com,
	trix@redhat.com, mdf@kernel.org, yilun.xu@intel.com,
	bhelgaas@google.com, akpm@linux-foundation.org,
	linux-fpga@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-mm@kvack.org
Cc: christophe.leroy@csgroup.eu, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au,
	wenhu.wang@hotmail.com
Subject: [PATCHv2 1/2] mm: eliminate ifdef of HAVE_IOREMAP_PROT in .c files
Date: Tue, 14 Jun 2022 22:57:34 -0700	[thread overview]
Message-ID: <SG2PR01MB295111ED8F547B9F99DB9FA99FAD9@SG2PR01MB2951.apcprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <20220615055735.53585-1-wenhu.wang@hotmail.com>

It is recommended in the "Conditional Compilation" chapter of kernel
coding-style documentation that preprocessor conditionals should not
be used in .c files wherever possible.

As for the macro CONFIG_HAVE_IOREMAP_PROT, now it's a proper chance
to eliminate it in .c files which are referencers. We constrict its usage
only to mm/memory.c.
HAVE_IOREMAP_PROT is supported by part of archectures such as powerpc and
x86, but not supported by some others such as arm. So for some functions,
a no-op version should be available. Currently it's generic_access_phys,
which is referenced by some other modules.

Signed-off-by: Wang Wenhu <wenhu.wang@hotmail.com>
---
v2:
 - Added IS_ENABLED(CONFIG_HAVE_IOREMAP_PROT) condition in __access_remote_vm
 - Added generic_access_phys() function with no-op in mm/memory.c instead of the 
 former one of "static inline" in include/linux/mm.h
Former: https://lore.kernel.org/linux-mm/YqMRtWAH5fIWsLQB@kroah.com/T/
---
 drivers/char/mem.c          |  2 --
 drivers/fpga/dfl-afu-main.c |  2 --
 drivers/pci/mmap.c          |  2 --
 drivers/uio/uio.c           |  2 --
 mm/memory.c                 | 13 +++++++++----
 5 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 84ca98ed1dad..40186a441e38 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -354,9 +354,7 @@ static inline int private_mapping_ok(struct vm_area_struct *vma)
 #endif
 
 static const struct vm_operations_struct mmap_mem_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys
-#endif
 };
 
 static int mmap_mem(struct file *file, struct vm_area_struct *vma)
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index 7f621e96d3b8..833e14806c7a 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -797,9 +797,7 @@ static long afu_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 }
 
 static const struct vm_operations_struct afu_vma_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys,
-#endif
 };
 
 static int afu_mmap(struct file *filp, struct vm_area_struct *vma)
diff --git a/drivers/pci/mmap.c b/drivers/pci/mmap.c
index b8c9011987f4..1dcfabf80453 100644
--- a/drivers/pci/mmap.c
+++ b/drivers/pci/mmap.c
@@ -35,9 +35,7 @@ int pci_mmap_page_range(struct pci_dev *pdev, int bar,
 #endif
 
 static const struct vm_operations_struct pci_phys_vm_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys,
-#endif
 };
 
 int pci_mmap_resource_range(struct pci_dev *pdev, int bar,
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 43afbb7c5ab9..c9205a121007 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -719,9 +719,7 @@ static int uio_mmap_logical(struct vm_area_struct *vma)
 }
 
 static const struct vm_operations_struct uio_physical_vm_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys,
-#endif
 };
 
 static int uio_mmap_physical(struct vm_area_struct *vma)
diff --git a/mm/memory.c b/mm/memory.c
index 7a089145cad4..7c0e59085456 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5413,6 +5413,13 @@ int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
 	return ret;
 }
 EXPORT_SYMBOL_GPL(generic_access_phys);
+#else
+int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
+			void *buf, int len, int write)
+{
+	return 0;
+}
+EXPORT_SYMBOL_GPL(generic_access_phys);
 #endif
 
 /*
@@ -5437,9 +5444,8 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
 		ret = get_user_pages_remote(mm, addr, 1,
 				gup_flags, &page, &vma, NULL);
 		if (ret <= 0) {
-#ifndef CONFIG_HAVE_IOREMAP_PROT
-			break;
-#else
+			if (!IS_ENABLED(CONFIG_HAVE_IOREMAP_PROT))
+				break;
 			/*
 			 * Check if this is a VM_IO | VM_PFNMAP VMA, which
 			 * we can access using slightly different code.
@@ -5453,7 +5459,6 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
 			if (ret <= 0)
 				break;
 			bytes = ret;
-#endif
 		} else {
 			bytes = len;
 			offset = addr & (PAGE_SIZE-1);
-- 
2.25.1


WARNING: multiple messages have this Message-ID (diff)
From: Wang Wenhu <wenhu.wang@hotmail.com>
To: gregkh@linuxfoundation.org, arnd@arndb.de, hao.wu@intel.com,
	trix@redhat.com, mdf@kernel.org, yilun.xu@intel.com,
	bhelgaas@google.com, akpm@linux-foundation.org,
	linux-fpga@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-mm@kvack.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	wenhu.wang@hotmail.com
Subject: [PATCHv2 1/2] mm: eliminate ifdef of HAVE_IOREMAP_PROT in .c files
Date: Tue, 14 Jun 2022 22:57:34 -0700	[thread overview]
Message-ID: <SG2PR01MB295111ED8F547B9F99DB9FA99FAD9@SG2PR01MB2951.apcprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <20220615055735.53585-1-wenhu.wang@hotmail.com>

It is recommended in the "Conditional Compilation" chapter of kernel
coding-style documentation that preprocessor conditionals should not
be used in .c files wherever possible.

As for the macro CONFIG_HAVE_IOREMAP_PROT, now it's a proper chance
to eliminate it in .c files which are referencers. We constrict its usage
only to mm/memory.c.
HAVE_IOREMAP_PROT is supported by part of archectures such as powerpc and
x86, but not supported by some others such as arm. So for some functions,
a no-op version should be available. Currently it's generic_access_phys,
which is referenced by some other modules.

Signed-off-by: Wang Wenhu <wenhu.wang@hotmail.com>
---
v2:
 - Added IS_ENABLED(CONFIG_HAVE_IOREMAP_PROT) condition in __access_remote_vm
 - Added generic_access_phys() function with no-op in mm/memory.c instead of the 
 former one of "static inline" in include/linux/mm.h
Former: https://lore.kernel.org/linux-mm/YqMRtWAH5fIWsLQB@kroah.com/T/
---
 drivers/char/mem.c          |  2 --
 drivers/fpga/dfl-afu-main.c |  2 --
 drivers/pci/mmap.c          |  2 --
 drivers/uio/uio.c           |  2 --
 mm/memory.c                 | 13 +++++++++----
 5 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 84ca98ed1dad..40186a441e38 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -354,9 +354,7 @@ static inline int private_mapping_ok(struct vm_area_struct *vma)
 #endif
 
 static const struct vm_operations_struct mmap_mem_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys
-#endif
 };
 
 static int mmap_mem(struct file *file, struct vm_area_struct *vma)
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index 7f621e96d3b8..833e14806c7a 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -797,9 +797,7 @@ static long afu_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 }
 
 static const struct vm_operations_struct afu_vma_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys,
-#endif
 };
 
 static int afu_mmap(struct file *filp, struct vm_area_struct *vma)
diff --git a/drivers/pci/mmap.c b/drivers/pci/mmap.c
index b8c9011987f4..1dcfabf80453 100644
--- a/drivers/pci/mmap.c
+++ b/drivers/pci/mmap.c
@@ -35,9 +35,7 @@ int pci_mmap_page_range(struct pci_dev *pdev, int bar,
 #endif
 
 static const struct vm_operations_struct pci_phys_vm_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys,
-#endif
 };
 
 int pci_mmap_resource_range(struct pci_dev *pdev, int bar,
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 43afbb7c5ab9..c9205a121007 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -719,9 +719,7 @@ static int uio_mmap_logical(struct vm_area_struct *vma)
 }
 
 static const struct vm_operations_struct uio_physical_vm_ops = {
-#ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys,
-#endif
 };
 
 static int uio_mmap_physical(struct vm_area_struct *vma)
diff --git a/mm/memory.c b/mm/memory.c
index 7a089145cad4..7c0e59085456 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5413,6 +5413,13 @@ int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
 	return ret;
 }
 EXPORT_SYMBOL_GPL(generic_access_phys);
+#else
+int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
+			void *buf, int len, int write)
+{
+	return 0;
+}
+EXPORT_SYMBOL_GPL(generic_access_phys);
 #endif
 
 /*
@@ -5437,9 +5444,8 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
 		ret = get_user_pages_remote(mm, addr, 1,
 				gup_flags, &page, &vma, NULL);
 		if (ret <= 0) {
-#ifndef CONFIG_HAVE_IOREMAP_PROT
-			break;
-#else
+			if (!IS_ENABLED(CONFIG_HAVE_IOREMAP_PROT))
+				break;
 			/*
 			 * Check if this is a VM_IO | VM_PFNMAP VMA, which
 			 * we can access using slightly different code.
@@ -5453,7 +5459,6 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
 			if (ret <= 0)
 				break;
 			bytes = ret;
-#endif
 		} else {
 			bytes = len;
 			offset = addr & (PAGE_SIZE-1);
-- 
2.25.1


  parent reply	other threads:[~2022-06-15  5:59 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220609102855.272270-1-wenhu.wang@hotmail.com>
2022-06-09 10:28 ` [PATCH 1/2] powerpc:mm: export symbol ioremap_coherent Wang Wenhu
2022-06-09 10:28   ` Wang Wenhu
2022-06-14 10:45   ` Michael Ellerman
2022-06-14 14:49     ` Christoph Hellwig
2022-06-14 14:49       ` Christoph Hellwig
2022-06-15  4:37     ` 回复: " Wenhu Wang
2022-06-09 10:28 ` [PATCH 2/2] uio:powerpc:mpc85xx: l2-cache-sram uio driver implementation Wang Wenhu
2022-06-09 10:28   ` Wang Wenhu
2022-06-09 13:17   ` Greg KH
2022-06-09 13:17     ` Greg KH
2022-06-14  6:09     ` 回复: " Wenhu Wang
2022-06-14  6:09       ` Wenhu Wang
2022-06-14  6:34       ` Greg KH
2022-06-14  6:34         ` Greg KH
2022-06-14  7:12         ` Christophe Leroy
2022-06-14  7:12           ` Christophe Leroy
2022-06-14  7:18       ` Christophe Leroy
2022-06-14  7:18         ` Christophe Leroy
2022-06-14  7:26         ` Christophe Leroy
2022-06-14  7:26           ` Christophe Leroy
2022-06-14  7:53           ` Wenhu Wang
2022-06-14  7:53             ` Wenhu Wang
2022-06-14  8:03             ` Greg KH
2022-06-14  8:03               ` Greg KH
2022-06-14  8:39               ` Wenhu Wang
2022-06-14  8:39                 ` Wenhu Wang
2022-06-14 14:40             ` Wenhu Wang
2022-06-14 14:40               ` Wenhu Wang
2022-06-14 14:59               ` Christophe Leroy
2022-06-14 14:59                 ` Christophe Leroy
2022-06-15  6:04       ` 回复: " Christophe Leroy
2022-06-15  6:04         ` Christophe Leroy
2022-06-15  5:57     ` [PATCHv2 0/2] uio:powerpc:mpc85xx: l2-cache-sram uio driver Wang Wenhu
2022-06-15  5:57       ` Wang Wenhu
     [not found]     ` <20220615055735.53585-1-wenhu.wang@hotmail.com>
2022-06-15  5:57       ` Wang Wenhu [this message]
2022-06-15  5:57         ` [PATCHv2 1/2] mm: eliminate ifdef of HAVE_IOREMAP_PROT in .c files Wang Wenhu
2022-06-15  6:49         ` Christoph Hellwig
2022-06-15  6:49           ` Christoph Hellwig
2022-06-22  2:22         ` kernel test robot
2022-06-22  2:22           ` kernel test robot
2022-06-22  4:13         ` kernel test robot
2022-06-22  4:13           ` kernel test robot
2022-06-15  5:57       ` [PATCHv2 2/2] uio:powerpc:mpc85xx: l2-cache-sram uio driver implementation Wang Wenhu
2022-06-15  5:57         ` Wang Wenhu
2022-06-15  6:43         ` Christoph Hellwig
2022-06-15  6:43           ` Christoph Hellwig
2022-06-15  6:48         ` Christophe Leroy
2022-06-15  6:48           ` Christophe Leroy
2022-06-15  6:49         ` Christophe Leroy
2022-06-15  6:49           ` Christophe Leroy
2022-06-14 14:51   ` [PATCH " Christoph Hellwig
2022-06-14 14:51     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SG2PR01MB295111ED8F547B9F99DB9FA99FAD9@SG2PR01MB2951.apcprd01.prod.exchangelabs.com \
    --to=wenhu.wang@hotmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=gregkh@linuxfoundation.org \
    --cc=hao.wu@intel.com \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mdf@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=trix@redhat.com \
    --cc=yilun.xu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.