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

On 11/04/2017 at 10:22:38 +1000, Stephen Rothwell wrote: > Hi Hans, > > On Mon, 10 Apr 2017 09:45:45 +0200 Hans de Goede wrote: > > > > On 10-04-17 08:04, Stephen Rothwell wrote: > > > > > > After merging the rtc tree, today's linux-next build (x86_64 allmodconfig) > > >

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

On 11/04/2017 at 10:22:38 +1000, Stephen Rothwell wrote: > Hi Hans, > > On Mon, 10 Apr 2017 09:45:45 +0200 Hans de Goede wrote: > > > > On 10-04-17 08:04, Stephen Rothwell wrote: > > > > > > After merging the rtc tree, today's linux-next build (x86_64 allmodconfig) > > > failed like this: > > >

Re: [PATCH] sched/deadline: Throttle a constrained task activated if overflow

On 04/11/2017 at 04:47 AM, Daniel Bristot de Oliveira wrote: > On 04/10/2017 11:22 AM, Xunlei Pang wrote: >> I was testing Daniel's changes with his test case in the commit >> df8eac8cafce ("sched/deadline: Throttle a constrained deadline >> task activated after the deadline"), and tweaked it a

Re: [PATCH] sched/deadline: Throttle a constrained task activated if overflow

On 04/11/2017 at 04:47 AM, Daniel Bristot de Oliveira wrote: > On 04/10/2017 11:22 AM, Xunlei Pang wrote: >> I was testing Daniel's changes with his test case in the commit >> df8eac8cafce ("sched/deadline: Throttle a constrained deadline >> task activated after the deadline"), and tweaked it a

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

Hi Greg, On Tue, 11 Apr 2017 07:38:32 +0200 Greg KH wrote: > > I should have this fixed now, sorry for taking so long. Thanks and no worries. -- Cheers, Stephen Rothwell

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

Hi Greg, On Tue, 11 Apr 2017 07:38:32 +0200 Greg KH wrote: > > I should have this fixed now, sorry for taking so long. Thanks and no worries. -- Cheers, Stephen Rothwell

linux-next: Tree for Apr 11

Hi all, Changes since 20170410: The crypto tree gained a conflict against the kbuild tree. The drm tree gained a conflict against the v4l-dvb tree. The mfd tree lost its build failure. The kvm-ppc tree still had its build failure for which I reverted 4 commits. The staging tree gained

linux-next: Tree for Apr 11

Hi all, Changes since 20170410: The crypto tree gained a conflict against the kbuild tree. The drm tree gained a conflict against the v4l-dvb tree. The mfd tree lost its build failure. The kvm-ppc tree still had its build failure for which I reverted 4 commits. The staging tree gained

Re: [RFC PATCH tip/master V3 0/8] kprobes/x86: Make kprobes instruction buffers read-only

Ping? On Wed, 29 Mar 2017 13:55:44 +0900 Masami Hiramatsu wrote: > Hi, > > This is the 3rd version of the series. I just updated 4/8 according > to Ingo's comment. > > This series tries to make kprobes instruction buffers read-only > pages. Since those buffers are used

Re: [RFC PATCH tip/master V3 0/8] kprobes/x86: Make kprobes instruction buffers read-only

Ping? On Wed, 29 Mar 2017 13:55:44 +0900 Masami Hiramatsu wrote: > Hi, > > This is the 3rd version of the series. I just updated 4/8 according > to Ingo's comment. > > This series tries to make kprobes instruction buffers read-only > pages. Since those buffers are used for trampoline code,

Re: [PATCH net-next] net: stmmac: set total length of the packet to be transmitted in TDES3

Hi Niklas patch looks ok for me, Alex any feedback? peppe On 4/10/2017 8:33 PM, Niklas Cassel wrote: From: Niklas Cassel Field FL/TPL in register TDES3 is not correctly set on GMAC4. TX appears to be functional on GMAC 4.10a even if this field is not set, however, to

Re: [PATCH net-next] net: stmmac: set total length of the packet to be transmitted in TDES3

Hi Niklas patch looks ok for me, Alex any feedback? peppe On 4/10/2017 8:33 PM, Niklas Cassel wrote: From: Niklas Cassel Field FL/TPL in register TDES3 is not correctly set on GMAC4. TX appears to be functional on GMAC 4.10a even if this field is not set, however, to avoid relying on

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

On Tue, Apr 11, 2017 at 07:15:42AM +0200, Greg KH wrote: > On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote: > > Hi Greg, > > > > After merging the staging tree, today's linux-next build (powerpc > > allyesconfig - I presume that an x86_64 allyesconfig will fail the > > same way)

