[RFC v3 14/17] x86/mm: Update the handle_speculative_fault's path

If handle_speculative_fault failed due to a VM ERROR, we try again the slow path to allow the signal to be delivered. Signed-off-by: Laurent Dufour --- arch/x86/mm/fault.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git

[RFC v3 14/17] x86/mm: Update the handle_speculative_fault's path

If handle_speculative_fault failed due to a VM ERROR, we try again the slow path to allow the signal to be delivered. Signed-off-by: Laurent Dufour --- arch/x86/mm/fault.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/arch/x86/mm/fault.c

[RFC v3 11/17] mm/spf; fix lock dependency against mapping->i_mmap_rwsem

kworker/32:1/819 is trying to acquire lock: (>vm_sequence){+.+...}, at: [] zap_page_range_single+0xd0/0x1a0 but task is already holding lock: (>i_mmap_rwsem){..}, at: [] unmap_mapping_range+0x7c/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse

[RFC v3 11/17] mm/spf; fix lock dependency against mapping->i_mmap_rwsem

kworker/32:1/819 is trying to acquire lock: (>vm_sequence){+.+...}, at: [] zap_page_range_single+0xd0/0x1a0 but task is already holding lock: (>i_mmap_rwsem){..}, at: [] unmap_mapping_range+0x7c/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse

[RFC v3 15/17] mm/spf: Add check on the VMA's flags

When handling speculative page fault we should check for the VMA's access permission as it is done in handle_mm_fault() or access_error in x86's fault handler. Signed-off-by: Laurent Dufour --- mm/memory.c | 24 1 file changed, 24

[RFC v3 15/17] mm/spf: Add check on the VMA's flags

When handling speculative page fault we should check for the VMA's access permission as it is done in handle_mm_fault() or access_error in x86's fault handler. Signed-off-by: Laurent Dufour --- mm/memory.c | 24 1 file changed, 24 insertions(+) diff --git a/mm/memory.c

[RFC v3 05/17] RCU free VMAs

From: Peter Zijlstra Manage the VMAs with SRCU such that we can do a lockless VMA lookup. We put the fput(vma->vm_file) in the SRCU callback, this keeps files valid during speculative faults, this is possible due to the delayed fput work by Al Viro -- do we need

[RFC v3 05/17] RCU free VMAs

From: Peter Zijlstra Manage the VMAs with SRCU such that we can do a lockless VMA lookup. We put the fput(vma->vm_file) in the SRCU callback, this keeps files valid during speculative faults, this is possible due to the delayed fput work by Al Viro -- do we need srcu_barrier() in unmount

[RFC v3 13/17] mm/spf Protect vm_policy's changes against speculative pf

Mark the VMA touched when policy changes are applied to it so that speculative page fault will be aborted. Signed-off-by: Laurent Dufour --- mm/mempolicy.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c

[RFC v3 13/17] mm/spf Protect vm_policy's changes against speculative pf

Mark the VMA touched when policy changes are applied to it so that speculative page fault will be aborted. Signed-off-by: Laurent Dufour --- mm/mempolicy.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 1518b022927d..57ec8d0a9c95

[RFC v3 17/17] mm/spf: protect mremap() against speculative pf

mremap() is modifying the VMA layout and thus must be protected against the speculative page fault handler. XXX: Is the change to vma->vm_flags to set VM_ACCOUNT require the protection ? Signed-off-by: Laurent Dufour --- mm/mremap.c | 7 +++ 1 file changed, 7

[RFC v3 17/17] mm/spf: protect mremap() against speculative pf

mremap() is modifying the VMA layout and thus must be protected against the speculative page fault handler. XXX: Is the change to vma->vm_flags to set VM_ACCOUNT require the protection ? Signed-off-by: Laurent Dufour --- mm/mremap.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[RFC v3 12/17] mm/spf: Protect changes to vm_flags

Protect VMA's flags change against the speculative page fault handler. Signed-off-by: Laurent Dufour --- fs/proc/task_mmu.c | 2 ++ mm/mempolicy.c | 2 ++ mm/mlock.c | 9 ++--- mm/mmap.c | 2 ++ mm/mprotect.c | 2 ++ 5 files changed, 14

