linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86
@ 2021-12-27 14:59 Kefeng Wang
  2021-12-27 14:59 ` [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
                   ` (3 more replies)
  0 siblings, 4 replies; 145+ messages in thread
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
  To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
	linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox, Kefeng Wang

Huge vmalloc mappings is supported on PPC[1], but this feature should
be not only used on PPC, it could be used on arch support HAVE_ARCH_HUGE_VMAP
and PMD sized vmap mappings. this patchset is to enable this feature
on arm64/x86.

There are some disadvantages about this feature[2], one of the main
concerns is the possible memory fragmentation/waste in some scenarios,
also archs must ensure that any arch specific vmalloc allocations that
require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.

Based on the above considerations, we add the first patch is to let
user to control huge vmalloc mapping default behavior.  Meanwhile,
add new kernel parameter hugevmalloc=on/off to enable/disable this
feature at boot time, nohugevmalloc parameter is still supported.

The later two patches to enable this feature on arm64/x86, select
HAVE_ARCH_HUGE_VMALLOC and mark VM_NO_HUGE_VMAP in arch's module_alloc().

This patchset based on next-20211224.

v2:
- Default y for HUGE_VMALLOC_DEFAULT_ENABLED, not only select it on PPC
- Fix copy/type error
- Mark VM_NO_HUGE_VMAP in module_alloc() on arm64/x86

[1] https://lore.kernel.org/linux-mm/20210317062402.533919-1-npiggin@gmail.com/
[2] https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/

Kefeng Wang (3):
  mm: vmalloc: Let user to control huge vmalloc default behavior
  arm64: Support huge vmalloc mappings
  x86: Support huge vmalloc mappings

 .../admin-guide/kernel-parameters.txt          | 14 +++++++++++++-
 arch/arm64/Kconfig                             |  1 +
 arch/arm64/kernel/module.c                     |  5 +++--
 arch/x86/Kconfig                               |  1 +
 arch/x86/kernel/module.c                       |  4 ++--
 mm/Kconfig                                     |  8 ++++++++
 mm/vmalloc.c                                   | 18 +++++++++++++++++-
 7 files changed, 45 insertions(+), 6 deletions(-)

-- 
2.26.2


^ permalink raw reply	[flat|nested] 145+ messages in thread