Re: [PATCH 0/5] zram clean up

Hi Andrew, Could you drop this patchset? I will send updated version based on Sergey with some bug fixes. zram-handle-multiple-pages-attached-bios-bvec.patch zram-partial-io-refactoring.patch zram-use-zram_slot_lock-instead-of-raw-bit_spin_lock-op.patch zram-remove-zram_meta-structure.patch

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

On Tue, Apr 11, 2017 at 07:15:42AM +0200, Greg KH wrote: > On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote: > > Hi Greg, > > > > After merging the staging tree, today's linux-next build (powerpc > > allyesconfig - I presume that an x86_64 allyesconfig will fail the > > same way)

Re: [PATCH 0/5] zram clean up

Hi Andrew, Could you drop this patchset? I will send updated version based on Sergey with some bug fixes. zram-handle-multiple-pages-attached-bios-bvec.patch zram-partial-io-refactoring.patch zram-use-zram_slot_lock-instead-of-raw-bit_spin_lock-op.patch zram-remove-zram_meta-structure.patch

6f58284e66: BUG: kernel hang in boot stage

dev event to link messages" 6f58284e66 Merge remote-tracking branch 'net-next/master' f8c97bdb49 Add linux-next specific files for 20170410 +-++++---+ |

6f58284e66: BUG: kernel hang in boot stage

e-tracking branch 'net-next/master' f8c97bdb49 Add linux-next specific files for 20170410 +-++++---+ | | 7fd97bca68 | bf74b20d00 | 6f58284e66 | nex

[PATCH v2 2/3] ARM: dts: imx6qdl.dtsi: add "fsl,imx6q-snvs-lpgpr" node

This node is for Low Power General Purpose Register which can be used as Non-Volatile Storage. Signed-off-by: Oleksij Rempel Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: Rob Herring Cc:

[PATCH v2 2/3] ARM: dts: imx6qdl.dtsi: add "fsl,imx6q-snvs-lpgpr" node

This node is for Low Power General Purpose Register which can be used as Non-Volatile Storage. Signed-off-by: Oleksij Rempel Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: Rob Herring Cc: Shawn Guo ---

Re: [PATCH v4 5/7] dt-bindings: display/panel: Add common rotation property

Hi Noralf, On Saturday 11 Feb 2017 19:48:56 Noralf Trønnes wrote: > Display panels can be oriented many ways, especially in the embedded > world. The rotation property is a way to describe this orientation. > The counter clockwise direction is chosen because that's what fbdev > and drm use. > >

Re: [PATCH v4 5/7] dt-bindings: display/panel: Add common rotation property

Hi Noralf, On Saturday 11 Feb 2017 19:48:56 Noralf Trønnes wrote: > Display panels can be oriented many ways, especially in the embedded > world. The rotation property is a way to describe this orientation. > The counter clockwise direction is chosen because that's what fbdev > and drm use. > >

Re: [PATCH] drivers/dax: Avoiding potential deadlock

Sent out another patch to correct return value. On Tue, Apr 11, 2017 at 10:25 AM, Dan Williams wrote: > On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar > wrote: >> dax_dev_huge_fault returning without releasing lock. Making code change to >>

[PATCH v2 1/3] nvmem: add snvs_lpgpr driver

This is a driver for Low Power General Purpose Register (LPGPR) available on i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) of this chip. It is a 32-bit read/write register located in the low power domain. Since LPGPR is located in the battery-backed power domain, LPGPR can be used by any

Re: [PATCH] drivers/dax: Avoiding potential deadlock

Sent out another patch to correct return value. On Tue, Apr 11, 2017 at 10:25 AM, Dan Williams wrote: > On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar > wrote: >> dax_dev_huge_fault returning without releasing lock. Making code change to >> avoid this situation >> >> Signed-off-by:

[PATCH v2 1/3] nvmem: add snvs_lpgpr driver

This is a driver for Low Power General Purpose Register (LPGPR) available on i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) of this chip. It is a 32-bit read/write register located in the low power domain. Since LPGPR is located in the battery-backed power domain, LPGPR can be used by any

[PATCH v2 3/3] nvmem: dt: document SNVS LPGPR binding

Documentation bindings for the Low Power General Purpose Register available on i.MX6 SoCs in the Secure Non-Volatile Storage. Signed-off-by: Oleksij Rempel Cc: Srinivas Kandagatla Cc: Maxime Ripard Cc:

