Re: [PATCH v4 2/4] KVM: X86: Add paravirt remote TLB flush

On Tue, Nov 14, 2017 at 02:28:56PM +0800, Wanpeng Li wrote: > > - have the TLB invalidate handler do something like: > > > >state = READ_ONCE(src->preempted); > >if (!(state & KVM_VCPU_IPI_PENDING)) > >return; > > > >local_flush_tlb(); > > > >do { > >} while

Re: [PATCH v4 2/4] KVM: X86: Add paravirt remote TLB flush

On Tue, Nov 14, 2017 at 02:28:56PM +0800, Wanpeng Li wrote: > > - have the TLB invalidate handler do something like: > > > >state = READ_ONCE(src->preempted); > >if (!(state & KVM_VCPU_IPI_PENDING)) > >return; > > > >local_flush_tlb(); > > > >do { > >} while

Re: [PATCH 0/2] backlight: pwm_bl: prevent backlight flicker when switching PWM on

Hi, On Fri, 10 Nov 2017 12:22:15 +0100 Enric Balletbo i Serra wrote: > Hi all, > > On 08/11/17 11:48, Daniel Thompson wrote: > > On 26/10/17 13:49, Lothar Waßmann wrote: > >> These patches implement some measures to prevent backlight flicker > >> when the backlight is being switched on for a

Re: [PATCH 0/2] backlight: pwm_bl: prevent backlight flicker when switching PWM on

Hi, On Fri, 10 Nov 2017 12:22:15 +0100 Enric Balletbo i Serra wrote: > Hi all, > > On 08/11/17 11:48, Daniel Thompson wrote: > > On 26/10/17 13:49, Lothar Waßmann wrote: > >> These patches implement some measures to prevent backlight flicker > >> when the backlight is being switched on for a

Re: [PATCH 4.13 00/33] 4.13.13-stable review

On Mon, Nov 13, 2017 at 02:29:09PM -0800, Guenter Roeck wrote: > On Mon, Nov 13, 2017 at 01:56:21PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.13.13 release. > > There are 33 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.13 00/33] 4.13.13-stable review

On Mon, Nov 13, 2017 at 02:29:09PM -0800, Guenter Roeck wrote: > On Mon, Nov 13, 2017 at 01:56:21PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.13.13 release. > > There are 33 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

Am 14.11.2017 um 08:41 schrieb Greg Kroah-Hartman: On Tue, Nov 14, 2017 at 07:48:47AM +0100, Sebastian Gottschall wrote: ahm it compiles well. but [   24.838120] Unable to handle kernel NULL pointer dereference at virtual address 0055 [   24.846193] pgd = c0004000 [   24.848893] [0055]

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

Am 14.11.2017 um 08:41 schrieb Greg Kroah-Hartman: On Tue, Nov 14, 2017 at 07:48:47AM +0100, Sebastian Gottschall wrote: ahm it compiles well. but [   24.838120] Unable to handle kernel NULL pointer dereference at virtual address 0055 [   24.846193] pgd = c0004000 [   24.848893] [0055]

RE: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

Hi Michal, > -Original Message- > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Tuesday, November 14, 2017 3:07 PM > To: Ran Wang > Cc: linux...@kvack.org; Michael Ellerman ; Vlastimil > Babka ; Andrew Morton

RE: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

Hi Michal, > -Original Message- > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Tuesday, November 14, 2017 3:07 PM > To: Ran Wang > Cc: linux...@kvack.org; Michael Ellerman ; Vlastimil > Babka ; Andrew Morton ; > KAMEZAWA Hiroyuki ; Reza Arbab > ; Yasuaki Ishimatsu ; >

Re: [PATCH RFC v3 4/6] Documentation: Add three sysctls for smart idle poll

* Quan Xu wrote: > > > On 2017/11/13 23:08, Ingo Molnar wrote: > > * Quan Xu wrote: > > > > > From: Quan Xu > > > > > > To reduce the cost of poll, we introduce three sysctl to control the > > > poll time when running as a

