Re: [PATCH 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings

On Thu, Nov 23, 2017 at 4:09 PM, Łukasz Stelmach wrote: > Add binding documentation for the True Random Number Generator > found on Samsung Exynos 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- >

Re: [PATCH 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings

On Thu, Nov 23, 2017 at 4:09 PM, Łukasz Stelmach wrote: > Add binding documentation for the True Random Number Generator > found on Samsung Exynos 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > .../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17 > + > 1 file

Re: usb/media/em28xx: use-after-free in dvb_unregister_frontend

On Thu, Nov 23, 2017 at 8:25 AM, Matthias Schwarzott wrote: > Am 21.11.2017 um 14:51 schrieb Andrey Konovalov: >> Hi! >> > Hi Andrey, > >> I've got the following report while fuzzing the kernel with syzkaller. >> >> On commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3 (4.15-rc1).

Re: usb/media/em28xx: use-after-free in dvb_unregister_frontend

On Thu, Nov 23, 2017 at 8:25 AM, Matthias Schwarzott wrote: > Am 21.11.2017 um 14:51 schrieb Andrey Konovalov: >> Hi! >> > Hi Andrey, > >> I've got the following report while fuzzing the kernel with syzkaller. >> >> On commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3 (4.15-rc1). >> >> em28xx

Re: [PATCH] xfs: handle register_shrinker error

On Fri 24-11-17 01:01:10, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 23-11-17 05:26:33, Christoph Hellwig wrote: > > > Looks good, > > > > > > Reviewed-by: Christoph Hellwig > > > > Thanks! > > > > > I can take a stab at the quota one. > > > > That would be really

Re: [PATCH] xfs: handle register_shrinker error

On Fri 24-11-17 01:01:10, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 23-11-17 05:26:33, Christoph Hellwig wrote: > > > Looks good, > > > > > > Reviewed-by: Christoph Hellwig > > > > Thanks! > > > > > I can take a stab at the quota one. > > > > That would be really great! > > >

Re: [PATCH v4 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

On 11/15/2017 03:37 PM, H. Nikolaus Schaller wrote: > Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart. > > Use serdev API hooks to monitor and forward the UART traffic to /dev/ttyGPSn > and turn on/off the module. It also detects if the module is turned on (sends > data) > but

Re: [PATCH v4 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

On 11/15/2017 03:37 PM, H. Nikolaus Schaller wrote: > Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart. > > Use serdev API hooks to monitor and forward the UART traffic to /dev/ttyGPSn > and turn on/off the module. It also detects if the module is turned on (sends > data) > but

Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Wed, 22 Nov 2017 09:43:19 -0800 schrieb Kees Cook : > On Wed, Nov 22, 2017 at 1:28 AM, Michael Holzheu > wrote: > > Am Mon, 13 Nov 2017 11:19:38 +0100 > > schrieb Michael Holzheu : > > > >> Am Fri, 10 Nov 2017

Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Wed, 22 Nov 2017 09:43:19 -0800 schrieb Kees Cook : > On Wed, Nov 22, 2017 at 1:28 AM, Michael Holzheu > wrote: > > Am Mon, 13 Nov 2017 11:19:38 +0100 > > schrieb Michael Holzheu : > > > >> Am Fri, 10 Nov 2017 10:46:49 -0800 > >> schrieb Kees Cook : > >> > >> > On Fri, Nov 10, 2017 at 7:45

Re: [PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format

On Thu, Nov 23, 2017 at 04:56:56PM +0800, Tina Zhang wrote: > The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in > windows. The float format in each component is 1:5:10 MSb-sign:exponent: > fraction. > > This patch is to introduce the format to drm, so that the windows

Re: [PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format

On Thu, Nov 23, 2017 at 04:56:56PM +0800, Tina Zhang wrote: > The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in > windows. The float format in each component is 1:5:10 MSb-sign:exponent: > fraction. > > This patch is to introduce the format to drm, so that the windows

[PATCH] perf buildid-cache: Document for Node.js USDT

Add a tip for Node.js USDT(User-Level Statically Defined Tracing) probes in tips.txt Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Hansuk Hong --- tools/perf/Documentation/tips.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] perf buildid-cache: Document for Node.js USDT

Add a tip for Node.js USDT(User-Level Statically Defined Tracing) probes in tips.txt Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Hansuk Hong --- tools/perf/Documentation/tips.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/Documentation/tips.txt

Re: [PATCH v2] KVM: VMX: Fix vmx->nested freeing when no SMI handler

On 22/11/2017 23:04, Wanpeng Li wrote: > From: Wanpeng Li > > Reported by syzkaller: > >[ cut here ] >WARNING: CPU: 5 PID: 2939 at arch/x86/kvm/vmx.c:3844 > free_loaded_vmcs+0x77/0x80 [kvm_intel] >CPU: 5 PID: 2939 Comm: repro Not

Re: [PATCH v2] KVM: VMX: Fix vmx->nested freeing when no SMI handler

On 22/11/2017 23:04, Wanpeng Li wrote: > From: Wanpeng Li > > Reported by syzkaller: > >[ cut here ] >WARNING: CPU: 5 PID: 2939 at arch/x86/kvm/vmx.c:3844 > free_loaded_vmcs+0x77/0x80 [kvm_intel] >CPU: 5 PID: 2939 Comm: repro Not tainted 4.14.0+ #26 >

Re: [PATCH v2 0/5] Memory hotplug support for arm64 - complete patchset v2

On Thu 23-11-17 11:13:35, Andrea Reale wrote: > Hi all, Hi, > > this is a second round of patches to introduce memory hotplug and > hotremove support for arm64. It builds on the work previously published at > [1] and it implements the feedback received in the first round of reviews. > > The

Re: [PATCH v2 0/5] Memory hotplug support for arm64 - complete patchset v2

On Thu 23-11-17 11:13:35, Andrea Reale wrote: > Hi all, Hi, > > this is a second round of patches to introduce memory hotplug and > hotremove support for arm64. It builds on the work previously published at > [1] and it implements the feedback received in the first round of reviews. > > The

Re: [PATCH] xfs: handle register_shrinker error

Michal Hocko wrote: > On Thu 23-11-17 05:26:33, Christoph Hellwig wrote: > > Looks good, > > > > Reviewed-by: Christoph Hellwig > > Thanks! > > > I can take a stab at the quota one. > > That would be really great! > Again, it does not look good. Since kmem_free() does only

Re: [PATCH] xfs: handle register_shrinker error

Michal Hocko wrote: > On Thu 23-11-17 05:26:33, Christoph Hellwig wrote: > > Looks good, > > > > Reviewed-by: Christoph Hellwig > > Thanks! > > > I can take a stab at the quota one. > > That would be really great! > Again, it does not look good. Since kmem_free() does only kvfree(), nothing

[PATCH] lkdtm: Missing kmalloc check

Handling a possible memory allocation failure. Signed-off-by: Vasyl Gomonovych --- drivers/misc/lkdtm_heap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/misc/lkdtm_heap.c b/drivers/misc/lkdtm_heap.c index f5494a6d4be5..65026d7de130 100644 ---

[PATCH] lkdtm: Missing kmalloc check

Handling a possible memory allocation failure. Signed-off-by: Vasyl Gomonovych --- drivers/misc/lkdtm_heap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/misc/lkdtm_heap.c b/drivers/misc/lkdtm_heap.c index f5494a6d4be5..65026d7de130 100644 --- a/drivers/misc/lkdtm_heap.c +++

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Thu, Nov 23, 2017 at 02:13:01PM +0100, Mike Galbraith wrote: > On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote: > > Hello, Atish, Peter, all. > > > > I have a question about if a task's nr_cpus_allowed is 1. > > In that scenario we do not call select_task_rq. Therefore > > even

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Thu, Nov 23, 2017 at 02:13:01PM +0100, Mike Galbraith wrote: > On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote: > > Hello, Atish, Peter, all. > > > > I have a question about if a task's nr_cpus_allowed is 1. > > In that scenario we do not call select_task_rq. Therefore > > even

Re: VMs freezing when host is running 4.14

2017-11-23 16:20+0100, Marc Haber: > On Wed, Nov 22, 2017 at 05:43:13PM +0100, Radim Krčmář wrote: > > 2017-11-22 16:52+0100, Marc Haber: > > > On Wed, Nov 22, 2017 at 04:04:42PM +0100, 王金浦 wrote: > > > > So all guest kernels are 4.14, or also other older kernel? > > > > > > Guest kernels are

Re: VMs freezing when host is running 4.14

2017-11-23 16:20+0100, Marc Haber: > On Wed, Nov 22, 2017 at 05:43:13PM +0100, Radim Krčmář wrote: > > 2017-11-22 16:52+0100, Marc Haber: > > > On Wed, Nov 22, 2017 at 04:04:42PM +0100, 王金浦 wrote: > > > > So all guest kernels are 4.14, or also other older kernel? > > > > > > Guest kernels are

Re: [PATCH 11/23] x86, kaiser: map entry stack variables

On Thu, Nov 23, 2017 at 7:37 AM, Dave Hansen wrote: > On 11/22/2017 07:31 PM, Andy Lutomirski wrote: >> On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen >> wrote: >>> >>> From: Dave Hansen >>> >>> There are times

[PATCH 2/2] extcon: axp288:: Handle return value of platform_get_irq

platform_get_irq() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/extcon/extcon-axp288.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c index

Re: [PATCH 11/23] x86, kaiser: map entry stack variables

On Thu, Nov 23, 2017 at 7:37 AM, Dave Hansen wrote: > On 11/22/2017 07:31 PM, Andy Lutomirski wrote: >> On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen >> wrote: >>> >>> From: Dave Hansen >>> >>> There are times where the kernel is entered but there is not a >>> safe stack, like at SYSCALL entry.

[PATCH 2/2] extcon: axp288:: Handle return value of platform_get_irq

platform_get_irq() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/extcon/extcon-axp288.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c index 981fba5..e16a783 100644 ---

[PATCH 1/2] extcon: adc-jack: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- drivers/extcon/extcon-adc-jack.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH 1/2] extcon: adc-jack: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- drivers/extcon/extcon-adc-jack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 0/2] Handle return value and error checking of platform_get_irq

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. platform_get_irq() can fail here and we must check its return value. Arvind Yadav (2): [PATCH 1/2] extcon: adc-jack: Fix

[PATCH 0/2] Handle return value and error checking of platform_get_irq

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. platform_get_irq() can fail here and we must check its return value. Arvind Yadav (2): [PATCH 1/2] extcon: adc-jack: Fix

usbutils 009 release

The 009 release of usbutils happened about a month ago, but I forgot to announce it anywhere, and also forgot to upload the tarball to kernel.org until today. So here's the belated announcement of the 009 release of usbutils. It's been a few years since the last release, sorry about that, didn't

usbutils 009 release

The 009 release of usbutils happened about a month ago, but I forgot to announce it anywhere, and also forgot to upload the tarball to kernel.org until today. So here's the belated announcement of the 009 release of usbutils. It's been a few years since the last release, sorry about that, didn't

Stack switching plan of attack (Re: [PATCH v2 00/18] Entry stack switching)

On Tue, Nov 21, 2017 at 8:43 PM, Andy Lutomirski wrote: > This sets up stack switching, including for SYSCALL. I think it's > in decent shape. What's the plan of attack? is the goal to get this thing in -rc1 or as soon as possible thereafter? If so, I think there are two

Stack switching plan of attack (Re: [PATCH v2 00/18] Entry stack switching)

On Tue, Nov 21, 2017 at 8:43 PM, Andy Lutomirski wrote: > This sets up stack switching, including for SYSCALL. I think it's > in decent shape. What's the plan of attack? is the goal to get this thing in -rc1 or as soon as possible thereafter? If so, I think there are two things that need

Re: [dm-devel] [PATCH 3/4] dm: convert dm_dev_internal.count from atomic_t to refcount_t

On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote: > } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) { > r = upgrade_mode(dd, mode, t->md); > if (r) > return r; > + refcount_inc(>count); > } Missing

Re: [dm-devel] [PATCH 3/4] dm: convert dm_dev_internal.count from atomic_t to refcount_t

On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote: > } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) { > r = upgrade_mode(dd, mode, t->md); > if (r) > return r; > + refcount_inc(>count); > } Missing

Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