* [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
  2021-12-27 14:59 [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Kefeng Wang
@ 2021-12-27 14:59 ` Kefeng Wang
  2022-01-18  2:52   ` Nicholas Piggin
  2021-12-27 14:59 ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 145+ messages in thread
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
  To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
	linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox, Kefeng Wang

Introduce HUGE_VMALLOC_DEFAULT_ENABLED and make it default y, this
let user to choose whether or not enable huge vmalloc mappings by
default.

Meanwhile, add new hugevmalloc=on/off parameter to enable or disable
this feature at boot time, nohugevmalloc is still supported and
equivalent to hugevmalloc=off.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 .../admin-guide/kernel-parameters.txt          | 12 ++++++++++++
 mm/Kconfig                                     |  8 ++++++++
 mm/vmalloc.c                                   | 18 +++++++++++++++++-
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a069d8fe2fee..7b2f900fd243 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1638,6 +1638,18 @@
 			If both parameters are enabled, hugetlb_free_vmemmap takes
 			precedence over memory_hotplug.memmap_on_memory.
 
+
+	hugevmalloc=	[PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+			Format: { on | off }
+			Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
+
+			This parameter enables/disables kernel huge vmalloc
+			mappings at boot time.
+
+			on:  Enable the feature
+			off: Disable the feature
+			     Equivalent to: nohugevmalloc
+
 	hung_task_panic=
 			[KNL] Should the hung task detector generate panics.
 			Format: 0 | 1
diff --git a/mm/Kconfig b/mm/Kconfig
index a99bd499ef51..8d8a92f22905 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -262,6 +262,14 @@ config HUGETLB_PAGE_SIZE_VARIABLE
 	  HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available
 	  on a platform.
 
+config HUGE_VMALLOC_DEFAULT_ENABLED
+	bool "Enable huge vmalloc mappings by default"
+	default y
+	depends on HAVE_ARCH_HUGE_VMALLOC
+	help
+	  Enable huge vmalloc mappings by default, this value could be overridden
+	  by hugevmalloc=off|on.
+
 config CONTIG_ALLOC
 	def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
 
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 9bf838817a47..0d0f8deb5639 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -60,7 +60,7 @@ static const unsigned int ioremap_max_page_shift = PAGE_SHIFT;
 #endif	/* CONFIG_HAVE_ARCH_HUGE_VMAP */
 
 #ifdef CONFIG_HAVE_ARCH_HUGE_VMALLOC
-static bool __ro_after_init vmap_allow_huge = true;
+static bool __ro_after_init vmap_allow_huge = IS_ENABLED(CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED);
 
 static int __init set_nohugevmalloc(char *str)
 {
@@ -68,6 +68,22 @@ static int __init set_nohugevmalloc(char *str)
 	return 0;
 }
 early_param("nohugevmalloc", set_nohugevmalloc);
+
+static int __init set_hugevmalloc(char *str)
+{
+	if (!str)
+		return -EINVAL;
+
+	if (!strcmp(str, "on"))
+		vmap_allow_huge = true;
+	else if (!strcmp(str, "off"))
+		vmap_allow_huge = false;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+early_param("hugevmalloc", set_hugevmalloc);
 #else /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */
 static const bool vmap_allow_huge = false;
 #endif	/* CONFIG_HAVE_ARCH_HUGE_VMALLOC */
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 145+ messages in thread

* [PATCH v2 2/3] arm64: Support huge vmalloc mappings
  2021-12-27 14:59 [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Kefeng Wang
  2021-12-27 14:59 ` [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
@ 2021-12-27 14:59 ` Kefeng Wang
  2021-12-27 17:35   ` (No subject) William Kucharski
  2022-01-15 10:05   ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Christophe Leroy
  2021-12-27 14:59 ` [PATCH v2 3/3] x86: " Kefeng Wang
  2022-01-15 10:07 ` [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Christophe Leroy
  3 siblings, 2 replies; 145+ messages in thread
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
  To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
	linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox, Kefeng Wang

This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
vmalloc mappings.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 4 ++--
 arch/arm64/Kconfig                              | 1 +
 arch/arm64/kernel/module.c                      | 5 +++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7b2f900fd243..e3f9fd7ec106 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1639,7 +1639,7 @@
 			precedence over memory_hotplug.memmap_on_memory.
 
 
-	hugevmalloc=	[PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+	hugevmalloc=	[KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
 			Format: { on | off }
 			Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
 
@@ -3424,7 +3424,7 @@
 
 	nohugeiomap	[KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
 
-	nohugevmalloc	[PPC] Disable kernel huge vmalloc mappings.
+	nohugevmalloc	[KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
 
 	nosmt		[KNL,S390] Disable symmetric multithreading (SMT).
 			Equivalent to smt=1.
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3bb0b67292b5..c34bbb4482b0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -142,6 +142,7 @@ config ARM64
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_BITREVERSE
 	select HAVE_ARCH_COMPILER_H
+	select HAVE_ARCH_HUGE_VMALLOC
 	select HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 309a27553c87..af7b4cbace2b 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
 		module_alloc_end = MODULES_END;
 
 	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
-				module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
+				module_alloc_end, gfp_mask, PAGE_KERNEL,
+				VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
 				NUMA_NO_NODE, __builtin_return_address(0));
 
 	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
@@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
 		 */
 		p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
 				module_alloc_base + SZ_2G, GFP_KERNEL,
-				PAGE_KERNEL, 0, NUMA_NO_NODE,
+				PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
 				__builtin_return_address(0));
 
 	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 145+ messages in thread

* [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-27 14:59 [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Kefeng Wang
  2021-12-27 14:59 ` [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
  2021-12-27 14:59 ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
@ 2021-12-27 14:59 ` Kefeng Wang
  2021-12-27 15:56   ` Dave Hansen
  2022-01-15 10:06   ` Christophe Leroy
  2022-01-15 10:07 ` [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Christophe Leroy
  3 siblings, 2 replies; 145+ messages in thread
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
  To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
	linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox, Kefeng Wang

This patch select HAVE_ARCH_HUGE_VMALLOC to let X86_64 and X86_PAE
support huge vmalloc mappings.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 4 ++--
 arch/x86/Kconfig                                | 1 +
 arch/x86/kernel/module.c                        | 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e3f9fd7ec106..ffce6591ae64 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1639,7 +1639,7 @@
 			precedence over memory_hotplug.memmap_on_memory.
 
 
-	hugevmalloc=	[KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+	hugevmalloc=	[KNL,PPC,ARM64,X86] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
 			Format: { on | off }
 			Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
 
@@ -3424,7 +3424,7 @@
 
 	nohugeiomap	[KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
 
-	nohugevmalloc	[KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
+	nohugevmalloc	[KNL,PPC,ARM64,X86] Disable kernel huge vmalloc mappings.
 
 	nosmt		[KNL,S390] Disable symmetric multithreading (SMT).
 			Equivalent to smt=1.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ebe8fc76949a..f6bf6675bbe7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -157,6 +157,7 @@ config X86
 	select HAVE_ACPI_APEI_NMI		if ACPI
 	select HAVE_ALIGNED_STRUCT_PAGE		if SLUB
 	select HAVE_ARCH_AUDITSYSCALL
+	select HAVE_ARCH_HUGE_VMALLOC		if HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_HUGE_VMAP		if X86_64 || X86_PAE
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 95fa745e310a..6bf5cb7d876a 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -75,8 +75,8 @@ void *module_alloc(unsigned long size)
 
 	p = __vmalloc_node_range(size, MODULE_ALIGN,
 				    MODULES_VADDR + get_module_load_offset(),
-				    MODULES_END, gfp_mask,
-				    PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE,
+				    MODULES_END, gfp_mask, PAGE_KERNEL,
+				    VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP, NUMA_NO_NODE,
 				    __builtin_return_address(0));
 	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
 		vfree(p);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-27 14:59 ` [PATCH v2 3/3] x86: " Kefeng Wang
@ 2021-12-27 15:56   ` Dave Hansen
  2021-12-28 10:26     ` Kefeng Wang
  2022-01-15 10:06   ` Christophe Leroy
  1 sibling, 1 reply; 145+ messages in thread
From: Dave Hansen @ 2021-12-27 15:56 UTC (permalink / raw)
  To: Kefeng Wang, Jonathan Corbet, Andrew Morton, linuxppc-dev,
	linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox

On 12/27/21 6:59 AM, Kefeng Wang wrote:
> This patch select HAVE_ARCH_HUGE_VMALLOC to let X86_64 and X86_PAE
> support huge vmalloc mappings.

In general, this seems interesting and the diff is simple.  But, I don't
see _any_ x86-specific data.  I think the bare minimum here would be a
few kernel compiles and some 'perf stat' data for some TLB events.

> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 95fa745e310a..6bf5cb7d876a 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -75,8 +75,8 @@ void *module_alloc(unsigned long size)
>  
>  	p = __vmalloc_node_range(size, MODULE_ALIGN,
>  				    MODULES_VADDR + get_module_load_offset(),
> -				    MODULES_END, gfp_mask,
> -				    PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE,
> +				    MODULES_END, gfp_mask, PAGE_KERNEL,
> +				    VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>  				    __builtin_return_address(0));
>  	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>  		vfree(p);

To figure out what's going on in this hunk, I had to look at the cover
letter (which I wasn't cc'd on).  That's not great and it means that
somebody who stumbles upon this in the code is going to have a really
hard time figuring out what is going on.  Cover letters don't make it
into git history.

This desperately needs a comment and some changelog material in *this*
patch.

But, even the description from the cover letter is sparse:

> There are some disadvantages about this feature[2], one of the main
> concerns is the possible memory fragmentation/waste in some scenarios,
> also archs must ensure that any arch specific vmalloc allocations that
> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.

That just says that x86 *needs* PAGE_SIZE allocations.  But, what
happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
subsequent permission changes just fragment the 2M mapping?

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (No subject)
  2021-12-27 14:59 ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
@ 2021-12-27 17:35   ` William Kucharski
  2021-12-28  1:36     ` Kefeng Wang
  2022-01-15 10:05   ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Christophe Leroy
  1 sibling, 1 reply; 145+ messages in thread
From: William Kucharski @ 2021-12-27 17:35 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
	linux-kernel, linux-mm, x86, linux-arm-kernel, Nicholas Piggin,
	Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, H. Peter Anvin, Michael Ellerman,
	Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
	Matthew Wilcox

You should also fix the existing typo in the documentation (inline):

> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> arch/arm64/Kconfig                              | 1 +
> arch/arm64/kernel/module.c                      | 5 +++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>            precedence over memory_hotplug.memmap_on_memory.
> 
> 
> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>            Format: { on | off }
>            Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.

"Reguires" should be "Requires." 

> 
> @@ -3424,7 +3424,7 @@
> 
>    nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
> 
> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
> 
>    nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>            Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
>    select HAVE_ARCH_AUDITSYSCALL
>    select HAVE_ARCH_BITREVERSE
>    select HAVE_ARCH_COMPILER_H
> +    select HAVE_ARCH_HUGE_VMALLOC
>    select HAVE_ARCH_HUGE_VMAP
>    select HAVE_ARCH_JUMP_LABEL
>    select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>        module_alloc_end = MODULES_END;
> 
>    p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>                NUMA_NO_NODE, __builtin_return_address(0));
> 
>    if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>         */
>        p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>                module_alloc_base + SZ_2G, GFP_KERNEL,
> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>                __builtin_return_address(0));
> 
>    if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> -- 
> 2.26.2
> 
> 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (No subject)
  2021-12-27 17:35   ` (No subject) William Kucharski
@ 2021-12-28  1:36     ` Kefeng Wang
  0 siblings, 0 replies; 145+ messages in thread
From: Kefeng Wang @ 2021-12-28  1:36 UTC (permalink / raw)
  To: William Kucharski
  Cc: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
	linux-kernel, linux-mm, x86, linux-arm-kernel, Nicholas Piggin,
	Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, H. Peter Anvin, Michael Ellerman,
	Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
	Matthew Wilcox


On 2021/12/28 1:35, William Kucharski wrote:
> You should also fix the existing typo in the documentation (inline):
>
>> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
>> vmalloc mappings.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>> arch/arm64/Kconfig                              | 1 +
>> arch/arm64/kernel/module.c                      | 5 +++--
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 7b2f900fd243..e3f9fd7ec106 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1639,7 +1639,7 @@
>>             precedence over memory_hotplug.memmap_on_memory.
>>
>>
>> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>>             Format: { on | off }
>>             Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
> "Reguires" should be "Requires."
Will fix, thanks.
>
>> @@ -3424,7 +3424,7 @@
>>
>>     nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>>
>> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
>> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>>
>>     nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>>             Equivalent to smt=1.
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3bb0b67292b5..c34bbb4482b0 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -142,6 +142,7 @@ config ARM64
>>     select HAVE_ARCH_AUDITSYSCALL
>>     select HAVE_ARCH_BITREVERSE
>>     select HAVE_ARCH_COMPILER_H
>> +    select HAVE_ARCH_HUGE_VMALLOC
>>     select HAVE_ARCH_HUGE_VMAP
>>     select HAVE_ARCH_JUMP_LABEL
>>     select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 309a27553c87..af7b4cbace2b 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>>         module_alloc_end = MODULES_END;
>>
>>     p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
>> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
>> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>>                 NUMA_NO_NODE, __builtin_return_address(0));
>>
>>     if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>>          */
>>         p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>                 module_alloc_base + SZ_2G, GFP_KERNEL,
>> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
>> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>                 __builtin_return_address(0));
>>
>>     if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>> -- 
>> 2.26.2
>>
>>

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-27 15:56   ` Dave Hansen
@ 2021-12-28 10:26     ` Kefeng Wang
  2021-12-28 16:14       ` Dave Hansen
  2022-01-15 10:11       ` Christophe Leroy
  0 siblings, 2 replies; 145+ messages in thread
From: Kefeng Wang @ 2021-12-28 10:26 UTC (permalink / raw)
  To: Dave Hansen, Jonathan Corbet, Andrew Morton, linuxppc-dev,
	linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox


On 2021/12/27 23:56, Dave Hansen wrote:
> On 12/27/21 6:59 AM, Kefeng Wang wrote:
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let X86_64 and X86_PAE
>> support huge vmalloc mappings.
> In general, this seems interesting and the diff is simple.  But, I don't
> see _any_ x86-specific data.  I think the bare minimum here would be a
> few kernel compiles and some 'perf stat' data for some TLB events.

When the feature supported on ppc,

commit 8abddd968a303db75e4debe77a3df484164f1f33
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Mon May 3 19:17:55 2021 +1000

     powerpc/64s/radix: Enable huge vmalloc mappings

     This reduces TLB misses by nearly 30x on a `git diff` workload on a
     2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due
     to vfs hashes being allocated with 2MB pages.

But the data could be different on different machine/arch.

>> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
>> index 95fa745e310a..6bf5cb7d876a 100644
>> --- a/arch/x86/kernel/module.c
>> +++ b/arch/x86/kernel/module.c
>> @@ -75,8 +75,8 @@ void *module_alloc(unsigned long size)
>>   
>>   	p = __vmalloc_node_range(size, MODULE_ALIGN,
>>   				    MODULES_VADDR + get_module_load_offset(),
>> -				    MODULES_END, gfp_mask,
>> -				    PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE,
>> +				    MODULES_END, gfp_mask, PAGE_KERNEL,
>> +				    VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>   				    __builtin_return_address(0));
>>   	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>>   		vfree(p);
> To figure out what's going on in this hunk, I had to look at the cover
> letter (which I wasn't cc'd on).  That's not great and it means that
> somebody who stumbles upon this in the code is going to have a really
> hard time figuring out what is going on.  Cover letters don't make it
> into git history.
Sorry for that, will add more into arch's patch changelog.
> This desperately needs a comment and some changelog material in *this*
> patch.
>
> But, even the description from the cover letter is sparse:
>
>> There are some disadvantages about this feature[2], one of the main
>> concerns is the possible memory fragmentation/waste in some scenarios,
>> also archs must ensure that any arch specific vmalloc allocations that
>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
> That just says that x86 *needs* PAGE_SIZE allocations.  But, what
> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
> subsequent permission changes just fragment the 2M mapping?
> .

Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.

When module alloc with STRICT_MODULE_RWX on x86, it calls 
__change_page_attr()

from set_memory_ro/rw/nx which will split large page, so there is no 
need to make

module alloc with HUGE_VMALLOC.

>                                   
>
>      
>      



^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-28 10:26     ` Kefeng Wang
@ 2021-12-28 16:14       ` Dave Hansen
  2021-12-29 11:01         ` Kefeng Wang
                           ` (2 more replies)
  2022-01-15 10:11       ` Christophe Leroy
  1 sibling, 3 replies; 145+ messages in thread
From: Dave Hansen @ 2021-12-28 16:14 UTC (permalink / raw)
  To: Kefeng Wang, Jonathan Corbet, Andrew Morton, linuxppc-dev,
	linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox

On 12/28/21 2:26 AM, Kefeng Wang wrote:
>>> There are some disadvantages about this feature[2], one of the main
>>> concerns is the possible memory fragmentation/waste in some scenarios,
>>> also archs must ensure that any arch specific vmalloc allocations that
>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
>> That just says that x86 *needs* PAGE_SIZE allocations.  But, what
>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
>> subsequent permission changes just fragment the 2M mapping?
> 
> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.
> 
> When module alloc with STRICT_MODULE_RWX on x86, it calls
> __change_page_attr()
> 
> from set_memory_ro/rw/nx which will split large page, so there is no
> need to make
> 
> module alloc with HUGE_VMALLOC.

This all sounds very fragile to me.  Every time a new architecture would
get added for huge vmalloc() support, the developer needs to know to go
find that architecture's module_alloc() and add this flag.  They next
guy is going to forget, just like you did.

Considering that this is not a hot path, a weak function would be a nice
choice:

/* vmalloc() flags used for all module allocations. */
unsigned long __weak arch_module_vm_flags()
{
	/*
	 * Modules use a single, large vmalloc().  Different
	 * permissions are applied later and will fragment
	 * huge mappings.  Avoid using huge pages for modules.
	 */
	return VM_NO_HUGE_VMAP;
}

Stick that in some the common module code, next to:

> void * __weak module_alloc(unsigned long size)
> {
>         return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
...

Then, put arch_module_vm_flags() in *all* of the module_alloc()
implementations, including the generic one.  That way (even with a new
architecture) whoever copies-and-pastes their module_alloc()
implementation is likely to get it right.  The next guy who just does a
"select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work.

VM_FLUSH_RESET_PERMS could probably be dealt with in the same way.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-28 16:14       ` Dave Hansen
@ 2021-12-29 11:01         ` Kefeng Wang
  2022-01-15 10:17           ` Christophe Leroy
  2022-01-15 10:15         ` Christophe Leroy
  2022-01-18  2:46         ` Nicholas Piggin
  2 siblings, 1 reply; 145+ messages in thread
From: Kefeng Wang @ 2021-12-29 11:01 UTC (permalink / raw)
  To: Dave Hansen, Jonathan Corbet, Andrew Morton, linuxppc-dev,
	linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Christophe Leroy, Matthew Wilcox


On 2021/12/29 0:14, Dave Hansen wrote:
> On 12/28/21 2:26 AM, Kefeng Wang wrote:
>>>> There are some disadvantages about this feature[2], one of the main
>>>> concerns is the possible memory fragmentation/waste in some scenarios,
>>>> also archs must ensure that any arch specific vmalloc allocations that
>>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
>>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
>>> That just says that x86 *needs* PAGE_SIZE allocations.  But, what
>>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
>>> subsequent permission changes just fragment the 2M mapping?
>> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.
>>
>> When module alloc with STRICT_MODULE_RWX on x86, it calls
>> __change_page_attr()
>>
>> from set_memory_ro/rw/nx which will split large page, so there is no
>> need to make
>>
>> module alloc with HUGE_VMALLOC.
> This all sounds very fragile to me.  Every time a new architecture would
> get added for huge vmalloc() support, the developer needs to know to go
> find that architecture's module_alloc() and add this flag.  They next
> guy is going to forget, just like you did.
>
> Considering that this is not a hot path, a weak function would be a nice
> choice:
>
> /* vmalloc() flags used for all module allocations. */
> unsigned long __weak arch_module_vm_flags()
> {
> 	/*
> 	 * Modules use a single, large vmalloc().  Different
> 	 * permissions are applied later and will fragment
> 	 * huge mappings.  Avoid using huge pages for modules.
> 	 */
> 	return VM_NO_HUGE_VMAP;

For x86, it only fragment, but for arm64, due to apply_to_page_range() in

set_memory_*, without this flag maybe crash. Whatever, we need this

flag for module.

> }
>
> Stick that in some the common module code, next to:
>
>> void * __weak module_alloc(unsigned long size)
>> {
>>          return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
> ...
>
> Then, put arch_module_vm_flags() in *all* of the module_alloc()
> implementations, including the generic one.  That way (even with a new
> architecture) whoever copies-and-pastes their module_alloc()
> implementation is likely to get it right.  The next guy who just does a
> "select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work.

OK, Let me check the VM_FLUSH_RESET_PERMS and try about this way.

Thanks.

>
> VM_FLUSH_RESET_PERMS could probably be dealt with in the same way.
> .

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 2/3] arm64: Support huge vmalloc mappings
  2021-12-27 14:59 ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
  2021-12-27 17:35   ` (No subject) William Kucharski
@ 2022-01-15 10:05   ` Christophe Leroy
  1 sibling, 0 replies; 145+ messages in thread
From: Christophe Leroy @ 2022-01-15 10:05 UTC (permalink / raw)
  To: Kefeng Wang, Jonathan Corbet, Andrew Morton, linuxppc-dev,
	linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Matthew Wilcox



Le 27/12/2021 à 15:59, Kefeng Wang a écrit :
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
>   Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>   arch/arm64/Kconfig                              | 1 +
>   arch/arm64/kernel/module.c                      | 5 +++--
>   3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>   			precedence over memory_hotplug.memmap_on_memory.
>   
>   
> -	hugevmalloc=	[PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +	hugevmalloc=	[KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>   			Format: { on | off }
>   			Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
>   
> @@ -3424,7 +3424,7 @@
>   
>   	nohugeiomap	[KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>   
> -	nohugevmalloc	[PPC] Disable kernel huge vmalloc mappings.
> +	nohugevmalloc	[KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>   
>   	nosmt		[KNL,S390] Disable symmetric multithreading (SMT).
>   			Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
>   	select HAVE_ARCH_AUDITSYSCALL
>   	select HAVE_ARCH_BITREVERSE
>   	select HAVE_ARCH_COMPILER_H
> +	select HAVE_ARCH_HUGE_VMALLOC
>   	select HAVE_ARCH_HUGE_VMAP
>   	select HAVE_ARCH_JUMP_LABEL
>   	select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>   		module_alloc_end = MODULES_END;
>   
>   	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> -				module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> +				module_alloc_end, gfp_mask, PAGE_KERNEL,
> +				VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,

you should add a comment like powerpc (commit 8abddd968a30 
("powerpc/64s/radix: Enable huge vmalloc mappings")) to explain why this 
requires VM_NO_HUGE_VMAP

>   				NUMA_NO_NODE, __builtin_return_address(0));
>   
>   	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>   		 */
>   		p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>   				module_alloc_base + SZ_2G, GFP_KERNEL,
> -				PAGE_KERNEL, 0, NUMA_NO_NODE,
> +				PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,

Same

>   				__builtin_return_address(0));
>   
>   	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-27 14:59 ` [PATCH v2 3/3] x86: " Kefeng Wang
  2021-12-27 15:56   ` Dave Hansen
@ 2022-01-15 10:06   ` Christophe Leroy
  1 sibling, 0 replies; 145+ messages in thread
From: Christophe Leroy @ 2022-01-15 10:06 UTC (permalink / raw)
  To: Kefeng Wang, Jonathan Corbet, Andrew Morton, linuxppc-dev,
	linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Matthew Wilcox



Le 27/12/2021 à 15:59, Kefeng Wang a écrit :
> This patch select HAVE_ARCH_HUGE_VMALLOC to let X86_64 and X86_PAE
> support huge vmalloc mappings.
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
>   Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>   arch/x86/Kconfig                                | 1 +
>   arch/x86/kernel/module.c                        | 4 ++--
>   3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index e3f9fd7ec106..ffce6591ae64 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>   			precedence over memory_hotplug.memmap_on_memory.
>   
>   
> -	hugevmalloc=	[KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +	hugevmalloc=	[KNL,PPC,ARM64,X86] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>   			Format: { on | off }
>   			Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
>   
> @@ -3424,7 +3424,7 @@
>   
>   	nohugeiomap	[KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>   
> -	nohugevmalloc	[KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
> +	nohugevmalloc	[KNL,PPC,ARM64,X86] Disable kernel huge vmalloc mappings.
>   
>   	nosmt		[KNL,S390] Disable symmetric multithreading (SMT).
>   			Equivalent to smt=1.
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index ebe8fc76949a..f6bf6675bbe7 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -157,6 +157,7 @@ config X86
>   	select HAVE_ACPI_APEI_NMI		if ACPI
>   	select HAVE_ALIGNED_STRUCT_PAGE		if SLUB
>   	select HAVE_ARCH_AUDITSYSCALL
> +	select HAVE_ARCH_HUGE_VMALLOC		if HAVE_ARCH_HUGE_VMAP
>   	select HAVE_ARCH_HUGE_VMAP		if X86_64 || X86_PAE
>   	select HAVE_ARCH_JUMP_LABEL
>   	select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 95fa745e310a..6bf5cb7d876a 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -75,8 +75,8 @@ void *module_alloc(unsigned long size)
>   
>   	p = __vmalloc_node_range(size, MODULE_ALIGN,
>   				    MODULES_VADDR + get_module_load_offset(),
> -				    MODULES_END, gfp_mask,
> -				    PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE,
> +				    MODULES_END, gfp_mask, PAGE_KERNEL,
> +				    VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP, NUMA_NO_NODE,

you should add a comment like powerpc (commit 8abddd968a30 
("powerpc/64s/radix: Enable huge vmalloc mappings")) to explain why this 
requires VM_NO_HUGE_VMAP

>   				    __builtin_return_address(0));
>   	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>   		vfree(p);

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86
  2021-12-27 14:59 [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Kefeng Wang
                   ` (2 preceding siblings ...)
  2021-12-27 14:59 ` [PATCH v2 3/3] x86: " Kefeng Wang
@ 2022-01-15 10:07 ` Christophe Leroy
  3 siblings, 0 replies; 145+ messages in thread
From: Christophe Leroy @ 2022-01-15 10:07 UTC (permalink / raw)
  To: Kefeng Wang, Jonathan Corbet, Andrew Morton, linuxppc-dev,
	linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Matthew Wilcox



Le 27/12/2021 à 15:59, Kefeng Wang a écrit :
> Huge vmalloc mappings is supported on PPC[1], but this feature should
> be not only used on PPC, it could be used on arch support HAVE_ARCH_HUGE_VMAP
> and PMD sized vmap mappings. this patchset is to enable this feature
> on arm64/x86.
> 
> There are some disadvantages about this feature[2], one of the main

There are some disadvantage, ok, so are there advantages as well ?

> concerns is the possible memory fragmentation/waste in some scenarios,
> also archs must ensure that any arch specific vmalloc allocations that
> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
> 
> Based on the above considerations, we add the first patch is to let
> user to control huge vmalloc mapping default behavior.  Meanwhile,
> add new kernel parameter hugevmalloc=on/off to enable/disable this
> feature at boot time, nohugevmalloc parameter is still supported.
> 
> The later two patches to enable this feature on arm64/x86, select
> HAVE_ARCH_HUGE_VMALLOC and mark VM_NO_HUGE_VMAP in arch's module_alloc().
> 
> This patchset based on next-20211224.
> 
> v2:
> - Default y for HUGE_VMALLOC_DEFAULT_ENABLED, not only select it on PPC
> - Fix copy/type error
> - Mark VM_NO_HUGE_VMAP in module_alloc() on arm64/x86
> 
> [1] https://lore.kernel.org/linux-mm/20210317062402.533919-1-npiggin@gmail.com/
> [2] https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/
> 
> Kefeng Wang (3):
>    mm: vmalloc: Let user to control huge vmalloc default behavior
>    arm64: Support huge vmalloc mappings
>    x86: Support huge vmalloc mappings
> 
>   .../admin-guide/kernel-parameters.txt          | 14 +++++++++++++-
>   arch/arm64/Kconfig                             |  1 +
>   arch/arm64/kernel/module.c                     |  5 +++--
>   arch/x86/Kconfig                               |  1 +
>   arch/x86/kernel/module.c                       |  4 ++--
>   mm/Kconfig                                     |  8 ++++++++
>   mm/vmalloc.c                                   | 18 +++++++++++++++++-
>   7 files changed, 45 insertions(+), 6 deletions(-)
> 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-28 10:26     ` Kefeng Wang
  2021-12-28 16:14       ` Dave Hansen
@ 2022-01-15 10:11       ` Christophe Leroy
  1 sibling, 0 replies; 145+ messages in thread
From: Christophe Leroy @ 2022-01-15 10:11 UTC (permalink / raw)
  To: Kefeng Wang, Dave Hansen, Jonathan Corbet, Andrew Morton,
	linuxppc-dev, linux-doc, linux-kernel, linux-mm, x86,
	linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Matthew Wilcox



Le 28/12/2021 à 11:26, Kefeng Wang a écrit :
> 
> On 2021/12/27 23:56, Dave Hansen wrote:
>> On 12/27/21 6:59 AM, Kefeng Wang wrote:
>>> This patch select HAVE_ARCH_HUGE_VMALLOC to let X86_64 and X86_PAE
>>> support huge vmalloc mappings.
>> In general, this seems interesting and the diff is simple.  But, I don't
>> see _any_ x86-specific data.  I think the bare minimum here would be a
>> few kernel compiles and some 'perf stat' data for some TLB events.
> 
> When the feature supported on ppc,
> 
> commit 8abddd968a303db75e4debe77a3df484164f1f33
> Author: Nicholas Piggin <npiggin@gmail.com>
> Date:   Mon May 3 19:17:55 2021 +1000
> 
>      powerpc/64s/radix: Enable huge vmalloc mappings
> 
>      This reduces TLB misses by nearly 30x on a `git diff` workload on a
>      2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due
>      to vfs hashes being allocated with 2MB pages.
> 
> But the data could be different on different machine/arch.
> 
>>> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
>>> index 95fa745e310a..6bf5cb7d876a 100644
>>> --- a/arch/x86/kernel/module.c
>>> +++ b/arch/x86/kernel/module.c
>>> @@ -75,8 +75,8 @@ void *module_alloc(unsigned long size)
>>>       p = __vmalloc_node_range(size, MODULE_ALIGN,
>>>                       MODULES_VADDR + get_module_load_offset(),
>>> -                    MODULES_END, gfp_mask,
>>> -                    PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE,
>>> +                    MODULES_END, gfp_mask, PAGE_KERNEL,
>>> +                    VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>>                       __builtin_return_address(0));
>>>       if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>>>           vfree(p);
>> To figure out what's going on in this hunk, I had to look at the cover
>> letter (which I wasn't cc'd on).  That's not great and it means that
>> somebody who stumbles upon this in the code is going to have a really
>> hard time figuring out what is going on.  Cover letters don't make it
>> into git history.
> Sorry for that, will add more into arch's patch changelog.
>> This desperately needs a comment and some changelog material in *this*
>> patch.
>>
>> But, even the description from the cover letter is sparse:
>>
>>> There are some disadvantages about this feature[2], one of the main
>>> concerns is the possible memory fragmentation/waste in some scenarios,
>>> also archs must ensure that any arch specific vmalloc allocations that
>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
>> That just says that x86 *needs* PAGE_SIZE allocations.  But, what
>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
>> subsequent permission changes just fragment the 2M mapping?
>> .
> 
> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.
> 
> When module alloc with STRICT_MODULE_RWX on x86, it calls 
> __change_page_attr()
> 
> from set_memory_ro/rw/nx which will split large page, so there is no 
> need to make
> 
> module alloc with HUGE_VMALLOC.
> 

Maybe there is no need to perform the module alloc with HUGE_VMALLOC, 
but it least it would still work if you do so.

Powerpc did add VM_NO_HUGE_VMAP temporarily and for some reason which is 
  explained in a comment.

If x86 already has the necessary logic to handle it, why add 
VM_NO_HUGE_VMAP ?

Christophe

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-28 16:14       ` Dave Hansen
  2021-12-29 11:01         ` Kefeng Wang
@ 2022-01-15 10:15         ` Christophe Leroy
  2022-01-18  2:46         ` Nicholas Piggin
  2 siblings, 0 replies; 145+ messages in thread
From: Christophe Leroy @ 2022-01-15 10:15 UTC (permalink / raw)
  To: Dave Hansen, Kefeng Wang, Jonathan Corbet, Andrew Morton,
	linuxppc-dev, linux-doc, linux-kernel, linux-mm, x86,
	linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Matthew Wilcox



Le 28/12/2021 à 17:14, Dave Hansen a écrit :
> On 12/28/21 2:26 AM, Kefeng Wang wrote:
>>>> There are some disadvantages about this feature[2], one of the main
>>>> concerns is the possible memory fragmentation/waste in some scenarios,
>>>> also archs must ensure that any arch specific vmalloc allocations that
>>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
>>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
>>> That just says that x86 *needs* PAGE_SIZE allocations.  But, what
>>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
>>> subsequent permission changes just fragment the 2M mapping?
>>
>> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.
>>
>> When module alloc with STRICT_MODULE_RWX on x86, it calls
>> __change_page_attr()
>>
>> from set_memory_ro/rw/nx which will split large page, so there is no
>> need to make
>>
>> module alloc with HUGE_VMALLOC.
> 
> This all sounds very fragile to me.  Every time a new architecture would
> get added for huge vmalloc() support, the developer needs to know to go
> find that architecture's module_alloc() and add this flag.  They next
> guy is going to forget, just like you did.

That's not correct from my point of view.

When powerpc added that, a clear comment explains why:


+	/*
+	 * Don't do huge page allocations for modules yet until more testing
+	 * is done. STRICT_MODULE_RWX may require extra work to support this
+	 * too.
+	 */

So as you can see, this is something specific to powerpc and temporary.

> 
> Considering that this is not a hot path, a weak function would be a nice
> choice:
> 
> /* vmalloc() flags used for all module allocations. */
> unsigned long __weak arch_module_vm_flags()
> {
> 	/*
> 	 * Modules use a single, large vmalloc().  Different
> 	 * permissions are applied later and will fragment
> 	 * huge mappings.  Avoid using huge pages for modules.
> 	 */

Why ? Not everybody use STRICT_MODULES_RWX.
Even if you do so, you can still benefit from huge pages for modules.

Why make what was initially a temporary precaution for powerpc become a 
definitive default limitation for all ?

> 	return VM_NO_HUGE_VMAP;
> }
> 
> Stick that in some the common module code, next to:
> 
>> void * __weak module_alloc(unsigned long size)
>> {
>>          return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
> ...
> 
> Then, put arch_module_vm_flags() in *all* of the module_alloc()
> implementations, including the generic one.  That way (even with a new
> architecture) whoever copies-and-pastes their module_alloc()
> implementation is likely to get it right.  The next guy who just does a
> "select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work.
> 
> VM_FLUSH_RESET_PERMS could probably be dealt with in the same way.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-29 11:01         ` Kefeng Wang
@ 2022-01-15 10:17           ` Christophe Leroy
  0 siblings, 0 replies; 145+ messages in thread
From: Christophe Leroy @ 2022-01-15 10:17 UTC (permalink / raw)
  To: Kefeng Wang, Dave Hansen, Jonathan Corbet, Andrew Morton,
	linuxppc-dev, linux-doc, linux-kernel, linux-mm, x86,
	linux-arm-kernel
  Cc: Nicholas Piggin, Catalin Marinas, Will Deacon, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Matthew Wilcox



Le 29/12/2021 à 12:01, Kefeng Wang a écrit :
> 
> On 2021/12/29 0:14, Dave Hansen wrote:
>> On 12/28/21 2:26 AM, Kefeng Wang wrote:
>>>>> There are some disadvantages about this feature[2], one of the main
>>>>> concerns is the possible memory fragmentation/waste in some scenarios,
>>>>> also archs must ensure that any arch specific vmalloc allocations that
>>>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
>>>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
>>>> That just says that x86 *needs* PAGE_SIZE allocations.  But, what
>>>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
>>>> subsequent permission changes just fragment the 2M mapping?
>>> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.
>>>
>>> When module alloc with STRICT_MODULE_RWX on x86, it calls
>>> __change_page_attr()
>>>
>>> from set_memory_ro/rw/nx which will split large page, so there is no
>>> need to make
>>>
>>> module alloc with HUGE_VMALLOC.
>> This all sounds very fragile to me.  Every time a new architecture would
>> get added for huge vmalloc() support, the developer needs to know to go
>> find that architecture's module_alloc() and add this flag.  They next
>> guy is going to forget, just like you did.
>>
>> Considering that this is not a hot path, a weak function would be a nice
>> choice:
>>
>> /* vmalloc() flags used for all module allocations. */
>> unsigned long __weak arch_module_vm_flags()
>> {
>>     /*
>>      * Modules use a single, large vmalloc().  Different
>>      * permissions are applied later and will fragment
>>      * huge mappings.  Avoid using huge pages for modules.
>>      */
>>     return VM_NO_HUGE_VMAP;
> 
> For x86, it only fragment, but for arm64, due to apply_to_page_range() in
> 
> set_memory_*, without this flag maybe crash. Whatever, we need this
> 
> flag for module.

I see no reason to have this flag by default.

Only ARM should have it if necessary, with a comment explaining why just 
like powerpc.

And maybe the flag should be there only when STRICT_MODULE_RWX is selected.

> 
>> }
>>
>> Stick that in some the common module code, next to:
>>
>>> void * __weak module_alloc(unsigned long size)
>>> {
>>>          return __vmalloc_node_range(size, 1, VMALLOC_START, 
>>> VMALLOC_END,
>> ...
>>
>> Then, put arch_module_vm_flags() in *all* of the module_alloc()
>> implementations, including the generic one.  That way (even with a new
>> architecture) whoever copies-and-pastes their module_alloc()
>> implementation is likely to get it right.  The next guy who just does a
>> "select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work.
> 
> OK, Let me check the VM_FLUSH_RESET_PERMS and try about this way.
> 
> Thanks.
> 
>>
>> VM_FLUSH_RESET_PERMS could probably be dealt with in the same way.
>> .

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2021-12-28 16:14       ` Dave Hansen
  2021-12-29 11:01         ` Kefeng Wang
  2022-01-15 10:15         ` Christophe Leroy
@ 2022-01-18  2:46         ` Nicholas Piggin
  2022-01-18 17:28           ` Dave Hansen
  2 siblings, 1 reply; 145+ messages in thread
From: Nicholas Piggin @ 2022-01-18  2:46 UTC (permalink / raw)
  To: Andrew Morton, Jonathan Corbet, Dave Hansen, linux-arm-kernel,
	linux-doc, linux-kernel, linux-mm, linuxppc-dev, Kefeng Wang,
	x86
  Cc: Benjamin Herrenschmidt, Borislav Petkov, Catalin Marinas,
	Christophe Leroy, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Michael Ellerman, Paul Mackerras, Thomas Gleixner, Will Deacon,
	Matthew Wilcox

Excerpts from Dave Hansen's message of December 29, 2021 2:14 am:
> On 12/28/21 2:26 AM, Kefeng Wang wrote:
>>>> There are some disadvantages about this feature[2], one of the main
>>>> concerns is the possible memory fragmentation/waste in some scenarios,
>>>> also archs must ensure that any arch specific vmalloc allocations that
>>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
>>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
>>> That just says that x86 *needs* PAGE_SIZE allocations.  But, what
>>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?  Will the
>>> subsequent permission changes just fragment the 2M mapping?
>> 
>> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping.
>> 
>> When module alloc with STRICT_MODULE_RWX on x86, it calls
>> __change_page_attr()
>> 
>> from set_memory_ro/rw/nx which will split large page, so there is no
>> need to make
>> 
>> module alloc with HUGE_VMALLOC.
> 
> This all sounds very fragile to me.  Every time a new architecture would
> get added for huge vmalloc() support, the developer needs to know to go
> find that architecture's module_alloc() and add this flag.

This is documented in the Kconfig.

 #
 #  Archs that select this would be capable of PMD-sized vmaps (i.e.,
 #  arch_vmap_pmd_supported() returns true), and they must make no assumptions
 #  that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
 #  can be used to prohibit arch-specific allocations from using hugepages to
 #  help with this (e.g., modules may require it).
 #
 config HAVE_ARCH_HUGE_VMALLOC
         depends on HAVE_ARCH_HUGE_VMAP
         bool

Is it really fair to say it's *very* fragile? Surely it's reasonable to 
read the (not very long) documentation ad understand the consequences for
the arch code before enabling it.

> They next
> guy is going to forget, just like you did.

The miss here could just be a simple oversight or thinko, and caught by 
review, as happens to a lot of things.

> 
> Considering that this is not a hot path, a weak function would be a nice
> choice:
> 
> /* vmalloc() flags used for all module allocations. */
> unsigned long __weak arch_module_vm_flags()
> {
> 	/*
> 	 * Modules use a single, large vmalloc().  Different
> 	 * permissions are applied later and will fragment
> 	 * huge mappings.  Avoid using huge pages for modules.
> 	 */
> 	return VM_NO_HUGE_VMAP;
> }
> 
> Stick that in some the common module code, next to:

Then they have to think about it even less, so I don't know if that's an 
improvement. I don't know what else an arch might be doing with these
allocations, at least modules will blow up pretty quickly, who knows 
what other rare code relies on 4k vmalloc mappings?

The huge vmalloc option is not supposed to be easy to enable. This is 
the same problem Andy was having with the TLB shootdown patches, he 
didn't read the documentation and thought it was supposed to be a 
trivial thing anybody could enable without thinking about it, and was
dutifully pointing out the the nasty "bugs" the feature has in it if
x86 were to enable it improperly.

Thanks,
Nick

> 
>> void * __weak module_alloc(unsigned long size)
>> {
>>         return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
> ...
> 
> Then, put arch_module_vm_flags() in *all* of the module_alloc()
> implementations, including the generic one.  That way (even with a new
> architecture) whoever copies-and-pastes their module_alloc()
> implementation is likely to get it right.  The next guy who just does a
> "select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work.
> 
> VM_FLUSH_RESET_PERMS could probably be dealt with in the same way.
> 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
  2021-12-27 14:59 ` [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
@ 2022-01-18  2:52   ` Nicholas Piggin
  2022-01-19 12:57     ` Kefeng Wang
  0 siblings, 1 reply; 145+ messages in thread
From: Nicholas Piggin @ 2022-01-18  2:52 UTC (permalink / raw)
  To: Andrew Morton, Jonathan Corbet, linux-arm-kernel, linux-doc,
	linux-kernel, linux-mm, linuxppc-dev, Kefeng Wang, x86
  Cc: Benjamin
	 Herrenschmidt, Borislav Petkov, Catalin Marinas,
	Christophe Leroy, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Michael Ellerman, Paul Mackerras, Thomas Gleixner, Will Deacon,
	Matthew Wilcox

Excerpts from Kefeng Wang's message of December 28, 2021 12:59 am:
> Introduce HUGE_VMALLOC_DEFAULT_ENABLED and make it default y, this
> let user to choose whether or not enable huge vmalloc mappings by
> default.
> 
> Meanwhile, add new hugevmalloc=on/off parameter to enable or disable
> this feature at boot time, nohugevmalloc is still supported and
> equivalent to hugevmalloc=off.

Runtime options are bad enough, Kconfig and boot options are even worse.

The 'nohugevmalloc' option mirrors 'nohugeiomap' and is not expected to
ever be understood by an administrator unless a kernel developer is 
working with them to hunt down a regression.

IMO there should be no new options. You could switch it off for 
CONFIG_BASE_SMALL perhaps, and otherwise just try to work on heuristics
first. Bring in new options once it's proven they're needed.

Aside from that, thanks for working on these ports, great work.

Thanks,
Nick

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2022-01-18  2:46         ` Nicholas Piggin
@ 2022-01-18 17:28           ` Dave Hansen
  2022-01-19  4:17             ` Nicholas Piggin
  0 siblings, 1 reply; 145+ messages in thread
From: Dave Hansen @ 2022-01-18 17:28 UTC (permalink / raw)
  To: Nicholas Piggin, Andrew Morton, Jonathan Corbet,
	linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
	linuxppc-dev, Kefeng Wang, x86
  Cc: Benjamin Herrenschmidt, Borislav Petkov, Catalin Marinas,
	Christophe Leroy, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Michael Ellerman, Paul Mackerras, Thomas Gleixner, Will Deacon,
	Matthew Wilcox

On 1/17/22 6:46 PM, Nicholas Piggin wrote:
>> This all sounds very fragile to me.  Every time a new architecture would
>> get added for huge vmalloc() support, the developer needs to know to go
>> find that architecture's module_alloc() and add this flag.
> This is documented in the Kconfig.
> 
>  #
>  #  Archs that select this would be capable of PMD-sized vmaps (i.e.,
>  #  arch_vmap_pmd_supported() returns true), and they must make no assumptions
>  #  that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
>  #  can be used to prohibit arch-specific allocations from using hugepages to
>  #  help with this (e.g., modules may require it).
>  #
>  config HAVE_ARCH_HUGE_VMALLOC
>          depends on HAVE_ARCH_HUGE_VMAP
>          bool
> 
> Is it really fair to say it's *very* fragile? Surely it's reasonable to 
> read the (not very long) documentation ad understand the consequences for
> the arch code before enabling it.

Very fragile or not, I think folks are likely to get it wrong.  It would
be nice to have it default *everyone* to safe and slow and make *sure*
they go look at the architecture modules code itself before enabling
this for modules.

Just from that Kconfig text, I don't think I'd know off the top of my
head what do do for x86, or what code I needed to go touch.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2022-01-18 17:28           ` Dave Hansen
@ 2022-01-19  4:17             ` Nicholas Piggin
  2022-01-19 13:32               ` Kefeng Wang
  0 siblings, 1 reply; 145+ messages in thread
From: Nicholas Piggin @ 2022-01-19  4:17 UTC (permalink / raw)
  To: Andrew Morton, Jonathan Corbet, Dave Hansen, linux-arm-kernel,
	linux-doc, linux-kernel, linux-mm, linuxppc-dev, Kefeng Wang,
	x86
  Cc: Benjamin Herrenschmidt, Borislav Petkov, Catalin Marinas,
	Christophe Leroy, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Michael Ellerman, Paul Mackerras, Thomas Gleixner, Will Deacon,
	Matthew Wilcox

Excerpts from Dave Hansen's message of January 19, 2022 3:28 am:
> On 1/17/22 6:46 PM, Nicholas Piggin wrote:
>>> This all sounds very fragile to me.  Every time a new architecture would
>>> get added for huge vmalloc() support, the developer needs to know to go
>>> find that architecture's module_alloc() and add this flag.
>> This is documented in the Kconfig.
>> 
>>  #
>>  #  Archs that select this would be capable of PMD-sized vmaps (i.e.,
>>  #  arch_vmap_pmd_supported() returns true), and they must make no assumptions
>>  #  that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
>>  #  can be used to prohibit arch-specific allocations from using hugepages to
>>  #  help with this (e.g., modules may require it).
>>  #
>>  config HAVE_ARCH_HUGE_VMALLOC
>>          depends on HAVE_ARCH_HUGE_VMAP
>>          bool
>> 
>> Is it really fair to say it's *very* fragile? Surely it's reasonable to 
>> read the (not very long) documentation ad understand the consequences for
>> the arch code before enabling it.
> 
> Very fragile or not, I think folks are likely to get it wrong.  It would
> be nice to have it default *everyone* to safe and slow and make *sure*

It's not safe to enable though. That's the problem. If it was just 
modules then you'd have a point but it could be anything.

> they go look at the architecture modules code itself before enabling
> this for modules.

This is required not just for modules for the whole arch code, it
has to be looked at and decided this will work.

> Just from that Kconfig text, I don't think I'd know off the top of my
> head what do do for x86, or what code I needed to go touch.

You have to make sure arch/x86 makes no assumptions that vmalloc memory
is backed by PAGE_SIZE ptes. If you can't do that then you shouldn't 
enable the option. The option can not explain it any more because any
arch could do anything with its mappings. The module code is an example,
not the recipe.

Thanks,
Nick

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
  2022-01-18  2:52   ` Nicholas Piggin
@ 2022-01-19 12:57     ` Kefeng Wang
  2022-01-19 13:22       ` Matthew Wilcox
  0 siblings, 1 reply; 145+ messages in thread
From: Kefeng Wang @ 2022-01-19 12:57 UTC (permalink / raw)
  To: Nicholas Piggin, Andrew Morton, Jonathan Corbet,
	linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
	linuxppc-dev, x86
  Cc: Benjamin Herrenschmidt, Borislav Petkov, Catalin Marinas,
	Christophe Leroy, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Michael Ellerman, Paul Mackerras, Thomas Gleixner, Will Deacon,
	Matthew Wilcox


On 2022/1/18 10:52, Nicholas Piggin wrote:
> Excerpts from Kefeng Wang's message of December 28, 2021 12:59 am:
>> Introduce HUGE_VMALLOC_DEFAULT_ENABLED and make it default y, this
>> let user to choose whether or not enable huge vmalloc mappings by
>> default.
>>
>> Meanwhile, add new hugevmalloc=on/off parameter to enable or disable
>> this feature at boot time, nohugevmalloc is still supported and
>> equivalent to hugevmalloc=off.
> Runtime options are bad enough, Kconfig and boot options are even worse.

nohugevmalloc is like blacklists, on the other hand, Add a 
HUGE_VMALLOC_DEFAULT_ENABLED

to close hugevmalloc default and enable it only via hugevmalloc=on is 
whiteList.


Only parts of our products wants this feature,  we add some interfaces 
which only

alloc hugevmalloc for them, eg, 
vmap_hugepage/vmalloc_hugepage/remap_vmalloc_hugepage_range..

for our products, but it's not the choice of most products, also add 
nohugevmalloc

for most products is expensive, so this is the reason for adding the patch.

more config/cmdline are more flexible for test/products,

>
> The 'nohugevmalloc' option mirrors 'nohugeiomap' and is not expected to
> ever be understood by an administrator unless a kernel developer is
> working with them to hunt down a regression.
>
> IMO there should be no new options. You could switch it off for
> CONFIG_BASE_SMALL perhaps, and otherwise just try to work on heuristics
> first. Bring in new options once it's proven they're needed.

but yes, this patch is optional, could others give some more comments 
about this way?

Thanks.

> Aside from that, thanks for working on these ports, great work.
>
> Thanks,
> Nick
> .

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
  2022-01-19 12:57     ` Kefeng Wang
@ 2022-01-19 13:22       ` Matthew Wilcox
  2022-01-19 13:44         ` Kefeng Wang
  0 siblings, 1 reply; 145+ messages in thread
From: Matthew Wilcox @ 2022-01-19 13:22 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: Nicholas Piggin, Andrew Morton, Jonathan Corbet,
	linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
	linuxppc-dev, x86, Benjamin Herrenschmidt, Borislav Petkov,
	Catalin Marinas, Christophe Leroy, Dave Hansen, H. Peter Anvin,
	Ingo Molnar, Michael Ellerman, Paul Mackerras, Thomas Gleixner,
	Will Deacon

On Wed, Jan 19, 2022 at 08:57:58PM +0800, Kefeng Wang wrote:
> Only parts of our products wants this feature,  we add some interfaces which
> only
> 
> alloc hugevmalloc for them, eg,
> vmap_hugepage/vmalloc_hugepage/remap_vmalloc_hugepage_range..
> 
> for our products, but it's not the choice of most products, also add
> nohugevmalloc
> 
> for most products is expensive, so this is the reason for adding the patch.
> 
> more config/cmdline are more flexible for test/products,

But why do only some products want it?  What goes wrong if all products
enable it?  Features should be auto-tuning, not relying on admins to
understand them.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
  2022-01-19  4:17             ` Nicholas Piggin
@ 2022-01-19 13:32               ` Kefeng Wang
  0 siblings, 0 replies; 145+ messages in thread
From: Kefeng Wang @ 2022-01-19 13:32 UTC (permalink / raw)
  To: Nicholas Piggin, Andrew Morton, Jonathan Corbet, Dave Hansen,
	linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
	linuxppc-dev, x86
  Cc: Benjamin Herrenschmidt, Borislav Petkov, Catalin Marinas,
	Christophe Leroy, Dave Hansen, H. Peter Anvin, Ingo Molnar,
	Michael Ellerman, Paul Mackerras, Thomas Gleixner, Will Deacon,
	Matthew Wilcox


On 2022/1/19 12:17, Nicholas Piggin wrote:
> Excerpts from Dave Hansen's message of January 19, 2022 3:28 am:
>> On 1/17/22 6:46 PM, Nicholas Piggin wrote:
>>>> This all sounds very fragile to me.  Every time a new architecture would
>>>> get added for huge vmalloc() support, the developer needs to know to go
>>>> find that architecture's module_alloc() and add this flag.
>>> This is documented in the Kconfig.
>>>
>>>   #
>>>   #  Archs that select this would be capable of PMD-sized vmaps (i.e.,
>>>   #  arch_vmap_pmd_supported() returns true), and they must make no assumptions
>>>   #  that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
>>>   #  can be used to prohibit arch-specific allocations from using hugepages to
>>>   #  help with this (e.g., modules may require it).
>>>   #
>>>   config HAVE_ARCH_HUGE_VMALLOC
>>>           depends on HAVE_ARCH_HUGE_VMAP
>>>           bool
>>>
>>> Is it really fair to say it's *very* fragile? Surely it's reasonable to
>>> read the (not very long) documentation ad understand the consequences for
>>> the arch code before enabling it.
>> Very fragile or not, I think folks are likely to get it wrong.  It would
>> be nice to have it default *everyone* to safe and slow and make *sure*
> It's not safe to enable though. That's the problem. If it was just
> modules then you'd have a point but it could be anything.
>
>> they go look at the architecture modules code itself before enabling
>> this for modules.
> This is required not just for modules for the whole arch code, it
> has to be looked at and decided this will work.
>
>> Just from that Kconfig text, I don't think I'd know off the top of my
>> head what do do for x86, or what code I needed to go touch.
> You have to make sure arch/x86 makes no assumptions that vmalloc memory
> is backed by PAGE_SIZE ptes. If you can't do that then you shouldn't
> enable the option. The option can not explain it any more because any
> arch could do anything with its mappings. The module code is an example,
> not the recipe.

Hi Nick, Dave and Christophe,thanks for your review,  a little 
confused,   I think,

1) for ppc/arm64 module_alloc(),  it must set VM_NO_HUGE_VMAP because the

arch's set_memory_* funcitons can only support PAGE_SIZE mapping, due to the

limit of apply_to_page_range().

2) but for x86's module_alloc(), add VM_NO_HUGE_VMAP is to avoid 
fragmentation,

x86's __change_page_attr functions will split the huge mapping. this 
flags is not a must.


and the behavior above occurred when STRICT_MODULE_RWX enabled, so

1) add a unified function to set vm flags(suggested by Dave ) or

2) add vm flags with some comments to per-arch's module_alloc()

are both acceptable, for the way of unified function ,  we could make 
this a default recipe

with STRICT_MODULE_RWX, also make two more vm flags into it, eg,

+unsigned long module_alloc_vm_flags(bool need_flush_reset_perms)
+{
+       unsigned long vm_flags = VM_DEFER_KMEMLEAK;
+
+       if (need_flush_reset_perms)
+               vm_flags |= VM_FLUSH_RESET_PERMS;
+       /*
+        * Modules use a single, large vmalloc(). Different permissions
+        * are applied later and will fragment huge mappings or even
+        * fails in set_memory_* on some architectures. Avoid using
+        * huge pages for modules.
+        */
+       if (IS_ENABLED(CONFIG_STRICT_MODULE_RWX))
+               vm_flags |= VM_NO_HUGE_VMAP;
+
+       return vm_flags;
+}

then called each arch's module_alloc().

Any suggestion, many thanks.


>
> Thanks,
> Nick
> .

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
  2022-01-19 13:22       ` Matthew Wilcox
@ 2022-01-19 13:44         ` Kefeng Wang
  2022-01-19 13:48           ` Matthew Wilcox
  0 siblings, 1 reply; 145+ messages in thread
From: Kefeng Wang @ 2022-01-19 13:44 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Nicholas Piggin, Andrew Morton, Jonathan Corbet,
	linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
	linuxppc-dev, x86, Benjamin Herrenschmidt, Borislav Petkov,
	Catalin Marinas, Christophe Leroy, Dave Hansen, H. Peter Anvin,
	Ingo Molnar, Michael Ellerman, Paul Mackerras, Thomas Gleixner,
	Will Deacon


On 2022/1/19 21:22, Matthew Wilcox wrote:
> On Wed, Jan 19, 2022 at 08:57:58PM +0800, Kefeng Wang wrote:
>> Only parts of our products wants this feature,  we add some interfaces which
>> only
>>
>> alloc hugevmalloc for them, eg,
>> vmap_hugepage/vmalloc_hugepage/remap_vmalloc_hugepage_range..
>>
>> for our products, but it's not the choice of most products, also add
>> nohugevmalloc
>>
>> for most products is expensive, so this is the reason for adding the patch.
>>
>> more config/cmdline are more flexible for test/products,
> But why do only some products want it?  What goes wrong if all products
> enable it?  Features should be auto-tuning, not relying on admins to
> understand them.

Because this feature will use more memory for vmalloc/vmap, that's why 
we add some explicit
interfaces as said above in our kernel to control the user.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
  2022-01-19 13:44         ` Kefeng Wang
@ 2022-01-19 13:48           ` Matthew Wilcox
  0 siblings, 0 replies; 145+ messages in thread
From: Matthew Wilcox @ 2022-01-19 13:48 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: Nicholas Piggin, Andrew Morton, Jonathan Corbet,
	linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
	linuxppc-dev, x86, Benjamin Herrenschmidt, Borislav Petkov,
	Catalin Marinas, Christophe Leroy, Dave Hansen, H. Peter Anvin,
	Ingo Molnar, Michael Ellerman, Paul Mackerras, Thomas Gleixner,
	Will Deacon

On Wed, Jan 19, 2022 at 09:44:20PM +0800, Kefeng Wang wrote:
> 
> On 2022/1/19 21:22, Matthew Wilcox wrote:
> > On Wed, Jan 19, 2022 at 08:57:58PM +0800, Kefeng Wang wrote:
> > > Only parts of our products wants this feature,  we add some interfaces which
> > > only
> > > 
> > > alloc hugevmalloc for them, eg,
> > > vmap_hugepage/vmalloc_hugepage/remap_vmalloc_hugepage_range..
> > > 
> > > for our products, but it's not the choice of most products, also add
> > > nohugevmalloc
> > > 
> > > for most products is expensive, so this is the reason for adding the patch.
> > > 
> > > more config/cmdline are more flexible for test/products,
> > But why do only some products want it?  What goes wrong if all products
> > enable it?  Features should be auto-tuning, not relying on admins to
> > understand them.
> 
> Because this feature will use more memory for vmalloc/vmap, that's why we
> add some explicit
> interfaces as said above in our kernel to control the user.

Have you validated that?  What sort of performance penalty do you see?

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (No Subject)
@ 2024-01-31  3:37 John Moon
  0 siblings, 0 replies; 145+ messages in thread
From: John Moon @ 2024-01-31  3:37 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel; +Cc: John Moon, Trilok Soni, Elliot Berman

Date: Tue, 30 Jan 2024 18:57:45 -0800
Subject: [PATCH] mailmap: switch email address for John Moon

Add current email address as QUIC email is no longer active.

Signed-off-by: John Moon <john@jmoon.dev>
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index 04998f7bda81..8ae00bd3708a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -289,6 +289,7 @@ Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
 John Crispin <john@phrozen.org> <blogic@openwrt.org>
 John Fastabend <john.fastabend@gmail.com> <john.r.fastabend@intel.com>
 John Keeping <john@keeping.me.uk> <john@metanate.com>
+John Moon <john@jmoon.dev> <quic_johmoo@quicinc.com>
 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
 John Stultz <johnstul@us.ibm.com>
 <jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 145+ messages in thread

* Re: (No Subject)
  2023-08-31  4:52 youngbludproductions
@ 2023-08-31  5:11 ` youngbludproductions
  0 siblings, 0 replies; 145+ messages in thread
From: youngbludproductions @ 2023-08-31  5:11 UTC (permalink / raw)
  To: linux-kernel

[Intro]
Desert you
Ooh-ooh-ooh-ooh
Hurt you

[Verse 1]
We're no strangers to love
You know the rules and so do I (Do I)
A full commitment's what I'm thinking of
You wouldn't get this from any other guy

[Pre-Chorus]
I just wanna tell you how I'm feeling
Gotta make you understand

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

[Verse 2]
We've known each other for so long
Your heart's been aching, but you're too shy to say it (To say it)
Inside, we both know what's been going on (Going on)
We know the game, and we're gonna play it
See Rick Astley Live
Get tickets as low as $53
[Pre-Chorus]
And if you ask me how I'm feeling
Don't tell me you're too blind to see

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

[Post-Chorus]
Ooh (Give you up)
Ooh-ooh (Give you up)
Ooh-ooh
Never gonna give, never gonna give (Give you up)
Ooh-ooh
Never gonna give, never gonna give (Give you up)
[Bridge]
We've known each other for so long
Your heart's been aching, but you're too shy to say it (To say it)
Inside, we both know what's been going on (Going on)
We know the game, and we're gonna play it

[Pre-Chorus]
I just wanna tell you how I'm feeling
Gotta make you understand

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (No Subject)
@ 2023-08-31  4:52 youngbludproductions
  2023-08-31  5:11 ` youngbludproductions
  0 siblings, 1 reply; 145+ messages in thread
From: youngbludproductions @ 2023-08-31  4:52 UTC (permalink / raw)
  To: linux-kernel

hi guys who wants to hear a good little story i made on the toilet

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [no subject]
@ 2023-05-13  8:12 Beatrice Benson
  0 siblings, 0 replies; 145+ messages in thread
From: Beatrice Benson @ 2023-05-13  8:12 UTC (permalink / raw)
  To: linux-kernel

Welcome to Financial Source Program.

Types of loan: business, personal, refinancing, farm, mortgage, self employed, debt consolidation, secured and unsecured, etc.

-No pre-payment penalty.
-Rate starting at: 2.08%. 
-Flexible repayment period.

For further info and how to apply, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (No Subject)
  2021-06-22 16:20 (No Subject) Yassine Oudjana
@ 2021-07-14 18:03 ` Rob Herring
  0 siblings, 0 replies; 145+ messages in thread
From: Rob Herring @ 2021-07-14 18:03 UTC (permalink / raw)
  To: Yassine Oudjana
  Cc: Stanimir Varbanov, devicetree, Andy Gross, Bjorn Andersson,
	Mauro Carvalho Chehab, linux-arm-msm, linux-media, linux-kernel,
	~postmarketos/upstreaming

On Tue, Jun 22, 2021 at 04:20:24PM +0000, Yassine Oudjana wrote:
> Date: Tue, 22 Jun 2021 20:08:25 +0400
> Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name
> 
> Support for parsing the firmware-name property was added a while ago [1],
> but the dt-bindings were never updated with the new property. This patch
> adds it to all venus dt-bindings.
> 
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> 
> [1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
> ---
>  .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
>  5 files changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> index 59ab16ad12f1..cb1b866d9c37 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> @@ -80,6 +80,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1

Not an array.

Is there a specific pattern and/or default name you can specify?

> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> index 199f45217b4a..b8809325138f 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> @@ -107,6 +107,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index 04013e5dd044..ffd3e2850366 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> @@ -99,6 +99,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> index 04b9af4db191..cd7a5e1374ce 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> @@ -94,6 +94,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> index 680f37726fdf..ae256238a637 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> @@ -108,6 +108,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> -- 
> 2.32.0
> 
> 
> 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (No Subject)
@ 2021-06-22 16:20 Yassine Oudjana
  2021-07-14 18:03 ` Rob Herring
  0 siblings, 1 reply; 145+ messages in thread
From: Yassine Oudjana @ 2021-06-22 16:20 UTC (permalink / raw)
  To: Stanimir Varbanov, Rob Herring, devicetree
  Cc: Yassine Oudjana, Andy Gross, Bjorn Andersson,
	Mauro Carvalho Chehab, linux-arm-msm, linux-media, linux-kernel,
	~postmarketos/upstreaming

Date: Tue, 22 Jun 2021 20:08:25 +0400
Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name

Support for parsing the firmware-name property was added a while ago [1],
but the dt-bindings were never updated with the new property. This patch
adds it to all venus dt-bindings.

Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>

[1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
---
 .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
 5 files changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
index 59ab16ad12f1..cb1b866d9c37 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
@@ -80,6 +80,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
index 199f45217b4a..b8809325138f 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
@@ -107,6 +107,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 04013e5dd044..ffd3e2850366 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -99,6 +99,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 04b9af4db191..cd7a5e1374ce 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -94,6 +94,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
index 680f37726fdf..ae256238a637 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
@@ -108,6 +108,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
-- 
2.32.0



^ permalink raw reply related	[flat|nested] 145+ messages in thread

* [No Subject]
@ 2019-05-22  2:09 Gardner, Tim
  0 siblings, 0 replies; 145+ messages in thread
From: Gardner, Tim @ 2019-05-22  2:09 UTC (permalink / raw)
  To: linux-kernel

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2015-08-07  6:30 Mr. Vincent Cheng
  0 siblings, 0 replies; 145+ messages in thread
From: Mr. Vincent Cheng @ 2015-08-07  6:30 UTC (permalink / raw)




-- 
I have a business proposal of USD $22,500,000.00 only for you to
transact with me from my bank to your country. Reply to
address: vincentche3434@gmail.com and I will let you know what is
required of you.

Best Regards,
Mr. Vincent Cheng
Your Brother

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2015-07-29 21:56 Mr. Vincent Cheng
  0 siblings, 0 replies; 145+ messages in thread
From: Mr. Vincent Cheng @ 2015-07-29 21:56 UTC (permalink / raw)




-- 
I have a business proposal of USD $22,500,000.00 only for you to
transact with me from my bank to your country. Reply to
address: vincentche3434@gmail.com and I will let you know what is
required of you.

Best Regards,
Mr. Vincent Cheng
Your Brother

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2014-09-20 22:12 Cleveland Finance
  0 siblings, 0 replies; 145+ messages in thread
From: Cleveland Finance @ 2014-09-20 22:12 UTC (permalink / raw)




-- 
Cleveland Finance Loan give out Guarantee Business Loans, Automobile
Purchase Loans, House Purchase Loans and other Personal Loans E.T.C We 
give
out long term loan from One to Fifty years maximum with 1% interest 
rate.

Mrs. Jean L. McFarland.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2014-09-03 12:19 US-ARMEE
  0 siblings, 0 replies; 145+ messages in thread
From: US-ARMEE @ 2014-09-03 12:19 UTC (permalink / raw)




-- 
Hallo Freund
Ich bin Sgt Edward Hatton, ein amerikanischer Soldat, der derzeit in 
Kabul Afghanistan dienen. Sie vertraut werden können?; Kann ich $ 5,5 
Millionen Us-Dollar in Ihre Obhut anzuvertrauen? Ich wird dich dieser 
Transaktion mehr aufzuklären, sobald ich von Ihnen zu hören. Ich brauche 
nur eine vertrauenswürdige Person mir erhalten und diese Mittel zu 
sichern, bis ich durch meine Pflicht hier Kabul Afghanistan bin zu 
helfen.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2014-05-03 16:50 James McCammond
  0 siblings, 0 replies; 145+ messages in thread
From: James McCammond @ 2014-05-03 16:50 UTC (permalink / raw)
  To: Recipients

Komfortable direkte Kredit-Angebot! Wir bieten dringende Darlehen zu einem sehr niedrigen Zinssatz von 4%, wir sind in einer breiten Palette von Kreditvergabe und unsere Region ist die Erbringung von Finanzdienstleistungen weltweit. Wir sind spezialisiert auf Immobilien-Investoren, Finanzierung, Bau-Darlehen, Startkredite, Hypothekendarlehen, HUD Darlehen, persönliche Darlehen, Business-Darlehen, FHA-Darlehen, VA-Darlehen, Auto-Titel Darlehen, Darlehen usw. entsprechen Bei Interesse kontaktieren Sie uns für weitere Informationen. 

Wir leisten unseren besten Service für unsere Darlehen Bewerber. 

Management 
(C) USA 2014

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2013-11-23  2:09 SANTANDER ASSET FINANCE PLC
  0 siblings, 0 replies; 145+ messages in thread
From: SANTANDER ASSET FINANCE PLC @ 2013-11-23  2:09 UTC (permalink / raw)





-- 
Do you need a Loan to start or expand your business ? We give Business
Loans upto £100 million if you need funding please send sumary of your
Project to our email below: krisparker.loanagency@aim.com
Dr. Kris Parker

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2012-10-12 13:00 a1tmblwd
  0 siblings, 0 replies; 145+ messages in thread
From: a1tmblwd @ 2012-10-12 13:00 UTC (permalink / raw)
  To: eetimes, saari, michkl1969, from_eetimes, hashemia, linux-kernel,
	commsdesign

Make Inc0me like m0ney making machine
http://www.vastusukh.com/http-morenul-1.php?nipfriend=977


_____________________
"  I never went near the house, but struck throughthe woods and made 
for the swamp." (c) ally winsor
Fri, 12 Oct 2012 14:00:55



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2012-09-19 14:53 Webmaster
  0 siblings, 0 replies; 145+ messages in thread
From: Webmaster @ 2012-09-19 14:53 UTC (permalink / raw)
  To: linux-kernel

sss






--
powered by phpList, www.phplist.com --



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2012-04-09 14:39 niamathullah sharief
  0 siblings, 0 replies; 145+ messages in thread
From: niamathullah sharief @ 2012-04-09 14:39 UTC (permalink / raw)
  To: shariefbe, trichystar, itsvijay85, trichystar, beagleboard,
	rizwan.mohammed, linux-kernel


Turn your pc into making money machine.
http://184.168.145.37/gerhfgtim.php?jqyrfreepage=201



__________________
"_Instead, therefore, of relying on the barometer,the ship is equipped with a telescope which maybe instantly set at an angle of 45 degrees, or vertically." (c) sammijo windgate
Mon, 9 Apr 2012 15:39:25

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2011-06-04  9:21  ©2011.Coca-Cola Great Britain 
  0 siblings, 0 replies; 145+ messages in thread
From:  ©2011.Coca-Cola Great Britain  @ 2011-06-04  9:21 UTC (permalink / raw)





-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2011-05-25 18:36  ©2011.Coca-Cola Great Britain 
  0 siblings, 0 replies; 145+ messages in thread
From:  ©2011.Coca-Cola Great Britain  @ 2011-05-25 18:36 UTC (permalink / raw)





-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2010-06-14 23:22       ` Stefan Richter
@ 2010-06-15  0:08         ` Stefan Richter
  0 siblings, 0 replies; 145+ messages in thread
From: Stefan Richter @ 2010-06-15  0:08 UTC (permalink / raw)
  To: Justin P. Mattock; +Cc: linux-kernel, linux1394-devel

On 15 Jun, Stefan Richter wrote:
> which caused gcc 4.6 to warn about
>     variable 'destination' set but not used.
...
>  drivers/firewire/core-transaction.c |   11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
...

Subject was meant to be [PATCH] firewire: core: remove unused variable.
-- 
Stefan Richter
-=====-==-=- -==- -====
http://arcgraph.de/sr/


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-12-14 23:44 Mr Mou Xinsheng
  0 siblings, 0 replies; 145+ messages in thread
From: Mr Mou Xinsheng @ 2009-12-14 23:44 UTC (permalink / raw)




-- 
Hello Friend,
I seek your assistance to receive funds on my behalf for mutual business
benefits,kindly reply via email:mrmouxinsheng01@gala.net, Mr Mou Xinsheng.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-08-24 19:35 MRS SANDRA WHITE
  0 siblings, 0 replies; 145+ messages in thread
From: MRS SANDRA WHITE @ 2009-08-24 19:35 UTC (permalink / raw)



I am Mrs Sandra White, I am currently sending you this mail from my sick
bed in the hospital,I would want you to contact my lawyer;Email
(Martins009@9.cn)

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-08-23 17:49 INFO
  0 siblings, 0 replies; 145+ messages in thread
From: INFO @ 2009-08-23 17:49 UTC (permalink / raw)


A lump sum of (£1,000,000.00 GBP) has been credited to your E-mail
id,contact markrobinson@9.cn with your Name: Address: Age: Sex:
Occupation:Tel: Country

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-08-03 10:14 kell
  0 siblings, 0 replies; 145+ messages in thread
From: kell @ 2009-08-03 10:14 UTC (permalink / raw)


You've earned £1,000,000 GBP.Necessary information:name,age,country ,
tel:

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-07-17 12:02 UK
  0 siblings, 0 replies; 145+ messages in thread
From: UK @ 2009-07-17 12:02 UTC (permalink / raw)


Your Email address have been picked as a winner of(£1 MIL.GBP) file REF
NO.UK/9876125.
Prof Derek Max Email: cgpdept2@w.cn
1.FULL NAMES:2.ADDRESS:3.City
4.State5.Postcode6.Country
7.SEX:8.AGE:9.OCCUPATION:
10.TELEPHONE NUMBER:

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-07-17  4:17 CG LOTTO
  0 siblings, 0 replies; 145+ messages in thread
From: CG LOTTO @ 2009-07-17  4:17 UTC (permalink / raw)




-- 
A lump sum of (£1,230,310 GBP) have been credited to your E-mail 
Address.Congrats...Confirm this receipt by contacting Mr Larry Whyte.
Email: (cgnlpaycenter@9.cn) your Name:___ Address:___ Age:___ Sex:___
Occupation:___Tel/Fax:___Country

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-07-13 23:56 Camelot Group.
  0 siblings, 0 replies; 145+ messages in thread
From: Camelot Group. @ 2009-07-13 23:56 UTC (permalink / raw)


A lump sum of (£891,934.00 GBP) have been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr Ray Donald.
Email: (mrraydonald18@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-07-10 21:36 The UKNL
  0 siblings, 0 replies; 145+ messages in thread
From: The UKNL @ 2009-07-10 21:36 UTC (permalink / raw)


Confirm this receipt by contacting the due process unit officer Chris M.
for the sum of One million Pounds E-mail (chrism01@9.cn)Fill the details:
FullName,Address,Tel,Occupation.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-07-09  7:20 UKNL
  0 siblings, 0 replies; 145+ messages in thread
From: UKNL @ 2009-07-09  7:20 UTC (permalink / raw)


Confirm this receipt by contacting the due process unit officer Dr.Evan
Kyle for the sum of 
One million Pounds E-mail (kyleevan@9.cn)Fill the details:
FullName,Address,Tel,Occupation:

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-07-09  2:20 UKNL
  0 siblings, 0 replies; 145+ messages in thread
From: UKNL @ 2009-07-09  2:20 UTC (permalink / raw)


Confirm this receipt by contacting the due process unit officer Dr.Evan
Kyle for the sum of 
One million Pounds E-mail (kyleevan@9.cn)Fill the details:
FullName,Address,Tel,Occupation:

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-07-02 14:23 The British
  0 siblings, 0 replies; 145+ messages in thread
From: The British @ 2009-07-02 14:23 UTC (permalink / raw)



Your email account have been credited with (£850,000.00 GBP) held
recently,contact with.E-mail(pinkett@9.cn)1.Full Name 2.Gender: 3Age.
4.Contact Address: 5. Country of Residence 6.Nationality: 7.Occupation:
8.Telephone Mobile

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-06-30  1:16 Mrs Dianne Thompson
  0 siblings, 0 replies; 145+ messages in thread
From: Mrs Dianne Thompson @ 2009-06-30  1:16 UTC (permalink / raw)




-- 
Contact Mr David Green for a sum pay out of 1,230,310 GBP. Provide Your
Name: Address: Age: Sex: Occupation:Email:cgnl2009@9.cn)for
Verification immediately.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-06-29 19:56 Uknl
  0 siblings, 0 replies; 145+ messages in thread
From: Uknl @ 2009-06-29 19:56 UTC (permalink / raw)


REF NO.REF:UKL/74-A0802742009
Congrats in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to (claimdepartment01@9.cn) for £1,000,000.00.send your
data for
more details.Choose your claims option.
(1)Courier Delivery
(2)Bank Transfer

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-06-23 16:08 UNL
  0 siblings, 0 replies; 145+ messages in thread
From: UNL @ 2009-06-23 16:08 UTC (permalink / raw)


Your email account have been credited with (1,500,000.00 GBP) in the
LOttery held recently,contact Dr Harry Raymond.Tel:+44.703.598.3025
with.E-mail (harry001@9.cn)1.Full Name 2.Gender:3.Age.4.Contact Address:of
Residence 6.Nationality:7.Occupation:8.Telephone Mobile


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-06-23  2:55 UKL-DEPT
  0 siblings, 0 replies; 145+ messages in thread
From: UKL-DEPT @ 2009-06-23  2:55 UTC (permalink / raw)


You are among the winners of the CAMELOT GROUP.(£891,934.00 GBP.)by
contacting Prof.Derek Max Email:(derek_max@9.cn)1. Full
Names...2.Gender:.3.Age:...4.Contact Address:...5. Country of
Residence:....6.Nationality:7....Occupation:.8.Telephone Mobile #....


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-06-21 13:34 The Nat
  0 siblings, 0 replies; 145+ messages in thread
From: The Nat @ 2009-06-21 13:34 UTC (permalink / raw)


Your email account have been credited with (£850,000.00 GBP) in the FREE
LOTTERY held recently,contact Dr Thomas White.
with.E-mail (drthomas@gala.net)1.Full Name 2.Gender: 3.Age.4.Contact
Address:of
Residence 6.Nationality:7.Occupation:8.Telephone Mobile


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-06-09 18:04 IL
  0 siblings, 0 replies; 145+ messages in thread
From: IL @ 2009-06-09 18:04 UTC (permalink / raw)


مرحبا ، لقد فاز € 801،613.00 يورو في
2009الأيرلندية اليانصيب الترويجي. الرد
منالآن وحتى المطالبة بالجائزة الخاصة بك.
إرسال الاسم والعنوان والعمر ورقم الهاتف،
المهنة.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-29 13:14 Camelot Uk
  0 siblings, 0 replies; 145+ messages in thread
From: Camelot Uk @ 2009-05-29 13:14 UTC (permalink / raw)


Participate in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to(claim_max22@9.cn )
for £891,934.00 GBP.send your data for 

more details




^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-28  4:26 CL
  0 siblings, 0 replies; 145+ messages in thread
From: CL @ 2009-05-28  4:26 UTC (permalink / raw)


 A lump sum of (£891,934.00 GBP)have been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr Phil Herald.
+447031907814 on (philherald03@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-28  1:44 Cgnlwin
  0 siblings, 0 replies; 145+ messages in thread
From: Cgnlwin @ 2009-05-28  1:44 UTC (permalink / raw)


Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claim_max22@9.cn )TEL (+4470359 60751 OR +4470359
60749 )for claims immediately.



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-26 18:10 Mnl
  0 siblings, 0 replies; 145+ messages in thread
From: Mnl @ 2009-05-26 18:10 UTC (permalink / raw)



-- 
A lump sum of (£1,000,000.00 GBP) Is been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr. Michael Smith.
+44-704-573-6915 on ( jeniferfox@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country__Choose your


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-25 18:02 IL
  0 siblings, 0 replies; 145+ messages in thread
From: IL @ 2009-05-25 18:02 UTC (permalink / raw)



-- 
Get back to us for a lump sum pay out of 1,801,613.00 EURO. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email (donnell.irish.2009@9.cn)TEL (+44 70457 09552)for
claims immediately.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-23 18:14 Cgnlwin
  0 siblings, 0 replies; 145+ messages in thread
From: Cgnlwin @ 2009-05-23 18:14 UTC (permalink / raw)


Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claims.max@gala.net )TEL (+4470359 60749 )for
claims immediately.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-23 11:09 Mnl
  0 siblings, 0 replies; 145+ messages in thread
From: Mnl @ 2009-05-23 11:09 UTC (permalink / raw)



-- 
Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jenifer.fox@9.cn to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-18 15:12 Mnl
  0 siblings, 0 replies; 145+ messages in thread
From: Mnl @ 2009-05-18 15:12 UTC (permalink / raw)



Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-18 12:16 Mnl
  0 siblings, 0 replies; 145+ messages in thread
From: Mnl @ 2009-05-18 12:16 UTC (permalink / raw)


Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-18  9:59 Mnl
  0 siblings, 0 replies; 145+ messages in thread
From: Mnl @ 2009-05-18  9:59 UTC (permalink / raw)


Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-18  8:58 Mnl
  0 siblings, 0 replies; 145+ messages in thread
From: Mnl @ 2009-05-18  8:58 UTC (permalink / raw)



-- 
Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-16  4:56 il
  0 siblings, 0 replies; 145+ messages in thread
From: il @ 2009-05-16  4:56 UTC (permalink / raw)


Hello,
1Million Pounds is now yours. Congrats...You have won.
Send your information to Kelly Moore (44)70457 09556
on barrkellymore@9.cn to process your claims. Provide
your name, address, age, phone number.
Signed,
UNL


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-15 14:29 il
  0 siblings, 0 replies; 145+ messages in thread
From: il @ 2009-05-15 14:29 UTC (permalink / raw)



-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
barrkellymoore@9.cn to help you process your claims.
Provide your name, address, age, phone number, occupation.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2009-05-09  1:50 IL
  0 siblings, 0 replies; 145+ messages in thread
From: IL @ 2009-05-09  1:50 UTC (permalink / raw)



-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
ilca7.fred@gmail.com to help process your claims.
Provide your name, address, age, phone number, occupation.

Erik Andersen
Irish Lotto


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
  2008-04-07  9:13   ` Alexander van Heukelum
@ 2008-04-07 10:00     ` zhenwenxu
  0 siblings, 0 replies; 145+ messages in thread
From: zhenwenxu @ 2008-04-07 10:00 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* RE: (no subject)
  2008-02-01 18:14 veerasena reddy
@ 2008-02-04  5:41 ` Ramgopal Kota
  0 siblings, 0 replies; 145+ messages in thread
From: Ramgopal Kota @ 2008-02-04  5:41 UTC (permalink / raw)
  To: veerasena reddy, linux-kernel.org, linux-mips

Hi,

You can set a real-time priority to the user-process.

Ramgopal Kota 
-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of veerasena reddy
Sent: Friday, February 01, 2008 11:45 PM
To: linux-kernel.org; linux-mips
Subject: (no subject)

Hi,

I have a requirement where i need to execute a user process even when
the kernel is utilizing 100% of CPU time.

Actual scenario is as below:
I have a device on my board. this device keeps generating regular (for
every 2secs) messages for a user process. the user process has to poll
on the device for any message is there to read and get the message from
the device. once the user process reads the message it will be removed
in device and uses for further/subsequent messages.

I have a test case where i need to send so much traffic through my board
such that the kernel will be utilizing 100% CPU time to process this
data. At this time (when CPU is 100% utilized) the user space process is
not getting scheduled even after a long duration (say 10 minutes to 45
minutes). Mean time the message buffer in the device is filled up and
the device halts (aka controlled crash; the device firmware has been
designed like this) as there is no more memory on the device.
To avoid this scenario of device's message queue getting filled up
because of the user space process not reading them, could you please
anyone suggest some technique for getting my user space process
scheduled even when there is very heavy traffic as described above.

In simple, i can put my requirement like this:
    Is there any way i can get a user space process get scheduled in the
above condition (kernel occupying 100% of CPU due to heavy traffic)

Thanks in Advance.

Regards,
Veerasena.


      Now you can chat without downloading messenger. Go to
http://in.messenger.yahoo.com/webmessengerpromo.php




^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2007-09-07 22:19 Jim Cromie
  0 siblings, 0 replies; 145+ messages in thread
From: Jim Cromie @ 2007-09-07 22:19 UTC (permalink / raw)
  To: linux-kernel

	auth 2efbb938 subscribe linux-kernel jim.cromie@gmail.com
	auth a339d34a subscribe linux-net jim.cromie@gmail.com



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2007-06-08  7:53 Nicklas Bondesson
  0 siblings, 0 replies; 145+ messages in thread
From: Nicklas Bondesson @ 2007-06-08  7:53 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2007-02-15 11:54 ddup1
  0 siblings, 0 replies; 145+ messages in thread
From: ddup1 @ 2007-02-15 11:54 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2007-02-01  9:19 ddup1
  0 siblings, 0 replies; 145+ messages in thread
From: ddup1 @ 2007-02-01  9:19 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2007-01-26  7:29 orig
  0 siblings, 0 replies; 145+ messages in thread
From: orig @ 2007-01-26  7:29 UTC (permalink / raw)
  To: linux-kernel


subscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2007-01-25 20:50 Craig Van Tassle
  0 siblings, 0 replies; 145+ messages in thread
From: Craig Van Tassle @ 2007-01-25 20:50 UTC (permalink / raw)
  To: linux-kernel

subscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2006-09-16  9:11 Laurent CARON
  0 siblings, 0 replies; 145+ messages in thread
From: Laurent CARON @ 2006-09-16  9:11 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2006-09-16  9:10 Laurent CARON
  0 siblings, 0 replies; 145+ messages in thread
From: Laurent CARON @ 2006-09-16  9:10 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2006-08-03  8:25 Franck Bui-Huu
  0 siblings, 0 replies; 145+ messages in thread
From: Franck Bui-Huu @ 2006-08-03  8:25 UTC (permalink / raw)
  To: linux-kernel

subscribe

--

Franck BUI-HUU
Software Engineer

INNOVA CARD
ZI Athelia IV - Le Forum, Batiment A
2 avenue de la Tramontane
13705 La Ciotat Cedex - France
Phone  : +33 (0)4 42 98 15 35
Fax    : +33 (0)4 42 08 33 19
Email  : franck.bui-huu@innova-card.com
Web    : www.innova-card.com

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
Innova Card will not therefore be liable for the message if modified.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
  2006-06-05 19:48 process starvation with 2.6 scheduler Kallol Biswas
@ 2006-06-05 23:49 ` Hack Sung Lee
  0 siblings, 0 replies; 145+ messages in thread
From: Hack Sung Lee @ 2006-06-05 23:49 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [No Subject]
@ 2006-05-14 12:57 Arnulfo Titor
  0 siblings, 0 replies; 145+ messages in thread
From: Arnulfo Titor @ 2006-05-14 12:57 UTC (permalink / raw)
  To: linux-kernel, majordomo

Hello,

If you want PROMPT assets to utilize ANY
way you feel like, or sincerely feel like to LOWER 
your premiums by 25% or more; 

Here are the offers We have ASAP : 

lNTEREST-OnIy : $ 564K @ UNDER  477 a month
VARlABLE : $ 556K at BELOW 453 each month

http://foigbil.com/9r

Rush, these proposals will end in 24 hours

Thanks Alot,
Arnulfo Titor


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2006-01-07  4:16 Chaitanya Vinay Hazarey
  0 siblings, 0 replies; 145+ messages in thread
From: Chaitanya Vinay Hazarey @ 2006-01-07  4:16 UTC (permalink / raw)
  To: linux-kernel

subscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
  2005-11-30 19:35   ` Greg KH
@ 2005-12-01  4:10     ` Glenn L Shurson
  0 siblings, 0 replies; 145+ messages in thread
From: Glenn L Shurson @ 2005-12-01  4:10 UTC (permalink / raw)
  To: Linux Kernel Mailing List

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2005-11-21 10:06 ` (no subject) Keir Fraser
  2005-11-21 10:11   ` Russell King
@ 2005-11-21 17:27   ` Andi Kleen
  1 sibling, 0 replies; 145+ messages in thread
From: Andi Kleen @ 2005-11-21 17:27 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Andi Kleen, virtualization, bunk, linux-kernel

> We could make use of virt_to_machine/machine_to_virt instead, which 

I don't like it because "machine" is quite meaningless outside
Xen. 

-Andi

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2005-11-21 10:06 ` (no subject) Keir Fraser
@ 2005-11-21 10:11   ` Russell King
  2005-11-21 17:27   ` Andi Kleen
  1 sibling, 0 replies; 145+ messages in thread
From: Russell King @ 2005-11-21 10:11 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Andi Kleen, virtualization, bunk, linux-kernel

On Mon, Nov 21, 2005 at 10:06:03AM +0000, Keir Fraser wrote:
> On 18 Nov 2005, at 16:05, Andi Kleen wrote:
> >I don't think you can do that. We still need these functions in low
> >level architecture code at least.
> >
> >Using __pa/__va doesn't cut it because it won't work on Xen guests
> >which have different views on bus vs physical addresses. The Xen
> >code is (hopefully) in the process of being merged, so intentionally
> >breaking them isn't a good idea.
> >
> >So if anything there would need to be replacement functions for it
> >first that do the same thing. But why not just keep the old ones?
> 
> We could make use of virt_to_machine/machine_to_virt instead, which 
> arguably better describe the intent of those functions. Currently we 
> only use virt_to_bus/bus_to_virt in our swiotlb implementation, and our 
> modified dma_map code. In those files I think the existing function 
> names make some sense, but we can easily change if that's preferred.

If you're thinking of replacing bus_to_virt/virt_to_bus, you might want
to think about virt_to_dma(dev, virt) and dma_to_virt(dev, dma) as a
replacement, where "dev" is the device actually performing the DMA
(which obviously may not be the device asking for the mapping to be set
up.)  ARM already has these for use in the architecture code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2005-11-18 16:05 Andi Kleen
@ 2005-11-21 10:06 ` Keir Fraser
  2005-11-21 10:11   ` Russell King
  2005-11-21 17:27   ` Andi Kleen
  0 siblings, 2 replies; 145+ messages in thread
From: Keir Fraser @ 2005-11-21 10:06 UTC (permalink / raw)
  To: Andi Kleen; +Cc: virtualization, bunk, linux-kernel


On 18 Nov 2005, at 16:05, Andi Kleen wrote:

> I don't think you can do that. We still need these functions in low
> level architecture code at least.
>
> Using __pa/__va doesn't cut it because it won't work on Xen guests
> which have different views on bus vs physical addresses. The Xen
> code is (hopefully) in the process of being merged, so intentionally
> breaking them isn't a good idea.
>
> So if anything there would need to be replacement functions for it
> first that do the same thing. But why not just keep the old ones?

We could make use of virt_to_machine/machine_to_virt instead, which 
arguably better describe the intent of those functions. Currently we 
only use virt_to_bus/bus_to_virt in our swiotlb implementation, and our 
modified dma_map code. In those files I think the existing function 
names make some sense, but we can easily change if that's preferred.

  -- Keir


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-05-22 16:05 Pedro Henrique
  0 siblings, 0 replies; 145+ messages in thread
From: Pedro Henrique @ 2005-05-22 16:05 UTC (permalink / raw)
  To: linux-kernel





^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-05-22 12:40 Timo Hallek
  0 siblings, 0 replies; 145+ messages in thread
From: Timo Hallek @ 2005-05-22 12:40 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-05-18  7:56 suzuki
  0 siblings, 0 replies; 145+ messages in thread
From: suzuki @ 2005-05-18  7:56 UTC (permalink / raw)
  To: lkml


unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-04-26  4:20 Frederic Weisbecker
  0 siblings, 0 replies; 145+ messages in thread
From: Frederic Weisbecker @ 2005-04-26  4:20 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-03-29  4:46 Sumesh
  0 siblings, 0 replies; 145+ messages in thread
From: Sumesh @ 2005-03-29  4:46 UTC (permalink / raw)
  To: linux list

unsubscribe.

Regards,
Sumesh

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-03-10  2:03 Ray Bryant
  0 siblings, 0 replies; 145+ messages in thread
From: Ray Bryant @ 2005-03-10  2:03 UTC (permalink / raw)
  To: linux-kernel

subscribe linux-kernel
end

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-02-16  4:08 Ethan Weinstein
  0 siblings, 0 replies; 145+ messages in thread
From: Ethan Weinstein @ 2005-02-16  4:08 UTC (permalink / raw)
  To: linux-kernel

Unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2005-01-20 19:33 Ram Kumar
  0 siblings, 0 replies; 145+ messages in thread
From: Ram Kumar @ 2005-01-20 19:33 UTC (permalink / raw)
  To: linux-kernel




^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2004-10-27 12:09 Mirko Bonasorte
  0 siblings, 0 replies; 145+ messages in thread
From: Mirko Bonasorte @ 2004-10-27 12:09 UTC (permalink / raw)
  To: Linux Kernel

Subscribe

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2004-09-01  2:42 Anthony DiSante
  0 siblings, 0 replies; 145+ messages in thread
From: Anthony DiSante @ 2004-09-01  2:42 UTC (permalink / raw)
  To: linux-kernel

subscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: <no subject>
@ 2004-08-29 13:21 Joachim Bremer
  0 siblings, 0 replies; 145+ messages in thread
From: Joachim Bremer @ 2004-08-29 13:21 UTC (permalink / raw)
  To: JoachimBremer, NickPiggin; +Cc: linux-kernel

Nick Piggin <nickpiggin@yahoo.com.au> schrieb am 29.08.04 14:43:43:
> 
> Joachim Bremer wrote:
> > As mentioned before I got even with Nicks patch some errors. Looking
> > closer at the source there is is a second "goto page_ok" a few lines
> > down the label "page_not_up_to_date". Inserting the same calculating
> > code used before the label "readpage_error" fixes the errors on my machine.
> > These for instance where failure to do reiserfsck (bread complains on last block
> > of device) and compiling the linux-tree (file truncated).
> > 
> > The leads to the same calculation 3 times...
> > 
> 
> Surely not - there is only 1 way to get to page_not_up_to_date,
> and through that path you have already done that calculation and
> none of the variables involved have been changed.
>

Sure I backed out the other patch - but you are right. It does magically work now
with your patch only. maybe  it was an interaction with the sound driver which hangs
on shutdown so maybe there where some transactions not written or replayed.

Thanks

Joachim
 
> I think. Put a printk before your goto out, and if it triggers
> then I am wrong.
> 
> What errors were you seeing with my patch? (If you applied my patch
> to an -mm kernel without first backing out the others then it will
> break).


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: <no subject>
  2004-08-29 12:36 Joachim Bremer
@ 2004-08-29 12:42 ` Nick Piggin
  0 siblings, 0 replies; 145+ messages in thread
From: Nick Piggin @ 2004-08-29 12:42 UTC (permalink / raw)
  To: Joachim Bremer; +Cc: linux-kernel

Joachim Bremer wrote:
> As mentioned before I got even with Nicks patch some errors. Looking
> closer at the source there is is a second "goto page_ok" a few lines
> down the label "page_not_up_to_date". Inserting the same calculating
> code used before the label "readpage_error" fixes the errors on my machine.
> These for instance where failure to do reiserfsck (bread complains on last block
> of device) and compiling the linux-tree (file truncated).
> 
> The leads to the same calculation 3 times...
> 

Surely not - there is only 1 way to get to page_not_up_to_date,
and through that path you have already done that calculation and
none of the variables involved have been changed.

I think. Put a printk before your goto out, and if it triggers
then I am wrong.

What errors were you seeing with my patch? (If you applied my patch
to an -mm kernel without first backing out the others then it will
break).

^ permalink raw reply	[flat|nested] 145+ messages in thread

* <no subject>
@ 2004-08-29 12:36 Joachim Bremer
  2004-08-29 12:42 ` Nick Piggin
  0 siblings, 1 reply; 145+ messages in thread
From: Joachim Bremer @ 2004-08-29 12:36 UTC (permalink / raw)
  To: linux-kernel; +Cc: nickpiggin

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

As mentioned before I got even with Nicks patch some errors. Looking
closer at the source there is is a second "goto page_ok" a few lines
down the label "page_not_up_to_date". Inserting the same calculating
code used before the label "readpage_error" fixes the errors on my machine.
These for instance where failure to do reiserfsck (bread complains on last block
of device) and compiling the linux-tree (file truncated).

The leads to the same calculation 3 times...

Patch attached


Joachim
_______________________________________________________
WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
Informationen unter: http://freemail.web.de/?mc=021199

[-- Attachment #2: mm-filemap-np-missing.patch.txt --]
[-- Type: text/plain, Size: 494 bytes --]

--- linux-2.6.9-np/mm/filemap.c	2004-08-29 14:03:40.989353448 +0200
+++ linux-2.6/mm/filemap.c	2004-08-29 13:48:37.000000000 +0200
@@ -798,6 +798,15 @@ page_not_up_to_date:
 		/* Did somebody else fill it already? */
 		if (PageUptodate(page)) {
 			unlock_page(page);
+			nr = PAGE_CACHE_SIZE;
+			if (index == end_index) {
+				nr = isize & ~PAGE_CACHE_MASK;
+				if (nr <= offset) {
+					page_cache_release(page);
+					goto out;
+				}
+			}
+			nr = nr - offset;
 			goto page_ok;
 		}
 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2004-08-16  1:09 A. Mani
  0 siblings, 0 replies; 145+ messages in thread
From: A. Mani @ 2004-08-16  1:09 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2004-06-30 17:58 Frederic Krueger
  0 siblings, 0 replies; 145+ messages in thread
From: Frederic Krueger @ 2004-06-30 17:58 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* <no subject>
@ 2004-06-30  9:50 Michael Tasche
  0 siblings, 0 replies; 145+ messages in thread
From: Michael Tasche @ 2004-06-30  9:50 UTC (permalink / raw)
  To: linux-kernel

Hi,
currently I'm developping a small kernel module for a hardware (which was developped by a friend of mine), which is supposed to load a firmware onto a PCI-card.
 
The development is done together with the friend, who's developping the firmware.
We tried the following:
He compiled a kernel-independent object (containing the firmware) on his system using kbuild
(Dual-AthlonMP, SuSE 8.2 with kernel.org-kernel 2.6.3, module-init-tools 0.9.14-pre2, gcc 3.3.1,
ld 2.14.90.0.5 20030722).
Afterwards I tried to link it to my kernel-module (using the same kbuild makefile with
firmware.o_shipped) on my machine (Fedora2, 2.6.5-3.1smp, module-init-tools 3.0-pre10, gcc 3.3.3, ld 2.15.90.0.3 20040415).
 
This is what happened:
 
Unable to handle kernel paging request at virtual address 82d90700
 printing eip:
02135657
*pde = 00000000
Oops: 0002 [#1]
PREEMPT SMP
CPU:    1
EIP:    0060:[<02135657>]    Not tainted
EFLAGS: 00010246   (2.6.5-3.1smp)
EIP is at module_unload_init+0xa/0x4d
eax: 82d90700   ebx: 82c2387c   ecx: 82d8f600   edx: 00000000
esi: 82c38f33   edi: 82c40027   ebp: 000005f0   esp: 763c3f38
ds: 007b   es: 007b   ss: 0068
Process insmod (pid: 1812, threadinfo=763c2000 task=7f3c60b0)
Stack: 02136dc0 7864cc40 8282a000 00000000 82d8f600 00000000 00000000 00000000
       00000000 00000000 0000000b 00000000 00000010 00000000 00000000 00000009
       00000025 00000024 00000026 82c3829c 82c23727 82a94000 0856a008 763c3fc4
Call Trace:
 [<02136dc0>] load_module+0x53e/0x7fa
 [<021370da>] sys_init_module+0x5e/0x293
 
Code: 89 81 00 11 00 00 89 81 04 11 00 00 89 c8 c7 80 00 01 00 00
 
 
What puzzles me, is that I don't see any of my code in the calltrace. I had a look into the
kernel-code and it seems to crash, before it even jumps into my code. What am I missing?
By the way, everything works fine, if I compile the entire module on my machine.
Some more testing showed, that we do also expierence a crash, if we do everything vice-versa.
 
Regards,
Michael

P.S: This was also posted by the driver developer to comp.os.linux.development.system.
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
  2004-03-18 11:34   ` Matthias Andree
@ 2004-03-18 11:58     ` Daniel Czarnecki
  0 siblings, 0 replies; 145+ messages in thread
From: Daniel Czarnecki @ 2004-03-18 11:58 UTC (permalink / raw)
  To: Linux Kernel

unsubscribe

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2004-02-25 15:16 Joel Cant
@ 2004-02-25 15:54 ` Redeeman
  0 siblings, 0 replies; 145+ messages in thread
From: Redeeman @ 2004-02-25 15:54 UTC (permalink / raw)
  To: joel; +Cc: linux-kernel

you would want to type:

subscribe linux-kernel

and send to majordomo@vger.kernel.org

> subscribe
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/




^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2004-02-25 15:16 Joel Cant
  2004-02-25 15:54 ` Redeeman
  0 siblings, 1 reply; 145+ messages in thread
From: Joel Cant @ 2004-02-25 15:16 UTC (permalink / raw)
  To: linux-kernel

subscribe

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
       [not found] <402A710F.9080908@surricani.cjb.net>
@ 2004-02-11 18:20 ` Armen Kaleshian
  0 siblings, 0 replies; 145+ messages in thread
From: Armen Kaleshian @ 2004-02-11 18:20 UTC (permalink / raw)
  To: Dott. Surricani; +Cc: linux-kernel

If you could send out dmesg output, that would help.

--Armen

On Wed, Feb 11, 2004 at 07:14:39PM +0100, Dott. Surricani wrote:
: Yes...
: 
: I enabled Dma, I disabled....  MMIO DMA error....
: 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2004-02-09 21:05 Alexandr Chernyy
  2004-02-09 21:22 ` Matti Aarnio
@ 2004-02-09 22:46 ` Alessandro Amici
  1 sibling, 0 replies; 145+ messages in thread
From: Alessandro Amici @ 2004-02-09 22:46 UTC (permalink / raw)
  To: Alexandr Chernyy, linux-kernel

On Monday 09 February 2004 22:05, Alexandr Chernyy wrote:
> Hello All! Can you help me! I write module for kernel 2.4.22 and have
> some problems! I need to read some information form file, create
> directory and etc. (Did kerlen have some stdio.h like function - fopen,
> fgets, fclose......)!!! Please help me.

what you are looking for is not usually needed by 'normal' kernel modules. 
could you please be more specific on what is exactly your porpouse?

alessandro

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2004-02-09 21:05 Alexandr Chernyy
@ 2004-02-09 21:22 ` Matti Aarnio
  2004-02-09 22:46 ` Alessandro Amici
  1 sibling, 0 replies; 145+ messages in thread
From: Matti Aarnio @ 2004-02-09 21:22 UTC (permalink / raw)
  To: Alexandr Chernyy; +Cc: linux-kernel

On Mon, Feb 09, 2004 at 11:05:58PM +0200, Alexandr Chernyy wrote:
> Hello All! Can you help me! I write module for kernel 2.4.22 and have 
> some problems! I need to read some information form file, create 
> directory and etc. (Did kerlen have some stdio.h like function - fopen, 
> fgets, fclose......)!!! Please help me.

  Programming in kernel-space isn't at all the same as in userspace.
  For starters, the context stack is highly restricted in size.

  You can have some pointers for it by studying the way, how
  the kernel-space NFS server works while opening files, and
  doing IO.

  Oh yes, there is NO STDIO in kernel.

> WBR, Alexandr Chernyy
> nikalex@sp.mk.ua

/Matti Aarnio

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2004-02-09 21:05 Alexandr Chernyy
  2004-02-09 21:22 ` Matti Aarnio
  2004-02-09 22:46 ` Alessandro Amici
  0 siblings, 2 replies; 145+ messages in thread
From: Alexandr Chernyy @ 2004-02-09 21:05 UTC (permalink / raw)
  To: linux-kernel

Hello All! Can you help me! I write module for kernel 2.4.22 and have 
some problems! I need to read some information form file, create 
directory and etc. (Did kerlen have some stdio.h like function - fopen, 
fgets, fclose......)!!! Please help me.

WBR, Alexandr Chernyy
nikalex@sp.mk.ua


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-12-05 23:35 Jonathan Fors
  0 siblings, 0 replies; 145+ messages in thread
From: Jonathan Fors @ 2003-12-05 23:35 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-11-04 15:47 Bas van Kampen
  0 siblings, 0 replies; 145+ messages in thread
From: Bas van Kampen @ 2003-11-04 15:47 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-11-02 21:58 phil
  0 siblings, 0 replies; 145+ messages in thread
From: phil @ 2003-11-02 21:58 UTC (permalink / raw)
  To: linux-kernel

  auth b4d3fc24 subscribe linux-kernel philippe.aubry1@mageos.com


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2003-09-01  6:15 Honne Gowda A
@ 2003-09-01 12:46 ` Herbert Poetzl
  0 siblings, 0 replies; 145+ messages in thread
From: Herbert Poetzl @ 2003-09-01 12:46 UTC (permalink / raw)
  To: Honne Gowda A; +Cc: linux-kernel

On Mon, Sep 01, 2003 at 11:45:07AM +0530, Honne Gowda A wrote:
> help

how could we?

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-09-01  6:15 Honne Gowda A
  2003-09-01 12:46 ` Herbert Poetzl
  0 siblings, 1 reply; 145+ messages in thread
From: Honne Gowda A @ 2003-09-01  6:15 UTC (permalink / raw)
  To: linux-kernel

help

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2003-08-13  9:14 Vid Strpic
  2003-08-13 10:36 ` Catalin BOIE
@ 2003-08-13 11:34 ` Herbert Pötzl
  1 sibling, 0 replies; 145+ messages in thread
From: Herbert Pötzl @ 2003-08-13 11:34 UTC (permalink / raw)
  To: Vid Strpic; +Cc: linux-kernel

On Wed, Aug 13, 2003 at 11:14:53AM +0200, Vid Strpic wrote:
> On Tue, Aug 12, 2003 at 04:55:19PM +0300, Catalin BOIE wrote:
> > "cat drivers/built-in.o > /dev/null" gives me i/o error.
> > Can I suspect a bad sector?
> 
> Where, in memory? :)  /dev/null is in memory :)

depends, if /dev/null does not exist before the cat,
it will be created as regular file, residing on the
device /dev is (which could be a disk ...)

ls -la /dev/null will show ...

> > I use reiserfs.
> 
> Any other file gives that?

best,
Herbert

> 
> -- 
>            vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
> Linux lorien 2.4.21 #1 Sat Jun 14 01:23:07 CEST 2003 i586
>  11:13:51 up 38 days, 21:33, 10 users,  load average: 0.03, 0.26, 0.18



^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2003-08-13  9:14 Vid Strpic
@ 2003-08-13 10:36 ` Catalin BOIE
  2003-08-13 11:34 ` Herbert Pötzl
  1 sibling, 0 replies; 145+ messages in thread
From: Catalin BOIE @ 2003-08-13 10:36 UTC (permalink / raw)
  To: Vid Strpic; +Cc: linux-kernel

> On Tue, Aug 12, 2003 at 04:55:19PM +0300, Catalin BOIE wrote:
> > "cat drivers/built-in.o > /dev/null" gives me i/o error.
> > Can I suspect a bad sector?
>
> Where, in memory? :)  /dev/null is in memory :)
:)
 ran badblocks and the disk is ok.
2.6.0test3mm1 let me read that file without i/o.


> > I use reiserfs.
>
> Any other file gives that?

Nope.

Also in 2.4.22pre? I can read ok the file.

>
> --
>            vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
> Linux lorien 2.4.21 #1 Sat Jun 14 01:23:07 CEST 2003 i586
>  11:13:51 up 38 days, 21:33, 10 users,  load average: 0.03, 0.26, 0.18
>

---
Catalin(ux) BOIE
catab@deuroconsult.ro

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
@ 2003-08-13  9:14 Vid Strpic
  2003-08-13 10:36 ` Catalin BOIE
  2003-08-13 11:34 ` Herbert Pötzl
  0 siblings, 2 replies; 145+ messages in thread
From: Vid Strpic @ 2003-08-13  9:14 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Tue, Aug 12, 2003 at 04:55:19PM +0300, Catalin BOIE wrote:
> "cat drivers/built-in.o > /dev/null" gives me i/o error.
> Can I suspect a bad sector?

Where, in memory? :)  /dev/null is in memory :)

> I use reiserfs.

Any other file gives that?

-- 
           vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
Linux lorien 2.4.21 #1 Sat Jun 14 01:23:07 CEST 2003 i586
 11:13:51 up 38 days, 21:33, 10 users,  load average: 0.03, 0.26, 0.18

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (No Subject)
@ 2003-08-07  1:46 Solaris Wildchild
  0 siblings, 0 replies; 145+ messages in thread
From: Solaris Wildchild @ 2003-08-07  1:46 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


Need a new email address that people can remember
Check out the new EudoraMail at
http://www.eudoramail.com

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (no subject)
  2003-07-20 11:46 (no subject) Cédric Barboiron
@ 2003-07-20 19:43 ` jiho
  0 siblings, 0 replies; 145+ messages in thread
From: jiho @ 2003-07-20 19:43 UTC (permalink / raw)
  To: Cédric Barboiron; +Cc: linux-kernel

You must send this to:

    majordomo@vger.kernel.org

not to linux-kernel itself.


Cédric Barboiron wrote:
> subscribe linux-kernel
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-07-20 11:46 Cédric Barboiron
  2003-07-20 19:43 ` jiho
  0 siblings, 1 reply; 145+ messages in thread
From: Cédric Barboiron @ 2003-07-20 11:46 UTC (permalink / raw)
  To: linux-kernel

subscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-05-20 10:50 COMALP - Mar.Ord. MATTIUZZO Riccardo
  0 siblings, 0 replies; 145+ messages in thread
From: COMALP - Mar.Ord. MATTIUZZO Riccardo @ 2003-05-20 10:50 UTC (permalink / raw)
  To: linux-kernel

uth 9d00c8d3 subscribe linux-kernel mailadm@comalp.esercito.difesa.it


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-05-16 21:35 Anders Franzen
  0 siblings, 0 replies; 145+ messages in thread
From: Anders Franzen @ 2003-05-16 21:35 UTC (permalink / raw)
  To: linux-kernel

subscribe


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-03-19  3:21 Gabe Arnold
  0 siblings, 0 replies; 145+ messages in thread
From: Gabe Arnold @ 2003-03-19  3:21 UTC (permalink / raw)
  To: linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

unsubscribe linux-kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+d+IzckcsnldWwycRArzrAJsGMMhSBi+33flvSmGMXVgr1+VIsACdGLYj
PhqZOaYivayzwPyiYR5e8cI=
=Z9Rg
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2003-03-16 15:35 MaxF
  0 siblings, 0 replies; 145+ messages in thread
From: MaxF @ 2003-03-16 15:35 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: (No subject)
@ 2002-12-02  9:21 Marc-Christian Petersen
  0 siblings, 0 replies; 145+ messages in thread
From: Marc-Christian Petersen @ 2002-12-02  9:21 UTC (permalink / raw)
  To: linux-kernel; +Cc: Nadav Rotem

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

Hi Nadav,

first: a subject would be nice ;)

> I am having some problems with recent kernels. The SIS DRI module since 
> 2.4.18 through 2.4.20 will not compile ^H ^H ^H Link properly. The Error I 
> get is undefined reference to sis_free() and sis_malloc(). I believe it has 
> to do with the dependencies or make file linking with a missing .o file.
> The problem occures whenever I try to compile the module into the kernel ( 
> [*] sis ).
> when I try to compile it as a module it fails when I go through "make 
> modules_install" with the same error.
that problem is known for a long time now and has been often discussed but 
never got a fix into mainstream. Use this.

The patch does 2 simple things.

1. If you select SiS DRI statically it selects SiS Framebuffer also statically
2. Same as above for module.

ciao, Marc


[-- Attachment #2: 032_xfree-drm-4.2.0-03.patch --]
[-- Type: text/x-diff, Size: 683 bytes --]

# Patch from: me

diff -Nur linux-2.4.18-wolk-3.3-fullkernel-org/drivers/char/drm/Config.in linux-2.4.18-wolk-3.3-fullkernel/drivers/char/drm/Config.in
--- linux-2.4.18-wolk-3.3-fullkernel-org/drivers/char/drm/Config.in	Mon Feb 25 20:37:57 2002
+++ linux-2.4.18-wolk-3.3-fullkernel/drivers/char/drm/Config.in	Tue Apr 23 19:22:31 2002
@@ -13,3 +13,10 @@
 dep_tristate '  Intel 830M' CONFIG_DRM_I830 $CONFIG_AGP
 dep_tristate '  Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP
 dep_tristate '  SiS' CONFIG_DRM_SIS $CONFIG_AGP
+
+    if [ "$CONFIG_DRM_SIS" = "y" ]; then
+	define_bool CONFIG_FB_SIS y
+    fi
+    if [ "$CONFIG_DRM_SIS" = "m" ]; then
+	define_bool CONFIG_FB_SIS m
+    fi

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2002-10-17 21:58 Daniele Lugli
  0 siblings, 0 replies; 145+ messages in thread
From: Daniele Lugli @ 2002-10-17 21:58 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: [No Subject]
  2002-09-13 17:39 [No Subject]  Jim Sibley
@ 2002-09-13 18:02 ` Jesse Pollard
  0 siblings, 0 replies; 145+ messages in thread
From: Jesse Pollard @ 2002-09-13 18:02 UTC (permalink / raw)
  To: jimsibley; +Cc: linux-kernel, riel, vda, alan

On Friday 13 September 2002 12:39 pm,  Jim Sibley wrote:
> First, please change your replies to me to jimsibley@earthlink.net and drop
> the IBM address. Some of my replies may not reflect IBM's position.
>
> Also please drop the LTC address in your replies. I'm told that the address
> is not a
> place to discuss issues like this. So much for monolithic turf wars.
>
> Anyway, back to the important stuff.
>
> GID might be sufficient if you reserve some GID for resource balancing and
> use the /proc interface to update it.

Only when a process can have one gid.

This usually means a single user/application system, in which case you
still can't determine which process to kill since they are all in the same
group.

Most production shops I have worked in requires multiple groups per user,
which gets translated into multiple GIDs per process. This defeats your
use of GIDs for resource allocation.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* [No Subject]
@ 2002-09-13 17:39  Jim Sibley
  2002-09-13 18:02 ` Jesse Pollard
  0 siblings, 1 reply; 145+ messages in thread
From:  Jim Sibley @ 2002-09-13 17:39 UTC (permalink / raw)
  To: pollard; +Cc: linux-kernel, riel, vda, alan

First, please change your replies to me to jimsibley@earthlink.net and drop
the IBM address. Some of my replies may not reflect IBM's position. 

Also please drop the LTC address in your replies. I'm told that the address is
not a
place to discuss issues like this. So much for monolithic turf wars.

Anyway, back to the important stuff.

GID might be sufficient if you reserve some GID for resource balancing and use
the /proc interface to update it.

As Thunder has pointed out, what do you do when all thatis left is critical
system stuff?

What I wouldn't want to see is a cumbersome workload manager ala zOS that
might consume as much resources as its tring to manage. Nor should the
solution be too extotic that other Unix might adopt.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: <no subject>
  2002-08-25  9:15 <no subject> joerg.beyer
@ 2002-08-25 11:04 ` Zwane Mwaikambo
  0 siblings, 0 replies; 145+ messages in thread
From: Zwane Mwaikambo @ 2002-08-25 11:04 UTC (permalink / raw)
  To: joerg.beyer; +Cc: linux-kernel

On Sun, 25 Aug 2002 joerg.beyer@email.de wrote:

> Disk access, like untaring a big tar file (e.g. kernel sources)
> are really slow.

> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> hda: HITACHI_DK23DA-20, ATA DISK drive
> hdc: QSI DVD-ROM SDR-081, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 39070080 sectors (20004 MB) w/2048KiB Cache, CHS=2432/255/63
> hdc: ATAPI 24X DVD-ROM drive, 512kB Cache

You seem to be running without DMA.

	Zwane
-- 
function.linuxpower.ca



^ permalink raw reply	[flat|nested] 145+ messages in thread

* <no subject>
@ 2002-08-25  9:15 joerg.beyer
  2002-08-25 11:04 ` Zwane Mwaikambo
  0 siblings, 1 reply; 145+ messages in thread
From: joerg.beyer @ 2002-08-25  9:15 UTC (permalink / raw)
  To: linux-kernel

Hi,

I see high latencies on a new medion (MD9788) laptop.

I had to use tha acpi patch to get a NIC module
loaded into the kernel. There is a realtec 8139 chip
onboard. I tried both Donald Beckers and the usual
kernel module for that chip - with similar results:

There are a lot lines in /var/log/messages like this:
kernel: eth0: Too much work at interrupt, IntrStatus=0x0040.

The NIC has a lot errors:
eth0      Link encap:Ethernet  HWaddr 00:07:CA:00:AC:A3
          inet addr:10.0.0.30  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:802 errors:5860 dropped:290 overruns:5860 frame:0
          TX packets:802 errors:0 dropped:0 overruns:0 carrier:0
          collisions:3 txqueuelen:100
          RX bytes:1116143 (1.0 Mb)  TX bytes:63846 (62.3 Kb)
          Interrupt:10 Base address:0xf000

Disk access, like untaring a big tar file (e.g. kernel sources)
are really slow.

I see this effect with 2.4.18, 2.4.19, 2.4.20-pre4 kernels (with the
matching acpi patch. without acpi patch the NIC is not usable).

Could anybody tell me why there are such high IRQ latencies?
Or are my assumptions wrong?


For reference, here is a lspci:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 80)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:06.0 Communication controller: Ambient Technologies Inc: Unknown device 4000   (rev 02)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40  )
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a)
00:07.4 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controlle  r (rev 50)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:0c.0 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)
00:0c.1 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)
01:00.0 VGA compatible controller: S3 Inc.: Unknown device 8d02 (rev 01)

