Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch() scheduler hook

(Re-sending in plain text) This hook is used in the following patch in the series to write to PQR_ASSOC_MSR, a msr that is utilized both by CQM/CMT and by CAT. Since CAT is not dependent on perf, I created this hook to start CQM monitoring right after other events start while keeping it

Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch() scheduler hook

(Re-sending in plain text) This hook is used in the following patch in the series to write to PQR_ASSOC_MSR, a msr that is utilized both by CQM/CMT and by CAT. Since CAT is not dependent on perf, I created this hook to start CQM monitoring right after other events start while keeping it

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt20

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c7e8f40..acb49c0 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3724,6 +3724,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt20

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c7e8f40..acb49c0 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3724,6 +3724,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.

[3.19.y-ckt stable] Linux 3.19.8-ckt20

I am announcing the release of the Linux 3.19.8-ckt20 kernel. The updated 3.19.y-ckt tree can be found at: git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt linux-3.19.y and can be browsed at:

[3.19.y-ckt stable] Linux 3.19.8-ckt20

I am announcing the release of the Linux 3.19.8-ckt20 kernel. The updated 3.19.y-ckt tree can be found at: git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt linux-3.19.y and can be browsed at:

[3.19.y-ckt stable] Linux 3.19.8-ckt20

I am announcing the release of the Linux 3.19.8-ckt20 kernel. The updated 3.19.y-ckt tree can be found at: git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt linux-3.19.y and can be browsed at:

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt20

[3.19.y-ckt stable] Linux 3.19.8-ckt20

I am announcing the release of the Linux 3.19.8-ckt20 kernel. The updated 3.19.y-ckt tree can be found at: git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt linux-3.19.y and can be browsed at:

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt20

ptrace vs FSGSBASE

Suppose I'm a ptracer. Wtf is supposed to happen when I write to fs_base or gs_base? Here are some schenarios: 1. I read fs_base using ptrace. I think I should get the actual fs_base without any nonsense. 2. I read all the regs (PEEKUSER or whatever) and then write then all back verbatim. At

ptrace vs FSGSBASE

Suppose I'm a ptracer. Wtf is supposed to happen when I write to fs_base or gs_base? Here are some schenarios: 1. I read fs_base using ptrace. I think I should get the actual fs_base without any nonsense. 2. I read all the regs (PEEKUSER or whatever) and then write then all back verbatim. At

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On 04/29/2016 11:37 AM, Richard W.M. Jones wrote: On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On 04/29/2016 11:37 AM, Richard W.M. Jones wrote: On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote: > This series picks patches from various different places to produce what > I consider the best solution to getting consistent mmc and mmcblk > ordering. > > Why consistent ordering and why not just use UUIDs? IMHO consistent >

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote: > This series picks patches from various different places to produce what > I consider the best solution to getting consistent mmc and mmcblk > ordering. > > Why consistent ordering and why not just use UUIDs? IMHO consistent >

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson wrote: > This series picks patches from various different places to produce what > I consider the best solution to getting consistent mmc and mmcblk > ordering. > > Why consistent ordering and why not just use UUIDs? IMHO

Re: [PATCH v2 5/7] perf: Introduce address range filtering

On 27 April 2016 at 09:44, Alexander Shishkin wrote: > Many instruction trace pmus out there support address range-based > filtering, which would, for example, generate trace data only for a > given range of instruction addresses, which is useful for tracing >

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson wrote: > This series picks patches from various different places to produce what > I consider the best solution to getting consistent mmc and mmcblk > ordering. > > Why consistent ordering and why not just use UUIDs? IMHO consistent > ordering

Re: [PATCH v2 5/7] perf: Introduce address range filtering

On 27 April 2016 at 09:44, Alexander Shishkin wrote: > Many instruction trace pmus out there support address range-based > filtering, which would, for example, generate trace data only for a > given range of instruction addresses, which is useful for tracing > individual functions, modules or

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/22/2016 2:48 AM, Kirill A. Shutemov wrote: On Thu, Apr 21, 2016 at 03:56:07PM -0700, Shi, Yang wrote: On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/22/2016 2:48 AM, Kirill A. Shutemov wrote: On Thu, Apr 21, 2016 at 03:56:07PM -0700, Shi, Yang wrote: On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

