Re: [PATCH v2] infiniband: remove WARN that is not kernel bug

On 11/21/2016 12:38 PM, Leon Romanovsky wrote: > On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote: >> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote: In ib_ucm_write function there is a wrong prefix: + pr_err_once("ucm_write: process %d (%s)

Re: [PATCH v2] infiniband: remove WARN that is not kernel bug

On 11/21/2016 12:38 PM, Leon Romanovsky wrote: > On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote: >> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote: In ib_ucm_write function there is a wrong prefix: + pr_err_once("ucm_write: process %d (%s)

Re: [PATCH v3 2/2] drm/panel: simple: Add support BOE nv101wxmn51

Hi, On Tue, Dec 13, 2016 at 7:19 PM, Caesar Wang wrote: > 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon > TFT's as an active switching devices. It can be supported by the > simple-panel driver. > > Read the panel default edid information: > > EDID

Re: [RFC] perf/x86/intel: Account interrupts for PEBS errors

On Wed, Dec 14, 2016 at 07:07:30PM +0100, Peter Zijlstra wrote: > On Wed, Dec 14, 2016 at 05:50:36PM +0100, Jiri Olsa wrote: > > > > I also fail to reproduce on other than snb_x (model 45) server > > reproduces on my ivb-ep as well model 62. > > > thoughts? > > cute find :-) > > > +++

Re: [PATCH v3 2/2] drm/panel: simple: Add support BOE nv101wxmn51

Hi, On Tue, Dec 13, 2016 at 7:19 PM, Caesar Wang wrote: > 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon > TFT's as an active switching devices. It can be supported by the > simple-panel driver. > > Read the panel default edid information: > > EDID MODE DETAILS >

Re: [RFC] perf/x86/intel: Account interrupts for PEBS errors

On Wed, Dec 14, 2016 at 07:07:30PM +0100, Peter Zijlstra wrote: > On Wed, Dec 14, 2016 at 05:50:36PM +0100, Jiri Olsa wrote: > > > > I also fail to reproduce on other than snb_x (model 45) server > > reproduces on my ivb-ep as well model 62. > > > thoughts? > > cute find :-) > > > +++

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 10:06 AM, arvind Yadav wrote: Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has 3.10 kernel version. In this device, we were getting Page allocation failure. This makes absolutely no sense

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 10:06 AM, arvind Yadav wrote: Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has 3.10 kernel version. In this device, we were getting Page allocation failure. This makes absolutely no sense

Re: Moratorium on coding style patches (was Re: [PATCH] include/linux/kernel.h: fixed coding style issues)

Alexey Dobriyan writes: > OK, someone needs to say it. > > These type of patches are advertised by some people as a good way > to enter Linux kernel development. You know, to learn how the process > works, how to setup email client pipeline, to get initial feedback. > And it

Re: Moratorium on coding style patches (was Re: [PATCH] include/linux/kernel.h: fixed coding style issues)

Alexey Dobriyan writes: > OK, someone needs to say it. > > These type of patches are advertised by some people as a good way > to enter Linux kernel development. You know, to learn how the process > works, how to setup email client pipeline, to get initial feedback. > And it is true. What those

Re: [PATCH 3/3] oom, trace: add compaction retry tracepoint

On Wed 14-12-16 18:28:38, Vlastimil Babka wrote: > On 12/14/2016 03:53 PM, Michal Hocko wrote: > > From: Michal Hocko > > > > Higher order requests oom debugging is currently quite hard. We do have > > some compaction points which can tell us how the compaction is operating > >

Re: [PATCH 3/3] oom, trace: add compaction retry tracepoint

On Wed 14-12-16 18:28:38, Vlastimil Babka wrote: > On 12/14/2016 03:53 PM, Michal Hocko wrote: > > From: Michal Hocko > > > > Higher order requests oom debugging is currently quite hard. We do have > > some compaction points which can tell us how the compaction is operating > > but there is no

Applied "spi: armada-3700: fix unsigned compare than zero on irq" to the spi tree

The patch spi: armada-3700: fix unsigned compare than zero on irq has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi David, On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: > Just marking the structure __packed, whether necessary or not, makes > the compiler assume that the members are not aligned and causes > byte-by-byte accesses to be performed for words. > Never, _ever_, use

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi David, On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: > Just marking the structure __packed, whether necessary or not, makes > the compiler assume that the members are not aligned and causes > byte-by-byte accesses to be performed for words. > Never, _ever_, use __packed unless

