[patch 54/55] x86/apic: Mark single target interrupts

If the interrupt destination mode of the APIC is physical then the effective affinity is restricted to a single CPU. Mark the interrupt accordingly in the domain allocation code, so the core code can avoid pointless affinity setting attempts. Signed-off-by: Thomas Gleixner

[patch 50/55] genirq: Handle managed irqs gracefully in irq_startup()

Affinity managed interrupts should keep their assigned affinity accross CPU hotplug. To avoid magic hackery in device drivers, the core code shall manage them transparently and set these interrupts into a managed shutdown state when the last CPU of the assigned affinity mask goes offline. The

[patch 47/55] genirq: Introduce IRQD_MANAGED_SHUTDOWN

Affinity managed interrupts should keep their assigned affinity accross CPU hotplug. To avoid magic hackery in device drivers, the core code shall manage them transparently. This will set these interrupts into a managed shutdown state when the last CPU of the assigned affinity mask goes offline.

[patch 55/55] genirq/affinity: Assign vectors to all present CPUs

From: Christoph Hellwig Currently the irq vector spread algorithm is restricted to online CPUs, which ties the IRQ mapping to the currently online devices and doesn't deal nicely with the fact that CPUs could come and go rapidly due to e.g. power management. Instead assign vectors

[patch 54/55] x86/apic: Mark single target interrupts

If the interrupt destination mode of the APIC is physical then the effective affinity is restricted to a single CPU. Mark the interrupt accordingly in the domain allocation code, so the core code can avoid pointless affinity setting attempts. Signed-off-by: Thomas Gleixner ---

[patch 50/55] genirq: Handle managed irqs gracefully in irq_startup()

Affinity managed interrupts should keep their assigned affinity accross CPU hotplug. To avoid magic hackery in device drivers, the core code shall manage them transparently and set these interrupts into a managed shutdown state when the last CPU of the assigned affinity mask goes offline. The

[patch 47/55] genirq: Introduce IRQD_MANAGED_SHUTDOWN

Affinity managed interrupts should keep their assigned affinity accross CPU hotplug. To avoid magic hackery in device drivers, the core code shall manage them transparently. This will set these interrupts into a managed shutdown state when the last CPU of the assigned affinity mask goes offline.

[patch 55/55] genirq/affinity: Assign vectors to all present CPUs

From: Christoph Hellwig Currently the irq vector spread algorithm is restricted to online CPUs, which ties the IRQ mapping to the currently online devices and doesn't deal nicely with the fact that CPUs could come and go rapidly due to e.g. power management. Instead assign vectors to all

[patch 31/55] genirq/cpuhotplug: Set force affinity flag on hotplug migration

Set the force migration flag when migrating interrupts away from an outgoing CPU. Signed-off-by: Thomas Gleixner --- kernel/irq/cpuhotplug.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/irq/cpuhotplug.c +++ b/kernel/irq/cpuhotplug.c @@ -79,7 +79,7

[patch 31/55] genirq/cpuhotplug: Set force affinity flag on hotplug migration

Set the force migration flag when migrating interrupts away from an outgoing CPU. Signed-off-by: Thomas Gleixner --- kernel/irq/cpuhotplug.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/irq/cpuhotplug.c +++ b/kernel/irq/cpuhotplug.c @@ -79,7 +79,7 @@ static bool

[patch 41/55] x86/uv: Use default_cpu_mask_to_apicid_and()

Same functionality except the extra bits ored on the apicid. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/x2apic_uv_x.c | 19 --- 1 file changed, 4 insertions(+), 15 deletions(-) --- a/arch/x86/kernel/apic/x2apic_uv_x.c +++

[patch 36/55] genirq: Remove pointless gfp argument

All callers hand in GPF_KERNEL. No point to have an extra argument for that. Signed-off-by: Thomas Gleixner --- kernel/irq/irqdesc.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -54,14

[patch 41/55] x86/uv: Use default_cpu_mask_to_apicid_and()

Same functionality except the extra bits ored on the apicid. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/x2apic_uv_x.c | 19 --- 1 file changed, 4 insertions(+), 15 deletions(-) --- a/arch/x86/kernel/apic/x2apic_uv_x.c +++ b/arch/x86/kernel/apic/x2apic_uv_x.c @@

