Re: [GIT PULL] tpmdd fixes for Linux 4.8

lowing changes since commit d4d03f74a73f3b8b2801d4d02011b6b69778cbcc: > > apparmor: fix arg_size computation for when setprocattr is null terminated > (2016-07-12 08:43:10 -0700) > > are available in the git repository at: > > git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmd

Re: [GIT PULL] tpmdd fixes for Linux 4.8

lowing changes since commit d4d03f74a73f3b8b2801d4d02011b6b69778cbcc: > > apparmor: fix arg_size computation for when setprocattr is null terminated > (2016-07-12 08:43:10 -0700) > > are available in the git repository at: > > git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmd

Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Tue, Jul 19, 2016 at 02:22:36PM -0400, Vince Weaver wrote: > On Fri, 17 Jun 2016, Huang Rui wrote: > > > On Thu, Jun 16, 2016 at 06:47:00PM +0200, Borislav Petkov wrote: > > > On Thu, Jun 16, 2016 at 01:38:14PM +0800, Huang Rui wrote: > > > > I was told this feature would be supported on

Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Tue, Jul 19, 2016 at 02:22:36PM -0400, Vince Weaver wrote: > On Fri, 17 Jun 2016, Huang Rui wrote: > > > On Thu, Jun 16, 2016 at 06:47:00PM +0200, Borislav Petkov wrote: > > > On Thu, Jun 16, 2016 at 01:38:14PM +0800, Huang Rui wrote: > > > > I was told this feature would be supported on

[PATCH] NFC: pn533: Avoid a double free in error handling code

'phy' has been allocated with 'devm_kzalloc', so we should not free it using an explicit 'kfree'. It would result in a double free if the allocation of 'in_buf' fails. Signed-off-by: Christophe JAILLET --- drivers/nfc/pn533/usb.c | 9 +++-- 1 file changed, 3

[PATCH] NFC: pn533: Avoid a double free in error handling code

'phy' has been allocated with 'devm_kzalloc', so we should not free it using an explicit 'kfree'. It would result in a double free if the allocation of 'in_buf' fails. Signed-off-by: Christophe JAILLET --- drivers/nfc/pn533/usb.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-)

linux-next: manual merge of the kvms390 tree with the kvm-arm tree

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: include/uapi/linux/kvm.h between commit: 2b8ddd9337ee ("KVM: Extend struct kvm_msi to hold a 32-bit device ID") from the kvm-arm tree and commit: 6502a34cfd66 ("KVM: s390: allow user space to handle instr 0x")

linux-next: manual merge of the kvms390 tree with the kvm-arm tree

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: include/uapi/linux/kvm.h between commit: 2b8ddd9337ee ("KVM: Extend struct kvm_msi to hold a 32-bit device ID") from the kvm-arm tree and commit: 6502a34cfd66 ("KVM: s390: allow user space to handle instr 0x")

[PATCH v2 2/2] mtd: nand: Get rid of needless 'goto'

Using "goto" and "switch" statement only makes it harder to follow control flow and doesn't bring any advantages. Rewrite the code to avoid using "goto". Signed-off-by: Brian Norris Signed-off-by: Andrey Smirnov ---

[PATCH v2 2/2] mtd: nand: Get rid of needless 'goto'

Using "goto" and "switch" statement only makes it harder to follow control flow and doesn't bring any advantages. Rewrite the code to avoid using "goto". Signed-off-by: Brian Norris Signed-off-by: Andrey Smirnov --- drivers/mtd/nand/nand_base.c | 18 ++ 1 file changed, 6

[PATCH v2 1/2] mtd: nand: Error out if cmd_ctrl() is missing

If no user specified chip->select_chip() function is provided, code in nand_base.c will automatically set this hook to nand_select_chip(), which in turn depends on chip->cmd_ctrl() hook being valid. Not providing both of those functions in NAND controller driver (for example by mistake) will

[PATCH v2 1/2] mtd: nand: Error out if cmd_ctrl() is missing

If no user specified chip->select_chip() function is provided, code in nand_base.c will automatically set this hook to nand_select_chip(), which in turn depends on chip->cmd_ctrl() hook being valid. Not providing both of those functions in NAND controller driver (for example by mistake) will

