Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces

On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार) wrote: > On Thu, Nov 9, 2017 at 4:02 AM, Christian Brauner > wrote: > > On Wed, Nov 08, 2017 at 03:09:59AM -0800, Mahesh Bandewar (महेश बंडेवार) > > wrote: > >> Sorry folks I was traveling

Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces

On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार) wrote: > On Thu, Nov 9, 2017 at 4:02 AM, Christian Brauner > wrote: > > On Wed, Nov 08, 2017 at 03:09:59AM -0800, Mahesh Bandewar (महेश बंडेवार) > > wrote: > >> Sorry folks I was traveling and seems like lot happened on

[PATCH RFC 1/1] f2fs: add per-device superblocks

From: Qiuyang Sun Currently, a multi-device F2FS only has superblocks written in its start device, but not the others. Thus, we cannot tell if a single device is part of a F2FS by reading itself only, which may be unsafe in scenarios like transferring devices between

[PATCH RFC 1/1] f2fs: add per-device superblocks

From: Qiuyang Sun Currently, a multi-device F2FS only has superblocks written in its start device, but not the others. Thus, we cannot tell if a single device is part of a F2FS by reading itself only, which may be unsafe in scenarios like transferring devices between computer systems. This patch

Re: [PATCH] iio: mma8452: add power_mode sysfs configuration

Hi Martin, Thanks for publishing the patch. I will work on it, but unfortunately I can't promise anything before 11/27. Thanks, Harinath On Mon, Nov 6, 2017 at 2:19 AM, Martin Kepplinger wrote: > This adds the power_mode sysfs interface to the device as documented in >

Re: [PATCH] iio: mma8452: add power_mode sysfs configuration

Hi Martin, Thanks for publishing the patch. I will work on it, but unfortunately I can't promise anything before 11/27. Thanks, Harinath On Mon, Nov 6, 2017 at 2:19 AM, Martin Kepplinger wrote: > This adds the power_mode sysfs interface to the device as documented in > sysfs-bus-iio. > > --- >

[PATCH] iio: accel: mma8452: Add single pulse/tap event detection

This patch adds following related changes: - defines pulse event related registers - enables and handles single pulse interrupt for fxls8471 - handles IIO_EV_DIR_EITHER in read/write callbacks (because event direction for pulse is either rising or falling) - configures read/write event value for

[PATCH] iio: accel: mma8452: Add single pulse/tap event detection

This patch adds following related changes: - defines pulse event related registers - enables and handles single pulse interrupt for fxls8471 - handles IIO_EV_DIR_EITHER in read/write callbacks (because event direction for pulse is either rising or falling) - configures read/write event value for

Re: [PATCH 0001/0001] format idle IP output func+offset/length

Hi Changcheng, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.14-rc8] [cannot apply to next-20171108] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 0001/0001] format idle IP output func+offset/length

Hi Changcheng, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.14-rc8] [cannot apply to next-20171108] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[PATCH v8 6/6] x86/tsc: use tsc early

This patch adds early clock feature to x86 platforms. tsc_early_init(): Determines offset, shift and multiplier for the early clock based on the TSC frequency. tsc_early_fini() Implement the finish part of early tsc feature, prints message about the offset, which can be useful to find out how

[PATCH v8 6/6] x86/tsc: use tsc early

This patch adds early clock feature to x86 platforms. tsc_early_init(): Determines offset, shift and multiplier for the early clock based on the TSC frequency. tsc_early_fini() Implement the finish part of early tsc feature, prints message about the offset, which can be useful to find out how

[PATCH v8 5/6] x86/paravirt: add active_sched_clock to pv_time_ops

Early boot clock might differ from the clock that is used later on, therefore add a new field to pv_time_ops, that shows currently active clock. If platform supports early boot clock, this field will be changed to use that clock early in boot, and later will be replaced with the permanent clock.

[PATCH v8 5/6] x86/paravirt: add active_sched_clock to pv_time_ops