[PATCH 2/2] drivers/dax: Changing RC value

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / unsupported fault size. Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index

[PATCH 2/2] drivers/dax: Changing RC value

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / unsupported fault size. Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index fd9c4db..6156fdc 100644

[PATCH v2 3/3] nvmem: dt: document SNVS LPGPR binding

Documentation bindings for the Low Power General Purpose Register available on i.MX6 SoCs in the Secure Non-Volatile Storage. Signed-off-by: Oleksij Rempel Cc: Srinivas Kandagatla Cc: Maxime Ripard Cc: Rob Herring Cc: Mark Rutland Cc: devicet...@vger.kernel.org Cc:

[PATCH] mtd: nand: NULL terminate a of_device_id table

of_device_id tables should be NULL terminated. Fixes: 07b23e3db9ed ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Christophe JAILLET --- drivers/mtd/nand/atmel/nand-controller.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index

[PATCH] mtd: nand: NULL terminate a of_device_id table

of_device_id tables should be NULL terminated. Fixes: 07b23e3db9ed ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Christophe JAILLET --- drivers/mtd/nand/atmel/nand-controller.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/atmel/nand-controller.c

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index 0d1ca24..fd9c4db 100644 ---

[PATCH 2/2] drivers/dax: Changing RC value

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / unsupported fault size. Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index

[PATCH 2/2] drivers/dax: Changing RC value

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / unsupported fault size. Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index fd9c4db..6156fdc 100644

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index 0d1ca24..fd9c4db 100644 ---

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index 0d1ca24..fd9c4db 100644 ---

Re: [PATCH v2] cfg80211: Fix array-bounds warning in fragment copy

On Mon, 2017-04-10 at 14:36 -0700, Matthias Kaehlcke wrote: > Ping, any feedback on this patch? You didn't cc linux-wireless, so it fell through the cracks ... I'll try to remember it when I merge later. johannes

Re: [PATCH v2] cfg80211: Fix array-bounds warning in fragment copy

On Mon, 2017-04-10 at 14:36 -0700, Matthias Kaehlcke wrote: > Ping, any feedback on this patch? You didn't cc linux-wireless, so it fell through the cracks ... I'll try to remember it when I merge later. johannes

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

On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote: > Hi Greg, > > After merging the staging tree, today's linux-next build (powerpc > allyesconfig - I presume that an x86_64 allyesconfig will fail the > same way) failed like this: > >

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

On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote: > Hi Greg, > > After merging the staging tree, today's linux-next build (powerpc > allyesconfig - I presume that an x86_64 allyesconfig will fail the > same way) failed like this: > >

Re: [For Linux v1 0/4] PV protocol headers for Linux Kernel

On 10/04/17 08:25, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hi, all! > > This patch series adds/updates para-virtual device > protocols for Linux Kernel (headers): > o kbdif (updated/multitouch support added) > o sndif - sound (new)

Re: [For Linux v1 0/4] PV protocol headers for Linux Kernel

On 10/04/17 08:25, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hi, all! > > This patch series adds/updates para-virtual device > protocols for Linux Kernel (headers): > o kbdif (updated/multitouch support added) > o sndif - sound (new) > o displif - display (new) > >

Re: linux-next: manual merge of the crypto tree with the kbuild tree

On Tue, Apr 11, 2017 at 03:02:50PM +1000, Stephen Rothwell wrote: > > So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported > header but 128 in the kernel header? In which case the kbuild patch > needs to be changed not removed. Or the merge resolution needs to be > cleverer.

Re: linux-next: manual merge of the crypto tree with the kbuild tree

On Tue, Apr 11, 2017 at 03:02:50PM +1000, Stephen Rothwell wrote: > > So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported > header but 128 in the kernel header? In which case the kbuild patch > needs to be changed not removed. Or the merge resolution needs to be > cleverer.