[patch 36/55] genirq: Remove pointless gfp argument

All callers hand in GPF_KERNEL. No point to have an extra argument for that. Signed-off-by: Thomas Gleixner --- kernel/irq/irqdesc.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -54,14 +54,14 @@ static void

[patch 13/55] x86/msi: Remove unused remap irq domain interface

Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/irq_remapping.h |1 - arch/x86/kernel/apic/msi.c |6 -- 2 files changed, 7 deletions(-) --- a/arch/x86/include/asm/irq_remapping.h +++ b/arch/x86/include/asm/irq_remapping.h @@ -55,7 +55,6 @@

[patch 13/55] x86/msi: Remove unused remap irq domain interface

Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/irq_remapping.h |1 - arch/x86/kernel/apic/msi.c |6 -- 2 files changed, 7 deletions(-) --- a/arch/x86/include/asm/irq_remapping.h +++ b/arch/x86/include/asm/irq_remapping.h @@ -55,7 +55,6 @@ extern struct irq_domain

[patch 08/55] x86/htirq: Create named domain

Use the fwnode to create a named domain so diagnosis works. Mark the init function __init while at it. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/htirq.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) ---

[patch 09/55] x86/uv: Create named irq domain

Use the fwnode to create a named domain so diagnosis works. Signed-off-by: Thomas Gleixner --- arch/x86/platform/uv/uv_irq.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) --- a/arch/x86/platform/uv/uv_irq.c +++ b/arch/x86/platform/uv/uv_irq.c

[patch 08/55] x86/htirq: Create named domain

Use the fwnode to create a named domain so diagnosis works. Mark the init function __init while at it. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/htirq.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) --- a/arch/x86/kernel/apic/htirq.c +++

[patch 09/55] x86/uv: Create named irq domain

Use the fwnode to create a named domain so diagnosis works. Signed-off-by: Thomas Gleixner --- arch/x86/platform/uv/uv_irq.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) --- a/arch/x86/platform/uv/uv_irq.c +++ b/arch/x86/platform/uv/uv_irq.c @@ -160,13 +160,21 @@

Re: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

On Tue, Jun 20, 2017 at 1:37 AM, Zheng, Lv wrote: > Hi, Rafael > >> From: linux-acpi-ow...@vger.kernel.org >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. >> Wysocki >> Subject: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle >> on

Re: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

On Tue, Jun 20, 2017 at 1:37 AM, Zheng, Lv wrote: > Hi, Rafael > >> From: linux-acpi-ow...@vger.kernel.org >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. >> Wysocki >> Subject: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle >> on recent Dell systems >> >>

[PATCH 19/23] xfs: define usercopy region in xfs_inode slab cache

From: David Windsor XFS inline inode data, stored in struct xfs_inode_t.i_df.if_u2.if_inline_data and therefore contained in the xfs_inode slab cache, needs to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the xfs_inode slab

[PATCH 20/23] usercopy: convert kmalloc caches to usercopy caches

From: David Windsor Mark the kmalloc slab caches as entirely whitelisted. These caches are frequently used to fulfill kernel allocations that contain data to be copied to/from userspace. It is impossible to know at build time what objects will be contained in these caches,

[PATCH 18/23] scsi: define usercopy region in scsi_sense_cache slab cache

From: David Windsor SCSI sense buffers, stored in struct scsi_cmnd.sense and therefore contained in the scsi_sense_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the scsi_sense_cache slab cache in which

[PATCH 19/23] xfs: define usercopy region in xfs_inode slab cache

From: David Windsor XFS inline inode data, stored in struct xfs_inode_t.i_df.if_u2.if_inline_data and therefore contained in the xfs_inode slab cache, needs to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the xfs_inode slab cache in which

[PATCH 20/23] usercopy: convert kmalloc caches to usercopy caches

From: David Windsor Mark the kmalloc slab caches as entirely whitelisted. These caches are frequently used to fulfill kernel allocations that contain data to be copied to/from userspace. It is impossible to know at build time what objects will be contained in these caches, so the entire cache

[PATCH 18/23] scsi: define usercopy region in scsi_sense_cache slab cache