Re: [PATCH 3.18 00/28] 3.18.81-stable review

On Mon, Nov 13, 2017 at 02:50:22PM -0700, Shuah Khan wrote: > On 11/13/2017 05:54 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.81 release. > > There are 28 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH RFC v3 4/6] Documentation: Add three sysctls for smart idle poll

* Quan Xu wrote: > > > On 2017/11/13 23:08, Ingo Molnar wrote: > > * Quan Xu wrote: > > > > > From: Quan Xu > > > > > > To reduce the cost of poll, we introduce three sysctl to control the > > > poll time when running as a virtual machine with paravirt. > > > > > > Signed-off-by: Yang

Re: [PATCH 3.18 00/28] 3.18.81-stable review

On Mon, Nov 13, 2017 at 02:50:22PM -0700, Shuah Khan wrote: > On 11/13/2017 05:54 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.81 release. > > There are 28 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.13 00/33] 4.13.13-stable review

On Mon, Nov 13, 2017 at 02:02:12PM -0800, kernelci.org bot wrote: > stable-rc/linux-4.13.y boot: 127 boots: 10 failed, 116 passed with 1 conflict > (v4.13.12-34-g109b28ca1340) > > Full Boot Summary: >

Re: [PATCH 4.13 00/33] 4.13.13-stable review

On Mon, Nov 13, 2017 at 02:02:12PM -0800, kernelci.org bot wrote: > stable-rc/linux-4.13.y boot: 127 boots: 10 failed, 116 passed with 1 conflict > (v4.13.12-34-g109b28ca1340) > > Full Boot Summary: >

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

On Tue, Nov 14, 2017 at 07:48:47AM +0100, Sebastian Gottschall wrote: > ahm it compiles well. but > > [   24.838120] Unable to handle kernel NULL pointer dereference at virtual > address 0055 > [   24.846193] pgd = c0004000 > [   24.848893] [0055] *pgd= > [   24.852472] Internal

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

On Tue, Nov 14, 2017 at 07:48:47AM +0100, Sebastian Gottschall wrote: > ahm it compiles well. but > > [   24.838120] Unable to handle kernel NULL pointer dereference at virtual > address 0055 > [   24.846193] pgd = c0004000 > [   24.848893] [0055] *pgd= > [   24.852472] Internal

Re: [PATCH 0/7] net: core: devname allocation cleanups

From: Rasmus Villemoes Date: Mon, 13 Nov 2017 00:15:03 +0100 > It's somewhat confusing to have both dev_alloc_name and > dev_get_valid_name. I can't see why the former is less strict than the > latter, so make them (or rather dev_alloc_name_ns and > dev_get_valid_name)

Re: [PATCH 0/7] net: core: devname allocation cleanups

From: Rasmus Villemoes Date: Mon, 13 Nov 2017 00:15:03 +0100 > It's somewhat confusing to have both dev_alloc_name and > dev_get_valid_name. I can't see why the former is less strict than the > latter, so make them (or rather dev_alloc_name_ns and > dev_get_valid_name) equivalent, hardening

Re: [PATCH v4 2/4] KVM: X86: Add paravirt remote TLB flush