[RFC v3 00/17] Speculative page faults

This is a port on kernel 4.10 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore. http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-0-6-Another-go-at-speculative-page-faults-tt965642.html#none This series is functional on x86, but there may be some pending

[RFC v3 12/17] mm/spf: Protect changes to vm_flags

Protect VMA's flags change against the speculative page fault handler. Signed-off-by: Laurent Dufour --- fs/proc/task_mmu.c | 2 ++ mm/mempolicy.c | 2 ++ mm/mlock.c | 9 ++--- mm/mmap.c | 2 ++ mm/mprotect.c | 2 ++ 5 files changed, 14 insertions(+), 3

[RFC v3 00/17] Speculative page faults

This is a port on kernel 4.10 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore. http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-0-6-Another-go-at-speculative-page-faults-tt965642.html#none This series is functional on x86, but there may be some pending

Re: [PATCH v3] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

On 27.04.2017 18:15, Eric W. Biederman wrote: > Kirill Tkhai writes: > >> On implementing of nested pid namespaces support in CRIU >> (checkpoint-restore in userspace tool) we run into >> the situation, that it's impossible to create a task with >> specific NSpid

Re: [PATCH v3] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

On 27.04.2017 18:15, Eric W. Biederman wrote: > Kirill Tkhai writes: > >> On implementing of nested pid namespaces support in CRIU >> (checkpoint-restore in userspace tool) we run into >> the situation, that it's impossible to create a task with >> specific NSpid effectively. After commit

[RFC v3 06/17] mm: Provide speculative fault infrastructure

From: Peter Zijlstra Provide infrastructure to do a speculative fault (not holding mmap_sem). The not holding of mmap_sem means we can race against VMA change/removal and page-table destruction. We use the SRCU VMA freeing to keep the VMA around. We use the VMA seqcount to

[RFC v3 06/17] mm: Provide speculative fault infrastructure

From: Peter Zijlstra Provide infrastructure to do a speculative fault (not holding mmap_sem). The not holding of mmap_sem means we can race against VMA change/removal and page-table destruction. We use the SRCU VMA freeing to keep the VMA around. We use the VMA seqcount to detect change

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/2017 12:25 AM, Dave Young wrote: > On 04/21/17 at 02:55pm, Dave Hansen wrote: >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can >>> determine if SME is active. >>> >>> A new directory will be created: >>>

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/2017 12:25 AM, Dave Young wrote: > On 04/21/17 at 02:55pm, Dave Hansen wrote: >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can >>> determine if SME is active. >>> >>> A new directory will be created: >>>