here is /proc/interrupts:
           CPU0
  0:     175728          XT-PIC  timer
  1:        684          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  9:          0          XT-PIC  acpi
 10:       1965          XT-PIC  eth0
 14:       4011          XT-PIC  ide0
 15:          2          XT-PIC  ide1
NMI:          0
ERR:          0


I have very limited knowledge about IRQs. Does anybody see how
to fix the high IRQ latencies?

If you need further informations, please drop me a mail.

    TIA
    Joerg

and below is the dmesg:
>pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 10
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_link-0501 [0001] [07] acpi_pci_link_add     : ----Entry
pci_link-0099 [0001] [08] acpi_pci_link_get_poss: ----Entry
pci_link-0164 [0001] [08] acpi_pci_link_get_poss: Found 1 possible IRQs
pci_link-0169 [0001] [08] acpi_pci_link_get_poss: ----Exit- 0000000000000000
pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 10
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKB] (IRQs *10)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_link-0501 [0001] [07] acpi_pci_link_add     : ----Entry
pci_link-0099 [0001] [08] acpi_pci_link_get_poss: ----Entry
pci_link-0164 [0001] [08] acpi_pci_link_get_poss: Found 1 possible IRQs
pci_link-0169 [0001] [08] acpi_pci_link_get_poss: ----Exit- 0000000000000000
pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 5
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_link-0501 [0001] [07] acpi_pci_link_add     : ----Entry
pci_link-0099 [0001] [08] acpi_pci_link_get_poss: ----Entry
pci_link-0164 [0001] [08] acpi_pci_link_get_poss: Found 1 possible IRQs
pci_link-0169 [0001] [08] acpi_pci_link_get_poss: ----Exit- 0000000000000000
pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 5
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKD] (IRQs *5)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.PPB_]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:01.00
pci_bind-0217 [0001] [05] acpi_pci_bind         : Device 00:00:01.00 is a PCI bridge
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.PPB_.VGA_]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:01:00.00
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.USB0]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:07.02
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.PM__]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:07.04
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.AUDI]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:07.05
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.MPC2]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:09.00
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.MPCI]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:06.00
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [06] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [06] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.CRD0]...
pci_bind-0176 [0001] [06] acpi_pci_bind         : ...to 00:00:0c.00
pci_bind-0217 [0001] [06] acpi_pci_bind         : Device 00:00:0c.00 is a PCI bridge
pci_bind-0260 [0001] [06] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [07] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [07] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.CRD1]...
pci_bind-0176 [0001] [07] acpi_pci_bind         : ...to 00:00:0c.01
pci_bind-0217 [0001] [07] acpi_pci_bind         : Device 00:00:0c.01 is a PCI bridge
pci_bind-0260 [0001] [07] acpi_pci_bind         : ----Exit- 0000000000000000
ACPI: Power Resource [PFAN] (on)
PCI: Probing PCI hardware
 pci_irq-0376 [0001] [04] acpi_pci_irq_init     : ----Entry