On Tue, Nov 14, 2017 at 02:10:16PM +0800, Wanpeng Li wrote: > 2017-11-13 21:02 GMT+08:00 Peter Zijlstra : > > That can be written like: > > > > do { > > if (state & KVM_VCPU_PREEMPTED) > > new_state = state |

Re: [PATCH v4 2/4] KVM: X86: Add paravirt remote TLB flush

On Tue, Nov 14, 2017 at 02:10:16PM +0800, Wanpeng Li wrote: > 2017-11-13 21:02 GMT+08:00 Peter Zijlstra : > > That can be written like: > > > > do { > > if (state & KVM_VCPU_PREEMPTED) > > new_state = state | KVM_VCPU_SHOULD_FLUSH; > >

Re: [RESEND PATCH v2 4/4] x86/umip: Warn if UMIP-protected instructions are used

* Ricardo Neri wrote: > +const char * const umip_insns[5] = { > + [UMIP_INST_SGDT] = "sgdt", > + [UMIP_INST_SIDT] = "sidt", > + [UMIP_INST_SMSW] = "smsw", > + [UMIP_INST_SLDT] = "sldt", > + [UMIP_INST_STR] = "str", > +}; Sigh ... >

Re: [RESEND PATCH v2 4/4] x86/umip: Warn if UMIP-protected instructions are used

* Ricardo Neri wrote: > +const char * const umip_insns[5] = { > + [UMIP_INST_SGDT] = "sgdt", > + [UMIP_INST_SIDT] = "sidt", > + [UMIP_INST_SMSW] = "smsw", > + [UMIP_INST_SLDT] = "sldt", > + [UMIP_INST_STR] = "str", > +}; Sigh ... > +/* > + * If you change these strings,

RE: [patch v2 3/8] KVM: x86: add Intel processor trace virtualization mode

> > + if (!(_cpu_based_2nd_exec_control & SECONDARY_EXEC_PT_USE_GPA) || > > + !(_vmexit_control & VM_EXIT_CLEAR_IA32_RTIT_CTL) || > > + !(_vmentry_control & VM_ENTRY_LOAD_IA32_RTIT_CTL)) { > > + _cpu_based_2nd_exec_control &= ~SECONDARY_EXEC_PT_USE_GPA; > > Also,

RE: [patch v2 3/8] KVM: x86: add Intel processor trace virtualization mode

> > + if (!(_cpu_based_2nd_exec_control & SECONDARY_EXEC_PT_USE_GPA) || > > + !(_vmexit_control & VM_EXIT_CLEAR_IA32_RTIT_CTL) || > > + !(_vmentry_control & VM_ENTRY_LOAD_IA32_RTIT_CTL)) { > > + _cpu_based_2nd_exec_control &= ~SECONDARY_EXEC_PT_USE_GPA; > > Also,

[f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 14/11/17 08:02, Quan Xu wrote: > > > On 2017/11/13 18:53, Juergen Gross wrote: >> On 13/11/17 11:06, Quan Xu wrote: >>> From: Quan Xu >>> >>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called >>> in idle path which will poll for a while before we enter

[f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for updating free bitmap

alloc_nid_failed and scan_nat_page can be called at the same time, and we haven't protected add_free_nid and update_free_nid_bitmap with the same nid_list_lock. That could lead to Thread AThread B - __build_free_nids - scan_nat_page

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 14/11/17 08:02, Quan Xu wrote: > > > On 2017/11/13 18:53, Juergen Gross wrote: >> On 13/11/17 11:06, Quan Xu wrote: >>> From: Quan Xu >>> >>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called >>> in idle path which will poll for a while before we enter the real idle >>>

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

Am 14.11.2017 05:56 schrieb harinath Nampally: Hi Martin, But given your concerns, I would strip down this patch to only offer the already documented "low_noise" and "low_power" modes. It wouldn't be worth it to extend the ABI just because of this! OK then we can map 'low_noise' to high

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

Am 14.11.2017 05:56 schrieb harinath Nampally: Hi Martin, But given your concerns, I would strip down this patch to only offer the already documented "low_noise" and "low_power" modes. It wouldn't be worth it to extend the ABI just because of this! OK then we can map 'low_noise' to high

Re: [PATCH v3 2/3] usb: xhci: Add DbC support in xHCI driver

Hi, Mathias Nyman writes: >> +static int dbc_buf_alloc(struct dbc_buf *db, unsigned int size) >> +{ >> +db->buf_buf = kzalloc(size, GFP_KERNEL); >> +if (!db->buf_buf) >> +return -ENOMEM; >> + >> +db->buf_size = size; >> +db->buf_put =

Re: [PATCH v3 2/3] usb: xhci: Add DbC support in xHCI driver

Hi, Mathias Nyman writes: >> +static int dbc_buf_alloc(struct dbc_buf *db, unsigned int size) >> +{ >> +db->buf_buf = kzalloc(size, GFP_KERNEL); >> +if (!db->buf_buf) >> +return -ENOMEM; >> + >> +db->buf_size = size; >> +db->buf_put = db->buf_buf; >> +db->buf_get

Re: [PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

On 14 November 2017 at 07:57, Rakib Mullick wrote: > Currently, during __bitmap_weight() calculation hweight_long() is used. > Inside a hweight_long() a check has been made to figure out whether a > hweight32() or hweight64() version to use. > > diff --git a/lib/bitmap.c

Re: [PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

On 14 November 2017 at 07:57, Rakib Mullick wrote: > Currently, during __bitmap_weight() calculation hweight_long() is used. > Inside a hweight_long() a check has been made to figure out whether a > hweight32() or hweight64() version to use. > > diff --git a/lib/bitmap.c b/lib/bitmap.c > index

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

Am 14.11.2017 05:36 schrieb harinath Nampally: > 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

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

Am 14.11.2017 05:36 schrieb harinath Nampally: > 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

Re: [RESEND PATCH v2 3/4] x86/umip: Identify the str and sldt instructions

* Ricardo Neri wrote: > The instructions STR and SLDT are not emulated in any case. Thus, it made > sense to not implement functionality to identify them. However, a > subsequent commit will introduce functionality to warn about the use of > all the

Re: [RESEND PATCH v2 3/4] x86/umip: Identify the str and sldt instructions

* Ricardo Neri wrote: > The instructions STR and SLDT are not emulated in any case. Thus, it made > sense to not implement functionality to identify them. However, a > subsequent commit will introduce functionality to warn about the use of > all the instructions that UMIP protect, not only

Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) leaking TLB entry

On Tue 14-11-17 10:45:49, Minchan Kim wrote: [...] > Anyway, I think Wang Nan's patch is already broken. > http://lkml.kernel.org/r/%3c20171107095453.179940-1-wangn...@huawei.com%3E > > Because unmap_page_range(ie, zap_pte_range) can flush TLB forcefully > and free pages. However, the

[f2fs-dev] [PATCH RESEND v2] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increased regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) leaking TLB entry

On Tue 14-11-17 10:45:49, Minchan Kim wrote: [...] > Anyway, I think Wang Nan's patch is already broken. > http://lkml.kernel.org/r/%3c20171107095453.179940-1-wangn...@huawei.com%3E > > Because unmap_page_range(ie, zap_pte_range) can flush TLB forcefully > and free pages. However, the

[f2fs-dev] [PATCH RESEND v2] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increased regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

Re: [PATCH 3/4] x86/umip: Identify the str and sldt instructions

* Ricardo Neri wrote: > On Mon, Nov 13, 2017 at 09:12:03AM +0100, Ingo Molnar wrote: > > > > * Ricardo Neri wrote: > > > > > The instructions str and sldt are not emulated in any case. Thus, it made > > > sense to

Re: [PATCH 3/4] x86/umip: Identify the str and sldt instructions

* Ricardo Neri wrote: > On Mon, Nov 13, 2017 at 09:12:03AM +0100, Ingo Molnar wrote: > > > > * Ricardo Neri wrote: > > > > > The instructions str and sldt are not emulated in any case. Thus, it made > > > sense to not implement functionality to identify them. However, a > > > subsequent

Re: [PATCH net-next 0/3] rxrpc: Fixes

From: David Howells Date: Sat, 11 Nov 2017 17:57:52 + > > Here are some patches that fix some things in AF_RXRPC: > > (1) Prevent notifications from being passed to a kernel service for a call > that it has ended. > > (2) Fix a null pointer deference that

Re: [PATCH net-next 0/3] rxrpc: Fixes

From: David Howells Date: Sat, 11 Nov 2017 17:57:52 + > > Here are some patches that fix some things in AF_RXRPC: > > (1) Prevent notifications from being passed to a kernel service for a call > that it has ended. > > (2) Fix a null pointer deference that occurs under some

Re: [RFC 1/7] x86/asm/64: Allocate and enable the SYSENTER stack

* Andy Lutomirski wrote: > I have old patches to stop using IST for #DB and #BP, but I never finished > them. I'm all in favor of reviving that effort! Thanks, Ingo

Re: [RFC 1/7] x86/asm/64: Allocate and enable the SYSENTER stack

* Andy Lutomirski wrote: > I have old patches to stop using IST for #DB and #BP, but I never finished > them. I'm all in favor of reviving that effort! Thanks, Ingo

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

2017-11-14 15:02 GMT+08:00 Quan Xu : > > > On 2017/11/13 18:53, Juergen Gross wrote: >> >> On 13/11/17 11:06, Quan Xu wrote: >>> >>> From: Quan Xu >>> >>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called >>> in idle path which will poll

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

2017-11-14 15:02 GMT+08:00 Quan Xu : > > > On 2017/11/13 18:53, Juergen Gross wrote: >> >> On 13/11/17 11:06, Quan Xu wrote: >>> >>> From: Quan Xu >>> >>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called >>> in idle path which will poll for a while before we enter the real

RE: [patch v2 3/8] KVM: x86: add Intel processor trace virtualization mode

> > +#define VM_EXIT_PT_SUPPRESS_PIP0x0100 > > +#define VM_EXIT_CLEAR_IA32_RTIT_CTL0x0200 > > > > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff > > > > @@ -108,6 +112,8 @@ > > #define VM_ENTRY_LOAD_IA32_PAT 0x4000 > >

RE: [patch v2 3/8] KVM: x86: add Intel processor trace virtualization mode

> > +#define VM_EXIT_PT_SUPPRESS_PIP0x0100 > > +#define VM_EXIT_CLEAR_IA32_RTIT_CTL0x0200 > > > > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff > > > > @@ -108,6 +112,8 @@ > > #define VM_ENTRY_LOAD_IA32_PAT 0x4000 > >

Re: Improving documentation of parent-ID field in /proc/PID/mountinfo

Hi Miklos, Ram Thanks for your comments. A question below. On 13 November 2017 at 09:11, Miklos Szeredi wrote: > On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai wrote: >> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote: >>> Hello

Re: Improving documentation of parent-ID field in /proc/PID/mountinfo

Hi Miklos, Ram Thanks for your comments. A question below. On 13 November 2017 at 09:11, Miklos Szeredi wrote: > On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai wrote: >> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote: >>> Hello Ram, >>> >>> Long ago (2.6.29) you added

Re: linux-next: Tree for Nov 7

On Mon 13-11-17 09:35:22, Khalid Aziz wrote: > On 11/13/2017 09:06 AM, Michal Hocko wrote: > > OK, so this one should take care of the backward compatibility while > > still not touching the arch code > > --- > > commit 39ff9bf8597e79a032da0954aea1f0d77d137765 > > Author: Michal Hocko

Re: linux-next: Tree for Nov 7

On Mon 13-11-17 09:35:22, Khalid Aziz wrote: > On 11/13/2017 09:06 AM, Michal Hocko wrote: > > OK, so this one should take care of the backward compatibility while > > still not touching the arch code > > --- > > commit 39ff9bf8597e79a032da0954aea1f0d77d137765 > > Author: Michal Hocko > > Date:

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

On Tue 14-11-17 06:10:00, Ran Wang wrote: [...] > > > This drop cause DWC3 USB controller fail on initialization with > > > Layerscaper processors (such as LS1043A) as below: > > > > > > [2.701437] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned > > bus number 1 > > > [2.710949]

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

On Tue 14-11-17 06:10:00, Ran Wang wrote: [...] > > > This drop cause DWC3 USB controller fail on initialization with > > > Layerscaper processors (such as LS1043A) as below: > > > > > > [2.701437] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned > > bus number 1 > > > [2.710949]

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called in idle path which will poll for a while before we enter the real idle state. In virtualization, idle path

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called in idle path which will poll for a while before we enter the real idle state. In virtualization, idle path includes several heavy

RE: [patch v2 8/8] KVM: x86: Disable intercept for Intel processor trace MSRs

> > + if (pt_mode == PT_MODE_HOST_GUEST) { > > + u32 i, eax, ebx, ecx, edx; > > + > > + cpuid_count(0x14, 1, , , , ); > > + vmx_disable_intercept_for_msr(MSR_IA32_RTIT_STATUS, false); > > + vmx_disable_intercept_for_msr(MSR_IA32_RTIT_OUTPUT_BASE, false); >

RE: [patch v2 8/8] KVM: x86: Disable intercept for Intel processor trace MSRs

> > + if (pt_mode == PT_MODE_HOST_GUEST) { > > + u32 i, eax, ebx, ecx, edx; > > + > > + cpuid_count(0x14, 1, , , , ); > > + vmx_disable_intercept_for_msr(MSR_IA32_RTIT_STATUS, false); > > + vmx_disable_intercept_for_msr(MSR_IA32_RTIT_OUTPUT_BASE, false); >

RE: [patch v2 7/8] KVM: x86: add Intel PT msr RTIT_CTL read/write

> > static DEFINE_PER_CPU(struct vmcs *, vmxarea); static > > DEFINE_PER_CPU(struct vmcs *, current_vmcs); @@ -3384,6 +3385,11 @@ > > static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > > return 1; > > msr_info->data = vcpu->arch.ia32_xss; >

RE: [patch v2 7/8] KVM: x86: add Intel PT msr RTIT_CTL read/write

> > static DEFINE_PER_CPU(struct vmcs *, vmxarea); static > > DEFINE_PER_CPU(struct vmcs *, current_vmcs); @@ -3384,6 +3385,11 @@ > > static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > > return 1; > > msr_info->data = vcpu->arch.ia32_xss; >

[PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

Currently, during __bitmap_weight() calculation hweight_long() is used. Inside a hweight_long() a check has been made to figure out whether a hweight32() or hweight64() version to use. However, it's unnecessary to do it in case of __bitmap_weight() calculation inside the loop. We can detect

[PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

Currently, during __bitmap_weight() calculation hweight_long() is used. Inside a hweight_long() a check has been made to figure out whether a hweight32() or hweight64() version to use. However, it's unnecessary to do it in case of __bitmap_weight() calculation inside the loop. We can detect

Re: KASAN: use-after-free Read in rds_tcp_dev_event

On (11/13/17 19:30), Girish Moodalbail wrote: > (L538-540). However, it leaves behind some of the rds_tcp connections that > shared the same underlying RDS connection (L534 and 535). These connections > with pointer to stale network namespace are left behind in the global list. It leaves behind

Re: KASAN: use-after-free Read in rds_tcp_dev_event

On (11/13/17 19:30), Girish Moodalbail wrote: > (L538-540). However, it leaves behind some of the rds_tcp connections that > shared the same underlying RDS connection (L534 and 535). These connections > with pointer to stale network namespace are left behind in the global list. It leaves behind

[PATCH -next] irqchip/exiu: Fix return value check in exiu_init()

In case of error, the function of_iomap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 706cffc1b912 ("irqchip/exiu: Add support for Socionext Synquacer EXIU controller") Signed-off-by: Wei Yongjun

[PATCH -next] irqchip/exiu: Fix return value check in exiu_init()

In case of error, the function of_iomap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 706cffc1b912 ("irqchip/exiu: Add support for Socionext Synquacer EXIU controller") Signed-off-by: Wei Yongjun ---

Re: [PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults

Ramon Fried writes: > From: Eyal Ilsar > > If the value for the firmware configuration parameters > BTC_STATIC_LEN_LE_BT and BTC_STATIC_LEN_LE_WLAN are not set the duty > cycle between BT and WLAN is such that if BT (including BLE) is active > WLAN

Re: [PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults

Ramon Fried writes: > From: Eyal Ilsar > > If the value for the firmware configuration parameters > BTC_STATIC_LEN_LE_BT and BTC_STATIC_LEN_LE_WLAN are not set the duty > cycle between BT and WLAN is such that if BT (including BLE) is active > WLAN gets 0 bandwidth. When tuning these parameters

Re: [PATCH v6 4/5] crash: export paddr_vmcoreinfo_note()

On 11/13/17 at 08:29pm, Marc-André Lureau wrote: > The following patch is going to use the symbol from the fw_cfg module, > to call the function and write the note location details in the > vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note. > > CC: Andrew Morton

Re: [PATCH v6 4/5] crash: export paddr_vmcoreinfo_note()

On 11/13/17 at 08:29pm, Marc-André Lureau wrote: > The following patch is going to use the symbol from the fw_cfg module, > to call the function and write the note location details in the > vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note. > > CC: Andrew Morton > CC: Baoquan

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

ahm it compiles well. but [   24.838120] Unable to handle kernel NULL pointer dereference at virtual address 0055 [   24.846193] pgd = c0004000 [   24.848893] [0055] *pgd= [   24.852472] Internal error: Oops - BUG: 817 [#1] PREEMPT SMP ARM [   24.858463] Modules linked in:

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

ahm it compiles well. but [   24.838120] Unable to handle kernel NULL pointer dereference at virtual address 0055 [   24.846193] pgd = c0004000 [   24.848893] [0055] *pgd= [   24.852472] Internal error: Oops - BUG: 817 [#1] PREEMPT SMP ARM [   24.858463] Modules linked in:

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

On Tue, Aug 22, 2017 at 10:45:24AM +0100, Will Deacon wrote: > On Mon, Aug 21, 2017 at 02:42:03PM +0100, Mark Rutland wrote: > > On Tue, Jul 11, 2017 at 03:58:49PM +0100, Will Deacon wrote: > > > On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > > > > When there's a fatal signal

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

On Tue, Aug 22, 2017 at 10:45:24AM +0100, Will Deacon wrote: > On Mon, Aug 21, 2017 at 02:42:03PM +0100, Mark Rutland wrote: > > On Tue, Jul 11, 2017 at 03:58:49PM +0100, Will Deacon wrote: > > > On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > > > > When there's a fatal signal

Re: [PATCH v2] coccinelle: fix parallel build with CHECK=scripts/coccicheck

On Tue, 14 Nov 2017, Masahiro Yamada wrote: > Hi Julia, > > 2017-11-14 1:45 GMT+09:00 Julia Lawall : > > > > > > On Tue, 14 Nov 2017, Masahiro Yamada wrote: > > > >> Hi Julia, > >> > >> > >> 2017-11-14 0:30 GMT+09:00 Julia Lawall : > >> > > >> > > >>

Re: [PATCH v2] coccinelle: fix parallel build with CHECK=scripts/coccicheck

On Tue, 14 Nov 2017, Masahiro Yamada wrote: > Hi Julia, > > 2017-11-14 1:45 GMT+09:00 Julia Lawall : > > > > > > On Tue, 14 Nov 2017, Masahiro Yamada wrote: > > > >> Hi Julia, > >> > >> > >> 2017-11-14 0:30 GMT+09:00 Julia Lawall : > >> > > >> > > >> > On Thu, 9 Nov 2017, Masahiro Yamada wrote:

Re: [PATCH v6 4/5] crash: export paddr_vmcoreinfo_note()

On 11/13/17 at 08:29pm, Marc-André Lureau wrote: > The following patch is going to use the symbol from the fw_cfg module, > to call the function and write the note location details in the > vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note. > > CC: Andrew Morton

Re: [PATCH v6 4/5] crash: export paddr_vmcoreinfo_note()

On 11/13/17 at 08:29pm, Marc-André Lureau wrote: > The following patch is going to use the symbol from the fw_cfg module, > to call the function and write the note location details in the > vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note. > > CC: Andrew Morton > CC: Baoquan

Re: n900 in next-20170901

On Mon, Nov 13, 2017 at 01:15:30PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171110 07:36]: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > >

Re: n900 in next-20170901

On Mon, Nov 13, 2017 at 01:15:30PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171110 07:36]: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > > +#define OMAP34XX_SRAM_VIRT

Re: Fwd: linux v4.14 causes firmware iwlwifi errors on Lenovo Thinkpad T440s

On Mon, 2017-11-13 at 16:23 -0600, Larry Finger wrote: > On 11/13/2017 03:30 PM, Bartosz Golaszewski wrote: > > 2017-11-13 21:45 GMT+01:00 Larry Finger > > : > > > On 11/13/2017 02:22 PM, Bartosz Golaszewski wrote: > > > > > > > > Forwarding here too as I messed up the

Re: Fwd: linux v4.14 causes firmware iwlwifi errors on Lenovo Thinkpad T440s

On Mon, 2017-11-13 at 16:23 -0600, Larry Finger wrote: > On 11/13/2017 03:30 PM, Bartosz Golaszewski wrote: > > 2017-11-13 21:45 GMT+01:00 Larry Finger > > : > > > On 11/13/2017 02:22 PM, Bartosz Golaszewski wrote: > > > > > > > > Forwarding here too as I messed up the address the last time. > >

Re: n900 in next-20170901

On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > >

Re: n900 in next-20170901

On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > > +#define OMAP34XX_SRAM_SIZE

[RESEND PATCH v2 2/4] x86/umip: Inform that UMIP has been enabled

Let us have an indication that this feature has been enabled. Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Borislav Petkov Cc: Tony Luck Cc: Paolo Bonzini Cc: Ravi V. Shankar Cc:

[PATCH] usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub

KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect to Realtek r8153. Similar to commit ("7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work. Signed-off-by: Kai-Heng Feng ---

[RESEND PATCH v2 2/4] x86/umip: Inform that UMIP has been enabled

Let us have an indication that this feature has been enabled. Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Borislav Petkov Cc: Tony Luck Cc: Paolo Bonzini Cc: Ravi V. Shankar Cc: x...@kernel.org Suggested-by: Ingo Molnar Signed-off-by: Ricardo Neri --- arch/x86/kernel/cpu/common.c | 2 ++

[PATCH] usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub

KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect to Realtek r8153. Similar to commit ("7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work. Signed-off-by: Kai-Heng Feng --- drivers/usb/core/quirks.c | 3

[RESEND PATCH v2 4/4] x86/umip: Warn if UMIP-protected instructions are used

Issue a rate-limited warning whenever any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR and SMSW) are used by user space programs. This is useful because, with UMIP enabled, the few programs that use such instructions will start receiving a SIGSEGV signal. In the specific

[RESEND PATCH v2 3/4] x86/umip: Identify the str and sldt instructions

The instructions STR and SLDT are not emulated in any case. Thus, it made sense to not implement functionality to identify them. However, a subsequent commit will introduce functionality to warn about the use of all the instructions that UMIP protect, not only those that are emulated. A first step

[RESEND PATCH v2 3/4] x86/umip: Identify the str and sldt instructions

The instructions STR and SLDT are not emulated in any case. Thus, it made sense to not implement functionality to identify them. However, a subsequent commit will introduce functionality to warn about the use of all the instructions that UMIP protect, not only those that are emulated. A first step

[RESEND PATCH v2 4/4] x86/umip: Warn if UMIP-protected instructions are used

Issue a rate-limited warning whenever any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR and SMSW) are used by user space programs. This is useful because, with UMIP enabled, the few programs that use such instructions will start receiving a SIGSEGV signal. In the specific

[RESEND PATCH v2 0/4] x86: Tweaks for UMIP

[To tip maintainers: This is a resend to copy the Linux kernel mailing list. No changes in the patches since my original v2 submission.] Now that the support for UMIP [1], [2] has been merged in the tip tree, this series add a couple of tweaks. Ingo asked for two small additions to select UMIP

[RESEND PATCH v2 1/4] x86/umip: Select X86_INTEL_UMIP by default

UMIP does not incur in a significant performance penalty. Furthermore, it is triggered only when a small group of instructions are used from user space programs. While here, provide more details on the benefits UMIP provides and the behavior that can expect the few applications that use the

  1   2   3   4   5   6   7   8   9   10   >