Re: [RESEND][PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

2016-09-15 0:08 GMT+03:00 Kyle Huey : > Signed-off-by: Kyle Huey > --- > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/kernel/process.c | 80 > ++ > arch/x86/kernel/process_64.c | 66

Re: [RESEND][PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

2016-09-15 0:08 GMT+03:00 Kyle Huey : > Signed-off-by: Kyle Huey > --- > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/kernel/process.c | 80 > ++ > arch/x86/kernel/process_64.c | 66 > 3 files

[RFC 3/3] phy,leds: add support for led triggers on phy link state change

From: Josh Cartwright Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a set of led triggers for each instantiated PHY device. There is one LED trigger per link-speed, per-phy. This allows for a user to configure their system to allow a set of LEDs

[RFC 3/3] phy,leds: add support for led triggers on phy link state change

From: Josh Cartwright Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a set of led triggers for each instantiated PHY device. There is one LED trigger per link-speed, per-phy. This allows for a user to configure their system to allow a set of LEDs to represent link state

[RFC 1/3] skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace

Adding led support for phy causes namespace conflicts for some phy drivers. The marvel skge driver declared an enum for representing the states of Link LED Register. The enum contained constant LED_OFF which conflicted with declartation found in linux/leds.h. LED_OFF changed to LED_REG_OFF

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On Wed, Sep 14, 2016 at 2:46 PM, Dave Hansen wrote: > On 09/14/2016 02:35 PM, Kyle Huey wrote: >> It's not quite a plain move. To leave the existing arch_prctls only >> accessible to 64 bit callers, I added the is_32 bit and the four early >> returns for each

[RFC 1/3] skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace

Adding led support for phy causes namespace conflicts for some phy drivers. The marvel skge driver declared an enum for representing the states of Link LED Register. The enum contained constant LED_OFF which conflicted with declartation found in linux/leds.h. LED_OFF changed to LED_REG_OFF

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On Wed, Sep 14, 2016 at 2:46 PM, Dave Hansen wrote: > On 09/14/2016 02:35 PM, Kyle Huey wrote: >> It's not quite a plain move. To leave the existing arch_prctls only >> accessible to 64 bit callers, I added the is_32 bit and the four early >> returns for each existing ARCH_BLAH. These cases are

[RFC 2/3] staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace

Adding led support for phy causes namespace conflicts for some phy drivers. The rtl871 driver declared an enum for representing LED states. The enum contains constant LED_OFF which conflicted with declartation found in linux/leds.h. LED_OFF changed to LED_STATE_OFF Signed-off-by: Zach Brown

[RFC 2/3] staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace

Adding led support for phy causes namespace conflicts for some phy drivers. The rtl871 driver declared an enum for representing LED states. The enum contains constant LED_OFF which conflicted with declartation found in linux/leds.h. LED_OFF changed to LED_STATE_OFF Signed-off-by: Zach Brown ---

[RFC 0/3] Add support for led triggers on phy link state change

Some drivers that include phy.h defined LED_OFF which conflicts with definition in leds.h. phy led support uses leds.h so the two namespaces are no longer isolated. The first two patches fix the two net drivers that declared enum constants that conflict with enum constants in linux/leds.h. The

[RFC 0/3] Add support for led triggers on phy link state change

Some drivers that include phy.h defined LED_OFF which conflicts with definition in leds.h. phy led support uses leds.h so the two namespaces are no longer isolated. The first two patches fix the two net drivers that declared enum constants that conflict with enum constants in linux/leds.h. The

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Wednesday, September 14, 2016 5:31:36 PM CEST Lorenzo Pieralisi wrote: > On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote: > > > > Hi, > > > > Robin Murphy writes: > > > On 07/09/16 10:55, Peter Chen wrote: > > > [...] > > >>> Regarding the DMA configuration

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Wednesday, September 14, 2016 5:31:36 PM CEST Lorenzo Pieralisi wrote: > On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote: > > > > Hi, > > > > Robin Murphy writes: > > > On 07/09/16 10:55, Peter Chen wrote: > > > [...] > > >>> Regarding the DMA configuration that you mention in

[PATCH] kvm: x86: correctly reset dest_map->vector when restoring LAPIC state

When userspace sends KVM_SET_LAPIC, KVM schedules a check between the vCPU's IRR and ISR and the IOAPIC redirection table, in order to re-establish the IOAPIC's dest_map (the list of CPUs servicing the real-time clock interrupt with the corresponding vectors). However,

[PATCH] kvm: x86: correctly reset dest_map->vector when restoring LAPIC state

When userspace sends KVM_SET_LAPIC, KVM schedules a check between the vCPU's IRR and ISR and the IOAPIC redirection table, in order to re-establish the IOAPIC's dest_map (the list of CPUs servicing the real-time clock interrupt with the corresponding vectors). However,

Re: drivers: staging: vme: Fixed some code style warnings

On 09/14/2016 06:31 PM, Andrew Kanner wrote: > ‎Thanks, I understood my fault, but haven't done this changes yet. I > can't understand if I should reply to original message with v2 patch or > send a new email with it? Just send the patch with your revised commit message as a new mail, and be sure

Re: drivers: staging: vme: Fixed some code style warnings

On 09/14/2016 06:31 PM, Andrew Kanner wrote: > ‎Thanks, I understood my fault, but haven't done this changes yet. I > can't understand if I should reply to original message with v2 patch or > send a new email with it? Just send the patch with your revised commit message as a new mail, and be sure

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On 09/14/2016 02:35 PM, Kyle Huey wrote: > It's not quite a plain move. To leave the existing arch_prctls only > accessible to 64 bit callers, I added the is_32 bit and the four early > returns for each existing ARCH_BLAH. These cases are now > conditionally compiled out in a 32 bit kernel, so

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On 09/14/2016 02:35 PM, Kyle Huey wrote: > It's not quite a plain move. To leave the existing arch_prctls only > accessible to 64 bit callers, I added the is_32 bit and the four early > returns for each existing ARCH_BLAH. These cases are now > conditionally compiled out in a 32 bit kernel, so

Re: [PATCH v2 1/4] clk: sunxi-ng: Add A64 clocks

On 09/09, Maxime Ripard wrote: > index 106cba27c331..964f22091a10 100644 > --- a/drivers/clk/sunxi-ng/Makefile > +++ b/drivers/clk/sunxi-ng/Makefile > @@ -22,3 +22,4 @@ obj-$(CONFIG_SUN6I_A31_CCU) += ccu-sun6i-a31.o > obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o > obj-$(CONFIG_SUN8I_A33_CCU)

Re: [PATCH v2 1/4] clk: sunxi-ng: Add A64 clocks

On 09/09, Maxime Ripard wrote: > index 106cba27c331..964f22091a10 100644 > --- a/drivers/clk/sunxi-ng/Makefile > +++ b/drivers/clk/sunxi-ng/Makefile > @@ -22,3 +22,4 @@ obj-$(CONFIG_SUN6I_A31_CCU) += ccu-sun6i-a31.o > obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o > obj-$(CONFIG_SUN8I_A33_CCU)

Re: [PATCH] sparse: Track the boundaries of memory sections for accurate checks

On 6/20/16, 10:23 AM, "Michal Hocko" wrote: On Sat 18-06-16 12:11:19, KarimAllah Ahmed wrote: > When sparse memory model is used an array of memory sections is created to > track each block of contiguous physical pages. Each element of this array > contains

Re: [PATCH] sparse: Track the boundaries of memory sections for accurate checks

On 6/20/16, 10:23 AM, "Michal Hocko" wrote: On Sat 18-06-16 12:11:19, KarimAllah Ahmed wrote: > When sparse memory model is used an array of memory sections is created to > track each block of contiguous physical pages. Each element of this array > contains PAGES_PER_SECTION

Re: [PATCH v5 6/6] regulator: core: Prevent falling too fast

Hi Douglas, [auto build test WARNING on regulator/for-next] [also build test WARNING on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenie

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On Wed, Sep 14, 2016 at 2:29 PM, Dave Hansen wrote: > On 09/14/2016 02:01 PM, Kyle Huey wrote: >> Signed-off-by: Kyle Huey >> --- >> arch/x86/entry/syscalls/syscall_32.tbl | 1 + >> arch/x86/kernel/process.c | 80 >>

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 09/14/2016 02:01 PM, Kyle Huey wrote: > Xen advertises the underlying support for CPUID faulting but not does pass > through writes to the relevant MSR, nor does it virtualize it, so it does > not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO. That needs to make it into

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 09/14/2016 02:01 PM, Kyle Huey wrote: > Xen advertises the underlying support for CPUID faulting but not does pass > through writes to the relevant MSR, nor does it virtualize it, so it does > not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO. That needs to make it into

Re: [PATCH v5 6/6] regulator: core: Prevent falling too fast

Hi Douglas, [auto build test WARNING on regulator/for-next] [also build test WARNING on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenie

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On Wed, Sep 14, 2016 at 2:29 PM, Dave Hansen wrote: > On 09/14/2016 02:01 PM, Kyle Huey wrote: >> Signed-off-by: Kyle Huey >> --- >> arch/x86/entry/syscalls/syscall_32.tbl | 1 + >> arch/x86/kernel/process.c | 80 >> ++ >>

[RFC] writev() semantics with invalid iovec in the middle

Right now writev() with 3-iovec array that has unmapped address in the second element and total length less than PAGE_SIZE will write the first segment and stop at that. Among other things, it guarantees the short copy, and I would rather have it yeild 0-bytes write (and -EFAULT as return

[RFC] writev() semantics with invalid iovec in the middle

Right now writev() with 3-iovec array that has unmapped address in the second element and total length less than PAGE_SIZE will write the first segment and stop at that. Among other things, it guarantees the short copy, and I would rather have it yeild 0-bytes write (and -EFAULT as return

Re: [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count

On Wednesday, September 14, 2016 11:04:33 PM CEST zhichang.yuan wrote: > The 8250_hisi_lpc.c support both ACPI and dts similar to 8250_dw : > > +static struct platform_driver hs_lpc8250_driver = { > + .driver = { > + .name = "hisi-lpc-uart", > +

Re: [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count

On Wednesday, September 14, 2016 11:04:33 PM CEST zhichang.yuan wrote: > The 8250_hisi_lpc.c support both ACPI and dts similar to 8250_dw : > > +static struct platform_driver hs_lpc8250_driver = { > + .driver = { > + .name = "hisi-lpc-uart", > +

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Wednesday, September 14, 2016 10:50:44 PM CEST zhichang.yuan wrote: > > On 2016/9/14 20:33, Arnd Bergmann wrote: > > On Wednesday, September 14, 2016 8:15:52 PM CEST Zhichang Yuan wrote: > > > >> +Required properties: > >> +- compatible: should be "hisilicon,low-pin-count" > >> +-

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Wednesday, September 14, 2016 10:50:44 PM CEST zhichang.yuan wrote: > > On 2016/9/14 20:33, Arnd Bergmann wrote: > > On Wednesday, September 14, 2016 8:15:52 PM CEST Zhichang Yuan wrote: > > > >> +Required properties: > >> +- compatible: should be "hisilicon,low-pin-count" > >> +-

Re: linux-next: build failure after merge of the pm tree

On Wednesday, September 14, 2016 02:27:47 PM Stephen Rothwell wrote: > Hi Rafael, > > After merging the pm tree, today's linux-next build (powerpc allyesconfig) > failed like this: > > drivers/devfreq/tegra-devfreq.c: In function 'tegra_devfreq_target': > drivers/devfreq/tegra-devfreq.c:500:2:

Re: linux-next: build failure after merge of the pm tree

On Wednesday, September 14, 2016 02:27:47 PM Stephen Rothwell wrote: > Hi Rafael, > > After merging the pm tree, today's linux-next build (powerpc allyesconfig) > failed like this: > > drivers/devfreq/tegra-devfreq.c: In function 'tegra_devfreq_target': > drivers/devfreq/tegra-devfreq.c:500:2:

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On 09/14/2016 02:01 PM, Kyle Huey wrote: > Signed-off-by: Kyle Huey > --- > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/kernel/process.c | 80 > ++ > arch/x86/kernel/process_64.c | 66

Re: [PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

On 09/14/2016 02:01 PM, Kyle Huey wrote: > Signed-off-by: Kyle Huey > --- > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/kernel/process.c | 80 > ++ > arch/x86/kernel/process_64.c | 66 > 3 files

Re: [PATCH 3/3] mm: memcontrol: consolidate cgroup socket tracking

Hi Johannes, [auto build test ERROR on net/master] [also build test ERROR on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Re: [PATCH 3/3] mm: memcontrol: consolidate cgroup socket tracking

Hi Johannes, [auto build test ERROR on net/master] [also build test ERROR on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Re: [RFC v3 22/22] samples/landlock: Add sandbox example

On Wed, Sep 14, 2016 at 09:24:15AM +0200, Mickaël Salaün wrote: > Add a basic sandbox tool to create a process isolated from some part of > the system. This can depend of the current cgroup. > > Example with the current process hierarchy (seccomp): > > $ ls /home > user1 > $

Re: [RFC v3 22/22] samples/landlock: Add sandbox example

On Wed, Sep 14, 2016 at 09:24:15AM +0200, Mickaël Salaün wrote: > Add a basic sandbox tool to create a process isolated from some part of > the system. This can depend of the current cgroup. > > Example with the current process hierarchy (seccomp): > > $ ls /home > user1 > $

Re: [PATCH v2 0/8] PCI: pciehp: Rework hotplug interrupt routine

On Mon, Sep 12, 2016 at 04:08:47PM -0500, Bjorn Helgaas wrote: > This is mostly Mayurkumar's work from [1] and [2]. I split [2] into two > patches and reworked it to keep the enclosing loop around the pciehp ISR. > > The patches I added are trivial ones to clarify variable names, make dmesg >

Re: [PATCH v2 0/8] PCI: pciehp: Rework hotplug interrupt routine

On Mon, Sep 12, 2016 at 04:08:47PM -0500, Bjorn Helgaas wrote: > This is mostly Mayurkumar's work from [1] and [2]. I split [2] into two > patches and reworked it to keep the enclosing loop around the pciehp ISR. > > The patches I added are trivial ones to clarify variable names, make dmesg >

RE: [PATCH v5] lib/bitmap.c: enhance bitmap syntax

> From: Andrew Morton [mailto:a...@linux-foundation.org] > Sent: Wednesday, September 14, 2016 1:54 AM >> diff --git a/Documentation/kernel-parameters.txt >> b/Documentation/kernel-parameters.txt >> index 623502e..4f1e95b 100644 >> --- a/Documentation/kernel-parameters.txt >> +++

RE: [PATCH v5] lib/bitmap.c: enhance bitmap syntax

> From: Andrew Morton [mailto:a...@linux-foundation.org] > Sent: Wednesday, September 14, 2016 1:54 AM >> diff --git a/Documentation/kernel-parameters.txt >> b/Documentation/kernel-parameters.txt >> index 623502e..4f1e95b 100644 >> --- a/Documentation/kernel-parameters.txt >> +++

Re: [PATCH] PCI: artpec6: drop __init from artpec6_add_pcie_port

On Fri, Sep 09, 2016 at 09:45:30AM +0200, Niklas Cassel wrote: > From: Niklas Cassel > > artpec6_add_pcie_port is called from artpec6_pcie_probe. > artpec6_pcie_probe does not have the __init section marker. > It is wrong to have the marker on artpec6_add_pcie_port > when

Re: [PATCH] PCI: artpec6: drop __init from artpec6_add_pcie_port

On Fri, Sep 09, 2016 at 09:45:30AM +0200, Niklas Cassel wrote: > From: Niklas Cassel > > artpec6_add_pcie_port is called from artpec6_pcie_probe. > artpec6_pcie_probe does not have the __init section marker. > It is wrong to have the marker on artpec6_add_pcie_port > when the marker is not on

Re: [RFC v3 21/22] bpf,landlock: Add optional skb pointer in the Landlock context

On Wed, Sep 14, 2016 at 09:24:14AM +0200, Mickaël Salaün wrote: > This is a proof of concept to expose optional values that could depend > of the process access rights. > > There is two dedicated flags: LANDLOCK_FLAG_ACCESS_SKB_READ and > LANDLOCK_FLAG_ACCESS_SKB_WRITE. Each of them can be

Re: [RFC v3 21/22] bpf,landlock: Add optional skb pointer in the Landlock context

On Wed, Sep 14, 2016 at 09:24:14AM +0200, Mickaël Salaün wrote: > This is a proof of concept to expose optional values that could depend > of the process access rights. > > There is two dedicated flags: LANDLOCK_FLAG_ACCESS_SKB_READ and > LANDLOCK_FLAG_ACCESS_SKB_WRITE. Each of them can be

Re: [RFC v3 14/22] bpf/cgroup: Make cgroup_bpf_update() return an error code

On Wed, Sep 14, 2016 at 09:24:07AM +0200, Mickaël Salaün wrote: > This will be useful to support Landlock for the next commits. > > Signed-off-by: Mickaël Salaün > Cc: Alexei Starovoitov > Cc: Daniel Borkmann > Cc: Daniel Mack

Re: [RFC v3 14/22] bpf/cgroup: Make cgroup_bpf_update() return an error code

On Wed, Sep 14, 2016 at 09:24:07AM +0200, Mickaël Salaün wrote: > This will be useful to support Landlock for the next commits. > > Signed-off-by: Mickaël Salaün > Cc: Alexei Starovoitov > Cc: Daniel Borkmann > Cc: Daniel Mack > Cc: David S. Miller > Cc: Tejun Heo I think this is good to

[PATCH V2 1/2] PCI/AER: Remove duplicate AER severity translation

Currently the AER severity is being translated twice in the code flow for PCIe errors. It is first translated in ghes_do_proc() before calling into the AER driver. Then it is translated again when the AER driver calls cper_print_aer(). This causes the severity that is used in cper_print_aer() to

[PATCH V2 0/2] Correct AER severity for printing AER information

AER severity handling has two issues that cause the AER information to be printed incorrectly. The first issue is that the function to calculate the AER severity is called twice in the code path to print the AER information. The second issue is that the original call to calculate the AER severity

[PATCH V2 2/2] acpi: apei: send correct severity to calculate AER severity

Currently the AER severity is calculated by calling cper_severity_to_aer(), but the parameter sent is actually the GHES severity. This causes the AER severity to be incorrect. Fix the parameter to be the CPER severity instead of the GHES severity. Signed-off-by: Tyler Baicar

[PATCH V2 2/2] acpi: apei: send correct severity to calculate AER severity

Currently the AER severity is calculated by calling cper_severity_to_aer(), but the parameter sent is actually the GHES severity. This causes the AER severity to be incorrect. Fix the parameter to be the CPER severity instead of the GHES severity. Signed-off-by: Tyler Baicar Reviewed-by:

[PATCH V2 0/2] Correct AER severity for printing AER information

AER severity handling has two issues that cause the AER information to be printed incorrectly. The first issue is that the function to calculate the AER severity is called twice in the code path to print the AER information. The second issue is that the original call to calculate the AER severity

[PATCH V2 1/2] PCI/AER: Remove duplicate AER severity translation

Currently the AER severity is being translated twice in the code flow for PCIe errors. It is first translated in ghes_do_proc() before calling into the AER driver. Then it is translated again when the AER driver calls cper_print_aer(). This causes the severity that is used in cper_print_aer() to

Re: [PATCH 7/9] net: ethernet: ti: cpts: calc mult and shift from refclk freq

On 09/15/2016 12:03 AM, Richard Cochran wrote: On Wed, Sep 14, 2016 at 11:47:46PM +0300, Grygorii Strashko wrote: As I understand (and tested), clocks_calc_mult_shift() will return max possible mult which can be used without overflow. Yes, BUT the returned values depends on the @maxsec input.

Re: [PATCH 7/9] net: ethernet: ti: cpts: calc mult and shift from refclk freq

On 09/15/2016 12:03 AM, Richard Cochran wrote: On Wed, Sep 14, 2016 at 11:47:46PM +0300, Grygorii Strashko wrote: As I understand (and tested), clocks_calc_mult_shift() will return max possible mult which can be used without overflow. Yes, BUT the returned values depends on the @maxsec input.

Re: [PATCH 3/3] mm: memcontrol: consolidate cgroup socket tracking

Hi Johannes, [auto build test ERROR on net/master] [also build test ERROR on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Re: [PATCH 3/3] mm: memcontrol: consolidate cgroup socket tracking

Hi Johannes, [auto build test ERROR on net/master] [also build test ERROR on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

[PATCH 0/2] Correct AER severity for printing AER information

AER severity handling has two issues that cause the AER information to be printed incorrectly. The first issue is that the function to calculate the AER severity is called twice in the code path to print the AER information. The second issue is that the original call to calculate the AER severity

[PATCH 0/2] Correct AER severity for printing AER information

AER severity handling has two issues that cause the AER information to be printed incorrectly. The first issue is that the function to calculate the AER severity is called twice in the code path to print the AER information. The second issue is that the original call to calculate the AER severity

Re: [PATCH 3/3] mm: memcontrol: consolidate cgroup socket tracking

Hi Johannes, [auto build test ERROR on net/master] [also build test ERROR on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Re: [PATCH 3/3] mm: memcontrol: consolidate cgroup socket tracking

Hi Johannes, [auto build test ERROR on net/master] [also build test ERROR on v4.8-rc6 next-20160914] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

[PATCH (man-pages)] arch_prctl.2: Note new support on x86-32, ARCH_[GET|SET]_CPUID.

Signed-off-by: Kyle Huey --- man2/arch_prctl.2 | 73 +-- 1 file changed, 60 insertions(+), 13 deletions(-) diff --git a/man2/arch_prctl.2 b/man2/arch_prctl.2 index 989d369..c388797 100644 --- a/man2/arch_prctl.2 +++

[RESEND][PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

Intel supports faulting on the CPUID instruction in newer processors. Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is documented in detail in Section 2.3.2 of

[PATCH (man-pages)] arch_prctl.2: Note new support on x86-32, ARCH_[GET|SET]_CPUID.

Signed-off-by: Kyle Huey --- man2/arch_prctl.2 | 73 +-- 1 file changed, 60 insertions(+), 13 deletions(-) diff --git a/man2/arch_prctl.2 b/man2/arch_prctl.2 index 989d369..c388797 100644 --- a/man2/arch_prctl.2 +++ b/man2/arch_prctl.2 @@

[RESEND][PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

Intel supports faulting on the CPUID instruction in newer processors. Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is documented in detail in Section 2.3.2 of

Re: [PATCH] blockgroup_lock.h: remove debris from bgl_lock_ptr() conversion

On Sep 14, 2016, at 1:27 PM, Eric Biggers wrote: > > An obsolete comment and extra parentheses were left over from when the > sb_bgl_lock() macro was replaced with the bgl_lock_ptr() function. > > Signed-off-by: Eric Biggers Reviewed-by: Andreas

Re: [PATCH] blockgroup_lock.h: remove debris from bgl_lock_ptr() conversion

On Sep 14, 2016, at 1:27 PM, Eric Biggers wrote: > > An obsolete comment and extra parentheses were left over from when the > sb_bgl_lock() macro was replaced with the bgl_lock_ptr() function. > > Signed-off-by: Eric Biggers Reviewed-by: Andreas Dilger > --- >

[RESEND][PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

Xen advertises the underlying support for CPUID faulting but not does pass through writes to the relevant MSR, nor does it virtualize it, so it does not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO. Signed-off-by: Kyle Huey ---

Re: [PATCH] blockgroup_lock.h: simplify definition of NR_BG_LOCKS

On Sep 14, 2016, at 1:28 PM, Eric Biggers wrote: > > We can use ilog2() to more easily produce the desired NR_BG_LOCKS. This > works because ilog2() is evaluated at compile-time when its argument is > a compile-time constant. > > I did not change the chosen NR_BG_LOCKS

[RESEND][PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

Xen advertises the underlying support for CPUID faulting but not does pass through writes to the relevant MSR, nor does it virtualize it, so it does not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO. Signed-off-by: Kyle Huey --- arch/x86/include/asm/cpufeatures.h | 1 +

Re: [PATCH] blockgroup_lock.h: simplify definition of NR_BG_LOCKS

On Sep 14, 2016, at 1:28 PM, Eric Biggers wrote: > > We can use ilog2() to more easily produce the desired NR_BG_LOCKS. This > works because ilog2() is evaluated at compile-time when its argument is > a compile-time constant. > > I did not change the chosen NR_BG_LOCKS values. > >

Re: [PATCH v2) posix-timers: make it configurable

On Wed, 14 Sep 2016, Josh Triplett wrote: > On Wed, Sep 14, 2016 at 04:46:54PM -0400, Nicolas Pitre wrote: > > Many embedded systems typically don't need them. This removes about > > 22KB from the kernel binary size on ARM when configured out. > > > > Corresponding syscalls are routed to a stub

[RESEND][PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

Signed-off-by: Kyle Huey --- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/kernel/process.c | 80 ++ arch/x86/kernel/process_64.c | 66 3 files changed, 81 insertions(+), 66

Re: [PATCH v2) posix-timers: make it configurable

On Wed, 14 Sep 2016, Josh Triplett wrote: > On Wed, Sep 14, 2016 at 04:46:54PM -0400, Nicolas Pitre wrote: > > Many embedded systems typically don't need them. This removes about > > 22KB from the kernel binary size on ARM when configured out. > > > > Corresponding syscalls are routed to a stub

[RESEND][PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

Signed-off-by: Kyle Huey --- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/kernel/process.c | 80 ++ arch/x86/kernel/process_64.c | 66 3 files changed, 81 insertions(+), 66 deletions(-) diff --git

[RESEND][PATCH v2] arch_prctl,x86 Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

(Resending because I screwed up the cover email, sorry about that.) rr (http://rr-project.org/), a userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support

[RESEND][PATCH v2] arch_prctl,x86 Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

(Resending because I screwed up the cover email, sorry about that.) rr (http://rr-project.org/), a userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support

Re: [RFC v3 07/22] landlock: Handle file comparisons

On Wed, Sep 14, 2016 at 09:24:00AM +0200, Mickaël Salaün wrote: > Add eBPF functions to compare file system access with a Landlock file > system handle: > * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file) > This function allows to compare the dentry, inode, device or mount >

Re: [RFC v3 07/22] landlock: Handle file comparisons

On Wed, Sep 14, 2016 at 09:24:00AM +0200, Mickaël Salaün wrote: > Add eBPF functions to compare file system access with a Landlock file > system handle: > * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file) > This function allows to compare the dentry, inode, device or mount >

Re: [PATCH v3 2/3] clk: xgene: Add PMD clock

On Wed, Sep 14, 2016 at 1:55 PM, Stephen Boyd wrote: > On 09/12, Hoan Tran wrote: >> Add X-Gene PMD clock support. >> >> PMD clock is implemented for a single register field. >> Output rate = parent_rate * (denominator - scale) / denominator >> with >> - denominator =

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long wrote: > > I can try, but the 16-socket system that I have at the moment takes a long > time (more than an hour) for one shutdown-reboot cycle. It may not be really > more interrupts in 4.8, it may be that the random driver just

Re: [PATCH v3 2/3] clk: xgene: Add PMD clock

On Wed, Sep 14, 2016 at 1:55 PM, Stephen Boyd wrote: > On 09/12, Hoan Tran wrote: >> Add X-Gene PMD clock support. >> >> PMD clock is implemented for a single register field. >> Output rate = parent_rate * (denominator - scale) / denominator >> with >> - denominator = bitmask of register

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long wrote: > > I can try, but the 16-socket system that I have at the moment takes a long > time (more than an hour) for one shutdown-reboot cycle. It may not be really > more interrupts in 4.8, it may be that the random driver just somehow run > very

Re: [PATCH v3 3/3] arm64: dts: xgene: Add DT node for APM X-Gene 2 CPU clocks

Hi Stephen, On Wed, Sep 14, 2016 at 1:55 PM, Stephen Boyd wrote: > On 09/12, Hoan Tran wrote: >> Add DT nodes to enable APM X-Gene 2 CPU clocks. >> >> Signed-off-by: Hoan Tran >> --- > > This can go through arm-soc? I'm not applying this. Yes, I can go

Re: [PATCH v3 3/3] arm64: dts: xgene: Add DT node for APM X-Gene 2 CPU clocks

Hi Stephen, On Wed, Sep 14, 2016 at 1:55 PM, Stephen Boyd wrote: > On 09/12, Hoan Tran wrote: >> Add DT nodes to enable APM X-Gene 2 CPU clocks. >> >> Signed-off-by: Hoan Tran >> --- > > This can go through arm-soc? I'm not applying this. Yes, I can go through arm-soc. Thanks Hoan > > -- >

Re: [PATCH 7/9] net: ethernet: ti: cpts: calc mult and shift from refclk freq

On Wed, Sep 14, 2016 at 11:47:46PM +0300, Grygorii Strashko wrote: > As I understand (and tested), clocks_calc_mult_shift() will > return max possible mult which can be used without overflow. Yes, BUT the returned values depends on the @maxsec input. As the kerneldec says, * Larger ranges may

Re: [PATCH 7/9] net: ethernet: ti: cpts: calc mult and shift from refclk freq

On Wed, Sep 14, 2016 at 11:47:46PM +0300, Grygorii Strashko wrote: > As I understand (and tested), clocks_calc_mult_shift() will > return max possible mult which can be used without overflow. Yes, BUT the returned values depends on the @maxsec input. As the kerneldec says, * Larger ranges may

[PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

Intel supports faulting on the CPUID instruction in newer processors. Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is documented in detail in Section 2.3.2 of

[PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

Intel supports faulting on the CPUID instruction in newer processors. Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is documented in detail in Section 2.3.2 of

[PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

Signed-off-by: Kyle Huey --- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/kernel/process.c | 80 ++ arch/x86/kernel/process_64.c | 66 3 files changed, 81 insertions(+), 66

Re: [PATCH 0/5] Input: alps - cleanup

On Tuesday 09 August 2016 09:56:07 Pali Rohár wrote: > On Saturday 09 July 2016 11:58:03 Pali Rohár wrote: > > On Friday 08 July 2016 23:37:54 Dmitry Torokhov wrote: > > > On Thu, Jul 07, 2016 at 01:41:01PM +0200, Pali Rohár wrote: > > > > On Tuesday 21 June 2016 13:27:30 Pali Rohár wrote: > > > >

[PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

Xen advertises the underlying support for CPUID faulting but not does pass through writes to the relevant MSR, nor does it virtualize it, so it does not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO. Signed-off-by: Kyle Huey ---

[PATCH v2 1/3] syscalls,x86 Expose arch_prctl on x86-32.

Signed-off-by: Kyle Huey --- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/kernel/process.c | 80 ++ arch/x86/kernel/process_64.c | 66 3 files changed, 81 insertions(+), 66 deletions(-) diff --git

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