pci_link-0385 [0001] [05] acpi_pci_link_check   : ----Entry
pci_link-0446 [0001] [05] acpi_pci_link_check   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:00.0
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:01.0
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:06[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fac0
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:06.0 using IRQ 10
 pci_irq-0361 [0001] [05] acpi_pci_irq_enable   : Setting IRQ 10 as level-triggered
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:07.0
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:07.1
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:07[D]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fa80
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 0000000000000005
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 5
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 0000000000000005
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:07.2 using IRQ 5
 pci_irq-0361 [0001] [05] acpi_pci_irq_enable   : Setting IRQ 5 as level-triggered
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000005
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:07.4
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:07[C]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fa40
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 0000000000000005
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 5
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 0000000000000005
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:07.5 using IRQ 5
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000005
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:09[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fb00
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:09.0 using IRQ 10
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:0c[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fb40
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:0c.0 using IRQ 10
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:0c[B]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fb80
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:0c.1 using IRQ 10
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:01:00[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0084 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- 00000000
 pci_irq-0248 [0001] [06] acpi_pci_irq_lookup   : PRT entry not found
 pci_irq-0249 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 0000000000000000
 pci_irq-0278 [0001] [06] acpi_pci_irq_derive   : ----Entry
 pci_irq-0240 [0001] [07] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [07] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:01[B]
 pci_irq-0066 [0001] [08] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0084 [0001] [08] acpi_pci_irq_find_prt_: ----Exit- 00000000
 pci_irq-0248 [0001] [07] acpi_pci_irq_lookup   : PRT entry not found
 pci_irq-0249 [0001] [07] acpi_pci_irq_lookup   : ----Exit- 0000000000000000
 pci_irq-0293 [0001] [06] acpi_pci_irq_derive   : Unable to derive IRQ for device 01:00.0
 pci_irq-0294 [0001] [06] acpi_pci_irq_derive   : ----Exit- 0000000000000000
PCI: No IRQ known for interrupt pin A of device 01:00.0 - using IRQ 5
 pci_irq-0349 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000005
 pci_irq-0396 [0001] [04] acpi_pci_irq_init     : ----Exit- 0000000000000000
Applying VIA southbridge workaround.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (on)
ACPI: Processor [CPU0] (supports C1 C2, 16 throttling states)
ACPI: Thermal Zone [THRM] (39 C)
vesafb: framebuffer at 0xf0000000, mapped to 0xcf808000, size 15296k
vesafb: mode is 1024x768x16, linelength=2048, pages=8
vesafb: protected mode interface info at c000:7f20
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
vga16fb: initializing
vga16fb: mapped to 0xc00a0000
fb1: VGA16 VGA frame buffer device
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: HITACHI_DK23DA-20, ATA DISK drive
hdc: QSI DVD-ROM SDR-081, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 39070080 sectors (20004 MB) w/2048KiB Cache, CHS=2432/255/63
hdc: ATAPI 24X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 hda3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
reiserfs: checking transaction log (device 03:01) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 240k freed
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Adding Swap: 481940k swap-space (priority 42)
8139too Fast Ethernet driver 0.9.25

**** Context Switch from TID 1 to TID 134 ****

 pci_irq-0311 [0134] [04] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0134] [05] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0134] [05] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:09[A]
 pci_irq-0066 [0134] [06] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0134] [06] acpi_pci_irq_find_prt_: ----Exit- c129fb00
 pci_irq-0264 [0134] [05] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0134] [05] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0134] [04] acpi_pci_irq_enable   : Device 00:09.0 using IRQ 10
 pci_irq-0367 [0134] [04] acpi_pci_irq_enable   : ----Exit- 000000000000000A