Re: [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

On 30/03/17 22:06, Nicolai Stange wrote: > In preparation for making the clockevents core NTP correction aware, > all clockevent device drivers must set ->min_delta_ticks and > ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a > clockevent device's rate is going to change

Re: [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

On 30/03/17 22:06, Nicolai Stange wrote: > In preparation for making the clockevents core NTP correction aware, > all clockevent device drivers must set ->min_delta_ticks and > ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a > clockevent device's rate is going to change

Re: [PATCHv3 08/22] staging: android: ion: Remove crufty cache support

Hi, On 04/04/2017 12:27 AM, Laura Abbott wrote: Now that we call dma_map in the dma_buf API callbacks there is no need to use the existing cache APIs. Remove the sync ioctl and the existing bad dma_sync calls. Explicit caching can be handled with the dma_buf sync API. We could get rid of the

Re: [PATCHv3 08/22] staging: android: ion: Remove crufty cache support

Hi, On 04/04/2017 12:27 AM, Laura Abbott wrote: Now that we call dma_map in the dma_buf API callbacks there is no need to use the existing cache APIs. Remove the sync ioctl and the existing bad dma_sync calls. Explicit caching can be handled with the dma_buf sync API. We could get rid of the

[PATCH v2] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel OOPS: [ 1275.165932] Bad kernel stack pointer cd93c840 at c0009868 [ 1275.166378] Oops: Bad kernel stack pointer, sig: 6 [#1] ... GPR00: c01fcd93cb30 cd93c840 c15c5e00 cd93c840

[PATCH v2] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel OOPS: [ 1275.165932] Bad kernel stack pointer cd93c840 at c0009868 [ 1275.166378] Oops: Bad kernel stack pointer, sig: 6 [#1] ... GPR00: c01fcd93cb30 cd93c840 c15c5e00 cd93c840

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On 04/10/2017 09:48 PM, Greg Kroah-Hartman wrote: On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote: On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.10.10 release. There are 110 patches in this series, all will be posted as a

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On 04/10/2017 09:48 PM, Greg Kroah-Hartman wrote: On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote: On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.10.10 release. There are 110 patches in this series, all will be posted as a

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (powerpc allyesconfig - I presume that an x86_64 allyesconfig will fail the same way) failed like this: drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function `.rtw_get_oper_ch': (.text+0x9d0): multiple definition of

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (powerpc allyesconfig - I presume that an x86_64 allyesconfig will fail the same way) failed like this: drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function `.rtw_get_oper_ch': (.text+0x9d0): multiple definition of

Re: [PATCH 4.9 000/152] 4.9.22-stable review

On Mon, Apr 10, 2017 at 06:40:52PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.22 release. > There are 152 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.9 000/152] 4.9.22-stable review

On Mon, Apr 10, 2017 at 06:40:52PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.22 release. > There are 152 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On Mon, Apr 10, 2017 at 06:41:51PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.10 release. > There are 110 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On Mon, Apr 10, 2017 at 06:41:51PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.10 release. > There are 110 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: linux-next: manual merge of the crypto tree with the kbuild tree

Hi Herbert, On Tue, 11 Apr 2017 10:42:15 +0800 Herbert Xu wrote: > > Actually the patch in the kbuild tree should be reverted because > we have now increased the in-kernel length limit and this must not > be directly exposed to user-space or it'll break

Re: linux-next: manual merge of the crypto tree with the kbuild tree

Hi Herbert, On Tue, 11 Apr 2017 10:42:15 +0800 Herbert Xu wrote: > > Actually the patch in the kbuild tree should be reverted because > we have now increased the in-kernel length limit and this must not > be directly exposed to user-space or it'll break compatibility. So basically we need

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On Mon, Apr 10, 2017 at 02:39:37PM -0600, Shuah Khan wrote: > On 04/10/2017 10:41 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.10 release. > > There are 110 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On Mon, Apr 10, 2017 at 02:39:37PM -0600, Shuah Khan wrote: > On 04/10/2017 10:41 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.10 release. > > There are 110 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH] mm: Add additional consistency check

On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko wrote: > On Tue 04-04-17 14:58:06, Cristopher Lameter wrote: >> On Tue, 4 Apr 2017, Michal Hocko wrote: >> >> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote: >> > > On Tue, 4 Apr 2017, Michal Hocko wrote: >> > > >> > > > Yes,

Re: [PATCH] mm: Add additional consistency check

On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko wrote: > On Tue 04-04-17 14:58:06, Cristopher Lameter wrote: >> On Tue, 4 Apr 2017, Michal Hocko wrote: >> >> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote: >> > > On Tue, 4 Apr 2017, Michal Hocko wrote: >> > > >> > > > Yes, but we do not have

[PATCH] drm: i915: Avoid format string expansion from engine names

While highly unlikely, this makes sure that the string built from engine names won't be processed as a format string. Signed-off-by: Kees Cook --- drivers/gpu/drm/i915/intel_hangcheck.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] drm: i915: Avoid format string expansion from engine names

While highly unlikely, this makes sure that the string built from engine names won't be processed as a format string. Signed-off-by: Kees Cook --- drivers/gpu/drm/i915/intel_hangcheck.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c

Re: [PATCH] drivers/dax: Avoiding potential deadlock

On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar wrote: > dax_dev_huge_fault returning without releasing lock. Making code change to > avoid this situation > > Signed-off-by: Pushkar Jambhlekar > --- > drivers/dax/dax.c | 2 +- > 1 file changed,

Re: [PATCH] drivers/dax: Avoiding potential deadlock

On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar wrote: > dax_dev_huge_fault returning without releasing lock. Making code change to > avoid this situation > > Signed-off-by: Pushkar Jambhlekar > --- > drivers/dax/dax.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [RFC][PATCH] mm: Tighten x86 /dev/mem with zeroing

On Thu, Apr 6, 2017 at 7:25 AM, Tommi Rantala wrote: > On 06.04.2017 03:00, Kees Cook wrote: >> >> This changes the x86 exception for the low 1MB by reading back zeros for >> RAM areas instead of blindly allowing them. (It may be possible for heap >> to end up getting

Re: [RFC][PATCH] mm: Tighten x86 /dev/mem with zeroing

On Thu, Apr 6, 2017 at 7:25 AM, Tommi Rantala wrote: > On 06.04.2017 03:00, Kees Cook wrote: >> >> This changes the x86 exception for the low 1MB by reading back zeros for >> RAM areas instead of blindly allowing them. (It may be possible for heap >> to end up getting allocated in low 1MB RAM,

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote: > On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.10 release. > > There are 110 patches in this series, all will be posted as a response > > to this one. If anyone has

Re: [PATCH 4.10 000/110] 4.10.10-stable review

On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote: > On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.10 release. > > There are 110 patches in this series, all will be posted as a response > > to this one. If anyone has

[PATCH] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index

[PATCH] drivers/dax: Avoiding potential deadlock

dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation Signed-off-by: Pushkar Jambhlekar --- drivers/dax/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index 0d1ca24..fd9c4db 100644 ---

Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni wrote: > On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler > wrote: >> I think that would be the prudent approach. There is still >> the possibility that blob sharing (or full stacking, if you >> prefer)

Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni wrote: > On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler > wrote: >> I think that would be the prudent approach. There is still >> the possibility that blob sharing (or full stacking, if you >> prefer) won't be accepted any time soon. > > Ok

Re: [PATCH 4.9 000/152] 4.9.22-stable review

On Mon, Apr 10, 2017 at 08:07:17PM -0700, Guenter Roeck wrote: > On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.22 release. > > There are 152 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.9 000/152] 4.9.22-stable review

On Mon, Apr 10, 2017 at 08:07:17PM -0700, Guenter Roeck wrote: > On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.22 release. > > There are 152 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH] pci/quirks: ITE 8893 needs quirk_use_pcie_bridge_dma_alias

On Mon, 10 Apr 2017 21:01:27 -0400 Jarod Wilson wrote: > This bridge has the same problems as the ITE 8892, which were resulting in > crippling an older PCI 1Gbps NIC down to 45Mbps throughput with IOMMU and > VT-d enabled. With the patch, this old e1000 goes back up to

Re: [PATCH] pci/quirks: ITE 8893 needs quirk_use_pcie_bridge_dma_alias

On Mon, 10 Apr 2017 21:01:27 -0400 Jarod Wilson wrote: > This bridge has the same problems as the ITE 8892, which were resulting in > crippling an older PCI 1Gbps NIC down to 45Mbps throughput with IOMMU and > VT-d enabled. With the patch, this old e1000 goes back up to ~900Mbps. > >

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 04/06/2017 11:58 AM, Catalin Marinas wrote: > The Cavium guys haven't shown any numbers (IIUC) to back the > L1_CACHE_BYTES performance improvement but I would not revert the > original commit since ARCH_DMA_MINALIGN definitely needs to cover the > maximum available cache line size, which is

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 04/06/2017 11:58 AM, Catalin Marinas wrote: > The Cavium guys haven't shown any numbers (IIUC) to back the > L1_CACHE_BYTES performance improvement but I would not revert the > original commit since ARCH_DMA_MINALIGN definitely needs to cover the > maximum available cache line size, which is

Re: [PATCH 4.9 000/152] 4.9.22-stable review

On Mon, Apr 10, 2017 at 03:55:12PM -0700, Guenter Roeck wrote: > On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.22 release. > > There are 152 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.9 000/152] 4.9.22-stable review

On Mon, Apr 10, 2017 at 03:55:12PM -0700, Guenter Roeck wrote: > On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.22 release. > > There are 152 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH] switchtec: Fix an error handling

