[PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

ARMv8.2 requires implementation of the RAS extension. In this extension, it adds SEI(SError Interrupt) notification type, this patch adds new GHES error source SEI handling functions. This error source parsing and handling method is similar with the SEA. Expose API ghes_notify_sei() to external

[PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

ARMv8.2 requires implementation of the RAS extension. In this extension, it adds SEI(SError Interrupt) notification type, this patch adds new GHES error source SEI handling functions. This error source parsing and handling method is similar with the SEA. Expose API ghes_notify_sei() to external

[PATCH v9 7/7] arm64: kvm: handle guest SError Interrupt by categorization

If it is not RAS SError, directly inject virtual SError, which will keep the old way, otherwise firstly let host ACPI kernel driver to handle it. If the ACPI handling is failed, KVM continues categorizing errors by the ESR_ELx. For the recoverable error (UER), it has not been silently propagated

[PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the guest and user space needs a way to tell KVM this value. So we add a new ioctl. Before user space specifies the Exception Syndrome Register ESR(ESR), it firstly checks that whether KVM has the capability to set the guest ESR, If

[PATCH v9 1/7] arm64: cpufeature: Detect CPU RAS Extentions

From: Xie XiuQi ARM's v8.2 Extentions add support for Reliability, Availability and Serviceability (RAS). On CPUs with these extensions system software can use additional barriers to isolate errors and determine if faults are pending. Add cpufeature detection and a barrier

[PATCH v9 7/7] arm64: kvm: handle guest SError Interrupt by categorization

If it is not RAS SError, directly inject virtual SError, which will keep the old way, otherwise firstly let host ACPI kernel driver to handle it. If the ACPI handling is failed, KVM continues categorizing errors by the ESR_ELx. For the recoverable error (UER), it has not been silently propagated

[PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the guest and user space needs a way to tell KVM this value. So we add a new ioctl. Before user space specifies the Exception Syndrome Register ESR(ESR), it firstly checks that whether KVM has the capability to set the guest ESR, If

[PATCH v9 1/7] arm64: cpufeature: Detect CPU RAS Extentions

From: Xie XiuQi ARM's v8.2 Extentions add support for Reliability, Availability and Serviceability (RAS). On CPUs with these extensions system software can use additional barriers to isolate errors and determine if faults are pending. Add cpufeature detection and a barrier in the context-switch

[PATCH v9 4/7] KVM: arm64: Trap RAS error registers and set HCR_EL2's TERR & TEA

ARMv8.2 adds a new bit HCR_EL2.TEA which routes synchronous external aborts to EL2, and adds a trap control bit HCR_EL2.TERR which traps all Non-secure EL1&0 error record accesses to EL2. This patch enables the two bits for the guest OS, guaranteeing that KVM takes external aborts and traps

[PATCH v9 4/7] KVM: arm64: Trap RAS error registers and set HCR_EL2's TERR & TEA

ARMv8.2 adds a new bit HCR_EL2.TEA which routes synchronous external aborts to EL2, and adds a trap control bit HCR_EL2.TERR which traps all Non-secure EL1&0 error record accesses to EL2. This patch enables the two bits for the guest OS, guaranteeing that KVM takes external aborts and traps

[PATCH v9 2/7] KVM: arm64: Save ESR_EL2 on guest SError

From: James Morse When we exit a guest due to an SError the vcpu fault info isn't updated with the ESR. Today this is only done for traps. The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's fault_info with the ESR on SError so that handle_exit() can

[PATCH v9 2/7] KVM: arm64: Save ESR_EL2 on guest SError

From: James Morse When we exit a guest due to an SError the vcpu fault info isn't updated with the ESR. Today this is only done for traps. The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's fault_info with the ESR on SError so that handle_exit() can determine if this was a

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 01/05/2018 10:53 PM, Hanjun Guo wrote: >> + /* >> +* PTI poisons low addresses in the kernel page tables in the >> +* name of making them unusable for userspace. To execute >> +* code at such a low address, the poison must be cleared. >> +*/ >> + pgd->pgd &=

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 01/05/2018 10:53 PM, Hanjun Guo wrote: >> + /* >> +* PTI poisons low addresses in the kernel page tables in the >> +* name of making them unusable for userspace. To execute >> +* code at such a low address, the poison must be cleared. >> +*/ >> + pgd->pgd &=

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 01/05/2018 10:28 PM, Hanjun Guo wrote: >> + >> p4d = p4d_alloc(_mm, pgd, vaddr); > Seems pgd will be re-set after p4d_alloc(), so should > we put the code behind (or after pud_alloc())? Yes, it has to go below where the PGD actually gets set which is after pud_alloc(). You can put it

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 01/05/2018 10:28 PM, Hanjun Guo wrote: >> + >> p4d = p4d_alloc(_mm, pgd, vaddr); > Seems pgd will be re-set after p4d_alloc(), so should > we put the code behind (or after pud_alloc())? Yes, it has to go below where the PGD actually gets set which is after pud_alloc(). You can put it

Re: [PATCH] tty: fix data race in n_tty_receive_buf_common

On 1/6/2018 2:35 AM, Alan Cox wrote: On Sat, 6 Jan 2018 01:54:36 +0530 "Kohli, Gaurav" wrote: Hi Alan, Sorry correcting the typo here: +retval =  tty_ldisc_lock(tty, 5 * HZ); +if (retval) +     goto err_release_lock; tty->port->itty = tty; /* * Structures all

Re: [PATCH] tty: fix data race in n_tty_receive_buf_common

On 1/6/2018 2:35 AM, Alan Cox wrote: On Sat, 6 Jan 2018 01:54:36 +0530 "Kohli, Gaurav" wrote: Hi Alan, Sorry correcting the typo here: +retval =  tty_ldisc_lock(tty, 5 * HZ); +if (retval) +     goto err_release_lock; tty->port->itty = tty; /* * Structures all installed ... call the

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 2018/1/6 14:28, Hanjun Guo wrote: > Hi Dave, > > Thank you very much for the quick response! Minor comments inline. > > On 2018/1/6 14:06, Dave Hansen wrote: >> On 01/05/2018 08:54 PM, Hanjun Guo wrote: >>> Do you mean NX bit will be brought back later? I'm asking this because >>> I tested

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 2018/1/6 14:28, Hanjun Guo wrote: > Hi Dave, > > Thank you very much for the quick response! Minor comments inline. > > On 2018/1/6 14:06, Dave Hansen wrote: >> On 01/05/2018 08:54 PM, Hanjun Guo wrote: >>> Do you mean NX bit will be brought back later? I'm asking this because >>> I tested

Re: KASAN: use-after-free Read in sctp_packet_transmit

On Sat, Jan 6, 2018 at 6:07 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 8a4816cad00bf14642f0ed6043b32d29a05006ce > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1

Re: KASAN: use-after-free Read in sctp_packet_transmit

On Sat, Jan 6, 2018 at 6:07 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 8a4816cad00bf14642f0ed6043b32d29a05006ce > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: [RFC] boot failed when enable KAISER/KPTI

On 2018/1/6 2:33, Jiri Kosina wrote: > On Fri, 5 Jan 2018, Xishi Qiu wrote: > >> I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed. >> >> ... >> [0.00] PM: Registered nosave memory: [mem >> 0x810-0x8ff] >> [0.00] PM: Registered nosave memory:

Re: [RFC] boot failed when enable KAISER/KPTI

On 2018/1/6 2:33, Jiri Kosina wrote: > On Fri, 5 Jan 2018, Xishi Qiu wrote: > >> I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed. >> >> ... >> [0.00] PM: Registered nosave memory: [mem >> 0x810-0x8ff] >> [0.00] PM: Registered nosave memory:

Re: [PATCH v2 0/8] IBRS patch series

On 01/05/2018 06:12 PM, Tim Chen wrote: > Thanks to everyone for the feedback on the initial posting. > This is an updated patchset and I hope I've captured all > the review comments. I've done a lot of code clean up > per everyone's comments. Please let me know if I've missed > something. >

Re: [PATCH v2 0/8] IBRS patch series

On 01/05/2018 06:12 PM, Tim Chen wrote: > Thanks to everyone for the feedback on the initial posting. > This is an updated patchset and I hope I've captured all > the review comments. I've done a lot of code clean up > per everyone's comments. Please let me know if I've missed > something. >

[PATCH v7] regmap: Add SoundWire bus support

SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah Signed-off-by: Sanyog Kale Reviewed-by: Philippe Ombredanne

[PATCH v7] regmap: Add SoundWire bus support

SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: Hardik T Shah Signed-off-by: Sanyog Kale Reviewed-by: Philippe Ombredanne Acked-by: Pierre-Louis Bossart Reviewed-by: Takashi Iwai

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Dave, Thank you very much for the quick response! Minor comments inline. On 2018/1/6 14:06, Dave Hansen wrote: > On 01/05/2018 08:54 PM, Hanjun Guo wrote: >> Do you mean NX bit will be brought back later? I'm asking this because >> I tested this patch which it fixed the boot panic issue but

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Dave, Thank you very much for the quick response! Minor comments inline. On 2018/1/6 14:06, Dave Hansen wrote: > On 01/05/2018 08:54 PM, Hanjun Guo wrote: >> Do you mean NX bit will be brought back later? I'm asking this because >> I tested this patch which it fixed the boot panic issue but

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman wrote: > Dan Williams writes: > >> Quoting Mark's original RFC: >> >> "Recently, Google Project Zero discovered several classes of attack >> against speculative execution. One of these, known as

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman wrote: > Dan Williams writes: > >> Quoting Mark's original RFC: >> >> "Recently, Google Project Zero discovered several classes of attack >> against speculative execution. One of these, known as variant-1, allows >> explicit bounds checks to be

Re: [PATCH net-next 06/20] net: hns3: Modify the update period of packet statistics

On 2018/1/5 22:54, Andrew Lunn wrote: --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -1126,6 +1126,7 @@ static int hns3_nic_set_features(struct net_device *netdev, { struct hns3_nic_priv *priv = netdev_priv(netdev);

Re: [PATCH net-next 06/20] net: hns3: Modify the update period of packet statistics

On 2018/1/5 22:54, Andrew Lunn wrote: --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -1126,6 +1126,7 @@ static int hns3_nic_set_features(struct net_device *netdev, { struct hns3_nic_priv *priv = netdev_priv(netdev);

Re: [alsa-devel] [PATCH v6 07/14] regmap: Add SoundWire bus support

On Fri, Jan 05, 2018 at 05:05:52PM +, Mark Brown wrote: > On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > > SoundWire bus provides sdw_read() and sdw_write() APIs for Slave > > devices to program the registers. Provide support in regmap for > > SoundWire bus. > > I can't apply

Re: [alsa-devel] [PATCH v6 07/14] regmap: Add SoundWire bus support

On Fri, Jan 05, 2018 at 05:05:52PM +, Mark Brown wrote: > On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > > SoundWire bus provides sdw_read() and sdw_write() APIs for Slave > > devices to program the registers. Provide support in regmap for > > SoundWire bus. > > I can't apply

Re: [alsa-devel] [PATCH v6 07/14] regmap: Add SoundWire bus support

On Fri, Jan 05, 2018 at 11:22:15AM -0600, Pierre-Louis Bossart wrote: > On 1/5/18 11:04 AM, Mark Brown wrote: > >On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > > > >>+ /* SoundWire register address are contiguous */ > >>+ if (config->reg_stride != 0) > >>+ return

Re: [alsa-devel] [PATCH v6 07/14] regmap: Add SoundWire bus support

On Fri, Jan 05, 2018 at 11:22:15AM -0600, Pierre-Louis Bossart wrote: > On 1/5/18 11:04 AM, Mark Brown wrote: > >On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > > > >>+ /* SoundWire register address are contiguous */ > >>+ if (config->reg_stride != 0) > >>+ return

Re: [PATCH v6 07/14] regmap: Add SoundWire bus support

On Fri, Jan 05, 2018 at 05:04:21PM +, Mark Brown wrote: > On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > > > + /* SoundWire register address are contiguous */ > > + if (config->reg_stride != 0) > > + return -ENOTSUPP; > > That doesn't mean the chip hasn't decided

Re: [PATCH v6 07/14] regmap: Add SoundWire bus support

On Fri, Jan 05, 2018 at 05:04:21PM +, Mark Brown wrote: > On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > > > + /* SoundWire register address are contiguous */ > > + if (config->reg_stride != 0) > > + return -ENOTSUPP; > > That doesn't mean the chip hasn't decided

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 01/05/2018 08:54 PM, Hanjun Guo wrote: > Do you mean NX bit will be brought back later? I'm asking this because > I tested this patch which it fixed the boot panic issue but the system > will hang when rebooting the system, because rebooting will also call efi > then panic as NS bit is set.

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 01/05/2018 08:54 PM, Hanjun Guo wrote: > Do you mean NX bit will be brought back later? I'm asking this because > I tested this patch which it fixed the boot panic issue but the system > will hang when rebooting the system, because rebooting will also call efi > then panic as NS bit is set.

Re: [PATCH v4 01/13] x86/retpoline: Add initial retpoline support

On 01/04/18 18:00, David Woodhouse wrote: > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index d4fc98c..1009d1a 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -429,6 +429,19 @@ config GOLDFISH > def_bool y > depends on X86_GOLDFISH > > +config RETPOLINE >

Re: [PATCH v4 01/13] x86/retpoline: Add initial retpoline support

On 01/04/18 18:00, David Woodhouse wrote: > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index d4fc98c..1009d1a 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -429,6 +429,19 @@ config GOLDFISH > def_bool y > depends on X86_GOLDFISH > > +config RETPOLINE >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote: >> From: Andi Kleen >> >> When access_ok fails we should always stop speculating. >> Add the required

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote: >> From: Andi Kleen >> >> When access_ok fails we should always stop speculating. >> Add the required barriers to the x86 access_ok macro. > > Honestly, this seems completely bogus. > >

[PATCH] trace_uprobe: Display correct offset in uprobe_events

Recently, how the pointers being printed with %p has been changed by commit ad67b74d2469 ("printk: hash addresses printed with %p"). This is causing a regression while showing offset in the uprobe_events file. Instead of %p, use %px to display offset. Before patch: # perf probe -vv -x

[PATCH] trace_uprobe: Display correct offset in uprobe_events

Recently, how the pointers being printed with %p has been changed by commit ad67b74d2469 ("printk: hash addresses printed with %p"). This is causing a regression while showing offset in the uprobe_events file. Instead of %p, use %px to display offset. Before patch: # perf probe -vv -x

[PATCH 6/7] arm64: allwinner: h6: add the basical Allwinner H6 DTSI file

Allwinner H6 is a new SoC with Cortex-A53 cores from Allwinner, with its memory map fully reworked and some high-speed peripherals (PCIe, USB 3.0) introduced. This commit adds the basical DTSI file of it, including the clock support and UART support. Signed-off-by: Icenowy Zheng

[PATCH 6/7] arm64: allwinner: h6: add the basical Allwinner H6 DTSI file

Allwinner H6 is a new SoC with Cortex-A53 cores from Allwinner, with its memory map fully reworked and some high-speed peripherals (PCIe, USB 3.0) introduced. This commit adds the basical DTSI file of it, including the clock support and UART support. Signed-off-by: Icenowy Zheng ---

Re: [PATCH 01/18] asm-generic/barrier: add generic nospec helpers

On Fri, Jan 5, 2018 at 6:55 PM, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote: >> +#ifndef nospec_ptr >> +#define nospec_ptr(ptr, lo, hi) >>\ > > Do we actually

Re: [PATCH 01/18] asm-generic/barrier: add generic nospec helpers

On Fri, Jan 5, 2018 at 6:55 PM, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote: >> +#ifndef nospec_ptr >> +#define nospec_ptr(ptr, lo, hi) >>\ > > Do we actually want this horrible interface? > > It just causes the

RE: [Intel-wired-lan] [PATCH 09/27] igb: Use timecounter_initialize interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:38 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A >

RE: [Intel-wired-lan] [PATCH 09/27] igb: Use timecounter_initialize interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:38 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject:

RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface

> -Original Message- > From: Brown, Aaron F > Sent: Friday, January 5, 2018 8:34 PM > To: 'Sagar Arun Kamble' ; linux- > ker...@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A >

RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface

> -Original Message- > From: Brown, Aaron F > Sent: Friday, January 5, 2018 8:34 PM > To: 'Sagar Arun Kamble' ; linux- > ker...@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject: RE: [Intel-wired-lan] [PATCH

[PATCH 5/7] clk: sunxi-ng: add support for the Allwinner H6 CCU

The Allwinner H6 SoC has a CCU which has been largely rearranged. Add support for it in the sunxi-ng CCU framework. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/clock/sunxi-ccu.txt|1 + drivers/clk/sunxi-ng/Kconfig |5 +

[PATCH 5/7] clk: sunxi-ng: add support for the Allwinner H6 CCU

The Allwinner H6 SoC has a CCU which has been largely rearranged. Add support for it in the sunxi-ng CCU framework. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/clock/sunxi-ccu.txt|1 + drivers/clk/sunxi-ng/Kconfig |5 +

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Jiri, Thanks for the fix, comments inline. On 2018/1/6 2:19, Jiri Kosina wrote: > > [ adding Hugh ] > > On Thu, 4 Jan 2018, Dave Hansen wrote: > >>> BTW, we have just reported a bug caused by kaiser[1], which looks like >>> caused by SMEP. Could you please help to have a look? >>> >>> [1]

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Jiri, Thanks for the fix, comments inline. On 2018/1/6 2:19, Jiri Kosina wrote: > > [ adding Hugh ] > > On Thu, 4 Jan 2018, Dave Hansen wrote: > >>> BTW, we have just reported a bug caused by kaiser[1], which looks like >>> caused by SMEP. Could you please help to have a look? >>> >>> [1]

[PATCH 4/7] clk: sunxi-ng: Support fixed post-dividers on NKMP style clocks

On the new Allwinner H6 SoC, multiple PLL's are NMP style clocks (modelled as NKMP with no K) and have fixed post-dividers. Add fixed post divider support to the NKMP style clocks. Signed-off-by: Icenowy Zheng --- drivers/clk/sunxi-ng/ccu_nkmp.c | 20 +---

[PATCH 4/7] clk: sunxi-ng: Support fixed post-dividers on NKMP style clocks

On the new Allwinner H6 SoC, multiple PLL's are NMP style clocks (modelled as NKMP with no K) and have fixed post-dividers. Add fixed post divider support to the NKMP style clocks. Signed-off-by: Icenowy Zheng --- drivers/clk/sunxi-ng/ccu_nkmp.c | 20 +---

[PATCH] mm: ratelimit end_swap_bio_write() error

Use the ratelimited printk() version for swap-device write error reporting. We can use ZRAM as a swap-device, and the tricky part here is that zsmalloc() stores compressed objects in memory, thus it has to allocates pages during swap-out. If the system is short on memory, then we begin to flood

[PATCH] mm: ratelimit end_swap_bio_write() error

Use the ratelimited printk() version for swap-device write error reporting. We can use ZRAM as a swap-device, and the tricky part here is that zsmalloc() stores compressed objects in memory, thus it has to allocates pages during swap-out. If the system is short on memory, then we begin to flood

Hey

Loan Offer at 3% Lowest Rate Get Now.

Hey

Loan Offer at 3% Lowest Rate Get Now.

RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A >

RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject:

RE: [Intel-wired-lan] [PATCH 21/27] igb: Use timecounter_reset interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A >

RE: [Intel-wired-lan] [PATCH 21/27] igb: Use timecounter_reset interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject:

RE: [Intel-wired-lan] [PATCH 08/27] e1000e: Use timecounter_initialize interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:38 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A >

RE: [Intel-wired-lan] [PATCH 08/27] e1000e: Use timecounter_initialize interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:38 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject:

RE: [Intel-wired-lan] [PATCH 20/27] e1000e: Use timecounter_reset interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A >

RE: [Intel-wired-lan] [PATCH 20/27] e1000e: Use timecounter_reset interface

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject:

RE: [Intel-wired-lan] [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Jeff Kirsher > Sent: Wednesday, December 6, 2017 8:25 AM > To: Kamble, Sagar A ; linux- > ker...@vger.kernel.org > Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org; >

[PATCH 3/7] pinctrl: sunxi: add support for the Allwinner H6 main pin controller

The Allwinner H6 SoC has two pin controllers, one main controller (called CPUX-PORT in user manual) and one controller in CPUs power domain (called CPUS-PORT in user manual). This commit introduces support for the main pin controller on H6. The pin bank A and B are not wired out and hidden from

RE: [Intel-wired-lan] [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Jeff Kirsher > Sent: Wednesday, December 6, 2017 8:25 AM > To: Kamble, Sagar A ; linux- > ker...@vger.kernel.org > Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org; > net...@vger.kernel.org; Richard

[PATCH 3/7] pinctrl: sunxi: add support for the Allwinner H6 main pin controller

The Allwinner H6 SoC has two pin controllers, one main controller (called CPUX-PORT in user manual) and one controller in CPUs power domain (called CPUS-PORT in user manual). This commit introduces support for the main pin controller on H6. The pin bank A and B are not wired out and hidden from

[PATCH 2/7] pinctrl: sunxi: support pin controllers with holes among IRQ banks

The Allwinner H6 SoC have its pin controllers with the first IRQ-capable GPIO bank at IRQ bank 1 and the second bank at IRQ bank 5. This situation cannot be processed with the current pinctrl IRQ code, as it only expects a offset to all IRQ banks. Update the code to use a logical IRQ bank to

[PATCH 2/7] pinctrl: sunxi: support pin controllers with holes among IRQ banks

The Allwinner H6 SoC have its pin controllers with the first IRQ-capable GPIO bank at IRQ bank 1 and the second bank at IRQ bank 5. This situation cannot be processed with the current pinctrl IRQ code, as it only expects a offset to all IRQ banks. Update the code to use a logical IRQ bank to

[PATCH 1/7] pinctrl: sunxi: add support for pin controllers without bus gate

The Allwinner H6 pin controllers (both the main one and the CPUs one) have no bus gate clocks. Add support for this kind of pin controllers. Signed-off-by: Icenowy Zheng --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30 --

[PATCH 1/7] pinctrl: sunxi: add support for pin controllers without bus gate

The Allwinner H6 pin controllers (both the main one and the CPUs one) have no bus gate clocks. Add support for this kind of pin controllers. Signed-off-by: Icenowy Zheng --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30 -- drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 +

[PATCH 0/7] Initial Allwinner H6 support

This patchset adds initial support for the Allwinner H6 SoC. It's quite different from earlier Allwinner SoCs. For example, the memory map is refactored, and the CCU is rearranged. It's also the first Allwinner SoC with PCI Express interface, and the second one with USB 3.0 (the first one is

[PATCH 0/7] Initial Allwinner H6 support

This patchset adds initial support for the Allwinner H6 SoC. It's quite different from earlier Allwinner SoCs. For example, the memory map is refactored, and the CCU is rearranged. It's also the first Allwinner SoC with PCI Express interface, and the second one with USB 3.0 (the first one is

Re: [PATCH v4 00/14] Modernization and fixes for NuBus subsystem

Hi Geert, On Fri, 5 Jan 2018, Geert Uytterhoeven wrote: > > I assume you meant this to go in through the m68k tree? > Yes, please. Because the NuBus-PowerMac port is out-of-tree, the m68k tree seems more appropriate than the powerpc tree for this submission. > Can you please run this

Re: [PATCH v4 00/14] Modernization and fixes for NuBus subsystem

Hi Geert, On Fri, 5 Jan 2018, Geert Uytterhoeven wrote: > > I assume you meant this to go in through the m68k tree? > Yes, please. Because the NuBus-PowerMac port is out-of-tree, the m68k tree seems more appropriate than the powerpc tree for this submission. > Can you please run this

Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/05/2018 06:12 PM, Tim Chen wrote: > .macro ENABLE_IBRS > - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL > + testl $1, dynamic_ibrs > + jz .Lskip_\@ There was an earlier suggestion to use STATIC_JUMP_IF_... here. That's a good suggestion, but we encountered

Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/05/2018 06:12 PM, Tim Chen wrote: > .macro ENABLE_IBRS > - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL > + testl $1, dynamic_ibrs > + jz .Lskip_\@ There was an earlier suggestion to use STATIC_JUMP_IF_... here. That's a good suggestion, but we encountered

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds wrote: > > The fact is, we have to stop speculating when access_ok() does *not* > fail - because that's when we'll actually do the access. And it's that > access that needs to be non-speculative. I also suspect we

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds wrote: > > The fact is, we have to stop speculating when access_ok() does *not* > fail - because that's when we'll actually do the access. And it's that > access that needs to be non-speculative. I also suspect we should probably do this entirely

RE: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

Hi, Rafael Best Regards! Anson Huang > -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael > J. Wysocki > Sent: 2018-01-05 8:21 PM > To: Anson Huang > Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;

RE: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

Hi, Rafael Best Regards! Anson Huang > -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael > J. Wysocki > Sent: 2018-01-05 8:21 PM > To: Anson Huang > Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; Linux > PM ; Linux

[PATCH V2 1/2] ARM: dts: imx6ul: add 696MHz operating point

Add 696MHz operating point according to datasheet (Rev. 0, 12/2015). Signed-off-by: Anson Huang --- arch/arm/boot/dts/imx6ul.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi index d5181f8..963e169

[PATCH V2 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

Add 696MHz operating point for i.MX6UL, only for those parts with speed grading fuse set to 2b'10 supports 696MHz operating point, so, speed grading check is also added for i.MX6UL in this patch, the clock tree for each operating point are as below: 696MHz: pll1

[PATCH V2 1/2] ARM: dts: imx6ul: add 696MHz operating point

Add 696MHz operating point according to datasheet (Rev. 0, 12/2015). Signed-off-by: Anson Huang --- arch/arm/boot/dts/imx6ul.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi index d5181f8..963e169 100644 ---

[PATCH V2 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

Add 696MHz operating point for i.MX6UL, only for those parts with speed grading fuse set to 2b'10 supports 696MHz operating point, so, speed grading check is also added for i.MX6UL in this patch, the clock tree for each operating point are as below: 696MHz: pll1

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, 2018-01-05 at 15:28 -0800, Hugh Dickins wrote: > On Fri, Jan 5, 2018 at 6:03 AM, Mike Galbraith wrote: > > On Fri, 2018-01-05 at 14:34 +0100, Greg Kroah-Hartman wrote: > >> > >> Ok, we found two patches that were missing in 4.4-stable that were in > >> the SLES12 tree

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, 2018-01-05 at 15:28 -0800, Hugh Dickins wrote: > On Fri, Jan 5, 2018 at 6:03 AM, Mike Galbraith wrote: > > On Fri, 2018-01-05 at 14:34 +0100, Greg Kroah-Hartman wrote: > >> > >> Ok, we found two patches that were missing in 4.4-stable that were in > >> the SLES12 tree (thanks to Jamie

Re: [PATCH 01/18] asm-generic/barrier: add generic nospec helpers

On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote: > +#ifndef nospec_ptr > +#define nospec_ptr(ptr, lo, hi) > \ Do we actually want this horrible interface? It just causes the compiler - or inline asm - to generate worse

Re: [PATCH 01/18] asm-generic/barrier: add generic nospec helpers

On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote: > +#ifndef nospec_ptr > +#define nospec_ptr(ptr, lo, hi) > \ Do we actually want this horrible interface? It just causes the compiler - or inline asm - to generate worse code, because it needs to

  1   2   3   4   5   6   7   8   9   10   >