eth0: RealTek RTL8139 Fast Ethernet at 0xd07ef000, 00:07:ca:00:ac:a3, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139C'



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2002-08-14 11:23 Bernard yap
  0 siblings, 0 replies; 145+ messages in thread
From: Bernard yap @ 2002-08-14 11:23 UTC (permalink / raw)
  To: linux-kernel

unsibscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
  2002-08-13  6:35 ` Jeff Chua
@ 2002-08-13  9:27   ` Tony Gale
  0 siblings, 0 replies; 145+ messages in thread
From: Tony Gale @ 2002-08-13  9:27 UTC (permalink / raw)
  To: Jeff Chua; +Cc: Linux Kernel

On Tue, 2002-08-13 at 07:35, Jeff Chua wrote:
> 
> I'm buying a Dell PowerEdge 2650 and need to know where to get driver for
> the RAID controller
> 
> 	PERC3-DI, PERC3-DC, or PERC3-QC

They are Adaptec AACRAID or AMI MegaRaid Cards. You may need a driver
update though. See http://domsch.com/linux/ for details.

> 
> Does anyone know what kind of network adaptor is on the board?
> 

Broadcom NetXtreme Gigabit.

-tony



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
  2002-07-26  0:06   ` EFAULT vs. SIGSEGV [was Re: close return value] Pavel Machek
@ 2002-07-26 14:01     ` Alexis Deruelle
  0 siblings, 0 replies; 145+ messages in thread