Applied "spi: armada-3700: fix unsigned compare than zero on irq" to the spi tree

The patch spi: armada-3700: fix unsigned compare than zero on irq has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: fsl-lpspi: Pre-initialize ret in fsl_lpspi_transfer_one_msg()" to the spi tree

The patch spi: fsl-lpspi: Pre-initialize ret in fsl_lpspi_transfer_one_msg() has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "spi: SPI_FSL_DSPI should depend on HAS_DMA" to the spi tree

The patch spi: SPI_FSL_DSPI should depend on HAS_DMA has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "spi: fsl-lpspi: Pre-initialize ret in fsl_lpspi_transfer_one_msg()" to the spi tree

The patch spi: fsl-lpspi: Pre-initialize ret in fsl_lpspi_transfer_one_msg() has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "spi: SPI_FSL_DSPI should depend on HAS_DMA" to the spi tree

The patch spi: SPI_FSL_DSPI should depend on HAS_DMA has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has 3.10 kernel version. In this device, we were getting Page allocation failure. Vmalloc size was not enough to run all application. So we have decide to

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has 3.10 kernel version. In this device, we were getting Page allocation failure. Vmalloc size was not enough to run all application. So we have decide to

[PATCH] genirq/affinity: fix node generation from cpumask

Commit 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading infrastructure") introduced a better IRQ spreading mechanism, taking account of the available NUMA nodes in the machine. Problem is that the algorithm of retrieving the nodemask iterates "linearly" based on the number of online

[PATCH] genirq/affinity: fix node generation from cpumask