On 11/23/2017 09:09 AM, Łukasz Stelmach wrote: > Add support for True Random Number Generator found in Samsung Exynos > 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > MAINTAINERS | 7 + > drivers/char/hw_random/Kconfig | 12 ++ >

Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

On 11/23/2017 09:09 AM, Łukasz Stelmach wrote: > Add support for True Random Number Generator found in Samsung Exynos > 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > MAINTAINERS | 7 + > drivers/char/hw_random/Kconfig | 12 ++ >

[PATCH] ipmi: bt-bmc: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- drivers/char/ipmi/bt-bmc.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] ipmi: bt-bmc: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- drivers/char/ipmi/bt-bmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2] MIPS: ralink: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- changes in v2: Subject spelling was not correct. change FIX in place

[PATCH v2] MIPS: ralink: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- changes in v2: Subject spelling was not correct. change FIX in place of 'ix'.

Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns

On Fri, Nov 24, 2017 at 12:35:29AM +0900, Tetsuo Handa wrote: > Al Viro wrote: > > On Fri, Nov 24, 2017 at 12:04:23AM +0900, Tetsuo Handa wrote: > > > Al Viro wrote: > > > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > > > Hopefully less screwed version. But as I've said I

Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns

On Fri, Nov 24, 2017 at 12:35:29AM +0900, Tetsuo Handa wrote: > Al Viro wrote: > > On Fri, Nov 24, 2017 at 12:04:23AM +0900, Tetsuo Handa wrote: > > > Al Viro wrote: > > > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > > > Hopefully less screwed version. But as I've said I

[PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller

This patch adds support to the Cadence PCIe controller in host mode. Signed-off-by: Cyrille Pitchen --- drivers/Makefile| 1 + drivers/pci/Kconfig | 1 + drivers/pci/cadence/Kconfig | 24 ++

[PATCH 0/5] PCI: Add support to the Cadence PCIe controller

Hi all, this series of patches adds support to the Cadence PCIe controller. It was tested on a ARM64 platform emulated by a Palladium running both linux-next (next-20171123) and pci-next kernels. The host mode was tested with some PCIe devices connected to the Palladium through a speed-bridge

[PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller

This patch adds support to the Cadence PCIe controller in host mode. Signed-off-by: Cyrille Pitchen --- drivers/Makefile| 1 + drivers/pci/Kconfig | 1 + drivers/pci/cadence/Kconfig | 24 ++ drivers/pci/cadence/Makefile|

[PATCH 0/5] PCI: Add support to the Cadence PCIe controller

Hi all, this series of patches adds support to the Cadence PCIe controller. It was tested on a ARM64 platform emulated by a Palladium running both linux-next (next-20171123) and pci-next kernels. The host mode was tested with some PCIe devices connected to the Palladium through a speed-bridge

[PATCH v3] f2fs: obsolete free nid list approach

From: Chao Yu Previously, we use free nid list to manage free nid entry, so during nid allocation, we can just pick up one entry from list header, which has quite low overhead. But sadly, during initialization of free nid list, we should do lookup combining with lots of

[PATCH v3] f2fs: obsolete free nid list approach

From: Chao Yu Previously, we use free nid list to manage free nid entry, so during nid allocation, we can just pick up one entry from list header, which has quite low overhead. But sadly, during initialization of free nid list, we should do lookup combining with lots of different inner caches,

Re: [PATCH 11/23] x86, kaiser: map entry stack variables

On 11/22/2017 07:31 PM, Andy Lutomirski wrote: > On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen > wrote: >> >> From: Dave Hansen >> >> There are times where the kernel is entered but there is not a >> safe stack, like at SYSCALL entry. To

Re: [PATCH 11/23] x86, kaiser: map entry stack variables

On 11/22/2017 07:31 PM, Andy Lutomirski wrote: > On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen > wrote: >> >> From: Dave Hansen >> >> There are times where the kernel is entered but there is not a >> safe stack, like at SYSCALL entry. To obtain a safe stack, the >> per-cpu variables

[PATCH] f2fs: fix lock dependency in between dio_rwsem & i_mmap_sem

From: Chao Yu test/generic/208 reports a potential deadlock as below: Chain exists of: >mmap_sem --> >i_mmap_sem --> >dio_rwsem[WRITE] Possible unsafe locking scenario: CPU0CPU1 lock(>dio_rwsem[WRITE]);

[PATCH] f2fs: fix lock dependency in between dio_rwsem & i_mmap_sem

From: Chao Yu test/generic/208 reports a potential deadlock as below: Chain exists of: >mmap_sem --> >i_mmap_sem --> >dio_rwsem[WRITE] Possible unsafe locking scenario: CPU0CPU1 lock(>dio_rwsem[WRITE]);

[PATCH] MIPS: ralink: ix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- arch/mips/ralink/timer.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] MIPS: ralink: ix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs. zero or positive number on success. platform_get_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- arch/mips/ralink/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns

Al Viro wrote: > On Fri, Nov 24, 2017 at 12:04:23AM +0900, Tetsuo Handa wrote: > > Al Viro wrote: > > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > > Hopefully less screwed version. But as I've said I am not really > > > > familiar with the code and do not feel competent

Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns

Al Viro wrote: > On Fri, Nov 24, 2017 at 12:04:23AM +0900, Tetsuo Handa wrote: > > Al Viro wrote: > > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > > Hopefully less screwed version. But as I've said I am not really > > > > familiar with the code and do not feel competent

Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 16:02:11, Michal Hocko wrote: > On Thu 23-11-17 14:55:40, Al Viro wrote: > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > Hopefully less screwed version. But as I've said I am not really > > > familiar with the code and do not feel competent to change it so

Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 16:02:11, Michal Hocko wrote: > On Thu 23-11-17 14:55:40, Al Viro wrote: > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > Hopefully less screwed version. But as I've said I am not really > > > familiar with the code and do not feel competent to change it so

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Wed, Nov 22, 2017 at 12:56:44PM +, Liuwenliang (Abbott Liu) wrote: > +static inline u64 get_ttbr0(void) > +{ > + if (IS_ENABLED(CONFIG_ARM_LPAE)) > + return read_sysreg(TTBR0_64); > + else > + return (u64)read_sysreg(TTBR0_32); > +} > +static inline u64 get_ttbr1(void) > +{

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Wed, Nov 22, 2017 at 12:56:44PM +, Liuwenliang (Abbott Liu) wrote: > +static inline u64 get_ttbr0(void) > +{ > + if (IS_ENABLED(CONFIG_ARM_LPAE)) > + return read_sysreg(TTBR0_64); > + else > + return (u64)read_sysreg(TTBR0_32); > +} > +static inline u64 get_ttbr1(void) > +{

[PATCH v2] quota: propagate error from __dquot_initialize

From: Chao Yu In commit 6184fc0b8dd7 ("quota: Propagate error from ->acquire_dquot()"), we have propagated error from __dquot_initialize to caller, but we forgot to handle such error in add_dquot_ref(), so, currently, during quota accounting information initialization flow,

[PATCH v2] quota: propagate error from __dquot_initialize

From: Chao Yu In commit 6184fc0b8dd7 ("quota: Propagate error from ->acquire_dquot()"), we have propagated error from __dquot_initialize to caller, but we forgot to handle such error in add_dquot_ref(), so, currently, during quota accounting information initialization flow, if we failed for some

Re: [PATCH] quota: propagate error from __dquot_initialize

On 2017/11/21 21:18, Jan Kara wrote: > On Fri 17-11-17 10:07:53, Chao Yu wrote: >> In commit 6184fc0b8dd7 ("quota: Propagate error from ->acquire_dquot()"), >> we have propagated error from __dquot_initialize to caller, but we forgot >> to handle such error in add_dquot_ref(), so, currently,

Re: [PATCH] quota: propagate error from __dquot_initialize

On 2017/11/21 21:18, Jan Kara wrote: > On Fri 17-11-17 10:07:53, Chao Yu wrote: >> In commit 6184fc0b8dd7 ("quota: Propagate error from ->acquire_dquot()"), >> we have propagated error from __dquot_initialize to caller, but we forgot >> to handle such error in add_dquot_ref(), so, currently,

Re: [PATCH v2 00/18] Entry stack switching

On Wed, Nov 22, 2017 at 10:58 PM, Ingo Molnar wrote: > > * Ingo Molnar wrote: > >> >> * Ingo Molnar wrote: >> >> > > Anyway, I booted your config (more or less -- I munged it through >> > > virtme-configkernel --update first) with 17 vCPUs

Re: [PATCH v2 00/18] Entry stack switching

On Wed, Nov 22, 2017 at 10:58 PM, Ingo Molnar wrote: > > * Ingo Molnar wrote: > >> >> * Ingo Molnar wrote: >> >> > > Anyway, I booted your config (more or less -- I munged it through >> > > virtme-configkernel --update first) with 17 vCPUs and it seems fine. >> > > Is the issue reliable enough

Re: [PATCH v2] fs: handle shrinker registration failure insget_userns

On Fri, Nov 24, 2017 at 12:04:23AM +0900, Tetsuo Handa wrote: > Al Viro wrote: > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > Hopefully less screwed version. But as I've said I am not really > > > familiar with the code and do not feel competent to change it so please > >

Re: [PATCH v2] fs: handle shrinker registration failure insget_userns

On Fri, Nov 24, 2017 at 12:04:23AM +0900, Tetsuo Handa wrote: > Al Viro wrote: > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote: > > > Hopefully less screwed version. But as I've said I am not really > > > familiar with the code and do not feel competent to change it so please > >

Re: [PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

On Tue, Nov 21, 2017 at 6:45 AM, Andrey Ryabinin wrote: > > > On 11/21/2017 10:38 AM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> /* May not be marked __init: used by software suspend */ >>> void syscall_init(void) >>> { >>> @@ -1627,7

Re: [PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

On Tue, Nov 21, 2017 at 6:45 AM, Andrey Ryabinin wrote: > > > On 11/21/2017 10:38 AM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> /* May not be marked __init: used by software suspend */ >>> void syscall_init(void) >>> { >>> @@ -1627,7 +1637,7 @@ void cpu_init(void) >>> *

Re: [PATCH v2 05/18] x86/fixmap: Generalize the GDT fixmap mechanism

On Wed, Nov 22, 2017 at 9:32 AM, Borislav Petkov wrote: > On Wed, Nov 22, 2017 at 09:16:00AM -0800, Andy Lutomirski wrote: >> Agreed, except that the fixmap enum needs to know >> sizeof(cpu_entry_area), and I'm really hesitant to add yet another >> header dependency. > > Perhaps a

Re: [PATCH v2 05/18] x86/fixmap: Generalize the GDT fixmap mechanism

On Wed, Nov 22, 2017 at 9:32 AM, Borislav Petkov wrote: > On Wed, Nov 22, 2017 at 09:16:00AM -0800, Andy Lutomirski wrote: >> Agreed, except that the fixmap enum needs to know >> sizeof(cpu_entry_area), and I'm really hesitant to add yet another >> header dependency. > > Perhaps a separate

Re: [PATCH v2 06/18] x86/kasan/64: Teach KASAN about the cpu_entry_area

On Thu, Nov 23, 2017 at 2:08 AM, Andrey Ryabinin wrote: > > > On 11/22/2017 06:22 PM, Andy Lutomirski wrote: >> On Wed, Nov 22, 2017 at 1:05 AM, Andrey Ryabinin >> wrote: >>> >>> >>> On 11/22/2017 07:44 AM, Andy Lutomirski wrote: The

Re: [PATCH v2 06/18] x86/kasan/64: Teach KASAN about the cpu_entry_area

On Thu, Nov 23, 2017 at 2:08 AM, Andrey Ryabinin wrote: > > > On 11/22/2017 06:22 PM, Andy Lutomirski wrote: >> On Wed, Nov 22, 2017 at 1:05 AM, Andrey Ryabinin >> wrote: >>> >>> >>> On 11/22/2017 07:44 AM, Andy Lutomirski wrote: The cpu_entry_area will contain stacks. Make sure that KASAN

Re: [PATCH v4 1/1] perf/bench/numa: Fixup discontiguous/sparse numa nodes

Em Wed, Nov 22, 2017 at 10:18:13PM +0530, Satheesh Rajendran escreveu: > On Wed, 2017-11-22 at 21:39 +0530, Naveen N. Rao wrote: > > >   sum += nr; > > >   } > > >   BUG_ON(nr_min > nr_max); > > > - > > >   BUG_ON(sum > g->p.nr_tasks); > > > > Looks like that change to

Re: [PATCH v4 1/1] perf/bench/numa: Fixup discontiguous/sparse numa nodes

Em Wed, Nov 22, 2017 at 10:18:13PM +0530, Satheesh Rajendran escreveu: > On Wed, 2017-11-22 at 21:39 +0530, Naveen N. Rao wrote: > > >   sum += nr; > > >   } > > >   BUG_ON(nr_min > nr_max); > > > - > > >   BUG_ON(sum > g->p.nr_tasks); > > > > Looks like that change to

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Thu, Nov 23, 2017 at 01:54:59AM +, Liuwenliang (Abbott Liu) wrote: > On Nov 23, 2017 20:30 Marc Zyngier [mailto:marc.zyng...@arm.com] wrote: > >Please define both PAR accessors. Yes, I know the 32bit version is not > >used yet, but it doesn't hurt to make it visible. > > Thanks for your

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Thu, Nov 23, 2017 at 01:54:59AM +, Liuwenliang (Abbott Liu) wrote: > On Nov 23, 2017 20:30 Marc Zyngier [mailto:marc.zyng...@arm.com] wrote: > >Please define both PAR accessors. Yes, I know the 32bit version is not > >used yet, but it doesn't hurt to make it visible. > > Thanks for your

Re: [PATCH 3/3] tools/perf/jvmti: generate correct debug information for inlined code

Em Wed, Nov 22, 2017 at 06:25:41PM -0600, Kim Phillips escreveu: > From: Ben Gainey > @@ -405,7 +405,9 @@ jvmti_write_debug_info(void *agent, uint64_t code, const > char *file, > return -1; > } > > - flen = strlen(file) + 1; > + for (i = 0; i <

Re: [PATCH 3/3] tools/perf/jvmti: generate correct debug information for inlined code

Em Wed, Nov 22, 2017 at 06:25:41PM -0600, Kim Phillips escreveu: > From: Ben Gainey > @@ -405,7 +405,9 @@ jvmti_write_debug_info(void *agent, uint64_t code, const > char *file, > return -1; > } > > - flen = strlen(file) + 1; > + for (i = 0; i < nr_lines; ++i) { > +

[PATCH 1/5] PCI: Add vendor ID for Cadence

This patch adds a new PCI vendor ID for Cadence. Signed-off-by: Cyrille Pitchen --- include/linux/pci_ids.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index ab20dc5db423..eb13e84e1fef 100644 ---

[PATCH 5/5] PCI: cadence: add EndPoint Controller driver for Cadence PCIe controller

This patch adds support to the Cadence PCIe controller in endpoint mode. Signed-off-by: Cyrille Pitchen --- drivers/pci/cadence/Kconfig | 9 + drivers/pci/cadence/Makefile | 1 + drivers/pci/cadence/pcie-cadence-ep.c | 553

[PATCH 1/5] PCI: Add vendor ID for Cadence

This patch adds a new PCI vendor ID for Cadence. Signed-off-by: Cyrille Pitchen --- include/linux/pci_ids.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index ab20dc5db423..eb13e84e1fef 100644 --- a/include/linux/pci_ids.h +++

[PATCH 5/5] PCI: cadence: add EndPoint Controller driver for Cadence PCIe controller

This patch adds support to the Cadence PCIe controller in endpoint mode. Signed-off-by: Cyrille Pitchen --- drivers/pci/cadence/Kconfig | 9 + drivers/pci/cadence/Makefile | 1 + drivers/pci/cadence/pcie-cadence-ep.c | 553 ++ 3 files

[PATCH 2/5] dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe host controller

From: Scott Telford This patch adds documentation for the DT bindings of the Cadence PCIe controller when configured in host (Root Complex) mode. Signed-off-by: Scott Telford Signed-off-by: Cyrille Pitchen

[PATCH 4/5] dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe endpoint controller

This patch documents the DT bindings for the Cadence PCIe controller when configured in endpoint mode. Signed-off-by: Cyrille Pitchen --- .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt| 20 1 file changed, 20 insertions(+) create

[PATCH 2/5] dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe host controller

From: Scott Telford This patch adds documentation for the DT bindings of the Cadence PCIe controller when configured in host (Root Complex) mode. Signed-off-by: Scott Telford Signed-off-by: Cyrille Pitchen dt-bindings: PCI: cadence: host fixup --- .../bindings/pci/cdns,cdns-pcie-host.txt

[PATCH 4/5] dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe endpoint controller

This patch documents the DT bindings for the Cadence PCIe controller when configured in endpoint mode. Signed-off-by: Cyrille Pitchen --- .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt| 20 1 file changed, 20 insertions(+) create mode 100644

Re: VMs freezing when host is running 4.14

On Wed, Nov 22, 2017 at 05:43:13PM +0100, Radim Krčmář wrote: > 2017-11-22 16:52+0100, Marc Haber: > > On Wed, Nov 22, 2017 at 04:04:42PM +0100, 王金浦 wrote: > > > So all guest kernels are 4.14, or also other older kernel? > > > > Guest kernels are also 4.14, but the issue disappears when the host

Re: VMs freezing when host is running 4.14

On Wed, Nov 22, 2017 at 05:43:13PM +0100, Radim Krčmář wrote: > 2017-11-22 16:52+0100, Marc Haber: > > On Wed, Nov 22, 2017 at 04:04:42PM +0100, 王金浦 wrote: > > > So all guest kernels are 4.14, or also other older kernel? > > > > Guest kernels are also 4.14, but the issue disappears when the host

Re: [PATCH 4/4] dm: convert table_device.count from atomic_t to refcount_t

Dne 20.10.2017 v 09:37 Elena Reshetova napsal(a): atomic_t variables are currently used to implement reference counters with the following properties: - counter is initialized to 1 using atomic_set() - a resource is freed upon counter reaching zero - once counter reaches zero, its further

Re: [PATCH 4/4] dm: convert table_device.count from atomic_t to refcount_t

Dne 20.10.2017 v 09:37 Elena Reshetova napsal(a): atomic_t variables are currently used to implement reference counters with the following properties: - counter is initialized to 1 using atomic_set() - a resource is freed upon counter reaching zero - once counter reaches zero, its further

Re: [PATCH 2/3] perf bench futex: synchronize 'bench futex wake-parallel' wakers

Em Wed, Nov 22, 2017 at 06:25:34PM -0600, Kim Phillips escreveu: > From: James Yang > > Waker threads in the futex wake-parallel benchmark are started by a > loop using pthread_create(). However, there is no synchronization > for when the waker threads wake the waiting

Re: [PATCH 2/3] perf bench futex: synchronize 'bench futex wake-parallel' wakers

Em Wed, Nov 22, 2017 at 06:25:34PM -0600, Kim Phillips escreveu: > From: James Yang > > Waker threads in the futex wake-parallel benchmark are started by a > loop using pthread_create(). However, there is no synchronization > for when the waker threads wake the waiting threads. Comparison of >

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