Early boot clock might differ from the clock that is used later on, therefore add a new field to pv_time_ops, that shows currently active clock. If platform supports early boot clock, this field will be changed to use that clock early in boot, and later will be replaced with the permanent clock.

[PATCH v8 2/6] time: sync read_boot_clock64() with persistent clock

read_boot_clock64() returns a boot start timestamp from epoch. Some arches may need to access the persistent clock interface in order to calculate the epoch offset. The resolution of the persistent clock, however, might be low. Therefore, in order to avoid time discrepancies a new argument 'now'

[PATCH v8 2/6] time: sync read_boot_clock64() with persistent clock

read_boot_clock64() returns a boot start timestamp from epoch. Some arches may need to access the persistent clock interface in order to calculate the epoch offset. The resolution of the persistent clock, however, might be low. Therefore, in order to avoid time discrepancies a new argument 'now'

[PATCH v8 1/6] x86/tsc: remove tsc_disabled flag

tsc_disabled is set when notsc is passed as kernel parameter. The reason we have notsc is to avoid timing problems on multi-socket systems. We already have a mechanism, however, to detect and resolve these issues by invoking tsc unstable path. Thus, make notsc to behave the same as tsc=unstable.

[PATCH v8 3/6] x86/time: read_boot_clock64() implementation

read_boot_clock64() returns time of when system was started. Now, that early boot clock is going to be available on x86 it is possible to implement x86 specific version of read_boot_clock64() that takes advantage of this new feature. Signed-off-by: Pavel Tatashin ---

[PATCH v8 1/6] x86/tsc: remove tsc_disabled flag

tsc_disabled is set when notsc is passed as kernel parameter. The reason we have notsc is to avoid timing problems on multi-socket systems. We already have a mechanism, however, to detect and resolve these issues by invoking tsc unstable path. Thus, make notsc to behave the same as tsc=unstable.

[PATCH v8 3/6] x86/time: read_boot_clock64() implementation

read_boot_clock64() returns time of when system was started. Now, that early boot clock is going to be available on x86 it is possible to implement x86 specific version of read_boot_clock64() that takes advantage of this new feature. Signed-off-by: Pavel Tatashin --- arch/x86/kernel/time.c | 30

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

Hi Ingo, On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote: > > > > Does this fix it? > > > > diff --git a/tools/objtool/Makefile

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

Hi Ingo, On Wed, 8 Nov 2017 10:18:28 +0100 Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Nov 08, 2017 at 01:47:17PM +1100, Stephen Rothwell wrote: > > > > Does this fix it? > > > > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile > > index

[PATCH v8 4/6] sched: early boot clock

Allow sched_clock() to be used before schec_clock_init() and sched_clock_init_late() are called. This provides us with a way to get early boot timestamps on machines with unstable clocks. Signed-off-by: Pavel Tatashin --- kernel/sched/clock.c | 10 -- 1 file

[PATCH] Input: sidewinder - mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114763 Addresses-Coverity-ID: 114764 Addresses-Coverity-ID: 114765 Addresses-Coverity-ID: 114766 Signed-off-by: Gustavo A. R. Silva ---

[PATCH v8 0/6] Early boot time stamps for x86

changelog - v8 - v7 - Addressed comments from Dou Liyang: - Moved tsc_early_init() and tsc_early_fini() to be all inside tsc.c, and changed them to be static. - Removed warning when notsc parameter is used. - Merged with:

[PATCH v8 4/6] sched: early boot clock

Allow sched_clock() to be used before schec_clock_init() and sched_clock_init_late() are called. This provides us with a way to get early boot timestamps on machines with unstable clocks. Signed-off-by: Pavel Tatashin --- kernel/sched/clock.c | 10 -- 1 file changed, 8 insertions(+), 2

[PATCH] Input: sidewinder - mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114763 Addresses-Coverity-ID: 114764 Addresses-Coverity-ID: 114765 Addresses-Coverity-ID: 114766 Signed-off-by: Gustavo A. R. Silva ---