From: David Windsor SCSI sense buffers, stored in struct scsi_cmnd.sense and therefore contained in the scsi_sense_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the scsi_sense_cache slab cache in which userspace copy

[PATCH 17/23] dcache: define usercopy region in dentry_cache slab cache

From: David Windsor When a dentry name is short enough, it can be stored directly in the dentry itself. These dentry short names, stored in struct dentry.d_iname and therefore contained in the dentry_cache slab cache, need to be coped to/from userspace. In support of

[PATCH 21/23] usercopy: Restrict non-usercopy caches to size 0

With all known usercopied cache whitelists now defined in the kernel, switch the default usercopy region of kmem_cache_create() to size 0. Any new caches with usercopy regions will now need to use kmem_cache_create_usercopy() instead of kmem_cache_create(). This patch is modified from Brad

[PATCH 17/23] dcache: define usercopy region in dentry_cache slab cache

From: David Windsor When a dentry name is short enough, it can be stored directly in the dentry itself. These dentry short names, stored in struct dentry.d_iname and therefore contained in the dentry_cache slab cache, need to be coped to/from userspace. In support of usercopy hardening, this

[PATCH 21/23] usercopy: Restrict non-usercopy caches to size 0

With all known usercopied cache whitelists now defined in the kernel, switch the default usercopy region of kmem_cache_create() to size 0. Any new caches with usercopy regions will now need to use kmem_cache_create_usercopy() instead of kmem_cache_create(). This patch is modified from Brad

[PATCH 23/23] mm: Allow slab_nomerge to be set at build time

Some hardened environments want to build kernels with slab_nomerge already set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches, increasing the

[PATCH 23/23] mm: Allow slab_nomerge to be set at build time

Some hardened environments want to build kernels with slab_nomerge already set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches, increasing the

[PATCH 03/23] vfs: define usercopy region in names_cache slab caches

From: David Windsor vfs pathnames stored internally in inodes and contained in the names_cache slab cache need to be copied to/from userspace. In support of usercopy hardening, this patch defines the entire cache object in the names_cache slab cache as whitelisted, since it

[PATCH 03/23] vfs: define usercopy region in names_cache slab caches

From: David Windsor vfs pathnames stored internally in inodes and contained in the names_cache slab cache need to be copied to/from userspace. In support of usercopy hardening, this patch defines the entire cache object in the names_cache slab cache as whitelisted, since it holds name strings

[PATCH 02/23] usercopy: Enforce slab cache usercopy region boundaries

From: David Windsor This patch adds the enforcement component of usercopy cache whitelisting, and is modified from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions

[PATCH 02/23] usercopy: Enforce slab cache usercopy region boundaries

From: David Windsor This patch adds the enforcement component of usercopy cache whitelisting, and is modified from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code

[PATCH 04/23] vfs: copy struct mount.mnt_id to userspace using put_user()

From: David Windsor The mnt_id field can be copied with put_user(), so there is no need to use copy_to_user(). In both cases, hardened usercopy is being bypassed since the size is constant, and not open to runtime manipulation. This patch is verbatim from Brad Spengler/PaX

[PATCH 01/23] usercopy: Prepare for usercopy whitelisting

From: David Windsor This patch prepares the slab allocator to handle caches having annotations (useroffset and usersize) defining usercopy regions. This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the last public patch of grsecurity/PaX

[PATCH 04/23] vfs: copy struct mount.mnt_id to userspace using put_user()

From: David Windsor The mnt_id field can be copied with put_user(), so there is no need to use copy_to_user(). In both cases, hardened usercopy is being bypassed since the size is constant, and not open to runtime manipulation. This patch is verbatim from Brad Spengler/PaX Team's PAX_USERCOPY

[PATCH 01/23] usercopy: Prepare for usercopy whitelisting

From: David Windsor This patch prepares the slab allocator to handle caches having annotations (useroffset and usersize) defining usercopy regions. This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the last public patch of grsecurity/PaX based on my

[PATCH 05/23] befs: define usercopy region in befs_inode_cache slab cache

From: David Windsor The befs symlink pathnames, stored in struct befs_inode_info.i_data.symlink and therefore contained in the befs_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the

