Re: [RFC PATCH 1/2] softirq: Account time and iteration stats per vector

On Thu, Jan 11, 2018 at 9:35 PM, Frederic Weisbecker wrote: > As we plan to be able to defer some specific softurq vector processing > to workqueues when those vectors need more time than IRQs can offer, > let's first count the time spent and the number of occurences per

Re: [RFC PATCH 1/2] softirq: Account time and iteration stats per vector

On Thu, Jan 11, 2018 at 9:35 PM, Frederic Weisbecker wrote: > As we plan to be able to defer some specific softurq vector processing > to workqueues when those vectors need more time than IRQs can offer, > let's first count the time spent and the number of occurences per vector. > > For now we

Re: [PATCH v2 05/12] drm/bridge/synopsys: dw-hdmi: Add deinit callback

On Thu, Jan 11, 2018 at 3:25 AM, Jernej Skrabec wrote: > Some SoCs, like Allwinner A83T, have to do additional cleanup when > HDMI driver unloads. When using DW HDMI through DRM bridge API, there is > no place to store driver's private data so it can be accessed in unbind

Re: [PATCH v2 05/12] drm/bridge/synopsys: dw-hdmi: Add deinit callback

On Thu, Jan 11, 2018 at 3:25 AM, Jernej Skrabec wrote: > Some SoCs, like Allwinner A83T, have to do additional cleanup when > HDMI driver unloads. When using DW HDMI through DRM bridge API, there is > no place to store driver's private data so it can be accessed in unbind > function. Because of