linux-next: manual merge of the kvm-arm tree with the tip tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: virt/kvm/kvm_main.c between commit: 8c18b2d2d088 ("virt: Convert kvm hotplug to state machine") from the tip tree and commit: 8a39d00670f0 ("KVM: kvm_io_bus: Add kvm_io_bus_get_dev() call") from the kvm-arm tree.

linux-next: manual merge of the kvm-arm tree with the tip tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: virt/kvm/kvm_main.c between commit: 8c18b2d2d088 ("virt: Convert kvm hotplug to state machine") from the tip tree and commit: 8a39d00670f0 ("KVM: kvm_io_bus: Add kvm_io_bus_get_dev() call") from the kvm-arm tree.

linux-next: manual merge of the kvm-arm tree with the kvm tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: include/uapi/linux/kvm.h between commit: 3713131345fb ("KVM: x86: add KVM_CAP_X2APIC_API") from the kvm tree and commit: 2b8ddd9337ee ("KVM: Extend struct kvm_msi to hold a 32-bit device ID") from the kvm-arm

linux-next: manual merge of the kvm-arm tree with the kvm tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: include/uapi/linux/kvm.h between commit: 3713131345fb ("KVM: x86: add KVM_CAP_X2APIC_API") from the kvm tree and commit: 2b8ddd9337ee ("KVM: Extend struct kvm_msi to hold a 32-bit device ID") from the kvm-arm

[ANNOUNCE] kmod 23

kmod 23 is out: ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-23.tar.xz ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-23.tar.sign - Improvements: - Don't add comment to modules.devname if it would otherwise be empty to play nice with tools

[ANNOUNCE] kmod 23

kmod 23 is out: ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-23.tar.xz ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-23.tar.sign - Improvements: - Don't add comment to modules.devname if it would otherwise be empty to play nice with tools

Re: [PATCH 2/3] xen-scsiback: One function call less in scsiback_device_action() after error detection