[PATCH 05/23] befs: define usercopy region in befs_inode_cache slab cache

From: David Windsor The befs symlink pathnames, stored in struct befs_inode_info.i_data.symlink and therefore contained in the befs_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the befs_inode_cache slab cache in

[PATCH 07/23] exofs: define usercopy region in exofs_inode_cache slab cache

From: David Windsor exofs short symlink names and device #'s, stored in struct exofs_i_info.i_data and therefore contained in the exofs_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the

[PATCH 07/23] exofs: define usercopy region in exofs_inode_cache slab cache

From: David Windsor exofs short symlink names and device #'s, stored in struct exofs_i_info.i_data and therefore contained in the exofs_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the exofs_inode_cache slab cache

[PATCH 06/23] cifs: define usercopy region in cifs_request slab cache

From: David Windsor cifs request buffers, stored in the cifs_request slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the cifs_request slab cache in which userspace copy operations are allowed. This region is

[PATCH 06/23] cifs: define usercopy region in cifs_request slab cache

From: David Windsor cifs request buffers, stored in the cifs_request slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the cifs_request slab cache in which userspace copy operations are allowed. This region is known as the slab

[PATCH 12/23] orangefs: define usercopy region in orangefs_inode_cache slab cache

From: David Windsor The orangefs symlink pathnames, stored in struct orangefs_inode_s.link_target and therefore contained in the orangefs_inode_cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the

[PATCH 12/23] orangefs: define usercopy region in orangefs_inode_cache slab cache

From: David Windsor The orangefs symlink pathnames, stored in struct orangefs_inode_s.link_target and therefore contained in the orangefs_inode_cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the orangefs_inode_cache slab cache in

[PATCH 11/23] jfs: define usercopy region in jfs_ip slab cache

From: David Windsor The jfs symlink pathnames, stored in struct jfs_inode_info.i_inline and therefore contained in the jfs_ip slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the jfs_ip slab cache in which

[PATCH 10/23] vxfs: define usercopy region in vxfs_inode slab cache

From: David Windsor The vxfs symlink pathnames, stored in struct vxfs_inode_info.vii_immed.vi_immed and therefore contained in the vxfs_inode slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the vxfs_inode slab

[PATCH 11/23] jfs: define usercopy region in jfs_ip slab cache

From: David Windsor The jfs symlink pathnames, stored in struct jfs_inode_info.i_inline and therefore contained in the jfs_ip slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the jfs_ip slab cache in which userspace copy

[PATCH 10/23] vxfs: define usercopy region in vxfs_inode slab cache

From: David Windsor The vxfs symlink pathnames, stored in struct vxfs_inode_info.vii_immed.vi_immed and therefore contained in the vxfs_inode slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the vxfs_inode slab cache in which

[PATCH 00/23] Hardened usercopy whitelisting

This series is modified from Brad Spengler/PaX Team's PAX_USERCOPY code in the last public patch of grsecurity/PaX based on our understanding of the code. Changes or omissions from the original code are ours and don't reflect the original grsecurity/PaX code. David Windsor did the bulk of the

[PATCH 09/23] ext4: define usercopy region in ext4_inode_cache slab cache

From: David Windsor The ext4 symlink pathnames, stored in struct ext4_inode_info.i_data and therefore contained in the ext4_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the ext4_inode_cache slab

[PATCH 09/23] ext4: define usercopy region in ext4_inode_cache slab cache

From: David Windsor The ext4 symlink pathnames, stored in struct ext4_inode_info.i_data and therefore contained in the ext4_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the ext4_inode_cache slab cache in which

[PATCH 00/23] Hardened usercopy whitelisting

This series is modified from Brad Spengler/PaX Team's PAX_USERCOPY code in the last public patch of grsecurity/PaX based on our understanding of the code. Changes or omissions from the original code are ours and don't reflect the original grsecurity/PaX code. David Windsor did the bulk of the

Re: [PATCH v3 1/2] clk: Hi3660: register fixed_rate_clks with CLK_OF_DECLARE_DRIVER