Hi Folks, I've heard through the grapevine that there's some concern that we should not be bothering to enable XSAVES because there's not a sufficient use case for it. Maybe it's meager today, but I still think we should do it. I'll try to lay out why. Today, on every Skylake system, this

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

Hi Folks, I've heard through the grapevine that there's some concern that we should not be bothering to enable XSAVES because there's not a sufficient use case for it. Maybe it's meager today, but I still think we should do it. I'll try to lay out why. Today, on every Skylake system, this

Re: [RFC PATCH v2 09/18] livepatch/x86: add TIF_PATCH_PENDING thread flag

On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > Add the TIF_PATCH_PENDING thread flag to enable the new livepatch > per-task consistency model for x86_64. The bit getting set indicates > the thread has a pending patch which needs to be applied when the thread >

Re: [RFC PATCH v2 09/18] livepatch/x86: add TIF_PATCH_PENDING thread flag

On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > Add the TIF_PATCH_PENDING thread flag to enable the new livepatch > per-task consistency model for x86_64. The bit getting set indicates > the thread has a pending patch which needs to be applied when the thread > exits the kernel. > > The

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > A preempted function might not have had a chance to save the frame > pointer to the stack yet, which can result in its caller getting skipped > on a stack trace. > > Add a flag to indicate when the task has been

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > A preempted function might not have had a chance to save the frame > pointer to the stack yet, which can result in its caller getting skipped > on a stack trace. > > Add a flag to indicate when the task has been preempted so that stack >

Re: random(4) changes

>> 1. It DOES depend on the attacker. Any statement about independence >>depends on the available knowledge. >> 2. XOR being entropy preserving depends on independence ONLY, it does >>NOT depend on identical distribution. The latter is a red herring. >>(An English metaphor for

Re: random(4) changes

>> 1. It DOES depend on the attacker. Any statement about independence >>depends on the available knowledge. >> 2. XOR being entropy preserving depends on independence ONLY, it does >>NOT depend on identical distribution. The latter is a red herring. >>(An English metaphor for

Re: [PATCH v3] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Hi Boris, On Wed, Mar 30, 2016 at 03:16:23PM +0200, Boris Brezillon wrote: > +Peter, who's currently reworking the NAND BBT code. > > On Wed, 30 Mar 2016 15:13:51 +0200 > Boris Brezillon wrote: > > > Hi Kyle, > > > > On Fri, 25 Mar 2016 17:31:16 -0500 > >

[PATCH] efibc: avoid stack overflow warning

gcc complains about a newly added file for the EFI Bootloader Control: drivers/firmware/efi/efibc.c: In function 'efibc_set_variable': drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] The problem is the declaration of

Re: [PATCH v3] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Hi Boris, On Wed, Mar 30, 2016 at 03:16:23PM +0200, Boris Brezillon wrote: > +Peter, who's currently reworking the NAND BBT code. > > On Wed, 30 Mar 2016 15:13:51 +0200 > Boris Brezillon wrote: > > > Hi Kyle, > > > > On Fri, 25 Mar 2016 17:31:16 -0500 > > Kyle Roeschley wrote: > > > > > If

[PATCH] efibc: avoid stack overflow warning

gcc complains about a newly added file for the EFI Bootloader Control: drivers/firmware/efi/efibc.c: In function 'efibc_set_variable': drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] The problem is the declaration of

[PATCH] i40e: fix misleading indentation

Newly added code in i40e_vc_config_promiscuous_mode_msg() is indented in a way that gcc rightly complains about: drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function 'i40e_vc_config_promiscuous_mode_msg': drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1543:4: error: this 'if'

[PATCH] i40e: fix misleading indentation