On 20/07/16 07:10, SF Markus Elfring wrote: > @@ -606,7 +606,7 @@ static void scsiback_device_action(struct > vscsibk_pend *pending_req, > tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL); > if (!tmr) { > target_put_sess_cmd(se_cmd); > - goto

Re: [PATCH 2/3] xen-scsiback: One function call less in scsiback_device_action() after error detection

On 20/07/16 07:10, SF Markus Elfring wrote: > @@ -606,7 +606,7 @@ static void scsiback_device_action(struct > vscsibk_pend *pending_req, > tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL); > if (!tmr) { > target_put_sess_cmd(se_cmd); > - goto

linux-next: manual merge of the kvm-arm tree with the tip tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: include/linux/irqchip/arm-gic-v3.h between commits: 9347359ad0ae ("irqchip/gicv3-its: Split its_alloc_tables() into two functions") 3faf24ea894a ("irqchip/gicv3-its: Implement two-level(indirect) device table

linux-next: manual merge of the kvm-arm tree with the tip tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: include/linux/irqchip/arm-gic-v3.h between commits: 9347359ad0ae ("irqchip/gicv3-its: Split its_alloc_tables() into two functions") 3faf24ea894a ("irqchip/gicv3-its: Implement two-level(indirect) device table

[PATCH v2] 2c: mv64xxx: Use clk_enable_prepare and clk_disable_unprepare

Replace clk_enable and clk_prepare with clk_enable_prepare and clk_disable and clk_unprepare with clk_disable_unprepare. The Coccinelle semantic patch used to make this change is as follows: @@ expression e; @@ - clk_prepare(e); - clk_enable(e); + clk_prepare_enable(e); @@ expression e; @@ -

[PATCH v2] 2c: mv64xxx: Use clk_enable_prepare and clk_disable_unprepare

Replace clk_enable and clk_prepare with clk_enable_prepare and clk_disable and clk_unprepare with clk_disable_unprepare. The Coccinelle semantic patch used to make this change is as follows: @@ expression e; @@ - clk_prepare(e); - clk_enable(e); + clk_prepare_enable(e); @@ expression e; @@ -

Re: [PATCH 2/3] xen-scsiback: One function call less in scsiback_device_action() after error detection

@@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend *pending_req, tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL); if (!tmr) { target_put_sess_cmd(se_cmd); - goto err; + goto do_resp; } >>>

Re: [PATCH 2/3] xen-scsiback: One function call less in scsiback_device_action() after error detection

@@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend *pending_req, tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL); if (!tmr) { target_put_sess_cmd(se_cmd); - goto err; + goto do_resp; } >>>

Re: [RFC PATCH 0/3] ECAM quirks handling for ARM64 platforms

On 19.07.2016 23:17, Bjorn Helgaas wrote: On Thu, Jun 02, 2016 at 10:41:00AM +0200, Tomasz Nowicki wrote: This series bases on pending ACPI PCI support for ARM64: https://lkml.org/lkml/2016/5/30/468 Quirk handling relies on an idea of matching MCFG OEM ID and OEM revision (the ones from

Re: [PATCH v3 02/12] binfmt_flat: convert printk invocations to their modern form

On Tue, 19 Jul 2016, Joe Perches wrote: > On Wed, 2016-07-20 at 00:20 -0400, Nicolas Pitre wrote: > > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c > [] > > @@ -15,6 +15,8 @@ > >   * JAN/99 -- coded full program relocation (g...@snapgear.com) > >   */ > >   > > +#define pr_fmt(fmt)

Re: [RFC PATCH 0/3] ECAM quirks handling for ARM64 platforms

On 19.07.2016 23:17, Bjorn Helgaas wrote: On Thu, Jun 02, 2016 at 10:41:00AM +0200, Tomasz Nowicki wrote: This series bases on pending ACPI PCI support for ARM64: https://lkml.org/lkml/2016/5/30/468 Quirk handling relies on an idea of matching MCFG OEM ID and OEM revision (the ones from

Re: [PATCH v3 02/12] binfmt_flat: convert printk invocations to their modern form

On Tue, 19 Jul 2016, Joe Perches wrote: > On Wed, 2016-07-20 at 00:20 -0400, Nicolas Pitre wrote: > > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c > [] > > @@ -15,6 +15,8 @@ > >   * JAN/99 -- coded full program relocation (g...@snapgear.com) > >   */ > >   > > +#define pr_fmt(fmt)

Re: [ANNOUNCE] 2016-Q2 release of KVMGT (Was Re: KVMGT - the implementation of ...)

Hi all, We are pleased to announce another update of Intel GVT-g for KVM. Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with mediated pass-through, starting from 5th generation Intel Core™ processors with Intel Graphics processors. A virtual GPU instance is

Re: [ANNOUNCE] 2016-Q2 release of KVMGT (Was Re: KVMGT - the implementation of ...)

Hi all, We are pleased to announce another update of Intel GVT-g for KVM. Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with mediated pass-through, starting from 5th generation Intel Core™ processors with Intel Graphics processors. A virtual GPU instance is

Re: [RFC] Avoid mutex starvation when optimistic spinning is disabled

On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote: > Hi Imre, > > Here is a patch which prevents a thread from spending too much "time" > waiting for a mutex in the !CONFIG_MUTEX_SPIN_ON_OWNER case. > > Would you like to try this out and see if this addresses the mutex > starvation issue you

Re: [RFC] Avoid mutex starvation when optimistic spinning is disabled

On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote: > Hi Imre, > > Here is a patch which prevents a thread from spending too much "time" > waiting for a mutex in the !CONFIG_MUTEX_SPIN_ON_OWNER case. > > Would you like to try this out and see if this addresses the mutex > starvation issue you

Re: staging/wilc1000: wrong conversion to completion?

On 11 July 2016 at 13:38, Arnd Bergmann wrote: > On Monday, July 11, 2016 9:41:15 AM CEST Jiri Slaby wrote: >> Hi, >> >> while looking at this commit: >> >> commit b27a6d5e636ac80b223a18ca2b3c892f1caef9e3 >> Author: Binoy Jayan >> Date: Wed Jun 15

Re: staging/wilc1000: wrong conversion to completion?

On 11 July 2016 at 13:38, Arnd Bergmann wrote: > On Monday, July 11, 2016 9:41:15 AM CEST Jiri Slaby wrote: >> Hi, >> >> while looking at this commit: >> >> commit b27a6d5e636ac80b223a18ca2b3c892f1caef9e3 >> Author: Binoy Jayan >> Date: Wed Jun 15 11:00:34 2016 +0530 >> >> staging:

Re: [PATCH 2/3] xen-scsiback: One function call less in scsiback_device_action() after error detection

On 19/07/16 16:56, SF Markus Elfring wrote: >>> @@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend >>> *pending_req, >>> tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL); >>> if (!tmr) { >>> target_put_sess_cmd(se_cmd); >>> - goto err;

Re: [PATCH 2/3] xen-scsiback: One function call less in scsiback_device_action() after error detection

On 19/07/16 16:56, SF Markus Elfring wrote: >>> @@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend >>> *pending_req, >>> tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL); >>> if (!tmr) { >>> target_put_sess_cmd(se_cmd); >>> - goto err;

[PATCH kernel v2 1/2] powerpc/iommu: Stop using @current in mm_iommu_xxx

In some situations the userspace memory context may live longer than the userspace process itself so if we need to do proper memory context cleanup, we better cache @mm and use it later when the process is gone (@current or @current->mm are NULL). This changes mm_iommu_xxx API to receive

[PATCH kernel v2 2/2] powerpc/mm/iommu: Put pages on process exit

At the moment VFIO IOMMU SPAPR v2 driver pins all guest RAM pages when the userspace starts using VFIO. When the userspace process finishes, all the pinned pages need to be put; this is done as a part of the userspace memory context (MM) destruction which happens on the very last mmdrop(). This

[PATCH kernel v2 1/2] powerpc/iommu: Stop using @current in mm_iommu_xxx

In some situations the userspace memory context may live longer than the userspace process itself so if we need to do proper memory context cleanup, we better cache @mm and use it later when the process is gone (@current or @current->mm are NULL). This changes mm_iommu_xxx API to receive

[PATCH kernel v2 2/2] powerpc/mm/iommu: Put pages on process exit

At the moment VFIO IOMMU SPAPR v2 driver pins all guest RAM pages when the userspace starts using VFIO. When the userspace process finishes, all the pinned pages need to be put; this is done as a part of the userspace memory context (MM) destruction which happens on the very last mmdrop(). This

[PATCH kernel v2 0/2] powerpc/mm/iommu: Put pages on process exit

This is a fix to a bug when guest memory stays Active after QEMU process exited. This happened because the QEMU memory context was not released in a short period of time after QEMU process exited. More details are in the commit logs. Please comment. Thanks. Alexey Kardashevskiy (2):

[PATCH kernel v2 0/2] powerpc/mm/iommu: Put pages on process exit

This is a fix to a bug when guest memory stays Active after QEMU process exited. This happened because the QEMU memory context was not released in a short period of time after QEMU process exited. More details are in the commit logs. Please comment. Thanks. Alexey Kardashevskiy (2):

Re: [PATCH v3 02/12] binfmt_flat: convert printk invocations to their modern form

On Wed, 2016-07-20 at 00:20 -0400, Nicolas Pitre wrote: > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c [] > @@ -15,6 +15,8 @@ >   * JAN/99 -- coded full program relocation (g...@snapgear.com) >   */ >   > +#define pr_fmt(fmt) "BINFMT_FLAT: : " fmt Why the double colon? Much more common

Re: [PATCH v3 02/12] binfmt_flat: convert printk invocations to their modern form

On Wed, 2016-07-20 at 00:20 -0400, Nicolas Pitre wrote: > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c [] > @@ -15,6 +15,8 @@ >   * JAN/99 -- coded full program relocation (g...@snapgear.com) >   */ >   > +#define pr_fmt(fmt) "BINFMT_FLAT: : " fmt Why the double colon? Much more common

[PATCH] iio: accel: bma180: use iio helper function to guarantee direct mode

Replace the code that guarantees the device stays in direct mode with iio_device_claim_direct_mode() which does same. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- Peter: I was not clear if we want to keep the data->mutex lock in addition

[PATCH] iio: accel: bma180: use iio helper function to guarantee direct mode

Replace the code that guarantees the device stays in direct mode with iio_device_claim_direct_mode() which does same. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- Peter: I was not clear if we want to keep the data->mutex lock in addition to claiming direct mode. I see that lock

[PATCH v3 02/12] binfmt_flat: convert printk invocations to their modern form

Signed-off-by: Nicolas Pitre --- fs/binfmt_flat.c | 118 --- 1 file changed, 51 insertions(+), 67 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 085059d879..36f5bb6b2c 100644 --- a/fs/binfmt_flat.c +++

[PATCH v3 04/12] elf_fdpic_transfer_args_to_stack(): make it generic

This copying of arguments and environment is common to both NOMMU binary formats we support. Let's make the elf_fdpic version available to the flat format as well. While at it, improve the code a bit not to copy below the actual data area. Signed-off-by: Nicolas Pitre

[PATCH v3 08/12] binfmt_flat: use proper user space accessors with old relocs code

Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 30 +++--- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 34f815540e..28fc272d9a 100644 ---

[PATCH v3 07/12] binfmt_flat: use proper user space accessors with relocs processing code

Relocs are fixed up in place in user space memory. The appropriate accessors are required for this code to work with an active MMU. The architecture specific handlers for ARM and M68K are also covered. SuperH and Xtensa are left out as they doesn't implement __get_user_unaligned() and

[PATCH v3 02/12] binfmt_flat: convert printk invocations to their modern form

Signed-off-by: Nicolas Pitre --- fs/binfmt_flat.c | 118 --- 1 file changed, 51 insertions(+), 67 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 085059d879..36f5bb6b2c 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c

[PATCH v3 04/12] elf_fdpic_transfer_args_to_stack(): make it generic

This copying of arguments and environment is common to both NOMMU binary formats we support. Let's make the elf_fdpic version available to the flat format as well. While at it, improve the code a bit not to copy below the actual data area. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer

[PATCH v3 08/12] binfmt_flat: use proper user space accessors with old relocs code

Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 30 +++--- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 34f815540e..28fc272d9a 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c

[PATCH v3 07/12] binfmt_flat: use proper user space accessors with relocs processing code

Relocs are fixed up in place in user space memory. The appropriate accessors are required for this code to work with an active MMU. The architecture specific handlers for ARM and M68K are also covered. SuperH and Xtensa are left out as they doesn't implement __get_user_unaligned() and

Re: [v2,1/2] refactor code parsing size based on memory range

Ping.. On Friday 24 June 2016 10:45 PM, Hari Bathini wrote: On 06/24/2016 10:56 AM, Michael Ellerman wrote: On Wed, 2016-22-06 at 19:25:26 UTC, Hari Bathini wrote: Currently, crashkernel parameter supports the below syntax to parse size based on memory range: crashkernel=:[,:,...]

Re: [v2,1/2] refactor code parsing size based on memory range

Ping.. On Friday 24 June 2016 10:45 PM, Hari Bathini wrote: On 06/24/2016 10:56 AM, Michael Ellerman wrote: On Wed, 2016-22-06 at 19:25:26 UTC, Hari Bathini wrote: Currently, crashkernel parameter supports the below syntax to parse size based on memory range: crashkernel=:[,:,...]

[PATCH v3 09/12] binfmt_flat: use clear_user() rather than memset() to clear .bss

This is needed on systems with a MMU. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 28fc272d9a..0d89830f76

[PATCH v3 06/12] binfmt_flat: clean up create_flat_tables() and stack accesses

In addition to better code clarity, this brings proper usage of user memory accessors everywhere the stack is touched. This is essential for making this work on MMU systems. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 117

[PATCH v3 03/12] binfmt_flat: prevent kernel dammage from corrupted executable headers

Signed-off-by: Nicolas Pitre --- fs/binfmt_flat.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 36f5bb6b2c..9c76d9a222 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -470,6 +470,17 @@ static int

[PATCH v3 12/12] binfmt_flat: allow compressed flat binary format to work on MMU systems

Let's take the simple and obvious approach by decompressing the binary into a kernel buffer and then copying it to user space. Those who are looking for top performance on an MMU system are unlikely to choose this executable format anyway. Signed-off-by: Nicolas Pitre

[PATCH v3 05/12] binfmt_flat: use generic transfer_args_to_stack()

This gets rid of the rather ugly, open coded and suboptimal copy code. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/fs/binfmt_flat.c

[PATCH v3 09/12] binfmt_flat: use clear_user() rather than memset() to clear .bss

This is needed on systems with a MMU. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 28fc272d9a..0d89830f76 100644 --- a/fs/binfmt_flat.c +++

[PATCH v3 06/12] binfmt_flat: clean up create_flat_tables() and stack accesses

In addition to better code clarity, this brings proper usage of user memory accessors everywhere the stack is touched. This is essential for making this work on MMU systems. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 117

[PATCH v3 03/12] binfmt_flat: prevent kernel dammage from corrupted executable headers

Signed-off-by: Nicolas Pitre --- fs/binfmt_flat.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 36f5bb6b2c..9c76d9a222 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -470,6 +470,17 @@ static int load_flat_file(struct

[PATCH v3 12/12] binfmt_flat: allow compressed flat binary format to work on MMU systems

Let's take the simple and obvious approach by decompressing the binary into a kernel buffer and then copying it to user space. Those who are looking for top performance on an MMU system are unlikely to choose this executable format anyway. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer

[PATCH v3 05/12] binfmt_flat: use generic transfer_args_to_stack()

This gets rid of the rather ugly, open coded and suboptimal copy code. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index

[PATCH v3 11/12] binfmt_flat: add MMU-specific support

Not much else to do at this point except for the different stack setups. SuperH and Xtensa could be added to the allowed list if they implement __put_user_unaligned() and __get_user_unaligned(). Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer ---

[PATCH v3 01/12] binfmt_flat: assorted cleanups

Remove excessive casts, do some code grouping, etc. No functional changes. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 118 ++- 1 file changed, 56 insertions(+), 62

[PATCH v3 10/12] binfmt_flat: update libraries' data segment pointer with userspace accessors

This is needed on systems with a MMU. This also gets rid of the strangest C code I've seen lateli i.e. an integer indexed with a pointer value within square brackets. That really looked backwards. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer ---

[PATCH v3 11/12] binfmt_flat: add MMU-specific support

Not much else to do at this point except for the different stack setups. SuperH and Xtensa could be added to the allowed list if they implement __put_user_unaligned() and __get_user_unaligned(). Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/Kconfig.binfmt | 3 ++-

[PATCH v3 01/12] binfmt_flat: assorted cleanups

Remove excessive casts, do some code grouping, etc. No functional changes. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 118 ++- 1 file changed, 56 insertions(+), 62 deletions(-) diff --git a/fs/binfmt_flat.c

[PATCH v3 10/12] binfmt_flat: update libraries' data segment pointer with userspace accessors

This is needed on systems with a MMU. This also gets rid of the strangest C code I've seen lateli i.e. an integer indexed with a pointer value within square brackets. That really looked backwards. Signed-off-by: Nicolas Pitre Reviewed-by: Greg Ungerer --- fs/binfmt_flat.c | 19

[PATCH v3 00/12] allow BFLT executables on systems with a MMU

This series provides the necessary changes to allow "flat" executable binaries meant for no-MMU systems to actually run on systems with a MMU. This can also be found in the following git repo: git://git.linaro.org/people/nicolas.pitre/linux binfmt_flat_with_mmu *Why?* Because

[PATCH v3 00/12] allow BFLT executables on systems with a MMU

This series provides the necessary changes to allow "flat" executable binaries meant for no-MMU systems to actually run on systems with a MMU. This can also be found in the following git repo: git://git.linaro.org/people/nicolas.pitre/linux binfmt_flat_with_mmu *Why?* Because

RE: [PATCH v17 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > >> From: kbuild test robot [mailto:l...@intel.com] > >> [auto build test WARNING on net-next/master] > >> > >> url:https://github.com/0day-ci/linux/commits/Dexuan-Cui/introduce- > >> Hyper-V-VM-Sockets-hv_sock/20160715-223433 > >> config:

RE: [PATCH v17 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > >> From: kbuild test robot [mailto:l...@intel.com] > >> [auto build test WARNING on net-next/master] > >> > >> url:https://github.com/0day-ci/linux/commits/Dexuan-Cui/introduce- > >> Hyper-V-VM-Sockets-hv_sock/20160715-223433 > >> config:

[PATCH] make __section_nr more efficient

When CONFIG_SPARSEMEM_EXTREME is disabled, __section_nr can get the section number with a subtraction directly. Signed-off-by: Zhou Chengming --- mm/sparse.c | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/mm/sparse.c b/mm/sparse.c

[PATCH] make __section_nr more efficient

When CONFIG_SPARSEMEM_EXTREME is disabled, __section_nr can get the section number with a subtraction directly. Signed-off-by: Zhou Chengming --- mm/sparse.c | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/mm/sparse.c b/mm/sparse.c index 5d0cf45..36d7bbb

Re: [PATCH 0/3] Enable legacy irq mode before jump to kexec/kdump kernel

Hi Jiangang, On 07/20/16 at 03:54am, Wei, Jiangang wrote: > Hi Baoquan He, > > Well, Indeed there‘s a relationship between the dump-capture hangs in > calibrate_delay_converge() and the interrupt mode. > > but there‘s no essential difference between your patches and mine that > calls

Re: [PATCH 0/3] Enable legacy irq mode before jump to kexec/kdump kernel

Hi Jiangang, On 07/20/16 at 03:54am, Wei, Jiangang wrote: > Hi Baoquan He, > > Well, Indeed there‘s a relationship between the dump-capture hangs in > calibrate_delay_converge() and the interrupt mode. > > but there‘s no essential difference between your patches and mine that > calls

Re: [Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware

From: Yeshaswi M R Gowda Date: Mon, 18 Jul 2016 22:42:14 -0700 > +config CRYPTO_DEV_CHELSIO > + tristate "Chelsio Crypto Co-processor Driver" > + depends on PCI && NETDEVICES && ETHERNET > + select CRYPTO_SHA1 > + select CRYPTO_SHA256 > + select

[PATCH 3/3] ARM: pxa: add module.h for spitz symbol_get/symbol_put usage

During unrelated work, attempting to remove an include of the linux/module.h in favour of "struct module;" in order to reduce header entanglement, we found doing so caused a build failure in this file. mach-pxa/spitz.c: In function 'spitz_bl_kick_battery': mach-pxa/spitz.c:524:2: error: implicit

Re: [Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware

From: Yeshaswi M R Gowda Date: Mon, 18 Jul 2016 22:42:14 -0700 > +config CRYPTO_DEV_CHELSIO > + tristate "Chelsio Crypto Co-processor Driver" > + depends on PCI && NETDEVICES && ETHERNET > + select CRYPTO_SHA1 > + select CRYPTO_SHA256 > + select CRYPTO_SHA512 > + select

[PATCH 3/3] ARM: pxa: add module.h for spitz symbol_get/symbol_put usage

During unrelated work, attempting to remove an include of the linux/module.h in favour of "struct module;" in order to reduce header entanglement, we found doing so caused a build failure in this file. mach-pxa/spitz.c: In function 'spitz_bl_kick_battery': mach-pxa/spitz.c:524:2: error: implicit

[PATCH 0/3] ARM: fix three implicit module use cases fed via gpio

While working on some for-4.9 cleanups of linux/gpio/driver.h it was found that changes there caused build failures when walking all the ARM defconfigs, in ARM specific mach-* files. The proposed GPIO header change is just this: --- ---

[PATCH 2/3] ARM: pxa: add module.h for corgi symbol_get/symbol_put usage

During unrelated work, attempting to remove an include of the linux/module.h in favour of "struct module;" in order to reduce header entanglement, we found doing so caused a build failure in this file. mach-pxa/corgi.c: In function 'corgi_bl_kick_battery': mach-pxa/corgi.c:548:2: error: implicit

[PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

During unrelated work, attempting to remove an include of the linux/module.h in favour of "struct module;" in order to reduce header entanglement, we found doing so caused a build failure in this file. It turns out this file uses __init_or_module which lives in the module.h header, but it wasn't

[PATCH 0/3] ARM: fix three implicit module use cases fed via gpio

While working on some for-4.9 cleanups of linux/gpio/driver.h it was found that changes there caused build failures when walking all the ARM defconfigs, in ARM specific mach-* files. The proposed GPIO header change is just this: --- ---

[PATCH 2/3] ARM: pxa: add module.h for corgi symbol_get/symbol_put usage

During unrelated work, attempting to remove an include of the linux/module.h in favour of "struct module;" in order to reduce header entanglement, we found doing so caused a build failure in this file. mach-pxa/corgi.c: In function 'corgi_bl_kick_battery': mach-pxa/corgi.c:548:2: error: implicit

[PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

During unrelated work, attempting to remove an include of the linux/module.h in favour of "struct module;" in order to reduce header entanglement, we found doing so caused a build failure in this file. It turns out this file uses __init_or_module which lives in the module.h header, but it wasn't

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

On Tue, 19 Jul 2016, Geert Uytterhoeven wrote: > On Tue, Jul 19, 2016 at 6:52 AM, Greg Ungerer wrote: > > Seeing as you have modified quite a few printk calls is it worth > > while annotating them with appropriate KERN_ERR, KERN_INFO, etc? > > You mean pr_err(), pr_info(),

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

On Tue, 19 Jul 2016, Geert Uytterhoeven wrote: > On Tue, Jul 19, 2016 at 6:52 AM, Greg Ungerer wrote: > > Seeing as you have modified quite a few printk calls is it worth > > while annotating them with appropriate KERN_ERR, KERN_INFO, etc? > > You mean pr_err(), pr_info(), ... ;-) Done.

Re: [RFC PATCH] locks: fix file locking on overlayfs

On Tue, Jul 19, 2016 at 8:01 PM, Jeff Layton wrote: > On Tue, 2016-07-19 at 14:27 +0200, Miklos Szeredi wrote: >> > diff --git a/mm/mmap.c b/mm/mmap.c >> index de2c1769cc68..a023caff19d5 100644 >> --- a/mm/mmap.c >> +++ b/mm/mmap.c >> @@ -126,7 +126,7 @@ static void

Re: [RFC PATCH] locks: fix file locking on overlayfs

On Tue, Jul 19, 2016 at 8:01 PM, Jeff Layton wrote: > On Tue, 2016-07-19 at 14:27 +0200, Miklos Szeredi wrote: >> > diff --git a/mm/mmap.c b/mm/mmap.c >> index de2c1769cc68..a023caff19d5 100644 >> --- a/mm/mmap.c >> +++ b/mm/mmap.c >> @@ -126,7 +126,7 @@ static void

[PATCH] arm64: dts: mt8173: add tvdpll and vencpll clocks for 4K support

From: Junzhi Zhao When the resolution is set to 4k*2k, the hdmi pixel clock will be 250MHz, however, the correct pixel clock should be 297MHz. Fix this error by adding the correct tvdpll clocks. If MT8173 can support 4K, the vencpll clock should be 800MHz. Add the

[PATCH] arm64: dts: mt8173: add tvdpll and vencpll clocks for 4K support

From: Junzhi Zhao When the resolution is set to 4k*2k, the hdmi pixel clock will be 250MHz, however, the correct pixel clock should be 297MHz. Fix this error by adding the correct tvdpll clocks. If MT8173 can support 4K, the vencpll clock should be 800MHz. Add the vencpll clocks to support 4K.

[PATCH 2/4] drm/mediatek: enhance the HDMI driving current

From: Junzhi Zhao In order to improve 4K resolution performance, we have to enhance the HDMI driving currend when clock rate is greater than 165MHz. Signed-off-by: Junzhi Zhao Signed-off-by: Bibby Hsieh ---

[PATCH 2/4] drm/mediatek: enhance the HDMI driving current

From: Junzhi Zhao In order to improve 4K resolution performance, we have to enhance the HDMI driving currend when clock rate is greater than 165MHz. Signed-off-by: Junzhi Zhao Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 89 +--- 1

  1   2   3   4   5   6   7   8   9   10   >