On 05/22, Leo Yan wrote: > The timer will register into system at very early phase at kernel boot; > if timer needs to use clock, the clock should be get ready in function > of_clk_init() so later the timer driver probe can retrieve clock > successfully. This is finished in below flow on arm64: >

Re: [PATCH v3 1/2] clk: Hi3660: register fixed_rate_clks with CLK_OF_DECLARE_DRIVER

On 05/22, Leo Yan wrote: > The timer will register into system at very early phase at kernel boot; > if timer needs to use clock, the clock should be get ready in function > of_clk_init() so later the timer driver probe can retrieve clock > successfully. This is finished in below flow on arm64: >

[PATCH 14/23] fork: define usercopy region in thread_stack, task_struct, mm_struct slab caches

From: David Windsor In support of usercopy hardening, this patch defines a region in the thread_stack, task_struct and mm_struct slab caches in which userspace copy operations are allowed. Since only a single whitelisted buffer region is used, this moves the usercopyable

[PATCH 14/23] fork: define usercopy region in thread_stack, task_struct, mm_struct slab caches

From: David Windsor In support of usercopy hardening, this patch defines a region in the thread_stack, task_struct and mm_struct slab caches in which userspace copy operations are allowed. Since only a single whitelisted buffer region is used, this moves the usercopyable fields next to each

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on > recent Dell systems > > From: Rafael J. Wysocki > >

[PATCH 13/23] ufs: define usercopy region in ufs_inode_cache slab cache

From: David Windsor The ufs symlink pathnames, stored in struct ufs_inode_info.i_u1.i_symlink and therefore contained in the ufs_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the ufs_inode_cache

RE: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent Dell systems

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: [PATCH v2 3/3] ACPI / sleep: EC-based wakeup from suspend-to-idle on > recent Dell systems > > From: Rafael J. Wysocki > > Some recent Dell laptops,

[PATCH 13/23] ufs: define usercopy region in ufs_inode_cache slab cache

From: David Windsor The ufs symlink pathnames, stored in struct ufs_inode_info.i_u1.i_symlink and therefore contained in the ufs_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the ufs_inode_cache slab cache in which

[PATCH 16/23] net: copy struct sctp_sock.autoclose to userspace using put_user()

From: David Windsor The autoclose field can be copied with put_user(), so there is no need to use copy_to_user(). In both cases, hardened usercopy is being bypassed since the size is constant, and not open to runtime manipulation. This patch is verbatim from Brad Spengler/PaX

[PATCH 16/23] net: copy struct sctp_sock.autoclose to userspace using put_user()

From: David Windsor The autoclose field can be copied with put_user(), so there is no need to use copy_to_user(). In both cases, hardened usercopy is being bypassed since the size is constant, and not open to runtime manipulation. This patch is verbatim from Brad Spengler/PaX Team's

[PATCH 15/23] net: define usercopy region in struct proto slab cache

From: David Windsor The following objects need to be copied to/from userspace: * sctp socket event notification subscription information * ICMP filters for IPv4 and IPv6 raw sockets * CAIF channel connection request parameters These objects are stored in per-protocol

[PATCH 08/23] ext2: define usercopy region in ext2_inode_cache slab cache

From: David Windsor The ext2 symlink pathnames, stored in struct ext2_inode_info.i_data and therefore contained in the ext2_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the ext2_inode_cache slab

[PATCH 22/23] usercopy: split user-controlled slabs to separate caches

From: David Windsor Some userspace APIs (e.g. ipc, seq_file) provide precise control over the size of kernel kmallocs, which provides a trivial way to perform heap overflow attacks where the attacker must control neighboring allocations of a specific size. Instead, move these

[PATCH 08/23] ext2: define usercopy region in ext2_inode_cache slab cache

From: David Windsor The ext2 symlink pathnames, stored in struct ext2_inode_info.i_data and therefore contained in the ext2_inode_cache slab cache, need to be copied to/from userspace. In support of usercopy hardening, this patch defines a region in the ext2_inode_cache slab cache in which

[PATCH 22/23] usercopy: split user-controlled slabs to separate caches

From: David Windsor Some userspace APIs (e.g. ipc, seq_file) provide precise control over the size of kernel kmallocs, which provides a trivial way to perform heap overflow attacks where the attacker must control neighboring allocations of a specific size. Instead, move these APIs into their own