From: Alexis Deruelle @ 2002-07-26 14:01 UTC (permalink / raw)
  To: linux-kernel

unsubscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2002-03-22 14:28 Pierre Rousselet
  0 siblings, 0 replies; 145+ messages in thread
From: Pierre Rousselet @ 2002-03-22 14:28 UTC (permalink / raw)
  To: lkml

subscribe linux-kernel


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2002-03-01  2:55 Justin Piszcz
  0 siblings, 0 replies; 145+ messages in thread
From: Justin Piszcz @ 2002-03-01  2:55 UTC (permalink / raw)
  To: linux-kernel

subscribe war@starband.net


^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2002-02-11 15:02 Aaron & Elizabeth Day
  0 siblings, 0 replies; 145+ messages in thread
From: Aaron & Elizabeth Day @ 2002-02-11 15:02 UTC (permalink / raw)
  To: linux-kernel

auth b6c8427d subscribe linux-kernel thedays@chartermi.net



^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2001-03-21  9:44 Moran Cohen
  0 siblings, 0 replies; 145+ messages in thread
From: Moran Cohen @ 2001-03-21  9:44 UTC (permalink / raw)
  To: linux-kernel

list
-- 
|\/| _  _ _  _  _| ....ne brocen ------
|  |(_)| (_|| |_\|<| ------ ne wurde...

^ permalink raw reply	[flat|nested] 145+ messages in thread

* (no subject)
@ 2001-01-10  1:40 Eko Sulistiono
  0 siblings, 0 replies; 145+ messages in thread
From: Eko Sulistiono @ 2001-01-10  1:40 UTC (permalink / raw)
  To: linux-kernel

 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 145+ messages in thread

end of thread, other threads:[~2024-01-31  3:38 UTC | newest]

Thread overview: 145+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-27 14:59 [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Kefeng Wang
2021-12-27 14:59 ` [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
2022-01-18  2:52   ` Nicholas Piggin
2022-01-19 12:57     ` Kefeng Wang
2022-01-19 13:22       ` Matthew Wilcox
2022-01-19 13:44         ` Kefeng Wang
2022-01-19 13:48           ` Matthew Wilcox
2021-12-27 14:59 ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
2021-12-27 17:35   ` (No subject) William Kucharski
2021-12-28  1:36     ` Kefeng Wang
2022-01-15 10:05   ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Christophe Leroy
2021-12-27 14:59 ` [PATCH v2 3/3] x86: " Kefeng Wang
2021-12-27 15:56   ` Dave Hansen
2021-12-28 10:26     ` Kefeng Wang
2021-12-28 16:14       ` Dave Hansen
2021-12-29 11:01         ` Kefeng Wang
2022-01-15 10:17           ` Christophe Leroy
2022-01-15 10:15         ` Christophe Leroy
2022-01-18  2:46         ` Nicholas Piggin
2022-01-18 17:28           ` Dave Hansen
2022-01-19  4:17             ` Nicholas Piggin
2022-01-19 13:32               ` Kefeng Wang
2022-01-15 10:11       ` Christophe Leroy
2022-01-15 10:06   ` Christophe Leroy
2022-01-15 10:07 ` [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Christophe Leroy
  -- strict thread matches above, loose matches on Subject: below --
2024-01-31  3:37 (No Subject) John Moon
2023-08-31  4:52 youngbludproductions
2023-08-31  5:11 ` youngbludproductions
2023-05-13  8:12 [no subject] Beatrice Benson
2021-06-22 16:20 (No Subject) Yassine Oudjana
2021-07-14 18:03 ` Rob Herring
2019-05-22  2:09 [No Subject] Gardner, Tim
2015-08-07  6:30 (no subject) Mr. Vincent Cheng
2015-07-29 21:56 Mr. Vincent Cheng
2014-09-20 22:12 Cleveland Finance
2014-09-03 12:19 US-ARMEE
2014-05-03 16:50 James McCammond
2013-11-23  2:09 SANTANDER ASSET FINANCE PLC
2012-10-12 13:00 a1tmblwd
2012-09-19 14:53 Webmaster
2012-04-09 14:39 niamathullah sharief
2011-06-04  9:21  ©2011.Coca-Cola Great Britain 
2011-05-25 18:36  ©2011.Coca-Cola Great Britain 
2010-06-14 20:26 [PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages Justin P. Mattock
2010-06-14 20:26 ` [PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used Justin P. Mattock
2010-06-14 21:44   ` [PATCH] ieee1394: sbp2: remove unused code Stefan Richter
2010-06-14 22:35     ` Justin P. Mattock
2010-06-14 23:22       ` Stefan Richter
2010-06-15  0:08         ` (no subject) Stefan Richter
2009-12-14 23:44 Mr Mou Xinsheng
2009-08-24 19:35 MRS SANDRA WHITE
2009-08-23 17:49 INFO
2009-08-03 10:14 kell
2009-07-17 12:02 UK
2009-07-17  4:17 CG LOTTO
2009-07-13 23:56 Camelot Group.
2009-07-10 21:36 The UKNL
2009-07-09  7:20 UKNL
2009-07-09  2:20 UKNL
2009-07-02 14:23 The British
2009-06-30  1:16 Mrs Dianne Thompson
2009-06-29 19:56 Uknl
2009-06-23 16:08 UNL
2009-06-23  2:55 UKL-DEPT
2009-06-21 13:34 The Nat
2009-06-09 18:04 IL
2009-05-29 13:14 Camelot Uk
2009-05-28  4:26 CL
2009-05-28  1:44 Cgnlwin
2009-05-26 18:10 Mnl
2009-05-25 18:02 IL
2009-05-23 18:14 Cgnlwin
2009-05-23 11:09 Mnl
2009-05-18 15:12 Mnl
2009-05-18 12:16 Mnl
2009-05-18  9:59 Mnl
2009-05-18  8:58 Mnl
2009-05-16  4:56 il
2009-05-15 14:29 il
2009-05-09  1:50 IL
2008-04-06 12:47 [PATCH] x86: remove superfluous initialisation in boot code Alexander van Heukelum
2008-04-07  7:46 ` Ingo Molnar
2008-04-07  9:13   ` Alexander van Heukelum
2008-04-07 10:00     ` (no subject) zhenwenxu
2008-02-01 18:14 veerasena reddy
2008-02-04  5:41 ` (no subject) Ramgopal Kota
2007-09-07 22:19 Jim Cromie
2007-06-08  7:53 Nicklas Bondesson
2007-02-15 11:54 ddup1
2007-02-01  9:19 ddup1
2007-01-26  7:29 orig
2007-01-25 20:50 Craig Van Tassle
2006-09-16  9:11 Laurent CARON
2006-09-16  9:10 Laurent CARON
2006-08-03  8:25 Franck Bui-Huu
2006-06-05 19:48 process starvation with 2.6 scheduler Kallol Biswas
2006-06-05 23:49 ` (no subject) Hack Sung Lee
2006-05-14 12:57 [No Subject] Arnulfo Titor
2006-01-07  4:16 (no subject) Chaitanya Vinay Hazarey
2005-11-30  5:56 [GIT PATCH] USB patches for 2.6.15-rc3 Greg KH
2005-11-30 18:23 ` Linus Torvalds
2005-11-30 19:35   ` Greg KH
2005-12-01  4:10     ` (no subject) Glenn L Shurson
2005-11-18 16:05 Andi Kleen
2005-11-21 10:06 ` (no subject) Keir Fraser
2005-11-21 10:11   ` Russell King
2005-11-21 17:27   ` Andi Kleen
2005-05-22 16:05 Pedro Henrique
2005-05-22 12:40 Timo Hallek
2005-05-18  7:56 suzuki
2005-04-26  4:20 Frederic Weisbecker
2005-03-29  4:46 Sumesh
2005-03-10  2:03 Ray Bryant
2005-02-16  4:08 Ethan Weinstein
2005-01-20 19:33 Ram Kumar
2004-10-27 12:09 Mirko Bonasorte
2004-09-01  2:42 Anthony DiSante
2004-08-29 13:21 <no subject> Joachim Bremer
2004-08-29 12:36 Joachim Bremer
2004-08-29 12:42 ` Nick Piggin
2004-08-16  1:09 (no subject) A. Mani
2004-06-30 17:58 Frederic Krueger
2004-06-30  9:50 <no subject> Michael Tasche
2004-03-18  1:08 True fsync() in Linux (on IDE) Peter Zaitsev
2004-03-18  6:47 ` Jens Axboe
2004-03-18 11:34   ` Matthias Andree
2004-03-18 11:58     ` (no subject) Daniel Czarnecki
2004-02-25 15:16 Joel Cant
2004-02-25 15:54 ` Redeeman
     [not found] <402A710F.9080908@surricani.cjb.net>
2004-02-11 18:20 ` Armen Kaleshian
2004-02-09 21:05 Alexandr Chernyy
2004-02-09 21:22 ` Matti Aarnio
2004-02-09 22:46 ` Alessandro Amici
2003-12-05 23:35 Jonathan Fors
2003-11-04 15:47 Bas van Kampen
2003-11-02 21:58 phil
2003-09-01  6:15 Honne Gowda A
2003-09-01 12:46 ` Herbert Poetzl
2003-08-13  9:14 Vid Strpic
2003-08-13 10:36 ` Catalin BOIE
2003-08-13 11:34 ` Herbert Pötzl
2003-08-07  1:46 (No Subject) Solaris Wildchild
2003-07-20 11:46 (no subject) Cédric Barboiron
2003-07-20 19:43 ` jiho
2003-05-20 10:50 COMALP - Mar.Ord. MATTIUZZO Riccardo
2003-05-16 21:35 Anders Franzen
2003-03-19  3:21 Gabe Arnold
2003-03-16 15:35 MaxF
2002-12-02  9:21 (No subject) Marc-Christian Petersen
2002-10-17 21:58 (no subject) Daniele Lugli
2002-09-13 17:39 [No Subject]  Jim Sibley
2002-09-13 18:02 ` Jesse Pollard
2002-08-25  9:15 <no subject> joerg.beyer
2002-08-25 11:04 ` Zwane Mwaikambo
2002-08-14 11:23 (no subject) Bernard yap
     [not found] <Pine.LNX.4.44.0208131430570.22034-100000@dstl.gov.uk>
2002-08-13  6:35 ` Jeff Chua
2002-08-13  9:27   ` (no subject) Tony Gale
2002-07-20  8:00 close return value Florian Weimer
2002-07-20 16:45 ` Linus Torvalds
2002-07-26  0:06   ` EFAULT vs. SIGSEGV [was Re: close return value] Pavel Machek
2002-07-26 14:01     ` (no subject) Alexis Deruelle
2002-03-22 14:28 Pierre Rousselet
2002-03-01  2:55 Justin Piszcz
2002-02-11 15:02 Aaron & Elizabeth Day
2001-03-21  9:44 Moran Cohen
2001-01-10  1:40 Eko Sulistiono

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).