Commit 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading infrastructure") introduced a better IRQ spreading mechanism, taking account of the available NUMA nodes in the machine. Problem is that the algorithm of retrieving the nodemask iterates "linearly" based on the number of online

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Sat, Dec 10, 2016 at 01:41:03PM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 09, 2016 at 11:46:54PM +0100, Dodji Seketeli wrote: > > Hello, > > > > Nicholas Piggin a �crit: > > > > [...] > > > > > That said, a dwarf based checker tool should be able to do as good a job

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Sat, Dec 10, 2016 at 01:41:03PM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 09, 2016 at 11:46:54PM +0100, Dodji Seketeli wrote: > > Hello, > > > > Nicholas Piggin a �crit: > > > > [...] > > > > > That said, a dwarf based checker tool should be able to do as good a job > > > (maybe a bit

Re: [PATCH] perf tools: ignore zombie process for user profile

On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > If user has zombie process, the perf record -u will error out. > Here is an example. > $ ./testd & > [1] 23796 > $ sudo perf record -e cycles -u kan > Error: > The

Re: [PATCH] perf tools: ignore zombie process for user profile

On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > If user has zombie process, the perf record -u will error out. > Here is an example. > $ ./testd & > [1] 23796 > $ sudo perf record -e cycles -u kan > Error: > The sys_perf_event_open() syscall

Re: [PATCH] IB/usnic: simplify IS_ERR_OR_NULL to IS_ERR

On 11/11/2016 2:04 PM, Julia Lawall wrote: > The function usnic_ib_qp_grp_get_chunk only returns an ERR_PTR value or a > valid pointer, never NULL. The same is true of get_qp_res_chunk, which > just returns the result of calling usnic_ib_qp_grp_get_chunk. Simplify > IS_ERR_OR_NULL to IS_ERR in

Re: [PATCH] IB/usnic: simplify IS_ERR_OR_NULL to IS_ERR

On 11/11/2016 2:04 PM, Julia Lawall wrote: > The function usnic_ib_qp_grp_get_chunk only returns an ERR_PTR value or a > valid pointer, never NULL. The same is true of get_qp_res_chunk, which > just returns the result of calling usnic_ib_qp_grp_get_chunk. Simplify > IS_ERR_OR_NULL to IS_ERR in

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hey Ted, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > One somewhat undesirable aspect of the current algorithm is that we > never change random_int_secret. Why exactly would this be a problem? So long as the secret is kept secret, the PRF is secure. If an attacker can

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hey Ted, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > One somewhat undesirable aspect of the current algorithm is that we > never change random_int_secret. Why exactly would this be a problem? So long as the secret is kept secret, the PRF is secure. If an attacker can read arbitrary

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

From: "Jason A. Donenfeld" Date: Wed, 14 Dec 2016 13:53:10 +0100 > In all current uses of __packed in the code, I think the impact is > precisely zero, because all structures have members in descending > order of size, with each member being a perfect multiple of the one > below

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

From: "Jason A. Donenfeld" Date: Wed, 14 Dec 2016 13:53:10 +0100 > In all current uses of __packed in the code, I think the impact is > precisely zero, because all structures have members in descending > order of size, with each member being a perfect multiple of the one > below it. The __packed

Re: [PATCH] IBcore/CM: Issue DREQ when receiving REQ/REP for stale QP

On 10/28/2016 7:14 AM, Hans Westgaard Ry wrote: > from "InfiBand Architecture Specifications Volume 1": > > A QP is said to have a stale connection when only one side has > connection information. A stale connection may result if the remote CM > had dropped the connection and sent a DREQ

Re: [PATCH 2/3] perf/x86/pebs: add workaround for broken OVFL status on HSW

Just spotted this again, ping? On Thu, Mar 10, 2016 at 11:42:36AM +0100, Peter Zijlstra wrote: > On Wed, Mar 09, 2016 at 09:40:07AM -0800, Stephane Eranian wrote: > > With your queue.tip perf/core branch, I run into another problem. > > I am monitoring with 2 PEBS events and I have the NMI

Re: [PATCH] IBcore/CM: Issue DREQ when receiving REQ/REP for stale QP

On 10/28/2016 7:14 AM, Hans Westgaard Ry wrote: > from "InfiBand Architecture Specifications Volume 1": > > A QP is said to have a stale connection when only one side has > connection information. A stale connection may result if the remote CM > had dropped the connection and sent a DREQ

Re: [PATCH 2/3] perf/x86/pebs: add workaround for broken OVFL status on HSW

Just spotted this again, ping? On Thu, Mar 10, 2016 at 11:42:36AM +0100, Peter Zijlstra wrote: > On Wed, Mar 09, 2016 at 09:40:07AM -0800, Stephane Eranian wrote: > > With your queue.tip perf/core branch, I run into another problem. > > I am monitoring with 2 PEBS events and I have the NMI

Re: [PATCH] IB/isert: do not ignore errors in dma_map_single()

On 10/21/2016 6:01 PM, Alexey Khoroshilov wrote: > There are several places, where errors in dma_map_single() are > ignored. The patch fixes them. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Thanks, applied.

Re: [PATCH] IB/isert: do not ignore errors in dma_map_single()

On 10/21/2016 6:01 PM, Alexey Khoroshilov wrote: > There are several places, where errors in dma_map_single() are > ignored. The patch fixes them. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Thanks, applied. -- Doug Ledford

Re: [PATCH] infiniband: nes: nes_nic: use new api ethtool_{get|set}_link_ksettings

On 10/25/2016 11:29 AM, Philippe Reynes wrote: > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Thanks, applied. -- Doug Ledford GPG Key ID: 0E572FDD

Re: [PATCH] infiniband: nes: nes_nic: use new api ethtool_{get|set}_link_ksettings

On 10/25/2016 11:29 AM, Philippe Reynes wrote: > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Thanks, applied. -- Doug Ledford GPG Key ID: 0E572FDD signature.asc Description: OpenPGP

Re: [PATCH] Add +~800M crashkernel explaination

On Tue, Dec 13, 2016 at 8:08 PM, Xunlei Pang wrote: > On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote: >> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote: >>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote: When trying to configure crashkernel greater than

Re: [PATCH] Add +~800M crashkernel explaination

On Tue, Dec 13, 2016 at 8:08 PM, Xunlei Pang wrote: > On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote: >> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote: >>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote: When trying to configure crashkernel greater than about 800 MB, the kernel fails

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On Wed, Dec 14, 2016 at 3:47 PM, David Laight wrote: > Just remove the __packed and ensure that the structure is 'nice'. > This includes ensuring there is no 'tail padding'. > In some cases you'll need to put the port number into a 32bit field. I'd rather not. There's no

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On Wed, Dec 14, 2016 at 3:47 PM, David Laight wrote: > Just remove the __packed and ensure that the structure is 'nice'. > This includes ensuring there is no 'tail padding'. > In some cases you'll need to put the port number into a 32bit field. I'd rather not. There's no point in wasting extra

[PATCH] perf tools: ignore zombie process for user profile

From: Kan Liang If user has zombie process, the perf record -u will error out. Here is an example. $ ./testd & [1] 23796 $ sudo perf record -e cycles -u kan Error: The sys_perf_event_open() syscall returned with 3 (No such process) for event (cycles). /bin/dmesg may

[PATCH] perf tools: ignore zombie process for user profile

From: Kan Liang If user has zombie process, the perf record -u will error out. Here is an example. $ ./testd & [1] 23796 $ sudo perf record -e cycles -u kan Error: The sys_perf_event_open() syscall returned with 3 (No such process) for event (cycles). /bin/dmesg may provide additional

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 08:25 AM, Arvind Yadav wrote: Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Have you ever seen this failure in the wild? How was the patch tested? Thanks, David Daney

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 08:25 AM, Arvind Yadav wrote: Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Have you ever seen this failure in the wild? How was the patch tested? Thanks, David Daney

Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot

On Wed, Dec 14, 2016 at 09:52:31PM +0800, Chen-Yu Tsai wrote: > What this patch does is make sure the registers match, to guarantee > access, and then reinitialize the regmap cache to get rid of any > stale data. So what you're saying is that previous writes may have been ignored? > > If the

Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot

On Wed, Dec 14, 2016 at 09:52:31PM +0800, Chen-Yu Tsai wrote: > What this patch does is make sure the registers match, to guarantee > access, and then reinitialize the regmap cache to get rid of any > stale data. So what you're saying is that previous writes may have been ignored? > > If the

Re: Fw: [lkp-developer] [sched,rcu] cf7a2dca60: [No primary change] +186% will-it-scale.time.involuntary_context_switches

On Wed 14-12-16 08:48:27, Paul E. McKenney wrote: > On Wed, Dec 14, 2016 at 05:15:41PM +0100, Michal Hocko wrote: > > On Wed 14-12-16 03:06:09, Paul E. McKenney wrote: > > > On Wed, Dec 14, 2016 at 10:54:25AM +0100, Michal Hocko wrote: > > > > On Tue 13-12-16 07:14:08, Paul E. McKenney wrote: > >

Re: Fw: [lkp-developer] [sched,rcu] cf7a2dca60: [No primary change] +186% will-it-scale.time.involuntary_context_switches

On Wed 14-12-16 08:48:27, Paul E. McKenney wrote: > On Wed, Dec 14, 2016 at 05:15:41PM +0100, Michal Hocko wrote: > > On Wed 14-12-16 03:06:09, Paul E. McKenney wrote: > > > On Wed, Dec 14, 2016 at 10:54:25AM +0100, Michal Hocko wrote: > > > > On Tue 13-12-16 07:14:08, Paul E. McKenney wrote: > >

Re: [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header

Hi Michal, [auto build test ERROR on tip/perf/core] [also build test ERROR on v4.9 next-20161214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-oom-add-oom-detection

Re: [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header

Hi Michal, [auto build test ERROR on tip/perf/core] [also build test ERROR on v4.9 next-20161214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-oom-add-oom-detection

Re: [PATCH 3/3] oom, trace: add compaction retry tracepoint

On 12/14/2016 03:53 PM, Michal Hocko wrote: From: Michal Hocko Higher order requests oom debugging is currently quite hard. We do have some compaction points which can tell us how the compaction is operating but there is no trace point to tell us about compaction retry logic.

Re: [PATCH 3/3] oom, trace: add compaction retry tracepoint

On 12/14/2016 03:53 PM, Michal Hocko wrote: From: Michal Hocko Higher order requests oom debugging is currently quite hard. We do have some compaction points which can tell us how the compaction is operating but there is no trace point to tell us about compaction retry logic. This patch adds a

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

think I'd even prefer here a simple aid = kvm_xapic_id(apic); if (apic_x2apic_mode(apic)) aid = kvm_x2apic_id(apic); that would keep changes minimal and I don't really see any benefit in the code when splitting handling up. It is neccesassary to write an entry for both IDs and I

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

think I'd even prefer here a simple aid = kvm_xapic_id(apic); if (apic_x2apic_mode(apic)) aid = kvm_x2apic_id(apic); that would keep changes minimal and I don't really see any benefit in the code when splitting handling up. It is neccesassary to write an entry for both IDs and I

linux-next x86 build fixes

Curious if the x86 symbol build issues are supposed to be resolved already on linux-next as of today, if not, how's it looking to get this fixed ? I am carrying around Adam's temporary patch "kbuild: provide include/asm/asm-prototypes.h for x86" on top of linux-next but each day I move on I keep

[PATCH 1/2] xilinx_dma: Edit device tree bindings documentation

Add reset property documentation for Xilinx DMA Signed-off-by: Ramiro Oliveira --- Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt

linux-next x86 build fixes

Curious if the x86 symbol build issues are supposed to be resolved already on linux-next as of today, if not, how's it looking to get this fixed ? I am carrying around Adam's temporary patch "kbuild: provide include/asm/asm-prototypes.h for x86" on top of linux-next but each day I move on I keep

[PATCH 1/2] xilinx_dma: Edit device tree bindings documentation

Add reset property documentation for Xilinx DMA Signed-off-by: Ramiro Oliveira --- Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 14/12/2016 18:07, Brijesh Singh wrote: >> > > Since now we are going to perform multiple conditional checks before > concluding that its safe to use HW provided GPA. How about if we add two > functions "emulator_is_rep_string_op" and "emulator_is_two_mem_op" into > emulator.c and use these

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 14/12/2016 18:07, Brijesh Singh wrote: >> > > Since now we are going to perform multiple conditional checks before > concluding that its safe to use HW provided GPA. How about if we add two > functions "emulator_is_rep_string_op" and "emulator_is_two_mem_op" into > emulator.c and use these

Re: [PATCH 0/2] IB/rdmavt: cq ktrhead worker fix and API update

On 10/20/2016 8:56 AM, Dalessandro, Dennis wrote: > On Wed, 2016-10-19 at 14:07 +0200, Petr Mladek wrote: >> The kthread worker API has been improved in 4.9-rc1. The 2nd >> patch uses the new functions and simplifies the kthread worker >> creation and destroying. >> >> I have found a possible race

Re: [PATCH 0/2] IB/rdmavt: cq ktrhead worker fix and API update

On 10/20/2016 8:56 AM, Dalessandro, Dennis wrote: > On Wed, 2016-10-19 at 14:07 +0200, Petr Mladek wrote: >> The kthread worker API has been improved in 4.9-rc1. The 2nd >> patch uses the new functions and simplifies the kthread worker >> creation and destroying. >> >> I have found a possible race

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hello Bartlomiej, On 12/14/2016 01:10 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote: >> Hello Bartlomiej, >> >> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote: >>> >>> Hi, >>> >>> On Wednesday, December 14,

Re: [PATCH v3 3/3] perf tool: add cgroup identifier entry in perf report

Peter Zijlstra writes: > On Wed, Dec 14, 2016 at 08:56:43AM +1300, Eric W. Biederman wrote: >> >> I would just make the identifier a structure containing the >> device number and the inode number. It didn't look like perf required >> the identifier to be a simple integer.

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hello Bartlomiej, On 12/14/2016 01:10 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote: >> Hello Bartlomiej, >> >> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote: >>> >>> Hi, >>> >>> On Wednesday, December 14,

Re: [PATCH v3 3/3] perf tool: add cgroup identifier entry in perf report

Peter Zijlstra writes: > On Wed, Dec 14, 2016 at 08:56:43AM +1300, Eric W. Biederman wrote: >> >> I would just make the identifier a structure containing the >> device number and the inode number. It didn't look like perf required >> the identifier to be a simple integer. > > Right, perf

Re: [GIT PULL] ext4 updates for 4.10

[ Johannes added to participants due to radix tree changes ] On Tue, Dec 13, 2016 at 12:00 PM, Theodore Ts'o wrote: > > This merge request includes the dax-4.0-iomap-pmd branch which is > needed for both ext4 and xfs dax changes to use iomap for DAX. It > also includes the

Re: [GIT PULL] ext4 updates for 4.10

[ Johannes added to participants due to radix tree changes ] On Tue, Dec 13, 2016 at 12:00 PM, Theodore Ts'o wrote: > > This merge request includes the dax-4.0-iomap-pmd branch which is > needed for both ext4 and xfs dax changes to use iomap for DAX. It > also includes the fscrypt branch which

[PATCH] drm/tegra: hdmi: Fix audio to work with any pixel clock rate

The audio setting implementation was limited to a few specific pixel clocks. This prevented HDMI audio from working on several test devices as they need a pixel clock that is not supported by this implementation. Fix this by implementing the algorithm provided in the TRM using fixed point

[PATCH 0/2] xilinx_dma: Add external reset control

This patchset adds support for controlling an external reset line. Since this reset line is optional it won't break compatibility. Ramiro Oliveira (2): xilinx_dma: Edit device tree bindings documentation xilinx_dma: Add reset support .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6

[PATCH 0/2] xilinx_dma: Add external reset control

This patchset adds support for controlling an external reset line. Since this reset line is optional it won't break compatibility. Ramiro Oliveira (2): xilinx_dma: Edit device tree bindings documentation xilinx_dma: Add reset support .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6

[PATCH] drm/tegra: hdmi: Fix audio to work with any pixel clock rate

The audio setting implementation was limited to a few specific pixel clocks. This prevented HDMI audio from working on several test devices as they need a pixel clock that is not supported by this implementation. Fix this by implementing the algorithm provided in the TRM using fixed point

[PATCH 2/2] xilinx_dma: Add reset support

Add a DT property to control an optional external reset line Signed-off-by: Ramiro Oliveira --- drivers/dma/xilinx/xilinx_dma.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c

[PATCH 2/2] xilinx_dma: Add reset support

Add a DT property to control an optional external reset line Signed-off-by: Ramiro Oliveira --- drivers/dma/xilinx/xilinx_dma.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c index 5c9f11b..b845224

Re: [PATCH 2/3] oom, trace: Add oom detection tracepoints

On 12/14/2016 03:53 PM, Michal Hocko wrote: From: Michal Hocko I guess the Subject should be more specific to the tracepoint? should_reclaim_retry is the central decision point for declaring the OOM. It might be really useful to expose data used for this decision making

Re: [PATCH 2/3] oom, trace: Add oom detection tracepoints

On 12/14/2016 03:53 PM, Michal Hocko wrote: From: Michal Hocko I guess the Subject should be more specific to the tracepoint? should_reclaim_retry is the central decision point for declaring the OOM. It might be really useful to expose data used for this decision making when debugging an

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

2016-12-14 17:59+0100, Paolo Bonzini: > On 14/12/2016 17:15, David Hildenbrand wrote: >> >>> kvm_for_each_vcpu(i, vcpu, kvm) >>> if (kvm_apic_present(vcpu)) >>> -max_id = max(max_id, kvm_apic_id(vcpu->arch.apic)); >>> +max_id = max(max_id,

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

2016-12-14 17:59+0100, Paolo Bonzini: > On 14/12/2016 17:15, David Hildenbrand wrote: >> >>> kvm_for_each_vcpu(i, vcpu, kvm) >>> if (kvm_apic_present(vcpu)) >>> -max_id = max(max_id, kvm_apic_id(vcpu->arch.apic)); >>> +max_id = max(max_id,

Re: [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header

On 12/14/2016 03:53 PM, Michal Hocko wrote: From: Michal Hocko COMPACTION_STATUS resp. ZONE_TYPE are currently used to translate enum compact_result resp. struct zone index into their symbolic names for an easier post processing. The follow up patch would like to reuse this as

Re: [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header

On 12/14/2016 03:53 PM, Michal Hocko wrote: From: Michal Hocko COMPACTION_STATUS resp. ZONE_TYPE are currently used to translate enum compact_result resp. struct zone index into their symbolic names for an easier post processing. The follow up patch would like to reuse this as well. The code

Re: [PATCH v2] IB/mlx5: avoid bogus -Wmaybe-uninitialized warning

On 10/24/2016 4:48 PM, Arnd Bergmann wrote: > We get a false-positive warning in linux-next for the mlx5 driver: > > infiniband/hw/mlx5/mr.c: In function ‘mlx5_ib_reg_user_mr’: > infiniband/hw/mlx5/mr.c:1172:5: error: ‘order’ may be used uninitialized in > this function

Re: [PATCH v2] IB/mlx5: avoid bogus -Wmaybe-uninitialized warning

On 10/24/2016 4:48 PM, Arnd Bergmann wrote: > We get a false-positive warning in linux-next for the mlx5 driver: > > infiniband/hw/mlx5/mr.c: In function ‘mlx5_ib_reg_user_mr’: > infiniband/hw/mlx5/mr.c:1172:5: error: ‘order’ may be used uninitialized in > this function

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

2016-12-14 17:15+0100, David Hildenbrand: >> kvm_for_each_vcpu(i, vcpu, kvm) >> if (kvm_apic_present(vcpu)) >> -max_id = max(max_id, kvm_apic_id(vcpu->arch.apic)); >> +max_id = max(max_id, kvm_x2apic_id(vcpu->arch.apic)); >> >> new =

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

2016-12-14 17:15+0100, David Hildenbrand: >> kvm_for_each_vcpu(i, vcpu, kvm) >> if (kvm_apic_present(vcpu)) >> -max_id = max(max_id, kvm_apic_id(vcpu->arch.apic)); >> +max_id = max(max_id, kvm_x2apic_id(vcpu->arch.apic)); >> >> new =

Re: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access

On Wed, Dec 14, 2016 at 05:08:58PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote: > > Only decrement *iff* we're possitive. Warn if we've hit > > a situation where the counter is already 0 after we're done > > with a modprobe call, this would tell us we have an

Re: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access

On Wed, Dec 14, 2016 at 05:08:58PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote: > > Only decrement *iff* we're possitive. Warn if we've hit > > a situation where the counter is already 0 after we're done > > with a modprobe call, this would tell us we have an

Re: [PATCH] IB/mlx4: avoid a -Wmaybe-uninitialize warning

On 10/25/2016 12:16 PM, Arnd Bergmann wrote: > There is an old warning about mlx4_SW2HW_EQ_wrapper on x86: > > ethernet/mellanox/mlx4/resource_tracker.c: In function > ‘mlx4_SW2HW_EQ_wrapper’: > ethernet/mellanox/mlx4/resource_tracker.c:3071:10: error: ‘eq’ may be used > uninitialized in this

Re: [PATCH] IB/mlx4: avoid a -Wmaybe-uninitialize warning

On 10/25/2016 12:16 PM, Arnd Bergmann wrote: > There is an old warning about mlx4_SW2HW_EQ_wrapper on x86: > > ethernet/mellanox/mlx4/resource_tracker.c: In function > ‘mlx4_SW2HW_EQ_wrapper’: > ethernet/mellanox/mlx4/resource_tracker.c:3071:10: error: ‘eq’ may be used > uninitialized in this

Re: [GIT PULL] f2fs update for 4.10

On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim wrote: > > Could you please consider this pull request? Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c ("block,fs: use REQ_* flags directly")? Linus

Re: [GIT PULL] f2fs update for 4.10

On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim wrote: > > Could you please consider this pull request? Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c ("block,fs: use REQ_* flags directly")? Linus

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > David, are these encrypted keys ever exported anywhere? If not, could > the code use a mode that doesn't need padding? ecryptfs uses them, I think. David

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > David, are these encrypted keys ever exported anywhere? If not, could > the code use a mode that doesn't need padding? ecryptfs uses them, I think. David

[PATCH v3] intelrdt: resctrl: recommend locking for resctrlfs

There is a locking problem between different applications reading/writing to resctrlfs directory at the same time (read the patch below for details). Suggest a standard locking scheme for applications to use. Signed-off-by: Marcelo Tosatti diff --git

[PATCH v3] intelrdt: resctrl: recommend locking for resctrlfs

There is a locking problem between different applications reading/writing to resctrlfs directory at the same time (read the patch below for details). Suggest a standard locking scheme for applications to use. Signed-off-by: Marcelo Tosatti diff --git a/Documentation/x86/intel_rdt_ui.txt

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