[PATCH 15/23] net: define usercopy region in struct proto slab cache

From: David Windsor The following objects need to be copied to/from userspace: * sctp socket event notification subscription information * ICMP filters for IPv4 and IPv6 raw sockets * CAIF channel connection request parameters These objects are stored in per-protocol slabs. In support

[PATCH 1/4] percpu: add missing lockdep_assert_held to func pcpu_free_area

Add a missing lockdep_assert_held for pcpu_lock to improve consistency and safety throughout mm/percpu.c. Signed-off-by: Dennis Zhou --- mm/percpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/percpu.c b/mm/percpu.c index e0aa8ae..f94a5eb 100644 --- a/mm/percpu.c

[PATCH 1/4] percpu: add missing lockdep_assert_held to func pcpu_free_area

Add a missing lockdep_assert_held for pcpu_lock to improve consistency and safety throughout mm/percpu.c. Signed-off-by: Dennis Zhou --- mm/percpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/percpu.c b/mm/percpu.c index e0aa8ae..f94a5eb 100644 --- a/mm/percpu.c +++ b/mm/percpu.c

[PATCH 2/4] percpu: migrate percpu data structures to internal header

Migrates pcpu_chunk definition and a few percpu static variables to an internal header file from mm/percpu.c. These will be used with debugfs to expose statistics about percpu memory improving visibility regarding allocations and fragmentation. Signed-off-by: Dennis Zhou ---

[PATCH 2/4] percpu: migrate percpu data structures to internal header

Migrates pcpu_chunk definition and a few percpu static variables to an internal header file from mm/percpu.c. These will be used with debugfs to expose statistics about percpu memory improving visibility regarding allocations and fragmentation. Signed-off-by: Dennis Zhou ---

[PATCH 0/4] percpu: add basic stats and tracepoints to percpu allocator

There is limited visibility into the percpu memory allocator making it hard to understand usage patterns. Without these concrete numbers, we are left to conjecture about the correctness of percpu memory patterns and usage. Additionally, there is no mechanism to review the correctness/efficiency of

[PATCH 4/4] percpu: add tracepoint support for percpu memory

Add support for tracepoints to the following events: chunk allocation, chunk free, area allocation, area free, and area allocation failure. This should let us replay percpu memory requests and evaluate corresponding decisions. Signed-off-by: Dennis Zhou ---

[PATCH 4/4] percpu: add tracepoint support for percpu memory

Add support for tracepoints to the following events: chunk allocation, chunk free, area allocation, area free, and area allocation failure. This should let us replay percpu memory requests and evaluate corresponding decisions. Signed-off-by: Dennis Zhou --- include/trace/events/percpu.h | 125

[PATCH 0/4] percpu: add basic stats and tracepoints to percpu allocator

There is limited visibility into the percpu memory allocator making it hard to understand usage patterns. Without these concrete numbers, we are left to conjecture about the correctness of percpu memory patterns and usage. Additionally, there is no mechanism to review the correctness/efficiency of

[PATCH 3/4] percpu: expose statistics about percpu memory via debugfs

There is limited visibility into the use of percpu memory leaving us unable to reason about correctness of parameters and overall use of percpu memory. These counters and statistics aim to help understand basic statistics about percpu memory such as number of allocations over the lifetime,

[PATCH 3/4] percpu: expose statistics about percpu memory via debugfs

There is limited visibility into the use of percpu memory leaving us unable to reason about correctness of parameters and overall use of percpu memory. These counters and statistics aim to help understand basic statistics about percpu memory such as number of allocations over the lifetime,

Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

On Mon, Jun 19, 2017 at 01:02:18PM -0700, Laura Abbott wrote: > On 06/19/2017 11:43 AM, Paul Donohue wrote: > > I get the same results as you - x_max and y_max affect cursor speed, and > > x_res and y_res seem to have no effect. I can't seem to come up with any > > values that cause

Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

On Mon, Jun 19, 2017 at 01:02:18PM -0700, Laura Abbott wrote: > On 06/19/2017 11:43 AM, Paul Donohue wrote: > > I get the same results as you - x_max and y_max affect cursor speed, and > > x_res and y_res seem to have no effect. I can't seem to come up with any > > values that cause