Re: [PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, 2018-01-11 at 21:38 -0800, Dan Williams wrote: > On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley > wrote: > > > > On Thu, 2018-01-11 at 16:47 -0800, Dan Williams wrote: > > > > > > Static analysis reports that 'handle' may be a user controlled > > > value that

Re: [PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, 2018-01-11 at 21:38 -0800, Dan Williams wrote: > On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley > wrote: > > > > On Thu, 2018-01-11 at 16:47 -0800, Dan Williams wrote: > > > > > > Static analysis reports that 'handle' may be a user controlled > > > value that is used as a data

Re: [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks

On Friday 12 January 2018 03:16 AM, David Lechner wrote: > > Sekhar, have you had a chance to look at the rest of the patches in the > series? Not yet. Sorry about the slow (and piecemeal) review. > > I'll wait a bit before I send a v6 to see if any other comments come. Yes. I will let you

Re: [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks

On Friday 12 January 2018 03:16 AM, David Lechner wrote: > > Sekhar, have you had a chance to look at the rest of the patches in the > series? Not yet. Sorry about the slow (and piecemeal) review. > > I'll wait a bit before I send a v6 to see if any other comments come. Yes. I will let you

Re: [PATCH] phy: work around 'phys' references to usb-phy devices

Hi Arnd, On Thursday 11 January 2018 11:46 PM, Eric Anholt wrote: > Arnd Bergmann writes: > >> On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I >> wrote: >>> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote: On Mon, Jan 8, 2018 at 7:32 PM,

Re: [PATCH] phy: work around 'phys' references to usb-phy devices

Hi Arnd, On Thursday 11 January 2018 11:46 PM, Eric Anholt wrote: > Arnd Bergmann writes: > >> On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I >> wrote: >>> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote: On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

> Il giorno 28 dic 2017, alle ore 15:00, Holger Hoffstätte > ha scritto: > > > On 12/28/17 12:19, Paolo Valente wrote: > (snip half a tech report ;) > > So either this or the previous patch ("limit tags for writes and async I/O" > can lead to a hard,

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

> Il giorno 28 dic 2017, alle ore 15:00, Holger Hoffstätte > ha scritto: > > > On 12/28/17 12:19, Paolo Valente wrote: > (snip half a tech report ;) > > So either this or the previous patch ("limit tags for writes and async I/O" > can lead to a hard, unrecoverable hang with heavy writes.

[PATCH] clk: aspeed: Handle inverse polarity of USB port 1 clock gate

The USB port 1 clock gate control has an inversed polarity from all the other clock gates in the chip. This makes the aspeed_clk_{enable,disable} functions honor the flag CLK_GATE_SET_TO_DISABLE and set that flag appropriately so it's set for all clocks except USB port 1. Signed-off-by: Benjamin

[PATCH] clk: aspeed: Handle inverse polarity of USB port 1 clock gate

The USB port 1 clock gate control has an inversed polarity from all the other clock gates in the chip. This makes the aspeed_clk_{enable,disable} functions honor the flag CLK_GATE_SET_TO_DISABLE and set that flag appropriately so it's set for all clocks except USB port 1. Signed-off-by: Benjamin

Re: [PATCH v5 1/6] base: power: runtime: Export pm_runtime_get/put_suppliers

On 01/12/2018 04:23 AM, Rafael J. Wysocki wrote: On Tue, Jan 9, 2018 at 11:01 AM, Vivek Gautam wrote: The device link allows the pm framework to tie the supplier and consumer. So, whenever the consumer is powered-on the supplier is powered-on first. There are

Re: [PATCH v5 1/6] base: power: runtime: Export pm_runtime_get/put_suppliers

On 01/12/2018 04:23 AM, Rafael J. Wysocki wrote: On Tue, Jan 9, 2018 at 11:01 AM, Vivek Gautam wrote: The device link allows the pm framework to tie the supplier and consumer. So, whenever the consumer is powered-on the supplier is powered-on first. There are however cases in which the

Re: [PATCH] ASoC: hdac_hdmi: Ensuring proper setting of output widget power state

On Thu, Jan 11, 2018 at 05:04:27PM +0530, abhijeet.ku...@intel.com wrote: > From: Abhijeet Kumar > > When we change the resolution of DP pannel or hot plug-unplug it while > playing an audio clip,sometimes we observe a silent playback(no audio). can you rephrase this

Re: [PATCH] ASoC: hdac_hdmi: Ensuring proper setting of output widget power state

On Thu, Jan 11, 2018 at 05:04:27PM +0530, abhijeet.ku...@intel.com wrote: > From: Abhijeet Kumar > > When we change the resolution of DP pannel or hot plug-unplug it while > playing an audio clip,sometimes we observe a silent playback(no audio). can you rephrase this please > During no audio

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 09:13:42PM +, Dmitry Safonov wrote: > On Thu, 2018-01-11 at 12:53 -0800, Eric Dumazet wrote: > > On Thu, Jan 11, 2018 at 12:46 PM, Dmitry Safonov > > wrote: > > > On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: > > > > On Thu, Jan 11, 2018 at

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 09:13:42PM +, Dmitry Safonov wrote: > On Thu, 2018-01-11 at 12:53 -0800, Eric Dumazet wrote: > > On Thu, Jan 11, 2018 at 12:46 PM, Dmitry Safonov > > wrote: > > > On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: > > > > On Thu, Jan 11, 2018 at 12:34 PM, Dmitry

Re: [PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley wrote: > On Thu, 2018-01-11 at 16:47 -0800, Dan Williams wrote: >> Static analysis reports that 'handle' may be a user controlled value >> that is used as a data dependency to read 'sp' from the >> 'req->outstanding_cmds'

Re: [PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley wrote: > On Thu, 2018-01-11 at 16:47 -0800, Dan Williams wrote: >> Static analysis reports that 'handle' may be a user controlled value >> that is used as a data dependency to read 'sp' from the >> 'req->outstanding_cmds' array. > > Greg already

[RFC PATCH 2/2] softirq: Per vector thread deferment

Some softirq vectors can be more CPU hungry than others. Especially networking may sometimes deal with packet storm and need more CPU than IRQ tail can offer without inducing scheduler latencies. In this case the current code defers to ksoftirqd that behaves nicer. Now this nice behaviour can be

[RFC PATCH 0/2] softirq: Per vector threading

So this is a first shot to implement what Linus suggested. To summarize: when a softirq vector is stormed and needs more time than what IRQ tail can offer, the whole softirq processing is offloaded to ksoftirqd. But this has an impact on other softirq vectors that are then subject to scheduler

[RFC PATCH 0/2] softirq: Per vector threading

So this is a first shot to implement what Linus suggested. To summarize: when a softirq vector is stormed and needs more time than what IRQ tail can offer, the whole softirq processing is offloaded to ksoftirqd. But this has an impact on other softirq vectors that are then subject to scheduler

[RFC PATCH 2/2] softirq: Per vector thread deferment

Some softirq vectors can be more CPU hungry than others. Especially networking may sometimes deal with packet storm and need more CPU than IRQ tail can offer without inducing scheduler latencies. In this case the current code defers to ksoftirqd that behaves nicer. Now this nice behaviour can be

[RFC PATCH 1/2] softirq: Account time and iteration stats per vector

As we plan to be able to defer some specific softurq vector processing to workqueues when those vectors need more time than IRQs can offer, let's first count the time spent and the number of occurences per vector. For now we still defer to ksoftirqd when the per vector limits are reached

[RFC PATCH 1/2] softirq: Account time and iteration stats per vector

As we plan to be able to defer some specific softurq vector processing to workqueues when those vectors need more time than IRQs can offer, let's first count the time spent and the number of occurences per vector. For now we still defer to ksoftirqd when the per vector limits are reached

linux-next: Tree for Jan 12

Hi all, Changes since 20180111: New tree: rdma-fixes The arm64 tree gained a conflict against Linus' tree. The pm tree gained a conflict against the i2c tree. The net-next tree lost its build failure but gained another due to an interaction with the net tree for which I reverted a commit

linux-next: Tree for Jan 12

Hi all, Changes since 20180111: New tree: rdma-fixes The arm64 tree gained a conflict against Linus' tree. The pm tree gained a conflict against the i2c tree. The net-next tree lost its build failure but gained another due to an interaction with the net tree for which I reverted a commit

Re: [PATCH v5 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Rob, On 01/12/2018 03:53 AM, Rob Herring wrote: On Tue, Jan 09, 2018 at 03:31:48PM +0530, Vivek Gautam wrote: qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. This smmu core is used with multiple masters on msm8996, viz. mdss, video, etc. Add

Re: [PATCH v5 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Rob, On 01/12/2018 03:53 AM, Rob Herring wrote: On Tue, Jan 09, 2018 at 03:31:48PM +0530, Vivek Gautam wrote: qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. This smmu core is used with multiple masters on msm8996, viz. mdss, video, etc. Add

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:22 -0800, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 12:16 PM, Eric Dumazet wrote: > > > > Note that when I implemented TCP Small queues, I did experiments between > > using a work queue or a tasklet, and workqueues added unacceptable P99 > >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:22 -0800, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 12:16 PM, Eric Dumazet wrote: > > > > Note that when I implemented TCP Small queues, I did experiments between > > using a work queue or a tasklet, and workqueues added unacceptable P99 > > latencies, when many

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On 01/11/2018 07:01 PM, Raj, Ashok wrote: > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: What's wrong with native_read_msr()? >>> >>> Yes, i think i should have added to msr.h. The names

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On 01/11/2018 07:01 PM, Raj, Ashok wrote: > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: What's wrong with native_read_msr()? >>> >>> Yes, i think i should have added to msr.h. The names didn't read as a >>> pair,

Re: [PATCH] mm: ratelimit end_swap_bio_write() error

On (01/08/18 19:22), Sergey Senozhatsky wrote: [..] > > Your changelog is rather modest on the information. > > fair point! > > > Could you be more specific on how the problem actually happens how > > likely it is? > > ok. so what we have is > > slow_path / swap-out page >

Re: [PATCH] mm: ratelimit end_swap_bio_write() error

On (01/08/18 19:22), Sergey Senozhatsky wrote: [..] > > Your changelog is rather modest on the information. > > fair point! > > > Could you be more specific on how the problem actually happens how > > likely it is? > > ok. so what we have is > > slow_path / swap-out page >

[x86-tip] RSDP changes converted i4790 box SMP -> UP

Hi Juergen, Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but discovered instead that my box had turned into a complete slug, not due to incredible RETPOLINE overhead, rather because box had forgotten that it had more than one CPU.  I was going to leave it for the weekend, but

[x86-tip] RSDP changes converted i4790 box SMP -> UP

Hi Juergen, Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but discovered instead that my box had turned into a complete slug, not due to incredible RETPOLINE overhead, rather because box had forgotten that it had more than one CPU.  I was going to leave it for the weekend, but

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

On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > From: Alexei Starovoitov > Date: Wed, 10 Jan 2018 17:58:54 -0800 > > > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > >> Hi all, > >> > >> After merging the net-next tree, today's

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

On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > From: Alexei Starovoitov > Date: Wed, 10 Jan 2018 17:58:54 -0800 > > > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > >> Hi all, > >> > >> After merging the net-next tree, today's linux-next build (x86_64 > >>

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Thu, 11 Jan 2018 21:55:47 -0500 Steven Rostedt wrote: > I ran this on a box with 4 CPUs and a serial console (so it has a slow > console). Again, all I have is each CPU doing exactly ONE printk()! > then sleeping for a full millisecond! It will cause a lot of output, >

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Thu, 11 Jan 2018 21:55:47 -0500 Steven Rostedt wrote: > I ran this on a box with 4 CPUs and a serial console (so it has a slow > console). Again, all I have is each CPU doing exactly ONE printk()! > then sleeping for a full millisecond! It will cause a lot of output, > and perhaps slow the

Re: [PATCH 3/3] tracing: don't set parser->cont if it has reached the end of input buffer

Hi Rostedt, On Tue, Jan 09, 2018 at 11:19:36PM -0500, Steven Rostedt wrote: > On Wed, 10 Jan 2018 11:18:23 +0800 > "Du, Changbin" wrote: > > > write(3, "abcdefg", 7) > > > > > > From my point of view, the above isn't done writing the function name > > > yet and we

Re: [PATCH 3/3] tracing: don't set parser->cont if it has reached the end of input buffer

Hi Rostedt, On Tue, Jan 09, 2018 at 11:19:36PM -0500, Steven Rostedt wrote: > On Wed, 10 Jan 2018 11:18:23 +0800 > "Du, Changbin" wrote: > > > write(3, "abcdefg", 7) > > > > > > From my point of view, the above isn't done writing the function name > > > yet and we SHOULD continue waiting for

Re: [PATCH] selftests/x86: Add test_vsyscall

On Thu, Jan 11, 2018 at 5:16 PM, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or its memory map handling,

Re: [PATCH] selftests/x86: Add test_vsyscall

On Thu, Jan 11, 2018 at 5:16 PM, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or its memory map handling, > running this

[ANNOUNCE] Git v2.16.0-rc2

A release candidate Git v2.16.0-rc2 is now available for testing at the usual places. It is comprised of 483 non-merge commits since v2.15.0, contributed by 80 people, 23 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

[ANNOUNCE] Git v2.16.0-rc2

A release candidate Git v2.16.0-rc2 is now available for testing at the usual places. It is comprised of 483 non-merge commits since v2.15.0, contributed by 80 people, 23 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCH] drm/virtio: Add window server support

> > this work is based on the virtio_wl driver in the ChromeOS kernel by > Zach Reizner, currently at: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c > > There's two features missing in this patch when compared with virtio_wl: > > *

Re: [PATCH] drm/virtio: Add window server support

> > this work is based on the virtio_wl driver in the ChromeOS kernel by > Zach Reizner, currently at: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c > > There's two features missing in this patch when compared with virtio_wl: > > *

Re: [PATCH v2 09/22] mmc: tmio: use mmc_can_gpio_cd() instead of checking TMIO_MMC_USE_GPIO_CD

Hi Ulf, 2018-01-02 21:56 GMT+09:00 Wolfram Sang : > On Sat, Nov 25, 2017 at 01:24:44AM +0900, Masahiro Yamada wrote: >> To use a GPIO line for card detection, TMIO_MMC_USE_GPIO_CD is set >> by a legacy board (arch/sh/boards/mach-ecovec24). >> >> For DT platforms, the

Re: [PATCH v2 09/22] mmc: tmio: use mmc_can_gpio_cd() instead of checking TMIO_MMC_USE_GPIO_CD

Hi Ulf, 2018-01-02 21:56 GMT+09:00 Wolfram Sang : > On Sat, Nov 25, 2017 at 01:24:44AM +0900, Masahiro Yamada wrote: >> To use a GPIO line for card detection, TMIO_MMC_USE_GPIO_CD is set >> by a legacy board (arch/sh/boards/mach-ecovec24). >> >> For DT platforms, the "cd-gpios" property is a

[PATCH] usb: dwc3: core: power on PHYs before initializing core

The dwc3_core_init() gets the PHYs and initializes the PHYs with the usb_phy_init() and phy_init() functions before initializing core, and power on the PHYs after core initialization is done. However, some platforms (e.g. Rockchip RK3399 DWC3 with Type-C USB3 PHY), it needs to do some special

[PATCH] usb: dwc3: core: power on PHYs before initializing core

The dwc3_core_init() gets the PHYs and initializes the PHYs with the usb_phy_init() and phy_init() functions before initializing core, and power on the PHYs after core initialization is done. However, some platforms (e.g. Rockchip RK3399 DWC3 with Type-C USB3 PHY), it needs to do some special

Re: [PATCH v1 3/8] x86/entry/clearregs: Clear registers for 64bit SYSCALL

On Tue, Jan 09, 2018 at 05:03:23PM -0800, Andi Kleen wrote: > From: Andi Kleen > > We clear all the non argument registers for 64bit SYSCALLs > to minimize any risk of bad speculation using user values. > > So far unused argument registers still leak. To be addressed > in

Re: [PATCH v1 3/8] x86/entry/clearregs: Clear registers for 64bit SYSCALL

On Tue, Jan 09, 2018 at 05:03:23PM -0800, Andi Kleen wrote: > From: Andi Kleen > > We clear all the non argument registers for 64bit SYSCALLs > to minimize any risk of bad speculation using user values. > > So far unused argument registers still leak. To be addressed > in future patches. > >

[PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

Customer reported memory corruption issue on previous mlx4_en driver version where the order-3 pages and multiple page reference counting were still used. Finally, find out one of the root causes is that the HW may see stale rx_descs due to prod db updating reaches HW before rx_desc. Especially

[PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

Customer reported memory corruption issue on previous mlx4_en driver version where the order-3 pages and multiple page reference counting were still used. Finally, find out one of the root causes is that the HW may see stale rx_descs due to prod db updating reaches HW before rx_desc. Especially

Re: [PATCH v2 04/19] x86: implement ifence()

On Thu, Jan 11, 2018 at 6:27 PM, Eric W. Biederman wrote: > > Dan Williams writes: > > > The new barrier, 'ifence', ensures that no instructions past the > > boundary are speculatively executed. > > This needs a much better description. > > If

Re: [PATCH v2 04/19] x86: implement ifence()

On Thu, Jan 11, 2018 at 6:27 PM, Eric W. Biederman wrote: > > Dan Williams writes: > > > The new barrier, 'ifence', ensures that no instructions past the > > boundary are speculatively executed. > > This needs a much better description. > > If that description was valid we could add ifence in

Re: [PATCH 05/12] arm64: dts: mt7622: add PMIC MT6380 related nodes

Hi, Philippe Currently, I'm really confused about what usage STYLE of SPDX license identifier I should use for each type of file. could you point me where I can find the related document describing SPDX usage style for those files expected by the community in the future? I found more than one

Re: [PATCH 05/12] arm64: dts: mt7622: add PMIC MT6380 related nodes

Hi, Philippe Currently, I'm really confused about what usage STYLE of SPDX license identifier I should use for each type of file. could you point me where I can find the related document describing SPDX usage style for those files expected by the community in the future? I found more than one

Re: [PATCH net-next 00/11] add some new features and fix some bugs

On 2018/1/12 1:07, David Miller wrote: From: Peng Li Date: Thu, 11 Jan 2018 19:45:55 +0800 This patchset adds some new features and fixes some bugs: [patch 1/11] adds ethtool_ops.get_channels support for VF. [patch 2/11] removes TSO config command from VF driver.

Re: [PATCH net-next 00/11] add some new features and fix some bugs

On 2018/1/12 1:07, David Miller wrote: From: Peng Li Date: Thu, 11 Jan 2018 19:45:55 +0800 This patchset adds some new features and fixes some bugs: [patch 1/11] adds ethtool_ops.get_channels support for VF. [patch 2/11] removes TSO config command from VF driver. [patch 3/11] adds

Re: [PATCH v1 1/8] x86/entry/clearregs: Remove partial stack frame in fast system call

On Tue, Jan 09, 2018 at 05:03:21PM -0800, Andi Kleen wrote: > From: Andi Kleen > > Remove the partial stack frame in the 64bit syscall fast path. > In the next patch we want to clear the extra registers, which requires > to always save all registers. So remove the partial

Re: [PATCH v1 1/8] x86/entry/clearregs: Remove partial stack frame in fast system call

On Tue, Jan 09, 2018 at 05:03:21PM -0800, Andi Kleen wrote: > From: Andi Kleen > > Remove the partial stack frame in the 64bit syscall fast path. > In the next patch we want to clear the extra registers, which requires > to always save all registers. So remove the partial stack frame > in the

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Fri, 12 Jan 2018 11:56:12 +0900 Sergey Senozhatsky wrote: > Hi, > > On (01/11/18 11:29), Steven Rostedt wrote: > [..] > > > - if the patch's goal is to bound (not necessarily to watchdog's > > > threshold) > > > the amount of time we spend in

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Fri, 12 Jan 2018 11:56:12 +0900 Sergey Senozhatsky wrote: > Hi, > > On (01/11/18 11:29), Steven Rostedt wrote: > [..] > > > - if the patch's goal is to bound (not necessarily to watchdog's > > > threshold) > > > the amount of time we spend in console_unlock(), then the patch is kinda > > >

Re: [PATCH 3/5] x86/ibrs: Add direct access support for MSR_IA32_SPEC_CTRL

On Thu, Jan 11, 2018 at 05:58:11PM -0800, Dave Hansen wrote: > On 01/11/2018 05:32 PM, Ashok Raj wrote: > > +static void save_guest_spec_ctrl(struct vcpu_vmx *vmx) > > +{ > > + if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { > > + vmx->spec_ctrl = spec_ctrl_get(); > > +

Re: [PATCH 3/5] x86/ibrs: Add direct access support for MSR_IA32_SPEC_CTRL

On Thu, Jan 11, 2018 at 05:58:11PM -0800, Dave Hansen wrote: > On 01/11/2018 05:32 PM, Ashok Raj wrote: > > +static void save_guest_spec_ctrl(struct vcpu_vmx *vmx) > > +{ > > + if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { > > + vmx->spec_ctrl = spec_ctrl_get(); > > +

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/11/18 20:30), Steven Rostedt wrote: [..] > Today, printk() can print for a time of A * B, where, as you state > above: > >A is the amount of data to print in the worst case >B the time call_console_drivers() needs to print a single > char to all registered and enabled

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/11/18 20:30), Steven Rostedt wrote: [..] > Today, printk() can print for a time of A * B, where, as you state > above: > >A is the amount of data to print in the worst case >B the time call_console_drivers() needs to print a single > char to all registered and enabled

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

From: Alexei Starovoitov Date: Wed, 10 Jan 2018 17:58:54 -0800 > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: >> Hi all, >> >> After merging the net-next tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >>

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

From: Alexei Starovoitov Date: Wed, 10 Jan 2018 17:58:54 -0800 > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: >> Hi all, >> >> After merging the net-next tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> kernel/bpf/verifier.o: In function

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: > On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: > >> > >> What's wrong with native_read_msr()? > > > > Yes, i think i should have added to msr.h. The names didn't read as a > > pair, one was

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: > On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: > >> > >> What's wrong with native_read_msr()? > > > > Yes, i think i should have added to msr.h. The names didn't read as a > > pair, one was native_read_msr, wrmsrl could be

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

Hi, On (01/11/18 11:29), Steven Rostedt wrote: [..] > > - if the patch's goal is to bound (not necessarily to watchdog's threshold) > > the amount of time we spend in console_unlock(), then the patch is kinda > > overcomplicated. but no further questions in this case. > > It's goal is to keep

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

Hi, On (01/11/18 11:29), Steven Rostedt wrote: [..] > > - if the patch's goal is to bound (not necessarily to watchdog's threshold) > > the amount of time we spend in console_unlock(), then the patch is kinda > > overcomplicated. but no further questions in this case. > > It's goal is to keep

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Thu, 11 Jan 2018 20:30:57 -0500 Steven Rostedt wrote: > I have to say that your analysis here really does point out the benefit > of my patch. > > Today, printk() can print for a time of A * B, where, as you state > above: > >A is the amount of data to print in the

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Thu, 11 Jan 2018 20:30:57 -0500 Steven Rostedt wrote: > I have to say that your analysis here really does point out the benefit > of my patch. > > Today, printk() can print for a time of A * B, where, as you state > above: > >A is the amount of data to print in the worst case >B the

[PATCH 1/2] genirq/affinity: assign vectors to all possible CPUs

From: Christoph Hellwig Currently we assign managed interrupt vectors to all present CPUs. This works fine for systems were we only online/offline CPUs. But in case of systems that support physical CPU hotplug (or the virtualized version of it) this means the additional CPUs

[PATCH 1/2] genirq/affinity: assign vectors to all possible CPUs

From: Christoph Hellwig Currently we assign managed interrupt vectors to all present CPUs. This works fine for systems were we only online/offline CPUs. But in case of systems that support physical CPU hotplug (or the virtualized version of it) this means the additional CPUs covered for in the

[PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

From: Christoph Hellwig The previous patch assigns interrupt vectors to all possible CPUs, so now hctx can be mapped to possible CPUs, this patch applies this fact to simplify queue mapping & schedule so that we don't need to handle CPU hotplug for dealing with physical CPU plug &

[PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

From: Christoph Hellwig The previous patch assigns interrupt vectors to all possible CPUs, so now hctx can be mapped to possible CPUs, this patch applies this fact to simplify queue mapping & schedule so that we don't need to handle CPU hotplug for dealing with physical CPU plug & unplug. With

[PATCH 0/2] blk-mq: support physical CPU hotplug

Hi, This two patches support physical CPU hotplug, so that we can make blk-mq scale well when new physical CPU is added or removed, and this use case is normal for VM world. Also this patchset fixes the following warning reported by Christian Borntraeger:

[PATCH 0/2] blk-mq: support physical CPU hotplug

Hi, This two patches support physical CPU hotplug, so that we can make blk-mq scale well when new physical CPU is added or removed, and this use case is normal for VM world. Also this patchset fixes the following warning reported by Christian Borntraeger:

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: >On 01/11/18 at 10:04am, Kees Cook wrote: >> On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He wrote: >> > Hi Luiz, >> > >> > On 01/04/18 at 11:21am, Luiz Capitulino wrote: >> >> Having a generic kaslr parameter to control

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: >On 01/11/18 at 10:04am, Kees Cook wrote: >> On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He wrote: >> > Hi Luiz, >> > >> > On 01/04/18 at 11:21am, Luiz Capitulino wrote: >> >> Having a generic kaslr parameter to control where the kernel is

Re: [PATCH v2 06/19] asm-generic/barrier: mask speculative execution flows

Dan Williams writes: > diff --git a/include/linux/nospec.h b/include/linux/nospec.h > new file mode 100644 > index ..5c66fc30f919 > --- /dev/null > +++ b/include/linux/nospec.h > @@ -0,0 +1,71 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright(c) 2018

Re: [PATCH v2 06/19] asm-generic/barrier: mask speculative execution flows

Dan Williams writes: > diff --git a/include/linux/nospec.h b/include/linux/nospec.h > new file mode 100644 > index ..5c66fc30f919 > --- /dev/null > +++ b/include/linux/nospec.h > @@ -0,0 +1,71 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright(c) 2018 Intel Corporation. All

Re: [PATCH] arm64: dts: angler: add pstore-ramoops support

On Thu, Dec 28, 2017 at 02:38:29AM -0500, zhuoweizh...@yahoo.com wrote: > From: Zhuowei Zhang > > Support pstore-ramoops for retrieving kernel oops and panics after reboot. > > The address and configs are taken from the downstream kernel's device tree. > >

Re: [PATCH] arm64: dts: angler: add pstore-ramoops support

On Thu, Dec 28, 2017 at 02:38:29AM -0500, zhuoweizh...@yahoo.com wrote: > From: Zhuowei Zhang > > Support pstore-ramoops for retrieving kernel oops and panics after reboot. > > The address and configs are taken from the downstream kernel's device tree. > > Signed-off-by: Zhuowei Zhang > --- >

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On 01/11/18 at 10:04am, Kees Cook wrote: > On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He wrote: > > Hi Luiz, > > > > On 01/04/18 at 11:21am, Luiz Capitulino wrote: > >> Having a generic kaslr parameter to control where the kernel is extracted > >> is one solution for this problem.

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On 01/11/18 at 10:04am, Kees Cook wrote: > On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He wrote: > > Hi Luiz, > > > > On 01/04/18 at 11:21am, Luiz Capitulino wrote: > >> Having a generic kaslr parameter to control where the kernel is extracted > >> is one solution for this problem. > >> > >> The

[PATCH v2 0/2] Add reboot modes for LEGO MINDSTORMS EV3

This series adds a new device tree node to declare a special memory address that is used by the I2C bootloader on LEGO MINDSTORMS EV3 to boot into a special firmware update mode and enables the required module to use it. v2 changes: * rebase on linux-davinci/master David Lechner (2): ARM: dts:

[PATCH v2 2/2] ARM: davinci_all_defconfig: enable SYSCON_REBOOT_MODE

This enables SYSCON_REBOOT_MODE as a module. This is used by LEGO MINDSTORMS EV3 to reboot into a special firmware update mode. Signed-off-by: David Lechner --- arch/arm/configs/davinci_all_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v2 0/2] Add reboot modes for LEGO MINDSTORMS EV3

This series adds a new device tree node to declare a special memory address that is used by the I2C bootloader on LEGO MINDSTORMS EV3 to boot into a special firmware update mode and enables the required module to use it. v2 changes: * rebase on linux-davinci/master David Lechner (2): ARM: dts:

[PATCH v2 2/2] ARM: davinci_all_defconfig: enable SYSCON_REBOOT_MODE

This enables SYSCON_REBOOT_MODE as a module. This is used by LEGO MINDSTORMS EV3 to reboot into a special firmware update mode. Signed-off-by: David Lechner --- arch/arm/configs/davinci_all_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/davinci_all_defconfig

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