Re: [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms

On Thu, Apr 27, 2017 at 09:16:41PM +0530, Ganapatrao Kulkarni wrote: > > Could you please give my diff a go? > > i tried your diff, and testing looks ok. Can I take that as a Tested-by when I post this as a proper patch? > below is the cleanly merged diff on top of latest commit > f832460 Merge

Re: [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms

On Thu, Apr 27, 2017 at 09:16:41PM +0530, Ganapatrao Kulkarni wrote: > > Could you please give my diff a go? > > i tried your diff, and testing looks ok. Can I take that as a Tested-by when I post this as a proper patch? > below is the cleanly merged diff on top of latest commit > f832460 Merge

[PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked() (was: Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem)

Hi Catalin/Will, The below addresses a boot failure Catalin spotted in next-20170424, based on Sebastian's patch [1]. I've given it a spin on Juno R1, where I can reproduce the issue prior to applying this patch. I believe this would need to go via tip, as the issue is a result of change in the

[PATCH] arm64: cpufeature: use static_branch_enable_cpuslocked() (was: Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem)

Hi Catalin/Will, The below addresses a boot failure Catalin spotted in next-20170424, based on Sebastian's patch [1]. I've given it a spin on Juno R1, where I can reproduce the issue prior to applying this patch. I believe this would need to go via tip, as the issue is a result of change in the

Re: [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms

On Thu, Apr 27, 2017 at 8:04 PM, Mark Rutland wrote: > On Wed, Apr 26, 2017 at 11:49:46PM +0530, Ganapatrao Kulkarni wrote: >> On Wed, Apr 26, 2017 at 10:42 PM, Mark Rutland wrote: >> > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c

Re: [PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

On Tue, Apr 18, 2017 at 04:17:27PM -0500, Tom Lendacky wrote: > Add support for Secure Memory Encryption (SME). This initial support > provides a Kconfig entry to build the SME support into the kernel and > defines the memory encryption mask that will be used in subsequent > patches to mark pages

Re: [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms

On Thu, Apr 27, 2017 at 8:04 PM, Mark Rutland wrote: > On Wed, Apr 26, 2017 at 11:49:46PM +0530, Ganapatrao Kulkarni wrote: >> On Wed, Apr 26, 2017 at 10:42 PM, Mark Rutland wrote: >> > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c >> > index 13b5499..638aefa 100644 >> > ---

Re: [PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

On Tue, Apr 18, 2017 at 04:17:27PM -0500, Tom Lendacky wrote: > Add support for Secure Memory Encryption (SME). This initial support > provides a Kconfig entry to build the SME support into the kernel and > defines the memory encryption mask that will be used in subsequent > patches to mark pages

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 26/04/17 09:56 PM, Herbert Xu wrote: > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in the caam driver >> and shash library. >> >> Signed-off-by: Logan Gunthorpe >> Cc: Herbert Xu

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 26/04/17 09:56 PM, Herbert Xu wrote: > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in the caam driver >> and shash library. >> >> Signed-off-by: Logan Gunthorpe >> Cc: Herbert Xu >> Cc: "David S. Miller" >> --- >>

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 12:53 AM, Christoph Hellwig wrote: > I think you'll need to follow the existing kmap semantics and never > fail the iomem version either. Otherwise you'll have a special case > that's almost never used that has a different error path. > > Again, wrong way. Suddenly making things

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 12:53 AM, Christoph Hellwig wrote: > I think you'll need to follow the existing kmap semantics and never > fail the iomem version either. Otherwise you'll have a special case > that's almost never used that has a different error path. > > Again, wrong way. Suddenly making things

Re: [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI

On Thu, 27 Apr 2017 17:28:07 +0200 Petr Mladek wrote: > > When I get a chance, I'll see if I can insert a trigger to crash the > > kernel from NMI on another box and see if this patch helps. > > I actually tested it here using this hack: > > diff --cc lib/nmi_backtrace.c >

Re: [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI

On Thu, 27 Apr 2017 17:28:07 +0200 Petr Mladek wrote: > > When I get a chance, I'll see if I can insert a trigger to crash the > > kernel from NMI on another box and see if this patch helps. > > I actually tested it here using this hack: > > diff --cc lib/nmi_backtrace.c > index

Re: [PATCH] irqchip/gicv3-its: use IORT only if IOMMU support is enabled

On Thu, Apr 27, 2017 at 04:26:12PM +0200, Arnd Bergmann wrote: > When the IOMMU subsystem is disabled, we cannot build ARM64 kernels with ACPI: > > drivers/acpi/arm64/iort.c: In function 'iort_iommu_xlate': > drivers/acpi/arm64/iort.c:647:22: error: 'struct iommu_fwspec' has no member > named

Re: [PATCH] irqchip/gicv3-its: use IORT only if IOMMU support is enabled

On Thu, Apr 27, 2017 at 04:26:12PM +0200, Arnd Bergmann wrote: > When the IOMMU subsystem is disabled, we cannot build ARM64 kernels with ACPI: > > drivers/acpi/arm64/iort.c: In function 'iort_iommu_xlate': > drivers/acpi/arm64/iort.c:647:22: error: 'struct iommu_fwspec' has no member > named

Re: [PATCH V2] x86/tboot: add an option to disable iommu force on

On Thu, Apr 27, 2017 at 05:18:55PM +0200, Joerg Roedel wrote: > On Thu, Apr 27, 2017 at 07:49:02AM -0700, Shaohua Li wrote: > > This is exactly the usage for us. And please note, not everybody should > > sacrifice the DMA security. It is only required when the pcie device hits > > iommu > >

Re: [PATCH V2] x86/tboot: add an option to disable iommu force on

On Thu, Apr 27, 2017 at 05:18:55PM +0200, Joerg Roedel wrote: > On Thu, Apr 27, 2017 at 07:49:02AM -0700, Shaohua Li wrote: > > This is exactly the usage for us. And please note, not everybody should > > sacrifice the DMA security. It is only required when the pcie device hits > > iommu > >

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

Jérémy Lefaure wrote: > Did you see the v2 of my patch (in which I keep the decimal value but > fix the buffer size) ? I did. > If special type cookies aren't handled, I guess that this v1 is better, > isn't it ? Yes. v1 is better. The docs are right. David

Re: [PATCH] checkpatch: add --typedefsfile

On 04/21/2017 08:31 AM, Jerome Forissier wrote: > On 04/20/2017 06:49 PM, Joe Perches wrote: >> On Thu, 2017-04-20 at 17:39 +0200, Jerome Forissier wrote: >>> When using checkpatch on out-of-tree code, it may occur that some >>> project-specific types are used, which will cause spurious warnings.

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

Jérémy Lefaure wrote: > Did you see the v2 of my patch (in which I keep the decimal value but > fix the buffer size) ? I did. > If special type cookies aren't handled, I guess that this v1 is better, > isn't it ? Yes. v1 is better. The docs are right. David

Re: [PATCH] checkpatch: add --typedefsfile

On 04/21/2017 08:31 AM, Jerome Forissier wrote: > On 04/20/2017 06:49 PM, Joe Perches wrote: >> On Thu, 2017-04-20 at 17:39 +0200, Jerome Forissier wrote: >>> When using checkpatch on out-of-tree code, it may occur that some >>> project-specific types are used, which will cause spurious warnings.

Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback

Hi Matwey, On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote: > This commit changes the order of actions undertaken in > musb_advance_schedule() in order to overcome issue with broken > isochronous transfer [1]. > > There is no harm to split musb_giveback into two pieces. The

Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback

Hi Matwey, On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote: > This commit changes the order of actions undertaken in > musb_advance_schedule() in order to overcome issue with broken > isochronous transfer [1]. > > There is no harm to split musb_giveback into two pieces. The

Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver

On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote: > On Tue, 2017-04-25 at 15:16 +, Eugeniy Paltsev wrote: > > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote: > > > On Mon, 2017-04-24 at 15:55 +, Eugeniy Paltsev wrote: > > > > Hi, > > > > On Fri, 2017-04-21 at 18:13 +0300,

Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver

On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote: > On Tue, 2017-04-25 at 15:16 +, Eugeniy Paltsev wrote: > > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote: > > > On Mon, 2017-04-24 at 15:55 +, Eugeniy Paltsev wrote: > > > > Hi, > > > > On Fri, 2017-04-21 at 18:13 +0300,

[PATCH 4/7] iio: adc: twl4030: Unexport twl4030_madc_conversion()

All madc users have been converted to IIO API, so drop the legacy API. The function is still used inside of the driver. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 5 +++-- include/linux/i2c/twl4030-madc.h | 2 -- 2 files changed, 3

Re: [PATCH -v3 0/13] mm: make movable onlining suck less

> Hi all, > Andrew prefers to take this after the merge window so I will repost the > full series then. Any feedback is still highly appreciated of course. Andrew i will repost HMM too when Michal repost (unless there is no rebase conflict but i doubt it). Cheers, Jérôme

[PATCH 3/7] iio: adc: twl4030: Drop twl4030_get_madc_conversion()

Drop legacy twl4030_get_madc_conversion() method. It has been used by drivers to get madc data before it conversion to IIO API. There are no users in the mainline kernel anymore. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 21

[PATCH 4/7] iio: adc: twl4030: Unexport twl4030_madc_conversion()

All madc users have been converted to IIO API, so drop the legacy API. The function is still used inside of the driver. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 5 +++-- include/linux/i2c/twl4030-madc.h | 2 -- 2 files changed, 3 insertions(+), 4 deletions(-)

Re: [PATCH -v3 0/13] mm: make movable onlining suck less

> Hi all, > Andrew prefers to take this after the merge window so I will repost the > full series then. Any feedback is still highly appreciated of course. Andrew i will repost HMM too when Michal repost (unless there is no rebase conflict but i doubt it). Cheers, Jérôme

[PATCH 3/7] iio: adc: twl4030: Drop twl4030_get_madc_conversion()

Drop legacy twl4030_get_madc_conversion() method. It has been used by drivers to get madc data before it conversion to IIO API. There are no users in the mainline kernel anymore. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 21 -

[PATCH 6/7] iio: adc: twl4030: Remove twl4030_madc_request.func_cb

This functionality is not used by the IIO subsystem. Due to removal of legacy API it can also be removed. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 70 include/linux/i2c/twl4030-madc.h | 1

[PATCH 6/7] iio: adc: twl4030: Remove twl4030_madc_request.func_cb

This functionality is not used by the IIO subsystem. Due to removal of legacy API it can also be removed. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 70 include/linux/i2c/twl4030-madc.h | 1 - 2 files changed, 71

[PATCH 5/7] iio: adc: twl4030: Drop struct twl4030_madc_user_parms

This struct is no longer used by anything in the kernel. Signed-off-by: Sebastian Reichel --- include/linux/i2c/twl4030-madc.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/include/linux/i2c/twl4030-madc.h b/include/linux/i2c/twl4030-madc.h index

[PATCH 5/7] iio: adc: twl4030: Drop struct twl4030_madc_user_parms

This struct is no longer used by anything in the kernel. Signed-off-by: Sebastian Reichel --- include/linux/i2c/twl4030-madc.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/include/linux/i2c/twl4030-madc.h b/include/linux/i2c/twl4030-madc.h index be9260e261ac..f395700fb933 100644 ---

[PATCH 2/7] power: supply: avoid unused twl4030-madc.h

Avoid inclusion of unused twl4030-madc.h. This will allow twl4030-madc.h to be merged into the iio driver. Signed-off-by: Sebastian Reichel --- drivers/power/supply/rx51_battery.c | 1 - drivers/power/supply/twl4030_madc_battery.c | 1 - 2 files

[PATCH 7/7] iio: adc: twl4030: Fold twl4030-madc.h into driver

twl4030-madc.h is no longer used by anything outside of the iio driver, so it can be merged into the driver. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 113 +++- include/linux/i2c/twl4030-madc.h | 137

[PATCH 2/7] power: supply: avoid unused twl4030-madc.h

Avoid inclusion of unused twl4030-madc.h. This will allow twl4030-madc.h to be merged into the iio driver. Signed-off-by: Sebastian Reichel --- drivers/power/supply/rx51_battery.c | 1 - drivers/power/supply/twl4030_madc_battery.c | 1 - 2 files changed, 2 deletions(-) diff --git

[PATCH 7/7] iio: adc: twl4030: Fold twl4030-madc.h into driver

twl4030-madc.h is no longer used by anything outside of the iio driver, so it can be merged into the driver. Signed-off-by: Sebastian Reichel --- drivers/iio/adc/twl4030-madc.c | 113 +++- include/linux/i2c/twl4030-madc.h | 137

[PATCH 1/7] hwmon: twl4030-madc: drop driver

This driver is no longer needed: * It has no mainline users * It has no DT support and OMAP is DT only * iio-hwmon can be used for madc, which also works with DT Signed-off-by: Sebastian Reichel --- drivers/hwmon/Kconfig | 10

[PATCH 1/7] hwmon: twl4030-madc: drop driver

This driver is no longer needed: * It has no mainline users * It has no DT support and OMAP is DT only * iio-hwmon can be used for madc, which also works with DT Signed-off-by: Sebastian Reichel --- drivers/hwmon/Kconfig | 10 drivers/hwmon/Makefile | 1 -

[PATCH 0/7] twl4030-madc cleanup

Hi, Here are a few cleanup patches for the twl4030-madc driver, that remove the last users of the driver's legacy API and then remove it. -- Sebastian Sebastian Reichel (7): hwmon: twl4030-madc: drop driver power: supply: avoid unused twl4030-madc.h iio: adc: twl4030: Drop

[PATCH 0/7] twl4030-madc cleanup

Hi, Here are a few cleanup patches for the twl4030-madc driver, that remove the last users of the driver's legacy API and then remove it. -- Sebastian Sebastian Reichel (7): hwmon: twl4030-madc: drop driver power: supply: avoid unused twl4030-madc.h iio: adc: twl4030: Drop

[PATCH 1/2] iommu/s390: Fix IOMMU groups

From: Joerg Roedel Currently the s390 iommu driver allocates an iommu-group for every device that is added. But that is wrong, as there is only one dma-table per pci-root-bus. Make all devices behind one dma-table share one iommu-group. Signed-off-by: Joerg Roedel

[PATCH 1/2] iommu/s390: Fix IOMMU groups

From: Joerg Roedel Currently the s390 iommu driver allocates an iommu-group for every device that is added. But that is wrong, as there is only one dma-table per pci-root-bus. Make all devices behind one dma-table share one iommu-group. Signed-off-by: Joerg Roedel ---

[RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

Hey, here are two patches for the s390 PCI and IOMMU code. It is based on the assumption that every pci_dev that points to the same zpci_dev shares a single dma-table (and thus a single address space). If this assupmtion is true (as it looks to me from reading the code) then the iommu-group

[RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

Hey, here are two patches for the s390 PCI and IOMMU code. It is based on the assumption that every pci_dev that points to the same zpci_dev shares a single dma-table (and thus a single address space). If this assupmtion is true (as it looks to me from reading the code) then the iommu-group

Re: [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI

On Thu 2017-04-27 10:31:18, Steven Rostedt wrote: > On Thu, 27 Apr 2017 15:38:19 +0200 > Petr Mladek wrote: > > > > by the way, > > > does this `nmi_print_seq' bypass even fix anything for Steven? > > > > I think that this is the most important question. > > > > Steven,

Re: [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI

On Thu 2017-04-27 10:31:18, Steven Rostedt wrote: > On Thu, 27 Apr 2017 15:38:19 +0200 > Petr Mladek wrote: > > > > by the way, > > > does this `nmi_print_seq' bypass even fix anything for Steven? > > > > I think that this is the most important question. > > > > Steven, does the patch from >

[PATCH 2/2] iommu/s390: Add support for iommu_device handling

From: Joerg Roedel Add support for the iommu_device_register interface to make the s390 hardware iommus visible to the iommu core and in sysfs. Signed-off-by: Joerg Roedel --- arch/s390/include/asm/pci.h | 1 + drivers/iommu/s390-iommu.c | 30

[PATCH 2/2] iommu/s390: Add support for iommu_device handling

From: Joerg Roedel Add support for the iommu_device_register interface to make the s390 hardware iommus visible to the iommu core and in sysfs. Signed-off-by: Joerg Roedel --- arch/s390/include/asm/pci.h | 1 + drivers/iommu/s390-iommu.c | 30 ++ 2 files changed,

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > > The main difficulty we > > have now is that neither of those functions are expected to fail and we > > need them to be able to in cases where the page doesn't map to system > > RAM. This patch series is trying to address it

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > > The main difficulty we > > have now is that neither of those functions are expected to fail and we > > need them to be able to in cases where the page doesn't map to system > > RAM. This patch series is trying to address it

Re: [PATCH v3] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

Kirill Tkhai writes: > On implementing of nested pid namespaces support in CRIU > (checkpoint-restore in userspace tool) we run into > the situation, that it's impossible to create a task with > specific NSpid effectively. After commit 49f4d8b93ccf > "pidns: Capture the

Re: [PATCH v3] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

Kirill Tkhai writes: > On implementing of nested pid namespaces support in CRIU > (checkpoint-restore in userspace tool) we run into > the situation, that it's impossible to create a task with > specific NSpid effectively. After commit 49f4d8b93ccf > "pidns: Capture the user namespace and filter

[PATCH -next] irqchip/mbigen: Fix return value check in mbigen_device_probe()

From: Wei Yongjun In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). Use devm_ioremap_resource() instead of devm_ioremap() to fix the IS_ERR() test issue. Fixes: 76e1f77f9c26 ("irqchip/mbigen: Introduce mbigen_of_create_domain()")

[PATCH -next] irqchip/mbigen: Fix return value check in mbigen_device_probe()

From: Wei Yongjun In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). Use devm_ioremap_resource() instead of devm_ioremap() to fix the IS_ERR() test issue. Fixes: 76e1f77f9c26 ("irqchip/mbigen: Introduce mbigen_of_create_domain()") Signed-off-by: Wei Yongjun ---

Re: [PATCH V2] x86/tboot: add an option to disable iommu force on

On Thu, Apr 27, 2017 at 07:49:02AM -0700, Shaohua Li wrote: > This is exactly the usage for us. And please note, not everybody should > sacrifice the DMA security. It is only required when the pcie device hits > iommu > hardware limitation. In our enviroment, normal network workloads (as high as

Re: [PATCH V2] x86/tboot: add an option to disable iommu force on

On Thu, Apr 27, 2017 at 07:49:02AM -0700, Shaohua Li wrote: > This is exactly the usage for us. And please note, not everybody should > sacrifice the DMA security. It is only required when the pcie device hits > iommu > hardware limitation. In our enviroment, normal network workloads (as high as

Re: [PATCH 2/3] selinux: add checksum to policydb

On Thu, 2017-04-27 at 10:41 +0200, Sebastien Buisson wrote: > 2017-04-26 20:30 GMT+02:00 Stephen Smalley : > > This seems like an odd place to trigger the computation. > > I noticed that the policy as exposed via /sys/fs/selinux/policy can > also be modified in

[PATCH] ASoC: Intel: Skylake: use dev in dev_err rather than skl pointer

From: Colin Ian King The dev_err message is dereferencing an uininitialized skl pointer which should be avoided. Don't use skl, use dev instead. Detected by CoverityScan, CID#1432042 ("Uninitialized pointer read") Fixes: 9fe9c71192832 ("ASoC: Intel: Skylake: Move sst

Re: [PATCH 2/3] selinux: add checksum to policydb

On Thu, 2017-04-27 at 10:41 +0200, Sebastien Buisson wrote: > 2017-04-26 20:30 GMT+02:00 Stephen Smalley : > > This seems like an odd place to trigger the computation. > > I noticed that the policy as exposed via /sys/fs/selinux/policy can > also be modified in security_set_bools(). That's true,

[PATCH] ASoC: Intel: Skylake: use dev in dev_err rather than skl pointer

From: Colin Ian King The dev_err message is dereferencing an uininitialized skl pointer which should be avoided. Don't use skl, use dev instead. Detected by CoverityScan, CID#1432042 ("Uninitialized pointer read") Fixes: 9fe9c71192832 ("ASoC: Intel: Skylake: Move sst common initialization to

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

On Thu, 27 Apr 2017 16:03:45 +0100 David Howells wrote: > Jérémy Lefaure wrote: > > > When building object-list.o, gcc 6 raises a warning on the sprintf call > > in fscache_objlist_show: > > > > CC fs/fscache/object-list.o > >

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

On Thu, 27 Apr 2017 16:03:45 +0100 David Howells wrote: > Jérémy Lefaure wrote: > > > When building object-list.o, gcc 6 raises a warning on the sprintf call > > in fscache_objlist_show: > > > > CC fs/fscache/object-list.o > > fs/fscache/object-list.c: In function

Re: [PATCH] [media] atmel-isc: Set the default DMA memory burst size

Le 20/04/2017 à 10:51, Songjun Wu a écrit : > Sometimes 'DMA single access' is not enough to transfer > a frame of image, '8-beat burst access' is set as the > default DMA memory burst size. > > Signed-off-by: Songjun Wu Seems okay: Acked-by: Nicolas Ferre

Re: [PATCH] [media] atmel-isc: Set the default DMA memory burst size

Le 20/04/2017 à 10:51, Songjun Wu a écrit : > Sometimes 'DMA single access' is not enough to transfer > a frame of image, '8-beat burst access' is set as the > default DMA memory burst size. > > Signed-off-by: Songjun Wu Seems okay: Acked-by: Nicolas Ferre > --- > >

Re: [RFC PATCH] printk: Make functions of pr_ macros

On Wed 2017-03-01 21:58:54, Joe Perches wrote: > On Thu, 2017-03-02 at 14:35 +0900, Sergey Senozhatsky wrote: > > Hello Joe, > > > > On (02/28/17 19:17), Joe Perches wrote: > > > Can save the space that the KERN_ headers require. > > > > > > The biggest negative here is the %pV use which needs >

Re: [RFC PATCH] printk: Make functions of pr_ macros

On Wed 2017-03-01 21:58:54, Joe Perches wrote: > On Thu, 2017-03-02 at 14:35 +0900, Sergey Senozhatsky wrote: > > Hello Joe, > > > > On (02/28/17 19:17), Joe Perches wrote: > > > Can save the space that the KERN_ headers require. > > > > > > The biggest negative here is the %pV use which needs >

Re: your mail

On Thu 27-04-17 11:08:38, Joonsoo Kim wrote: > On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote: > > > > [...] > > > > > > > > > > You are trying to change a semantic of something that has a well > > > > > > defined > > > > > > meaning. I disagree that we should change it. It might

Re: your mail

On Thu 27-04-17 11:08:38, Joonsoo Kim wrote: > On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote: > > > > [...] > > > > > > > > > > You are trying to change a semantic of something that has a well > > > > > > defined > > > > > > meaning. I disagree that we should change it. It might

Re: [PATCH] mtd: spi-nor: stm32: remove broken MODULE_ALIAS

Le 27/04/2017 à 14:17, Ludovic BARRE a écrit : > thanks a lot Arnd > Indeed, thanks Arnd! Since commit ("mtd: spi-nor: add driver for STM32 quad spi flash controller") was included with the spi-nor PR for 4.12 I've sent yesterday to Brian, I will check with him to know how he wants us to

Re: [PATCH] mtd: spi-nor: stm32: remove broken MODULE_ALIAS

Le 27/04/2017 à 14:17, Ludovic BARRE a écrit : > thanks a lot Arnd > Indeed, thanks Arnd! Since commit ("mtd: spi-nor: add driver for STM32 quad spi flash controller") was included with the spi-nor PR for 4.12 I've sent yesterday to Brian, I will check with him to know how he wants us to

Re: [PATCH v4 1/2] of: per-file dtc compiler flags

2017-04-26 9:09 GMT+09:00 : > From: Frank Rowand > > The dtc compiler version that adds initial support was available > in 4.11-rc1. Add the ability to set an additional dtc compiler > flag is needed by overlays. > > Signed-off-by: Frank Rowand

Re: [PATCH v4 1/2] of: per-file dtc compiler flags

2017-04-26 9:09 GMT+09:00 : > From: Frank Rowand > > The dtc compiler version that adds initial support was available > in 4.11-rc1. Add the ability to set an additional dtc compiler > flag is needed by overlays. > > Signed-off-by: Frank Rowand > --- Acked-by: Masahiro Yamada -- Best

Re: [PATCH 0/5] KEYS: sanitize key payloads

Do you have a git branch I can pull from? David

Re: [PATCH 0/5] KEYS: sanitize key payloads

Do you have a git branch I can pull from? David

<    3   4   5   6   7   8   9   10   11   12   >