Newly added code in i40e_vc_config_promiscuous_mode_msg() is indented in a way that gcc rightly complains about: drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function 'i40e_vc_config_promiscuous_mode_msg': drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1543:4: error: this 'if'

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 05:02:57PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote: > > You are trying to take a generalized kernel and somehow "know" about the > > hardware ahead of time it is going to run on. That seems like two > > conflicting

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 05:02:57PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote: > > You are trying to take a generalized kernel and somehow "know" about the > > hardware ahead of time it is going to run on. That seems like two > > conflicting

Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller

On Fri, Apr 29, 2016 at 2:07 PM, Lorenzo Pieralisi wrote: > On Thu, Apr 28, 2016 at 04:48:00PM -0500, Bjorn Helgaas wrote: > > [...] > >> > +static int pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root, >> > + struct

Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller

On Fri, Apr 29, 2016 at 2:07 PM, Lorenzo Pieralisi wrote: > On Thu, Apr 28, 2016 at 04:48:00PM -0500, Bjorn Helgaas wrote: > > [...] > >> > +static int pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root, >> > + struct acpi_pci_generic_root_info *ri) >> > +{ >>

[PATCH v2 2/4] mmc: read mmc alias from device tree

From: Stefan Agner To get the SD/MMC host device ID, read the alias from the device tree. This is useful in case a SoC has multipe SD/MMC host controllers while the second controller should logically be the first device (e.g. if the second controller is connected to an internal

[PATCH v2 4/4] ARM: dts: rockchip: Add mmc aliases for rk3288 platform

Now that mmc aliases are officially in bindings, add them to rk3288. This could be done to lots of platforms, but this is the one I tested with. Signed-off-by: Douglas Anderson --- Changes in v2: - rk3288 patch new for v2 arch/arm/boot/dts/rk3288.dtsi | 4 1 file

[PATCH v2 2/4] mmc: read mmc alias from device tree

From: Stefan Agner To get the SD/MMC host device ID, read the alias from the device tree. This is useful in case a SoC has multipe SD/MMC host controllers while the second controller should logically be the first device (e.g. if the second controller is connected to an internal eMMC). Combined

[PATCH v2 4/4] ARM: dts: rockchip: Add mmc aliases for rk3288 platform

Now that mmc aliases are officially in bindings, add them to rk3288. This could be done to lots of platforms, but this is the one I tested with. Signed-off-by: Douglas Anderson --- Changes in v2: - rk3288 patch new for v2 arch/arm/boot/dts/rk3288.dtsi | 4 1 file changed, 4 insertions(+)

[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

This series picks patches from various different places to produce what I consider the best solution to getting consistent mmc and mmcblk ordering. Why consistent ordering and why not just use UUIDs? IMHO consistent ordering solves a few different problems: 1. For poor, feeble-minded humans

[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

This series picks patches from various different places to produce what I consider the best solution to getting consistent mmc and mmcblk ordering. Why consistent ordering and why not just use UUIDs? IMHO consistent ordering solves a few different problems: 1. For poor, feeble-minded humans

[PATCH v2 1/4] Documentation: mmc: Document mmc aliases

From: Jaehoon Chung Now, index of mmc/mmcblk devices is allocated in accordance with probing time. If want to use the mmcblk1 for some device, it can use alias. aliases { mmc0 =/* mmc0/mmcblk0 for eMMC */ mmc1 =/* mmc1/mmcblk1 for SD */

[PATCH v2 1/4] Documentation: mmc: Document mmc aliases

From: Jaehoon Chung Now, index of mmc/mmcblk devices is allocated in accordance with probing time. If want to use the mmcblk1 for some device, it can use alias. aliases { mmc0 =/* mmc0/mmcblk0 for eMMC */ mmc1 =/* mmc1/mmcblk1 for SD */ mmc2 =/* mmc2/mmcblk2

[PATCH v2 3/4] mmc: use SD/MMC host ID for block device name ID

From: Stefan Agner By using the SD/MMC host device ID as a starting point for block device numbering, one can reliably predict the first block device name (at least for the first controller). This is especially useful for SoCs with multiple SD/MMC host controller, where the

Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

Ulf, On Fri, Apr 29, 2016 at 12:21 AM, Ulf Hansson wrote: > On 29 April 2016 at 01:06, Douglas Anderson wrote: >> This series picks patches from various different places to produce what >> I consider the best solution to getting consistent mmc and

[PATCH v2 3/4] mmc: use SD/MMC host ID for block device name ID

From: Stefan Agner By using the SD/MMC host device ID as a starting point for block device numbering, one can reliably predict the first block device name (at least for the first controller). This is especially useful for SoCs with multiple SD/MMC host controller, where the controller with index

Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

Ulf, On Fri, Apr 29, 2016 at 12:21 AM, Ulf Hansson wrote: > On 29 April 2016 at 01:06, Douglas Anderson wrote: >> This series picks patches from various different places to produce what >> I consider the best solution to getting consistent mmc and mmcblk >> ordering. >> >> Why consistent

Re: [PATCH 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return

On Friday 29 April 2016 17:01:55 Catalin Marinas wrote: > On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote: > > ILP32 VDSO exports next symbols: > > __kernel_rt_sigreturn; > > __kernel_gettimeofday; > > __kernel_clock_gettime; > > __kernel_clock_getres; > > [...] > > >

Re: [PATCH 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return

On Friday 29 April 2016 17:01:55 Catalin Marinas wrote: > On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote: > > ILP32 VDSO exports next symbols: > > __kernel_rt_sigreturn; > > __kernel_gettimeofday; > > __kernel_clock_gettime; > > __kernel_clock_getres; > > [...] > > >

RE: [PATCH] PCI: hv: report resources release after stopping the bus

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Friday, April 29, 2016 2:39 AM > To: linux-...@vger.kernel.org > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; KY > Srinivasan ; Haiyang Zhang >

RE: [PATCH] PCI: hv: report resources release after stopping the bus

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Friday, April 29, 2016 2:39 AM > To: linux-...@vger.kernel.org > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; KY > Srinivasan ; Haiyang Zhang > ; Bjorn Helgaas ; Jake > Oshins > Subject:

Re: [PATCH 1/3] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Ksenija, thanks for working on this. A bit of nit picking inline. On 29.04.2016 13:47, Ksenija Stanojevic wrote: Add core files for mxs-lradc MFD driver. Signed-off-by: Ksenija Stanojevic --- drivers/mfd/Kconfig | 33 +-- drivers/mfd/Makefile

Re: [PATCH 1/3] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Ksenija, thanks for working on this. A bit of nit picking inline. On 29.04.2016 13:47, Ksenija Stanojevic wrote: Add core files for mxs-lradc MFD driver. Signed-off-by: Ksenija Stanojevic --- drivers/mfd/Kconfig | 33 +-- drivers/mfd/Makefile | 1 +

Re: [PATCH V2] gpio: tegra: Implement gpio_get_direction callback

On 29/04/16 17:25, Laxman Dewangan wrote: > Implement gpio_get_direction() callback for Tegra GPIO. > The direction is only valid if the pin is configured as > GPIO. If pin is not configured in GPIO mode then this > function return error. > > Signed-off-by: Laxman Dewangan

Re: [PATCH V2] gpio: tegra: Implement gpio_get_direction callback

On 29/04/16 17:25, Laxman Dewangan wrote: > Implement gpio_get_direction() callback for Tegra GPIO. > The direction is only valid if the pin is configured as > GPIO. If pin is not configured in GPIO mode then this > function return error. > > Signed-off-by: Laxman Dewangan > > --- > This patch

Re: [PATCH] mtd: nand: gpmi: get correct free oob space

From: Boris Brezillon Sent: Friday, April 29, 2016 2:31 AM To: Han Xu Cc: rich...@nod.at; dw...@infradead.org; computersforpe...@gmail.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re:

Re: [PATCH] mtd: nand: gpmi: get correct free oob space

From: Boris Brezillon Sent: Friday, April 29, 2016 2:31 AM To: Han Xu Cc: rich...@nod.at; dw...@infradead.org; computersforpe...@gmail.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: nand: gpmi: get correct

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Hi Mark and Rob, [...] > > Regardless, I'll need an ack from Rob or Mark before I can merge this. > > Will Do you have any more comments, please? Thanks, -- Tai

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Hi Mark and Rob, [...] > > Regardless, I'll need an ack from Rob or Mark before I can merge this. > > Will Do you have any more comments, please? Thanks, -- Tai

Re: [PATCH] media: fix media_ioctl use-after-free when driver unbinds

On 04/28/2016 01:19 AM, Lars-Peter Clausen wrote: > On 04/27/2016 11:56 PM, Shuah Khan wrote: dev_dbg(mdev->dev, "Media device unregistered\n"); } diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index 29409f4..9af9ba1 100644 ---

Re: [PATCH] media: fix media_ioctl use-after-free when driver unbinds

On 04/28/2016 01:19 AM, Lars-Peter Clausen wrote: > On 04/27/2016 11:56 PM, Shuah Khan wrote: dev_dbg(mdev->dev, "Media device unregistered\n"); } diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index 29409f4..9af9ba1 100644 ---

Re: [PATCH v2 0/5] Add SATA3 support for Broadcom NS2 SVK

On 29/04/16 01:36, Kishon Vijay Abraham I wrote: > Hi, > > On Monday 28 March 2016 10:18 AM, Anup Patel wrote: >> The Broadcom NS2 SoC has a AHCI compliant SATA3 controller with >> two ports. >> >> This patchset adds common Broadcom SATA3 PHY driver and related >> DT bindings document. It also

Re: [PATCH v2 0/5] Add SATA3 support for Broadcom NS2 SVK

On 29/04/16 01:36, Kishon Vijay Abraham I wrote: > Hi, > > On Monday 28 March 2016 10:18 AM, Anup Patel wrote: >> The Broadcom NS2 SoC has a AHCI compliant SATA3 controller with >> two ports. >> >> This patchset adds common Broadcom SATA3 PHY driver and related >> DT bindings document. It also

Re: [PATCH 0/4] x86, boot: KASLR memory randomization

Any feedback on this patch proposal? Thanks, Thomas On Mon, Apr 25, 2016 at 9:39 AM, Thomas Garnier wrote: > This is PATCH v1 for KASLR memory implementation on x86_64. Minor changes > were done based on RFC v1 comments. > > ***Background: > The current implementation of

Re: [PATCH 0/4] x86, boot: KASLR memory randomization

Any feedback on this patch proposal? Thanks, Thomas On Mon, Apr 25, 2016 at 9:39 AM, Thomas Garnier wrote: > This is PATCH v1 for KASLR memory implementation on x86_64. Minor changes > were done based on RFC v1 comments. > > ***Background: > The current implementation of KASLR randomizes only

Re: [PATCH V2] gpio: tegra: Implement gpio_get_direction callback

On 04/29/2016 10:25 AM, Laxman Dewangan wrote: Implement gpio_get_direction() callback for Tegra GPIO. The direction is only valid if the pin is configured as GPIO. If pin is not configured in GPIO mode then this function return error. Reviewed-by: Stephen Warren

Re: [PATCH V2] gpio: tegra: Implement gpio_get_direction callback

On 04/29/2016 10:25 AM, Laxman Dewangan wrote: Implement gpio_get_direction() callback for Tegra GPIO. The direction is only valid if the pin is configured as GPIO. If pin is not configured in GPIO mode then this function return error. Reviewed-by: Stephen Warren

[GIT PULL] EDAC fix for 4.6

Hi Linus, please pull the tag below. Thanks. --- The following changes since commit 02da2d72174c61988eb4456b53f405e3ebdebce4: Linux 4.6-rc5 (2016-04-24 16:17:05 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_fix_for_4.6

[GIT PULL] EDAC fix for 4.6

Hi Linus, please pull the tag below. Thanks. --- The following changes since commit 02da2d72174c61988eb4456b53f405e3ebdebce4: Linux 4.6-rc5 (2016-04-24 16:17:05 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_fix_for_4.6

Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote: > On 04/29/2016 01:30 PM, Mark Brown wrote: > > Supplies are only optional if they may be physically absent. In this > > case it's possible that on device regulators may be used instead, a > > pattern more like that used for

Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote: > On 04/29/2016 01:30 PM, Mark Brown wrote: > > Supplies are only optional if they may be physically absent. In this > > case it's possible that on device regulators may be used instead, a > > pattern more like that used for

[PATCH 3/3] time: Remove timespec_add_safe()

All references to timespec_add_safe() now use timespec64_add_safe(). The plan is to replace struct timespec references with struct timespec64 throughout the kernel as timespec is not y2038 safe. Drop timespec_add_safe() and use timespec64_add_safe() for all architectures. Signed-off-by: Deepa

[PATCH 3/3] time: Remove timespec_add_safe()

All references to timespec_add_safe() now use timespec64_add_safe(). The plan is to replace struct timespec references with struct timespec64 throughout the kernel as timespec is not y2038 safe. Drop timespec_add_safe() and use timespec64_add_safe() for all architectures. Signed-off-by: Deepa

[PATCH 0/3] Use timespec64 for select like timeouts

The series is part of y2038 changes. This changes a few syscalls that have common functions to use struct timespec64 instead of struct timespec. This does not include changes to system call uapi interfaces. Those will be in a different series. Thanks to Arnd Bergmann for comments on the

[PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events

struct timespec is not y2038 safe. Even though timespec might be sufficient to represent timeouts, use struct timespec64 here as the plan is to get rid of all timespec reference in the kernel. The patch transitions the common functions: poll_select_set_timeout() and select_estimate_accuracy() to

[PATCH 0/3] Use timespec64 for select like timeouts

The series is part of y2038 changes. This changes a few syscalls that have common functions to use struct timespec64 instead of struct timespec. This does not include changes to system call uapi interfaces. Those will be in a different series. Thanks to Arnd Bergmann for comments on the

[PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events

struct timespec is not y2038 safe. Even though timespec might be sufficient to represent timeouts, use struct timespec64 here as the plan is to get rid of all timespec reference in the kernel. The patch transitions the common functions: poll_select_set_timeout() and select_estimate_accuracy() to

[PATCH 1/3] time: Add missing implementation for timespec64_add_safe()

timespec64_add_safe() has been defined in time64.h for 64 bit systems. But, 32 bit systems only have an extern function prototype defined. Provide a definition for the above function. The function will be necessary as part of y2038 changes. struct timespec is not y2038 safe. All references to

[PATCH 1/3] time: Add missing implementation for timespec64_add_safe()

timespec64_add_safe() has been defined in time64.h for 64 bit systems. But, 32 bit systems only have an extern function prototype defined. Provide a definition for the above function. The function will be necessary as part of y2038 changes. struct timespec is not y2038 safe. All references to

Re: [PATCH v5 0/2] ext4: Improve parallel I/O performance on NVDIMM

On 04/29/2016 12:27 PM, Waiman Long wrote: v4->v5: - Change patch 1 to disable i_dio_count update in do_dax_io(). v3->v4: - For patch 1, add the DIO_SKIP_DIO_COUNT flag to dax_do_io() calls only to address issue raised by Dave Chinner. v2->v3: - Remove the percpu_stats helper

Re: [PATCH v5 0/2] ext4: Improve parallel I/O performance on NVDIMM

On 04/29/2016 12:27 PM, Waiman Long wrote: v4->v5: - Change patch 1 to disable i_dio_count update in do_dax_io(). v3->v4: - For patch 1, add the DIO_SKIP_DIO_COUNT flag to dax_do_io() calls only to address issue raised by Dave Chinner. v2->v3: - Remove the percpu_stats helper

[PATCH V2] gpio: tegra: Implement gpio_get_direction callback

Implement gpio_get_direction() callback for Tegra GPIO. The direction is only valid if the pin is configured as GPIO. If pin is not configured in GPIO mode then this function return error. Signed-off-by: Laxman Dewangan --- This patch is based on discussion on series Re:

[PATCH V2] gpio: tegra: Implement gpio_get_direction callback

Implement gpio_get_direction() callback for Tegra GPIO. The direction is only valid if the pin is configured as GPIO. If pin is not configured in GPIO mode then this function return error. Signed-off-by: Laxman Dewangan --- This patch is based on discussion on series Re: [PATCH V5 0/4] gpio:

Re: [BUG] vfio device assignment regression with THP ref counting redesign

On Fri, Apr 29, 2016 at 10:06:11AM +0300, Kirill A. Shutemov wrote: > Hm. I just woke up and haven't got any coffee yet, but I don't why my > approach would be worse for performance. Both have the same algorithmic > complexity. Even before looking at the overall performance, I'm not sure your

Re: [BUG] vfio device assignment regression with THP ref counting redesign

On Fri, Apr 29, 2016 at 10:06:11AM +0300, Kirill A. Shutemov wrote: > Hm. I just woke up and haven't got any coffee yet, but I don't why my > approach would be worse for performance. Both have the same algorithmic > complexity. Even before looking at the overall performance, I'm not sure your

[PATCH v5 0/2] ext4: Improve parallel I/O performance on NVDIMM

v4->v5: - Change patch 1 to disable i_dio_count update in do_dax_io(). v3->v4: - For patch 1, add the DIO_SKIP_DIO_COUNT flag to dax_do_io() calls only to address issue raised by Dave Chinner. v2->v3: - Remove the percpu_stats helper functions and use percpu_counters instead. v1->v2:

[PATCH v5 1/2] dax: Don't touch i_dio_count in dax_do_io()

The purpose of the i_dio_count is to protect against truncation while the I/O operation is in progress. As dax_do_io() only does synchronous I/O, the locking performed by the caller or within dax_do_io() for read should be enough to protect it against truncation. There is no need to touch the

[PATCH v5 0/2] ext4: Improve parallel I/O performance on NVDIMM

v4->v5: - Change patch 1 to disable i_dio_count update in do_dax_io(). v3->v4: - For patch 1, add the DIO_SKIP_DIO_COUNT flag to dax_do_io() calls only to address issue raised by Dave Chinner. v2->v3: - Remove the percpu_stats helper functions and use percpu_counters instead. v1->v2:

[PATCH v5 1/2] dax: Don't touch i_dio_count in dax_do_io()

The purpose of the i_dio_count is to protect against truncation while the I/O operation is in progress. As dax_do_io() only does synchronous I/O, the locking performed by the caller or within dax_do_io() for read should be enough to protect it against truncation. There is no need to touch the

[PATCH v5 2/2] ext4: Make cache hits/misses per-cpu counts

This patch changes the es_stats_cache_hits and es_stats_cache_misses statistics counts to percpu counters to reduce cacheline contention issues whem multiple threads are trying to update those counts simultaneously. With a 38-threads fio I/O test with 2 shared files (on DAX-mount NVDIMM) running

[PATCH v5 2/2] ext4: Make cache hits/misses per-cpu counts

This patch changes the es_stats_cache_hits and es_stats_cache_misses statistics counts to percpu counters to reduce cacheline contention issues whem multiple threads are trying to update those counts simultaneously. With a 38-threads fio I/O test with 2 shared files (on DAX-mount NVDIMM) running

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Fri, Apr 29, 2016 at 05:14:46PM +0100, Catalin Marinas wrote: > On Fri, Apr 29, 2016 at 07:08:55PM +0300, Yury Norov wrote: > > On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote: > > > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > > > > +config ARM64_ILP32 > > > >

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Fri, Apr 29, 2016 at 05:14:46PM +0100, Catalin Marinas wrote: > On Fri, Apr 29, 2016 at 07:08:55PM +0300, Yury Norov wrote: > > On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote: > > > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > > > > +config ARM64_ILP32 > > > >

Re: klp: make object/func-walking helpers more robust

+++ Miroslav Benes [28/04/16 16:34 +0200]: Current object-walking helper checks the presence of obj->funcs to determine the end of objs array in klp_object structure. This is somewhat fragile because one can easily forget about funcs definition during livepatch creation. In such a case the

Re: klp: make object/func-walking helpers more robust

+++ Miroslav Benes [28/04/16 16:34 +0200]: Current object-walking helper checks the presence of obj->funcs to determine the end of objs array in klp_object structure. This is somewhat fragile because one can easily forget about funcs definition during livepatch creation. In such a case the

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