Re: [PATCH v2 10/10] x86/mm: Try to preserve old TLB entries using PCID

Nadav Amit wrote: >> > Just to clarify: I asked since I don’t understand how the interaction with > PCID-unaware CR3 users go. Specifically, IIUC, arch_efi_call_virt_teardown() > can reload CR3 with an old PCID value. No? Please ignore this email. I realized it is not a

Re: [PATCH v2 10/10] x86/mm: Try to preserve old TLB entries using PCID

Nadav Amit wrote: >> > Just to clarify: I asked since I don’t understand how the interaction with > PCID-unaware CR3 users go. Specifically, IIUC, arch_efi_call_virt_teardown() > can reload CR3 with an old PCID value. No? Please ignore this email. I realized it is not a problem. Nadav

Re: [PATCH v2 10/10] x86/mm: Try to preserve old TLB entries using PCID

Andy Lutomirski wrote: > On Sat, Jun 17, 2017 at 11:26 PM, Nadav Amit wrote: >>> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote: >>> >>> PCID is a "process context ID" -- it's what other architectures call >>> an address space ID.

Re: [PATCH v2 10/10] x86/mm: Try to preserve old TLB entries using PCID

Andy Lutomirski wrote: > On Sat, Jun 17, 2017 at 11:26 PM, Nadav Amit wrote: >>> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote: >>> >>> PCID is a "process context ID" -- it's what other architectures call >>> an address space ID. Every non-global TLB entry is tagged with a >>> PCID,

Re: [PATCH 3.10 000/268] 3.10.107-stable review

Hi Guenter, On Mon, Jun 19, 2017 at 03:46:36PM -0700, Guenter Roeck wrote: > Build results: > total: 121 pass: 118 fail: 3 > Failed builds: > arm:at91_dt_defconfig > arm:sama5_defconfig > s390:defconfig > > Qemu test results: > total: 83 pass: 82 fail: 1 > Failed

Re: [PATCH 3.10 000/268] 3.10.107-stable review

Hi Guenter, On Mon, Jun 19, 2017 at 03:46:36PM -0700, Guenter Roeck wrote: > Build results: > total: 121 pass: 118 fail: 3 > Failed builds: > arm:at91_dt_defconfig > arm:sama5_defconfig > s390:defconfig > > Qemu test results: > total: 83 pass: 82 fail: 1 > Failed

Re: [PATCH v9 1/5] firmware: add extensible driver data params

Hi Greg, On 6/17/2017 2:38 PM, Greg KH wrote: On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote: On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote: On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote: As the firmware API evolves we keep extending functions

Re: [PATCH v9 1/5] firmware: add extensible driver data params

Hi Greg, On 6/17/2017 2:38 PM, Greg KH wrote: On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote: On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote: On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote: As the firmware API evolves we keep extending functions

Re: [PATCH 4.11 00/78] 4.11.7-stable review

On Mon, Jun 19, 2017 at 11:15:00PM +0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.7 release. > There are 78 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.11 00/78] 4.11.7-stable review

On Mon, Jun 19, 2017 at 11:15:00PM +0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.7 release. > There are 78 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.18 00/32] 3.18.58-stable review

On Mon, Jun 19, 2017 at 11:20:44PM +0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.58 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.18 00/32] 3.18.58-stable review

On Mon, Jun 19, 2017 at 11:20:44PM +0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.58 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.10 000/268] 3.10.107-stable review

On Mon, Jun 19, 2017 at 08:28:19PM +0200, Willy Tarreau wrote: > This is the start of the stable review cycle for the 3.10.107 release. > All patches will be posted as a response to this one. If anyone has any > issue with these being applied, please let me know. If anyone thinks some > important

Re: [PATCH 3.10 000/268] 3.10.107-stable review

On Mon, Jun 19, 2017 at 08:28:19PM +0200, Willy Tarreau wrote: > This is the start of the stable review cycle for the 3.10.107 release. > All patches will be posted as a response to this one. If anyone has any > issue with these being applied, please let me know. If anyone thinks some > important

<    1   2   3   4   5   6   7   8   9   10   >