Nice catch. Thanks. Reviewed-by: Logan Gunthorpe Logan On 10/04/17 10:32 PM, Christophe JAILLET wrote: > 'stuser_create' returns an error pointer in case of error, not NULL. > So test its return value with IS_ERR. > > Fixes: 74004262f329 ("MicroSemi Switchtec management

Re: [PATCH] switchtec: Fix an error handling

Nice catch. Thanks. Reviewed-by: Logan Gunthorpe Logan On 10/04/17 10:32 PM, Christophe JAILLET wrote: > 'stuser_create' returns an error pointer in case of error, not NULL. > So test its return value with IS_ERR. > > Fixes: 74004262f329 ("MicroSemi Switchtec management interface driver") >

Re: [PATCH v1 3/3] nvmem: dt: document SNVS LPGPR binding

Hi, On 04/10/2017 08:22 PM, Rob Herring wrote: On Thu, Apr 06, 2017 at 09:31:07AM +0200, Oleksij Rempel wrote: Documenation bindings for the Low Power General Purpose Registe s/Registe/Register/ available on i.MX6 SoCs in the Secure Non-Volatile Storage. Signed-off-by: Oleksij Rempel

Re: [PATCH v1 3/3] nvmem: dt: document SNVS LPGPR binding

Hi, On 04/10/2017 08:22 PM, Rob Herring wrote: On Thu, Apr 06, 2017 at 09:31:07AM +0200, Oleksij Rempel wrote: Documenation bindings for the Low Power General Purpose Registe s/Registe/Register/ available on i.MX6 SoCs in the Secure Non-Volatile Storage. Signed-off-by: Oleksij Rempel Cc:

[PATCH] switchtec: Fix an error handling

'stuser_create' returns an error pointer in case of error, not NULL. So test its return value with IS_ERR. Fixes: 74004262f329 ("MicroSemi Switchtec management interface driver") Signed-off-by: Christophe JAILLET --- drivers/pci/switch/switchtec.c | 2 +- 1 file

[PATCH] switchtec: Fix an error handling

'stuser_create' returns an error pointer in case of error, not NULL. So test its return value with IS_ERR. Fixes: 74004262f329 ("MicroSemi Switchtec management interface driver") Signed-off-by: Christophe JAILLET --- drivers/pci/switch/switchtec.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni wrote: > Hi List, > > This is RFC v2 of the Module auto-loading restriction feature. The > module has been renamed ModAutoRestrict LSM. > > This RFC is a work in progress update. > > There are still minor things to fix which are

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni wrote: > Hi List, > > This is RFC v2 of the Module auto-loading restriction feature. The > module has been renamed ModAutoRestrict LSM. > > This RFC is a work in progress update. > > There are still minor things to fix which are listed in the TODO >

Re: [PATCH] ibmveth: Support to enable LSO/CSO for Trunk VEA.

Re-sending as my earlier response had some HTML subparts. Let me give some background before I answer your queries. In IBM PowerVM environment, ibmveth driver supports largesend and checksum offload today, but only for virtual ethernet adapters (VEA) which are not configured in "Trunk mode".

Re: [PATCH] ibmveth: Support to enable LSO/CSO for Trunk VEA.

Re-sending as my earlier response had some HTML subparts. Let me give some background before I answer your queries. In IBM PowerVM environment, ibmveth driver supports largesend and checksum offload today, but only for virtual ethernet adapters (VEA) which are not configured in "Trunk mode".

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Tue, 2017-04-11 at 00:23 +0300, Michael S. Tsirkin wrote: > On Sat, Apr 08, 2017 at 07:01:34AM +0200, Mike Galbraith wrote: > > On Fri, 2017-04-07 at 21:56 +0300, Michael S. Tsirkin wrote: > > > > > OK. test3 and test4 are now pushed: test3 should fix your hang, > > > test4 is trying to fix a

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Tue, 2017-04-11 at 00:23 +0300, Michael S. Tsirkin wrote: > On Sat, Apr 08, 2017 at 07:01:34AM +0200, Mike Galbraith wrote: > > On Fri, 2017-04-07 at 21:56 +0300, Michael S. Tsirkin wrote: > > > > > OK. test3 and test4 are now pushed: test3 should fix your hang, > > > test4 is trying to fix a

  1   2   3   4   5   6   7   8   9   10   >