[PATCH v8 0/6] Early boot time stamps for x86

changelog - v8 - v7 - Addressed comments from Dou Liyang: - Moved tsc_early_init() and tsc_early_fini() to be all inside tsc.c, and changed them to be static. - Removed warning when notsc parameter is used. - Merged with:

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Thu, Nov 9, 2017 at 11:02 AM, Johannes Berg wrote: > nit: I think your line got a little long here :) Ack. For v4. > and here Ack. For v4. > >> + nlk->dump_done_errno = INT_MAX; > > I guess positive values aren't really returned from dump? When a positive

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Thu, Nov 9, 2017 at 11:02 AM, Johannes Berg wrote: > nit: I think your line got a little long here :) Ack. For v4. > and here Ack. For v4. > >> + nlk->dump_done_errno = INT_MAX; > > I guess positive values aren't really returned from dump? When a positive value is returned, the API

[PATCH] Input: spaceball - mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114767 Addresses-Coverity-ID: 114768 Addresses-Coverity-ID: 114769 Signed-off-by: Gustavo A. R. Silva ---

[PATCH] Input: spaceball - mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114767 Addresses-Coverity-ID: 114768 Addresses-Coverity-ID: 114769 Signed-off-by: Gustavo A. R. Silva --- drivers/input/joystick/spaceball.c | 4 1 file

[PATCH v3] KVM: X86: Fix softlockup when get the current kvmclock

From: Wanpeng Li watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [qemu-system-x86:10185] CPU: 6 PID: 10185 Comm: qemu-system-x86 Tainted: G OE 4.14.0-rc4+ #4 RIP: 0010:kvm_get_time_scale+0x4e/0xa0 [kvm] Call Trace: ? get_kvmclock_ns+0xa3/0x140 [kvm]

[PATCH v3] KVM: X86: Fix softlockup when get the current kvmclock

From: Wanpeng Li watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [qemu-system-x86:10185] CPU: 6 PID: 10185 Comm: qemu-system-x86 Tainted: G OE 4.14.0-rc4+ #4 RIP: 0010:kvm_get_time_scale+0x4e/0xa0 [kvm] Call Trace: ? get_kvmclock_ns+0xa3/0x140 [kvm]

[PATCH] NFS: super: mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 703509 Addresses-Coverity-ID: 703510 Addresses-Coverity-ID: 703511 Addresses-Coverity-ID: 703512 Addresses-Coverity-ID: 703513 Signed-off-by: Gustavo A. R. Silva

[PATCH] NFS: super: mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 703509 Addresses-Coverity-ID: 703510 Addresses-Coverity-ID: 703511 Addresses-Coverity-ID: 703512 Addresses-Coverity-ID: 703513 Signed-off-by: Gustavo A. R. Silva

Re: [vlan_device_event] BUG: unable to handle kernel paging request at 6b6b6ccf

Of course, if it's bisectable, that would be great too. Yes, bisect is on the way. So far it's bisecting in the 4.12 commits. The bisect was unsuccessful due to an unrelated DRM_BOCHS oops in 4.11. Disabling the buggy driver, I managed to reproduce the vlan_device_event bug in 4.11. However

Re: [vlan_device_event] BUG: unable to handle kernel paging request at 6b6b6ccf

Of course, if it's bisectable, that would be great too. Yes, bisect is on the way. So far it's bisecting in the 4.12 commits. The bisect was unsuccessful due to an unrelated DRM_BOCHS oops in 4.11. Disabling the buggy driver, I managed to reproduce the vlan_device_event bug in 4.11. However

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, Nov 8, 2017 at 4:43 PM, Patrick McLean wrote: > As of 4.13.11 (and also with 4.14-rc) we have an issue where when > serving nfs4 sometimes we get the following BUG. When this bug happens, > it usually also causes the motherboard to no longer POST until we > externally

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Wed, Nov 8, 2017 at 4:43 PM, Patrick McLean wrote: > As of 4.13.11 (and also with 4.14-rc) we have an issue where when > serving nfs4 sometimes we get the following BUG. When this bug happens, > it usually also causes the motherboard to no longer POST until we > externally re-flash the BIOS

