Re: [PATCH v2 1/2] vfio iommu type1: Fix size argument to vfio_find_dma() during DMA UNMAP.

On Tue, 6 Dec 2016 22:43:30 +0530 Kirti Wankhede wrote: > vfio_dma keeps track of address range from (dma->iova + 0) to > (dma->iova + dma->size - 1), while vfio_find_dma() search logic looks for > range from (dma->iova + 1) to (dma->iova + dma->size). This is not true.

Re: [PATCH v2 1/2] vfio iommu type1: Fix size argument to vfio_find_dma() during DMA UNMAP.

On Tue, 6 Dec 2016 22:43:30 +0530 Kirti Wankhede wrote: > vfio_dma keeps track of address range from (dma->iova + 0) to > (dma->iova + dma->size - 1), while vfio_find_dma() search logic looks for > range from (dma->iova + 1) to (dma->iova + dma->size). This is not true. The issue is with the

Re: [PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'

On Mon, Dec 05, 2016 at 03:42:14PM +, Ard Biesheuvel wrote: > On 2 December 2016 at 14:49, James Morse wrote: > > Patch "arm64: mm: Fix memmap to be initialized for the entire section" > > changes pfn_valid() in a way that breaks hibernate. These patches fix > >

Re: [PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'

On Mon, Dec 05, 2016 at 03:42:14PM +, Ard Biesheuvel wrote: > On 2 December 2016 at 14:49, James Morse wrote: > > Patch "arm64: mm: Fix memmap to be initialized for the entire section" > > changes pfn_valid() in a way that breaks hibernate. These patches fix > > hibernate, and provided struct

Re: [RFC v3 05/10] iommu: Do not map reserved regions

On 15/11/16 13:09, Eric Auger wrote: > As we introduced IOMMU_RESV_NOMAP and IOMMU_RESV_MSI regions, > let's prevent those new regions from being mapped. > > Signed-off-by: Eric Auger > --- > drivers/iommu/iommu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git

Re: [RFC v3 05/10] iommu: Do not map reserved regions

On 15/11/16 13:09, Eric Auger wrote: > As we introduced IOMMU_RESV_NOMAP and IOMMU_RESV_MSI regions, > let's prevent those new regions from being mapped. > > Signed-off-by: Eric Auger > --- > drivers/iommu/iommu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git

Re: [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

On 12/6/2016 9:31 AM, Rafał Miłecki wrote: > On 6 December 2016 at 18:28, Ray Jui wrote: >> On 12/6/2016 9:17 AM, Rafał Miłecki wrote: >>> From: Rafał Miłecki >>> >>> There are 3 separated controllers, one per USB /standard/. With PHY >>> drivers in

Re: [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

On 12/6/2016 9:31 AM, Rafał Miłecki wrote: > On 6 December 2016 at 18:28, Ray Jui wrote: >> On 12/6/2016 9:17 AM, Rafał Miłecki wrote: >>> From: Rafał Miłecki >>> >>> There are 3 separated controllers, one per USB /standard/. With PHY >>> drivers in place they can be simply supported with

[PATCH v7 3/4] ata: ATA Command Priority Disabled By Default

From: Adam Manzanares Add a sysfs entry to turn on priority information being passed to a ATA device. By default this feature is turned off. This patch depends on ata: Enabling ATA Command Priorities tj: Renamed ncq_prio_on to ncq_prio_enable and removed trivial

[PATCH v7 3/4] ata: ATA Command Priority Disabled By Default

From: Adam Manzanares Add a sysfs entry to turn on priority information being passed to a ATA device. By default this feature is turned off. This patch depends on ata: Enabling ATA Command Priorities tj: Renamed ncq_prio_on to ncq_prio_enable and removed trivial ata_ncq_prio_on() and

[PATCH v7 4/4] ata: set ncq_prio_enabled iff device has support

From: Adam Manzanares We previously had a check to see if the device has support for prioritized ncq commands and a check to see if a device flag is set, through a sysfs variable, in order to send a prioritized command. This patch only allows the sysfs variable to be

[PATCH v7 4/4] ata: set ncq_prio_enabled iff device has support

From: Adam Manzanares We previously had a check to see if the device has support for prioritized ncq commands and a check to see if a device flag is set, through a sysfs variable, in order to send a prioritized command. This patch only allows the sysfs variable to be set if the device supports

Re: [PATCH] iommu/intel-iommu: fix pasid table size encoding

On Tue, 6 Dec 2016 17:31:11 +0100 Joerg Roedel wrote: > Hi Jacob, > > On Thu, Dec 01, 2016 at 01:50:26PM -0800, Jacob Pan wrote: > > diff --git a/drivers/iommu/intel-iommu.c > > b/drivers/iommu/intel-iommu.c index 27596e6..f112aa9 100644 > > --- a/drivers/iommu/intel-iommu.c >

Re: [PATCH] iommu/intel-iommu: fix pasid table size encoding

On Tue, 6 Dec 2016 17:31:11 +0100 Joerg Roedel wrote: > Hi Jacob, > > On Thu, Dec 01, 2016 at 01:50:26PM -0800, Jacob Pan wrote: > > diff --git a/drivers/iommu/intel-iommu.c > > b/drivers/iommu/intel-iommu.c index 27596e6..f112aa9 100644 > > --- a/drivers/iommu/intel-iommu.c > > +++

Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access

[ this is a resend bc of some mailing list issues] On 12/06/2016 03:57 AM, Andrew Jeffery wrote: > The registers for the bt-bmc device live under the Aspeed LPC > controller. Devicetree bindings have recently been introduced for the > LPC controller where the "host" portion of the LPC register

Re: [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

On 12/6/2016 9:17 AM, Rafał Miłecki wrote: > From: Rafał Miłecki > > There are 3 separated controllers, one per USB /standard/. With PHY > drivers in place they can be simply supported with generic drivers. > > Signed-off-by: Rafał Miłecki > --- >

Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access

[ this is a resend bc of some mailing list issues] On 12/06/2016 03:57 AM, Andrew Jeffery wrote: > The registers for the bt-bmc device live under the Aspeed LPC > controller. Devicetree bindings have recently been introduced for the > LPC controller where the "host" portion of the LPC register

Re: [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

On 12/6/2016 9:17 AM, Rafał Miłecki wrote: > From: Rafał Miłecki > > There are 3 separated controllers, one per USB /standard/. With PHY > drivers in place they can be simply supported with generic drivers. > > Signed-off-by: Rafał Miłecki > --- > arch/arm/boot/dts/bcm5301x.dtsi | 33

Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings

On 2016-12-06 00:26, Rob Herring wrote: > On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote: >> Signed-off-by: Peter Rosin >> --- >> .../bindings/iio/multiplexer/iio-mux.txt | 40 >> ++ >> MAINTAINERS

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 06, 2016 at 09:51:15AM -0700, Logan Gunthorpe wrote: > Hey, > > On 06/12/16 09:38 AM, Jason Gunthorpe wrote: > >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > >>> device-dax

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On 6 December 2016 at 18:26, Pavel Machek wrote: > On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote: >> On Thu, 1 Dec 2016 17:56:07 +0100 >> Rafał Miłecki wrote: >> >> > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote: >> > > Below the oops with your debug patch

Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings

On 2016-12-06 00:26, Rob Herring wrote: > On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote: >> Signed-off-by: Peter Rosin >> --- >> .../bindings/iio/multiplexer/iio-mux.txt | 40 >> ++ >> MAINTAINERS| 6 >> 2

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 06, 2016 at 09:51:15AM -0700, Logan Gunthorpe wrote: > Hey, > > On 06/12/16 09:38 AM, Jason Gunthorpe wrote: > >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > >>> device-dax

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On 6 December 2016 at 18:26, Pavel Machek wrote: > On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote: >> On Thu, 1 Dec 2016 17:56:07 +0100 >> Rafał Miłecki wrote: >> >> > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote: >> > > Below the oops with your debug patch applied. >> > > >> > > (...) >>

Re: [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

On 6 December 2016 at 18:28, Ray Jui wrote: > On 12/6/2016 9:17 AM, Rafał Miłecki wrote: >> From: Rafał Miłecki >> >> There are 3 separated controllers, one per USB /standard/. With PHY >> drivers in place they can be simply supported with generic drivers.

Re: [PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

On 6 December 2016 at 18:28, Ray Jui wrote: > On 12/6/2016 9:17 AM, Rafał Miłecki wrote: >> From: Rafał Miłecki >> >> There are 3 separated controllers, one per USB /standard/. With PHY >> drivers in place they can be simply supported with generic drivers. >> >> Signed-off-by: Rafał Miłecki >>

Re: [PATCH V6 6/6] iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'

On Fri, Dec 02, 2016 at 08:25:09PM +0530, Sricharan R wrote: > Currently the driver sets all the device transactions privileges > to UNPRIVILEGED, but there are cases where the iommu masters wants > to isolate privileged supervisor and unprivileged user. > So don't override the privileged setting

Re: [RFC v3 02/10] iommu: Rename iommu_dm_regions into iommu_resv_regions

On 15/11/16 13:09, Eric Auger wrote: > We want to extend the callbacks used for dm regions and > use them for reserved regions. Reserved regions can be > - directly mapped regions > - regions that cannot be iommu mapped (PCI host bridge windows, ...) > - MSI regions (because they belong to another

Re: [RFC v3 04/10] iommu: iommu_alloc_resv_region

On 15/11/16 13:09, Eric Auger wrote: > Introduce a new helper serving the purpose to allocate a reserved > region. This will be used in iommu driver implementing reserved > region callbacks. > > Signed-off-by: Eric Auger > --- > drivers/iommu/iommu.c | 16

Re: [PATCH V6 6/6] iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'

On Fri, Dec 02, 2016 at 08:25:09PM +0530, Sricharan R wrote: > Currently the driver sets all the device transactions privileges > to UNPRIVILEGED, but there are cases where the iommu masters wants > to isolate privileged supervisor and unprivileged user. > So don't override the privileged setting

Re: [RFC v3 02/10] iommu: Rename iommu_dm_regions into iommu_resv_regions

On 15/11/16 13:09, Eric Auger wrote: > We want to extend the callbacks used for dm regions and > use them for reserved regions. Reserved regions can be > - directly mapped regions > - regions that cannot be iommu mapped (PCI host bridge windows, ...) > - MSI regions (because they belong to another

Re: [RFC v3 04/10] iommu: iommu_alloc_resv_region

On 15/11/16 13:09, Eric Auger wrote: > Introduce a new helper serving the purpose to allocate a reserved > region. This will be used in iommu driver implementing reserved > region callbacks. > > Signed-off-by: Eric Auger > --- > drivers/iommu/iommu.c | 16 >

Re: [RFC v3 03/10] iommu: Add new reserved IOMMU attributes

On 15/11/16 13:09, Eric Auger wrote: > IOMMU_RESV_NOMAP is used to tag reserved IOVAs that are not > supposed to be IOMMU mapped. IOMMU_RESV_MSI tags IOVAs > corresponding to MSIs that need to be IOMMU mapped. > > IOMMU_RESV_MASK allows to check if the IOVA is reserved. > > Signed-off-by: Eric

Re: [RFC v3 03/10] iommu: Add new reserved IOMMU attributes

On 15/11/16 13:09, Eric Auger wrote: > IOMMU_RESV_NOMAP is used to tag reserved IOVAs that are not > supposed to be IOMMU mapped. IOMMU_RESV_MSI tags IOVAs > corresponding to MSIs that need to be IOMMU mapped. > > IOMMU_RESV_MASK allows to check if the IOVA is reserved. > > Signed-off-by: Eric

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote: > On Thu, 1 Dec 2016 17:56:07 +0100 > Rafał Miłecki wrote: > > > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote: > > > Below the oops with your debug patch applied. > > > > > > (...) > > > > > > root@wrt1900acs:/# cd

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote: > On Thu, 1 Dec 2016 17:56:07 +0100 > Rafał Miłecki wrote: > > > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote: > > > Below the oops with your debug patch applied. > > > > > > (...) > > > > > > root@wrt1900acs:/# cd

Re: [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias

On Thu, Dec 01, 2016 at 02:36:05PM +0300, Andrey Ryabinin wrote: > On 11/29/2016 09:55 PM, Laura Abbott wrote: > > __pa_symbol is the correct API to find the physical address of symbols. > > Switch to it to allow for debugging APIs to work correctly. > > But __pa() is correct for symbols. I see

Re: [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias

On Thu, Dec 01, 2016 at 02:36:05PM +0300, Andrey Ryabinin wrote: > On 11/29/2016 09:55 PM, Laura Abbott wrote: > > __pa_symbol is the correct API to find the physical address of symbols. > > Switch to it to allow for debugging APIs to work correctly. > > But __pa() is correct for symbols. I see

[GIT] Sparc

Please pull to get this quick use-before-NULL-check from Dan Carpenter. Thanks! The following changes since commit 88abd8249ee8bcebb98c90e890ea5e342db832af: Merge branch 'for-4.9-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata (2016-11-28 14:17:10 -0800) are available in

[GIT] Sparc

Please pull to get this quick use-before-NULL-check from Dan Carpenter. Thanks! The following changes since commit 88abd8249ee8bcebb98c90e890ea5e342db832af: Merge branch 'for-4.9-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata (2016-11-28 14:17:10 -0800) are available in

[PATCH v7 0/4] Enabling ATA Command Priorities

From: Adam Manzanares This patch builds ATA commands with high priority if the iocontext of a process is set to real time. The goal of the patch is to improve tail latencies of workloads that use higher queue depths. This requires setting the iocontext ioprio on the

Re: [PATCH v4 09/13] net: ethernet: ti: cpts: rework initialization/deinitialization

On Tue, Dec 06, 2016 at 10:45:55AM -0600, Grygorii Strashko wrote: > On 12/06/2016 07:40 AM, Richard Cochran wrote: > > [ BTW, resetting the timecounter here makes no sense either. Why > > reset the clock just because the interface goes down? ] > > > > Huh. This is how it works now (even

[PATCH v7 0/4] Enabling ATA Command Priorities

From: Adam Manzanares This patch builds ATA commands with high priority if the iocontext of a process is set to real time. The goal of the patch is to improve tail latencies of workloads that use higher queue depths. This requires setting the iocontext ioprio on the request when it is

Re: [PATCH v4 09/13] net: ethernet: ti: cpts: rework initialization/deinitialization

On Tue, Dec 06, 2016 at 10:45:55AM -0600, Grygorii Strashko wrote: > On 12/06/2016 07:40 AM, Richard Cochran wrote: > > [ BTW, resetting the timecounter here makes no sense either. Why > > reset the clock just because the interface goes down? ] > > > > Huh. This is how it works now (even

[PATCH 5/5] ARM: BCM53573: Specify USB ports of on-SoC controllers

From: Rafał Miłecki Broadcom OHCI and EHCI controllers always have 2 ports each on the root hub. Describe them in DT to allow specifying extra info or referencing port nodes. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm53573.dtsi | 22

[PATCH 5/5] ARM: BCM53573: Specify USB ports of on-SoC controllers

From: Rafał Miłecki Broadcom OHCI and EHCI controllers always have 2 ports each on the root hub. Describe them in DT to allow specifying extra info or referencing port nodes. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm53573.dtsi | 22 ++ 1 file changed, 22

[PATCH 1/5] ARM: BCM5301X: Fix LAN LED labels for Luxul XWR-3100

From: Rafał Miłecki They were named incorrectly most likely due to copy & paste mistake. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

From: Rafał Miłecki There are 3 separated controllers, one per USB /standard/. With PHY drivers in place they can be simply supported with generic drivers. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm5301x.dtsi | 33

[PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block

From: Rafał Miłecki So far we were specifying only the first block which is always limited up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts| 3 ++-

[PATCH 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000

There is one GPIO controlling power for both USB ports. Signed-off-by: Rafał Miłecki Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 1 file changed, 8 insertions(+) diff --git

[PATCH 1/5] ARM: BCM5301X: Fix LAN LED labels for Luxul XWR-3100

From: Rafał Miłecki They were named incorrectly most likely due to copy & paste mistake. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts

[PATCH 2/5] ARM: BCM5301X: Specify USB controllers in DT

From: Rafał Miłecki There are 3 separated controllers, one per USB /standard/. With PHY drivers in place they can be simply supported with generic drivers. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm5301x.dtsi | 33 - 1 file changed, 32

[PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block

From: Rafał Miłecki So far we were specifying only the first block which is always limited up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB. Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts| 3 ++-

[PATCH 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000

There is one GPIO controlling power for both USB ports. Signed-off-by: Rafał Miłecki Signed-off-by: Rafał Miłecki --- arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts

[PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write()

This patch removes the WARN_ONCE() test in spi_nor_write(). This macro triggers the display of a warning message almost every time we use a UBI file-system because a write operation is performed at offset 64, which is in the middle of the SPI NOR memory page. This is a valid operation for ubifs.

[PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write()

This patch removes the WARN_ONCE() test in spi_nor_write(). This macro triggers the display of a warning message almost every time we use a UBI file-system because a write operation is performed at offset 64, which is in the middle of the SPI NOR memory page. This is a valid operation for ubifs.

[PATCH v2 2/2] vfio iommu: Fix size argument to vfio_find_dma() in pin_pages/unpin_pages

vfio_dma keeps track of address range from (dma->iova + 0) to (dma->iova + dma->size - 1), while vfio_find_dma() search logic looks for range from (dma->iova + 1) to (dma->iova + dma->size). In vfio_find_dma(), when the start address is equal to dma->iova and size is 0, check for the end of search

[PATCH v2 2/2] vfio iommu: Fix size argument to vfio_find_dma() in pin_pages/unpin_pages

vfio_dma keeps track of address range from (dma->iova + 0) to (dma->iova + dma->size - 1), while vfio_find_dma() search logic looks for range from (dma->iova + 1) to (dma->iova + dma->size). In vfio_find_dma(), when the start address is equal to dma->iova and size is 0, check for the end of search

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote: > > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > > device-dax instance under the nvme device, or if you already have the

[PATCH v2 1/2] vfio iommu type1: Fix size argument to vfio_find_dma() during DMA UNMAP.

vfio_dma keeps track of address range from (dma->iova + 0) to (dma->iova + dma->size - 1), while vfio_find_dma() search logic looks for range from (dma->iova + 1) to (dma->iova + dma->size). In vfio_find_dma(), when the start address is equal to dma->iova and size is 0, check for the end of search

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote: > > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > > device-dax instance under the nvme device, or if you already have the

[PATCH v2 1/2] vfio iommu type1: Fix size argument to vfio_find_dma() during DMA UNMAP.

vfio_dma keeps track of address range from (dma->iova + 0) to (dma->iova + dma->size - 1), while vfio_find_dma() search logic looks for range from (dma->iova + 1) to (dma->iova + dma->size). In vfio_find_dma(), when the start address is equal to dma->iova and size is 0, check for the end of search

[PATCH 1/7] arm: Add livepatch arch specific code

klp_get_ftrace_location is used by ftrace to get the entry for a specific function from the mcount list. klp_arch_set_pc is used to set the pc from the regs passed as an argument to the ftrace_ops_no_ops function to the starting address of the patched function. klp_write_module_reloc is not doing

[PATCH 1/7] arm: Add livepatch arch specific code

klp_get_ftrace_location is used by ftrace to get the entry for a specific function from the mcount list. klp_arch_set_pc is used to set the pc from the regs passed as an argument to the ftrace_ops_no_ops function to the starting address of the patched function. klp_write_module_reloc is not doing

[PATCH 7/7] arm: Add livepatch necessary arch selects into Kconfig

This adds HAVE_LIVEPATCH, MODULES_USE_ELF_RELA and HAVE_LIVEPATCH to arm Kconfig. Signed-off-by: Abel Vesa --- arch/arm/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 186c4c2..f4e9ace 100644 --- a/arch/arm/Kconfig

[PATCH 0/7] arm: Add livepatch support

This is just an idea I've been trying out for a while now. Just in case somebody wants to play with it, this applies to linux-arm/for-next. Also please note that this was only tested in qemu, but I will do some testing on some real hardware in the following days. FWICT, on this arch the

[PATCH 5/7] arm: ftrace: Add ARCH_SUPPORTS_FTRACE_OPS for ftrace with regs

ARCH_SUPPORTS_FTRACE_OPS is needed for livepatch if CONFIG_DYNAMIC_FTRACE_WITH_REGS is defined. Signed-off-by: Abel Vesa --- arch/arm/include/asm/ftrace.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h

[PATCH 6/7] arm: Add livepatch to build if CONFIG_LIVEPATCH

Necessary livepatch file added to makefile. Signed-off-by: Abel Vesa --- arch/arm/kernel/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile index ad325a8..9e70220 100644 --- a/arch/arm/kernel/Makefile +++

[PATCH 5/7] arm: ftrace: Add ARCH_SUPPORTS_FTRACE_OPS for ftrace with regs

ARCH_SUPPORTS_FTRACE_OPS is needed for livepatch if CONFIG_DYNAMIC_FTRACE_WITH_REGS is defined. Signed-off-by: Abel Vesa --- arch/arm/include/asm/ftrace.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h index bfe2a2f..f434ce9

[PATCH 6/7] arm: Add livepatch to build if CONFIG_LIVEPATCH

Necessary livepatch file added to makefile. Signed-off-by: Abel Vesa --- arch/arm/kernel/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile index ad325a8..9e70220 100644 --- a/arch/arm/kernel/Makefile +++ b/arch/arm/kernel/Makefile

[PATCH 7/7] arm: Add livepatch necessary arch selects into Kconfig

This adds HAVE_LIVEPATCH, MODULES_USE_ELF_RELA and HAVE_LIVEPATCH to arm Kconfig. Signed-off-by: Abel Vesa --- arch/arm/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 186c4c2..f4e9ace 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig

[PATCH 0/7] arm: Add livepatch support

This is just an idea I've been trying out for a while now. Just in case somebody wants to play with it, this applies to linux-arm/for-next. Also please note that this was only tested in qemu, but I will do some testing on some real hardware in the following days. FWICT, on this arch the

Re: [PATCH v3] mach-omap2: fixing wrong strcat for Non-NULL terminated string

* Maninder Singh [161204 21:32]: > Issue caught with static analysis tool: > "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)" > > Use strlcpy _includes_ the NUL terminator, and strlcat() which ensures > that it won't overflow the buffer. > >

[PATCH V3] staging: dgnc: Fix lines longer than 80 characters

For two cases (beginning and end of the patch) I opted to create small functions instead of breaking the the lines in a weird way. The other changes are simple ones: either by breaking the line when appropriate or by turning a comment into a multi-line one. Signed-off-by: Fernando Apesteguia

Re: [PATCH v3] mach-omap2: fixing wrong strcat for Non-NULL terminated string

* Maninder Singh [161204 21:32]: > Issue caught with static analysis tool: > "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)" > > Use strlcpy _includes_ the NUL terminator, and strlcat() which ensures > that it won't overflow the buffer. > > Reported-by: Maninder Singh >

[PATCH V3] staging: dgnc: Fix lines longer than 80 characters

For two cases (beginning and end of the patch) I opted to create small functions instead of breaking the the lines in a weird way. The other changes are simple ones: either by breaking the line when appropriate or by turning a comment into a multi-line one. Signed-off-by: Fernando Apesteguia

Re: i8042 error at booting an Intel Cherry Trail-based device

Hi Takashi, On Tue, Dec 06, 2016 at 11:36:09AM +0100, Takashi Iwai wrote: > On Tue, 06 Dec 2016 07:07:54 +0100, > Dmitry Torokhov wrote: > > > > On December 5, 2016 4:56:05 PM PST, Marcos Paulo de Souza > > wrote: > > >Hi Takashi, > > > > > >On Fri, Dec 02, 2016 at

Re: i8042 error at booting an Intel Cherry Trail-based device

Hi Takashi, On Tue, Dec 06, 2016 at 11:36:09AM +0100, Takashi Iwai wrote: > On Tue, 06 Dec 2016 07:07:54 +0100, > Dmitry Torokhov wrote: > > > > On December 5, 2016 4:56:05 PM PST, Marcos Paulo de Souza > > wrote: > > >Hi Takashi, > > > > > >On Fri, Dec 02, 2016 at 11:55:07AM +0100, Takashi

[PATCH 2/7] arm: ftrace: Add call modify mechanism

Function ftrace_modify_call provides a way to replace ftrace_stub with the ftrace function. This helps the klp_ftrace_handler to be called via ftrace_ops_no_ops, which in turn will set the pc with the patched function's starting address. This is used for livepatching. Signed-off-by: Abel Vesa

[PATCH 2/7] arm: ftrace: Add call modify mechanism

Function ftrace_modify_call provides a way to replace ftrace_stub with the ftrace function. This helps the klp_ftrace_handler to be called via ftrace_ops_no_ops, which in turn will set the pc with the patched function's starting address. This is used for livepatching. Signed-off-by: Abel Vesa

[PATCH 4/7] arm: Add ftrace with regs support

This adds __ftrace_regs_caller which, unlike __ftrace_caller, adds register saving/restoring and livepatch handling if the pc register gets modified by klp_ftrace_handler. Signed-off-by: Abel Vesa --- arch/arm/kernel/entry-ftrace.S | 49

[PATCH 4/7] arm: Add ftrace with regs support

This adds __ftrace_regs_caller which, unlike __ftrace_caller, adds register saving/restoring and livepatch handling if the pc register gets modified by klp_ftrace_handler. Signed-off-by: Abel Vesa --- arch/arm/kernel/entry-ftrace.S | 49 ++ 1 file

[PATCH 3/7] arm: module: Add apply_relocate_add

It was only added to fix compiler error. It is not implemented yet. Signed-off-by: Abel Vesa --- arch/arm/kernel/module.c | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c index 4f14b5c..bf94922 100644 ---

[PATCH 3/7] arm: module: Add apply_relocate_add

It was only added to fix compiler error. It is not implemented yet. Signed-off-by: Abel Vesa --- arch/arm/kernel/module.c | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c index 4f14b5c..bf94922 100644 --- a/arch/arm/kernel/module.c

[GIT] Networking

1) When dcbnl_cee_fill() fails to be able to push a new netlink attribute, it return 0 instead of an error code. From Pan Bian. 2) Two suffix handling fixes to FIB trie code, from Alexander Duyck. 3) bnxt_hwrm_stat_ctx_alloc() goes through all the trouble of setting and maintaining a

[GIT] Networking

1) When dcbnl_cee_fill() fails to be able to push a new netlink attribute, it return 0 instead of an error code. From Pan Bian. 2) Two suffix handling fixes to FIB trie code, from Alexander Duyck. 3) bnxt_hwrm_stat_ctx_alloc() goes through all the trouble of setting and maintaining a

Re: [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols

Hi, As a heads-up, it looks like this got mangled somewhere. In the hunk at arch/arm64/mm/kasan_init.c:68, 'do' in the context became 'edo'. Deleting the 'e' makes it apply. I think this is almost there; other than James's hibernate bug I only see one real issue, and everything else is a minor

Re: [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols

Hi, As a heads-up, it looks like this got mangled somewhere. In the hunk at arch/arm64/mm/kasan_init.c:68, 'do' in the context became 'edo'. Deleting the 'e' makes it apply. I think this is almost there; other than James's hibernate bug I only see one real issue, and everything else is a minor

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

On Tue, Dec 6, 2016 at 8:55 AM, Tejun Heo wrote: > Hello, > > On Mon, Dec 05, 2016 at 04:36:51PM -0800, Andy Lutomirski wrote: >> I really don't know. The cgroupfs interface is a bit unfortunate in >> that it doesn't really express the constraints. To safely migrate a >> task,

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

On Tue, Dec 6, 2016 at 8:55 AM, Tejun Heo wrote: > Hello, > > On Mon, Dec 05, 2016 at 04:36:51PM -0800, Andy Lutomirski wrote: >> I really don't know. The cgroupfs interface is a bit unfortunate in >> that it doesn't really express the constraints. To safely migrate a >> task, ISTM you ought to

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

On Tue, Nov 01, 2016 at 01:14:16PM +0700, Phong Vo wrote: > >From: Mika Westerberg > >Subject: Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when > using DT ids through ACPI > >Date: Monday 13th June 2016 09:26:55 UTC (5 months ago) > > > >On Fri, Jun 10,

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

On Tue, Nov 01, 2016 at 01:14:16PM +0700, Phong Vo wrote: > >From: Mika Westerberg > >Subject: Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when > using DT ids through ACPI > >Date: Monday 13th June 2016 09:26:55 UTC (5 months ago) > > > >On Fri, Jun 10, 2016 at 06:57:36PM +0300,

[PATCH] locking/pvqspinlock: Wait early if vcpu is preempted

If prev node is not in runnig state or its cpu is preempted, we need wait early in pv_wait_node. After commit "sched/core: Introduce the vcpu_is_preempted(cpu) interface" kernel has knowledge of one vcpu is running or not. So lets use it. Signed-off-by: Pan Xinhui

[PATCH] locking/pvqspinlock: Wait early if vcpu is preempted

If prev node is not in runnig state or its cpu is preempted, we need wait early in pv_wait_node. After commit "sched/core: Introduce the vcpu_is_preempted(cpu) interface" kernel has knowledge of one vcpu is running or not. So lets use it. Signed-off-by: Pan Xinhui ---

Re: [PATCH] net: return value of skb_linearize should be handled in Linux kernel

On Tue, Dec 06, 2016 at 03:10:33PM +0800, Zhouyi Zhou wrote: > kmalloc_reserve may fail to allocate memory inside skb_linearize, > which means skb_linearize's return value should not be ignored. > Following patch correct the uses of skb_linearize. > > Compiled in x86_64 FWIW compiled also on

Re: [PATCH] net: return value of skb_linearize should be handled in Linux kernel

On Tue, Dec 06, 2016 at 03:10:33PM +0800, Zhouyi Zhou wrote: > kmalloc_reserve may fail to allocate memory inside skb_linearize, > which means skb_linearize's return value should not be ignored. > Following patch correct the uses of skb_linearize. > > Compiled in x86_64 FWIW compiled also on

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

Hello, Serge. On Mon, Dec 05, 2016 at 08:00:11PM -0600, Serge E. Hallyn wrote: > > I really don't know. The cgroupfs interface is a bit unfortunate in > > that it doesn't really express the constraints. To safely migrate a > > task, ISTM you ought to have some form of privilege over the task >

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

Hello, Serge. On Mon, Dec 05, 2016 at 08:00:11PM -0600, Serge E. Hallyn wrote: > > I really don't know. The cgroupfs interface is a bit unfortunate in > > that it doesn't really express the constraints. To safely migrate a > > task, ISTM you ought to have some form of privilege over the task >

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

Hello, On Mon, Dec 05, 2016 at 04:36:51PM -0800, Andy Lutomirski wrote: > I really don't know. The cgroupfs interface is a bit unfortunate in > that it doesn't really express the constraints. To safely migrate a > task, ISTM you ought to have some form of privilege over the task > *and* some

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

Hello, On Mon, Dec 05, 2016 at 04:36:51PM -0800, Andy Lutomirski wrote: > I really don't know. The cgroupfs interface is a bit unfortunate in > that it doesn't really express the constraints. To safely migrate a > task, ISTM you ought to have some form of privilege over the task > *and* some

<    5   6   7   8   9   10   11   12   13   14   >