linux-next: manual merge of the devicetree tree with the arm-soc tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: arch/arm64/boot/dts/amlogic/Makefile between commit: 593d311d9f17 ("ARM64: dts: meson-gxm: Add Vega S96 board") from the arm-soc tree and commit: 4408a86af32e ("kbuild: handle dtb-y and CONFIG_OF_ALL_DTBS

linux-next: manual merge of the devicetree tree with the arm-soc tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: arch/arm64/boot/dts/amlogic/Makefile between commit: 593d311d9f17 ("ARM64: dts: meson-gxm: Add Vega S96 board") from the arm-soc tree and commit: 4408a86af32e ("kbuild: handle dtb-y and CONFIG_OF_ALL_DTBS

linux-next: manual merge of the devicetree tree with the arm-soc tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: arch/arm64/boot/dts/allwinner/Makefile between commit: d7341305863b ("arm64: allwinner: h5: add NanoPi NEO Plus2 DT support") from the arm-soc tree and commit: 4408a86af32e ("kbuild: handle dtb-y and

linux-next: manual merge of the devicetree tree with the arm-soc tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: arch/arm64/boot/dts/allwinner/Makefile between commit: d7341305863b ("arm64: allwinner: h5: add NanoPi NEO Plus2 DT support") from the arm-soc tree and commit: 4408a86af32e ("kbuild: handle dtb-y and

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

> > IMHO that should just fail then, ie, a "locked down" kernel should not want > > to > > *pass* a firmware signature if such thing could not be done. > > > > Its no different than trying to verify a signed module on a "locked down" > > for > > which it has no signature. > > > > But perhaps

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

> > IMHO that should just fail then, ie, a "locked down" kernel should not want > > to > > *pass* a firmware signature if such thing could not be done. > > > > Its no different than trying to verify a signed module on a "locked down" > > for > > which it has no signature. > > > > But perhaps

Re: [PATCH] checkpatch.pl: Add SPDX license tag check

On Wed, 2017-11-08 at 19:10 -0600, Rob Herring wrote: > Add a check warning if SPDX-License-Identifier tags are not used in > newly added files. If this is to be done, and I think it's not a great idea, there are better ways of doing this that emit this warning on a per-file basis instead of a

Re: [PATCH] checkpatch.pl: Add SPDX license tag check

On Wed, 2017-11-08 at 19:10 -0600, Rob Herring wrote: > Add a check warning if SPDX-License-Identifier tags are not used in > newly added files. If this is to be done, and I think it's not a great idea, there are better ways of doing this that emit this warning on a per-file basis instead of a

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Thu, Nov 09, 2017 at 11:49:52AM +1100, Michael Ellerman wrote: > "Tobin C. Harding" writes: > > > On Wed, Nov 08, 2017 at 11:10:56PM +1100, Michael Ellerman wrote: > >> "Tobin C. Harding" writes: > > [snip] > > > > Hi Michael, > > > > I'm working an adding

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Thu, Nov 09, 2017 at 11:49:52AM +1100, Michael Ellerman wrote: > "Tobin C. Harding" writes: > > > On Wed, Nov 08, 2017 at 11:10:56PM +1100, Michael Ellerman wrote: > >> "Tobin C. Harding" writes: > > [snip] > > > > Hi Michael, > > > > I'm working an adding support for ppc64 to

Re: [PATCH net-next 1/2] net: hns3: fix a bug when getting phy address from NCL_config file

On 2017/11/8 22:30, Andrew Lunn wrote: On Wed, Nov 08, 2017 at 03:52:22PM +0800, Lipeng wrote: From: Fuyun Liang Driver gets phy address from NCL_config file and uses the phy address to initialize phydev. There are 5 bits for phy address. And C22 phy address has 5

Re: [PATCH net-next 1/2] net: hns3: fix a bug when getting phy address from NCL_config file

On 2017/11/8 22:30, Andrew Lunn wrote: On Wed, Nov 08, 2017 at 03:52:22PM +0800, Lipeng wrote: From: Fuyun Liang Driver gets phy address from NCL_config file and uses the phy address to initialize phydev. There are 5 bits for phy address. And C22 phy address has 5 bits. So 0-31 are all

[PATCH RESEND 2/3] KVM: Add paravirt remote TLB flush

From: Wanpeng Li Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set

[PATCH RESEND 2/3] KVM: Add paravirt remote TLB flush

From: Wanpeng Li Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Thu, 2017-11-09 at 10:42 +0900, Jason A. Donenfeld wrote: > +++ b/net/netlink/af_netlink.c > @@ -2136,7 +2136,7 @@ static int netlink_dump(struct sock *sk) > struct sk_buff *skb = NULL; > struct nlmsghdr *nlh; > struct module *module; > - int len, err = -ENOBUFS; > +

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Thu, 2017-11-09 at 10:42 +0900, Jason A. Donenfeld wrote: > +++ b/net/netlink/af_netlink.c > @@ -2136,7 +2136,7 @@ static int netlink_dump(struct sock *sk) > struct sk_buff *skb = NULL; > struct nlmsghdr *nlh; > struct module *module; > - int len, err = -ENOBUFS; > +

[PATCH RESEND 1/3] KVM: Add vCPU running/preempted state

From: Wanpeng Li This patch reuses the preempted field in kvm_steal_time, and will export the vcpu running/pre-empted information to the guest from host. This will enable guest to intelligently send ipi to running vcpus and set flag for pre-empted vcpus. This will

[PATCH RESEND 0/3] KVM: Paravirt remote TLB flush

Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt flush tlbs making sure

[PATCH RESEND 3/3] KVM: Add flush_on_enter before guest enter

From: Wanpeng Li PV-Flush guest would indicate to flush on enter, flush the TLB before entering and exiting the guest. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/x86.c

[PATCH RESEND 1/3] KVM: Add vCPU running/preempted state

From: Wanpeng Li This patch reuses the preempted field in kvm_steal_time, and will export the vcpu running/pre-empted information to the guest from host. This will enable guest to intelligently send ipi to running vcpus and set flag for pre-empted vcpus. This will prevent waiting for vcpus

[PATCH RESEND 0/3] KVM: Paravirt remote TLB flush

Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt flush tlbs making sure

[PATCH RESEND 3/3] KVM: Add flush_on_enter before guest enter

From: Wanpeng Li PV-Flush guest would indicate to flush on enter, flush the TLB before entering and exiting the guest. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/x86.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

Re: [RFC] hung task: check specific tasks for long uninterruptible sleep state

On Wed, Nov 08, 2017 at 11:58:13AM +0530, Lingutla Chandrasekhar wrote: > khungtask by default monitors all tasks for long unterruptible sleep. > This change introduces a sysctl option, /proc/sys/kernel/ > hung_task_selective_monitoring, to enable monitoring selected tasks. > If this sysctl option

Re: [RFC] hung task: check specific tasks for long uninterruptible sleep state

On Wed, Nov 08, 2017 at 11:58:13AM +0530, Lingutla Chandrasekhar wrote: > khungtask by default monitors all tasks for long unterruptible sleep. > This change introduces a sysctl option, /proc/sys/kernel/ > hung_task_selective_monitoring, to enable monitoring selected tasks. > If this sysctl option

Re: [PATCH v2 2/2] rtc: sprd: Add Spreadtrum RTC driver

Hi Alexandre, On 9 November 2017 at 09:26, Alexandre Belloni wrote: > Hi, > > On 08/11/2017 at 17:16:15 +0800, Baolin Wang wrote: >> +static int sprd_rtc_read_time(struct device *dev, struct rtc_time *tm) >> +{ >> + struct sprd_rtc *rtc =

Re: [PATCH v2 2/2] rtc: sprd: Add Spreadtrum RTC driver

Hi Alexandre, On 9 November 2017 at 09:26, Alexandre Belloni wrote: > Hi, > > On 08/11/2017 at 17:16:15 +0800, Baolin Wang wrote: >> +static int sprd_rtc_read_time(struct device *dev, struct rtc_time *tm) >> +{ >> + struct sprd_rtc *rtc = dev_get_drvdata(dev); >> + time64_t secs; >> +

[PATCH 2/3] KVM: Add paravirt remote TLB flush

From: Wanpeng Li Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set

[PATCH 1/3] KVM: Add vCPU running/preempted state

From: Wanpeng Li This patch reuses the preempted field in kvm_steal_time, and will export the vcpu running/pre-empted information to the guest from host. This will enable guest to intelligently send ipi to running vcpus and set flag for pre-empted vcpus. This will

[PATCH 2/3] KVM: Add paravirt remote TLB flush

From: Wanpeng Li Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt

[PATCH 1/3] KVM: Add vCPU running/preempted state

From: Wanpeng Li This patch reuses the preempted field in kvm_steal_time, and will export the vcpu running/pre-empted information to the guest from host. This will enable guest to intelligently send ipi to running vcpus and set flag for pre-empted vcpus. This will prevent waiting for vcpus

[PATCH 0/3] KVM: Paravirt remote TLB flush

Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt flush tlbs making sure

[PATCH 0/3] KVM: Paravirt remote TLB flush

Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt flush tlbs making sure

[PATCH 3/3] KVM: Add flush_on_enter before guest enter

From: Wanpeng Li PV-Flush guest would indicate to flush on enter, flush the TLB before entering and exiting the guest. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/x86.c

[PATCH 3/3] KVM: Add flush_on_enter before guest enter

From: Wanpeng Li PV-Flush guest would indicate to flush on enter, flush the TLB before entering and exiting the guest. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/x86.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[PATCH] kallsyms: don't leak address when printing symbol

Currently if a pointer is printed using %p[ssB] and the symbol is not found (kallsyms_lookup() fails) then we print the actual address. This leaks kernel addresses. We should instead print something _safe_. Print "" instead of kernel address. Signed-off-by: Tobin C. Harding ---

[PATCH] kallsyms: don't leak address when printing symbol

Currently if a pointer is printed using %p[ssB] and the symbol is not found (kallsyms_lookup() fails) then we print the actual address. This leaks kernel addresses. We should instead print something _safe_. Print "" instead of kernel address. Signed-off-by: Tobin C. Harding ---

[lkp-robot] [net] 8e5bf9759a: WARNING:at_lib/refcount.c:#refcount_inc

FYI, we noticed the following commit (built with gcc-5): commit: 8e5bf9759a06be2251fa96cfd8b412f1808c62f9 ("net: dsa: simplify tree reference counting") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-i386 -enable-kvm -cpu

[lkp-robot] [net] 8e5bf9759a: WARNING:at_lib/refcount.c:#refcount_inc

FYI, we noticed the following commit (built with gcc-5): commit: 8e5bf9759a06be2251fa96cfd8b412f1808c62f9 ("net: dsa: simplify tree reference counting") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-i386 -enable-kvm -cpu

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote: > On Wed, Nov 08, 2017 at 03:15:54PM +0900, AKASHI, Takahiro wrote: > > Luis, > > > > Thank you for this heads-up. > > > > On Wed, Nov 08, 2017 at 12:07:00AM +0100, Luis R. Rodriguez wrote: > > > On Thu, Nov 02, 2017 at

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote: > On Wed, Nov 08, 2017 at 03:15:54PM +0900, AKASHI, Takahiro wrote: > > Luis, > > > > Thank you for this heads-up. > > > > On Wed, Nov 08, 2017 at 12:07:00AM +0100, Luis R. Rodriguez wrote: > > > On Thu, Nov 02, 2017 at

[PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

The way people generally use netlink_dump is that they fill in the skb as much as possible, breaking when nla_put returns an error. Then, they get called again and start filling out the next skb, and again, and so forth. The mechanism at work here is the ability for the iterative dumping function

[PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

The way people generally use netlink_dump is that they fill in the skb as much as possible, breaking when nla_put returns an error. Then, they get called again and start filling out the next skb, and again, and so forth. The mechanism at work here is the ability for the iterative dumping function

[RFC PATCH 2/3] mm: memfd: split out memfd for use by multiple filesystems

When memfd_create support was originally written, it only provided suport for tmpfs. Support has recently been added for hugetlbfs. memfd originally depended on tmpfs. In an effort to make it depend on tmpfs -or- hugetlbfs, split out the required code to separate files. Signed-off-by: Mike

[RFC PATCH 2/3] mm: memfd: split out memfd for use by multiple filesystems

When memfd_create support was originally written, it only provided suport for tmpfs. Support has recently been added for hugetlbfs. memfd originally depended on tmpfs. In an effort to make it depend on tmpfs -or- hugetlbfs, split out the required code to separate files. Signed-off-by: Mike

[RFC PATCH 3/3] mm: memfd: remove memfd code from shmem files and use new memfd files

Remove memfd and file sealing routines from shmem.c and enable the use of the new files (memfd.c and memfd.h). A new config option MEMFD_CREATE is defined that is enabled if TMPFS -or- HUGETLBFS is defined. Signed-off-by: Mike Kravetz --- fs/Kconfig | 3

[RFC PATCH 3/3] mm: memfd: remove memfd code from shmem files and use new memfd files

Remove memfd and file sealing routines from shmem.c and enable the use of the new files (memfd.c and memfd.h). A new config option MEMFD_CREATE is defined that is enabled if TMPFS -or- HUGETLBFS is defined. Signed-off-by: Mike Kravetz --- fs/Kconfig | 3 + fs/fcntl.c

[RFC PATCH 1/3] mm: hugetlbfs: move HUGETLBFS_I outside #ifdef CONFIG_HUGETLBFS

HUGETLBFS_I will be referenced but not used in code outside #ifdef CONFIG_HUGETLBFS. Move the definition to prevent compiler errors. Signed-off-by: Mike Kravetz --- include/linux/hugetlb.h | 27 --- 1 file changed, 16 insertions(+), 11

[RFC PATCH 1/3] mm: hugetlbfs: move HUGETLBFS_I outside #ifdef CONFIG_HUGETLBFS

HUGETLBFS_I will be referenced but not used in code outside #ifdef CONFIG_HUGETLBFS. Move the definition to prevent compiler errors. Signed-off-by: Mike Kravetz --- include/linux/hugetlb.h | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git

[RFC PATCH 0/3] restructure memfd code

With the addition of memfd hugetlbfs support, we now have the situation where memfd depends on TMPFS -or- HUGETLBFS. Previously, memfd was only supported on tmpfs, so it made sense that the code resides in shmem.c. This patch series moves the memfd code to separate files (memfd.c and memfd.h).

[RFC PATCH 0/3] restructure memfd code

With the addition of memfd hugetlbfs support, we now have the situation where memfd depends on TMPFS -or- HUGETLBFS. Previously, memfd was only supported on tmpfs, so it made sense that the code resides in shmem.c. This patch series moves the memfd code to separate files (memfd.c and memfd.h).

Re: [PATCH v2] mm, shrinker: make shrinker_list lockless

On Wed, Nov 08, 2017 at 05:07:08PM -0800, Shakeel Butt wrote: > On Wed, Nov 8, 2017 at 4:07 PM, Minchan Kim wrote: > > Hi, > > > > On Wed, Nov 08, 2017 at 09:37:40AM -0800, Shakeel Butt wrote: > >> In our production, we have observed that the job loader gets stuck for > >> 10s

Re: [PATCH v2] mm, shrinker: make shrinker_list lockless

On Wed, Nov 08, 2017 at 05:07:08PM -0800, Shakeel Butt wrote: > On Wed, Nov 8, 2017 at 4:07 PM, Minchan Kim wrote: > > Hi, > > > > On Wed, Nov 08, 2017 at 09:37:40AM -0800, Shakeel Butt wrote: > >> In our production, we have observed that the job loader gets stuck for > >> 10s of seconds while

Re: [PATCH] sh: migor: Reserve memory block for CEU

Hi Jacopo, Thank you for the patch. On Wednesday, 8 November 2017 20:05:46 EET Jacopo Mondi wrote: > A memory region for CEU video buffer has to be reserved during machine > initialization. > > Originally, it was allocated through DMA API helpers and stored in the > second IORESOURCE_MEM entry,

Re: [PATCH] sh: migor: Reserve memory block for CEU

Hi Jacopo, Thank you for the patch. On Wednesday, 8 November 2017 20:05:46 EET Jacopo Mondi wrote: > A memory region for CEU video buffer has to be reserved during machine > initialization. > > Originally, it was allocated through DMA API helpers and stored in the > second IORESOURCE_MEM entry,

Re: [PATCH v4 1/1] xdp: Sample xdp program implementing ip forward

On Wed, 08 Nov 2017 10:40:24 +0900 (KST) David Miller wrote: > From: Christina Jacob > Date: Sun, 5 Nov 2017 08:52:30 +0530 > > > From: Christina Jacob > > > > Implements port to port forwarding with route

Re: [PATCH v4 1/1] xdp: Sample xdp program implementing ip forward

On Wed, 08 Nov 2017 10:40:24 +0900 (KST) David Miller wrote: > From: Christina Jacob > Date: Sun, 5 Nov 2017 08:52:30 +0530 > > > From: Christina Jacob > > > > Implements port to port forwarding with route table and arp table > > lookup for ipv4 packets using bpf_redirect helper function

Re: [PATCH for-next 2/4] RDMA/hns: Add IOMMU enable support in hip08

On 2017/11/1 20:26, Robin Murphy wrote: > On 01/11/17 07:46, Wei Hu (Xavier) wrote: >> >> On 2017/10/12 20:59, Robin Murphy wrote: >>> On 12/10/17 13:31, Wei Hu (Xavier) wrote: On 2017/10/1 0:10, Leon Romanovsky wrote: > On Sat, Sep 30, 2017 at 05:28:59PM +0800, Wei Hu (Xavier) wrote:

Re: [PATCH for-next 2/4] RDMA/hns: Add IOMMU enable support in hip08

On 2017/11/1 20:26, Robin Murphy wrote: > On 01/11/17 07:46, Wei Hu (Xavier) wrote: >> >> On 2017/10/12 20:59, Robin Murphy wrote: >>> On 12/10/17 13:31, Wei Hu (Xavier) wrote: On 2017/10/1 0:10, Leon Romanovsky wrote: > On Sat, Sep 30, 2017 at 05:28:59PM +0800, Wei Hu (Xavier) wrote:

Re: [PATCH] sh: migor: Reserve memory block for CEU

Hi Geert, On Wednesday, 8 November 2017 20:31:22 EET Geert Uytterhoeven wrote: > On Wed, Nov 8, 2017 at 7:05 PM, Jacopo Mondi wrote: > > A memory region for CEU video buffer has to be reserved during machine > > initialization. > > > > Originally, it was allocated through DMA API helpers and

Re: [PATCH] sh: migor: Reserve memory block for CEU

Hi Geert, On Wednesday, 8 November 2017 20:31:22 EET Geert Uytterhoeven wrote: > On Wed, Nov 8, 2017 at 7:05 PM, Jacopo Mondi wrote: > > A memory region for CEU video buffer has to be reserved during machine > > initialization. > > > > Originally, it was allocated through DMA API helpers and

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