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

On Sun 12 Nov 06:21 PST 2017, Ramon Fried wrote: > 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

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

On Sun 12 Nov 06:21 PST 2017, Ramon Fried wrote: > 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. >

[GIT PULL] irqchip updates for 4.15, take 4

Hi Thomas, And when I thought we were done, they keep'em comming. Oh well. This time, one core fix for a regression introduced a while back that breaks platform that just don't have any firmware to tell us what the trigger configuration should be, and a handfull of GICv3/v4 fixes. Please pull.

[GIT PULL] irqchip updates for 4.15, take 4

Hi Thomas, And when I thought we were done, they keep'em comming. Oh well. This time, one core fix for a regression introduced a while back that breaks platform that just don't have any firmware to tell us what the trigger configuration should be, and a handfull of GICv3/v4 fixes. Please pull.

Re: [PATCH] mm: show stats for non-default hugepage sizes in /proc/meminfo

On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote: > On 11/13/2017 08:03 AM, Roman Gushchin wrote: > > To solve this problem, let's display stats for all hugepage sizes. > > To provide the backward compatibility let's save the existing format > > for the default size, and add a prefix

Re: [PATCH] mm: show stats for non-default hugepage sizes in /proc/meminfo

On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote: > On 11/13/2017 08:03 AM, Roman Gushchin wrote: > > To solve this problem, let's display stats for all hugepage sizes. > > To provide the backward compatibility let's save the existing format > > for the default size, and add a prefix

Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay?

On Mon, Nov 13, 2017 at 5:54 AM, Paolo Bonzini wrote: > On 28/10/2017 21:38, Andy Lutomirski wrote: >> We currently do this on boot: >> >> write_rdtscp_aux((node << 12) | cpu); >> >> This *sucks*. It means that, to very quickly obtain the CPU number >> using RDPID, an ALU op

Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay?

On Mon, Nov 13, 2017 at 5:54 AM, Paolo Bonzini wrote: > On 28/10/2017 21:38, Andy Lutomirski wrote: >> We currently do this on boot: >> >> write_rdtscp_aux((node << 12) | cpu); >> >> This *sucks*. It means that, to very quickly obtain the CPU number >> using RDPID, an ALU op is needed. It also

[PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper

Hi I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes deadlocks in device mapper when real time preemption is used. Mikulas From: Mikulas Patocka When some block device driver creates a bio and submits it to another block device driver, the bio is

[PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper

Hi I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes deadlocks in device mapper when real time preemption is used. Mikulas From: Mikulas Patocka When some block device driver creates a bio and submits it to another block device driver, the bio is added to

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 09:30:28AM -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 9:26 AM, Mark Brown wrote: > > Actually one other thing that just occurred to me is that they might be > > upset by the mails I send telling people I've applied their patches. If > >

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 09:30:28AM -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 9:26 AM, Mark Brown wrote: > > Actually one other thing that just occurred to me is that they might be > > upset by the mails I send telling people I've applied their patches. If > > that is the case I'm

Re: [PATCH IMPROVEMENT/BUGFIX 0/4] block, bfq: increase sustainable IOPS and fix a bug

On 11/12/2017 11:34 PM, Paolo Valente wrote: > Hi, > these patches address the following issue, raised and > discussed in [1]. > > BFQ provides a proportional share policy for the blkio controller. In > this respect, BFQ updates the I/O accounting related to its policy, > i.e., the statistics

Re: [PATCH IMPROVEMENT/BUGFIX 0/4] block, bfq: increase sustainable IOPS and fix a bug

On 11/12/2017 11:34 PM, Paolo Valente wrote: > Hi, > these patches address the following issue, raised and > discussed in [1]. > > BFQ provides a proportional share policy for the blkio controller. In > this respect, BFQ updates the I/O accounting related to its policy, > i.e., the statistics

Re: [PATCH v2 1/3] dt-bindings: phy: Add Cygnus usb phy binding

On Sun, Nov 12, 2017 at 10:23 PM, Raveendra Padasalagi wrote: > Hi, > > On Sat, Nov 11, 2017 at 3:14 AM, Rob Herring wrote: >> On Wed, Nov 08, 2017 at 01:16:41PM +0530, Raveendra Padasalagi wrote: >>> Add devicetree binding document for

Re: [PATCH v2 1/3] dt-bindings: phy: Add Cygnus usb phy binding

On Sun, Nov 12, 2017 at 10:23 PM, Raveendra Padasalagi wrote: > Hi, > > On Sat, Nov 11, 2017 at 3:14 AM, Rob Herring wrote: >> On Wed, Nov 08, 2017 at 01:16:41PM +0530, Raveendra Padasalagi wrote: >>> Add devicetree binding document for broadcom's >>> Cygnus SoC specific usb phy controller

Re: [PATCH 2/3] fpga: manager: don't use drvdata in common fpga code

On Tue, Oct 31, 2017 at 9:22 PM, Alan Tull wrote: Any further comments on v5? I'm getting ready to send v6. If I do it today, most of these patches will have no changes (again), the only changes will be in the patches that move drvdata out of the common code. I've gone to a

Re: [PATCH 2/3] fpga: manager: don't use drvdata in common fpga code

On Tue, Oct 31, 2017 at 9:22 PM, Alan Tull wrote: Any further comments on v5? I'm getting ready to send v6. If I do it today, most of these patches will have no changes (again), the only changes will be in the patches that move drvdata out of the common code. I've gone to a lot of trouble to

Allocation failure of ring buffer for trace

When using trace_buf_size= boot option, memory allocation of ring buffer for trace fails as follows: [ ] x86: Booting SMP configuration: [ ] node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 [ ]

Allocation failure of ring buffer for trace

When using trace_buf_size= boot option, memory allocation of ring buffer for trace fails as follows: [ ] x86: Booting SMP configuration: [ ] node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 [ ]

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 09:28:43AM -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 9:16 AM, Mark Brown wrote: > > Are you sure you're seeing stuff from sirena.org.uk and not > > sirena.co.uk? That's the envelope sender, I changed it after the last > > time this

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 09:28:43AM -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 9:16 AM, Mark Brown wrote: > > Are you sure you're seeing stuff from sirena.org.uk and not > > sirena.co.uk? That's the envelope sender, I changed it after the last > > time this happened to see if that

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

On Sat, Nov 11, 2017 at 02:32:40AM +, Alan Cox wrote: > > My assumption here is: > > 1) there are some less important and so security-insensitive firmwares, > >by which I mean that such firmwares won't be expected to be signed in > >terms of vulnerability or integrity. > >(I can't

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

On Sat, Nov 11, 2017 at 02:32:40AM +, Alan Cox wrote: > > My assumption here is: > > 1) there are some less important and so security-insensitive firmwares, > >by which I mean that such firmwares won't be expected to be signed in > >terms of vulnerability or integrity. > >(I can't

[PATCH] Documentation: sound: hd-audio: notes.rst

Fixed reference to file HD-Audio-Models.rst which has been moved to hd-audio/models.rst Signed-off-by: Chris Gorman --- Documentation/sound/hd-audio/notes.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/sound/hd-audio/notes.rst

[PATCH] Documentation: sound: hd-audio: notes.rst

Fixed reference to file HD-Audio-Models.rst which has been moved to hd-audio/models.rst Signed-off-by: Chris Gorman --- Documentation/sound/hd-audio/notes.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/sound/hd-audio/notes.rst

Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

You should Cc Nitesh who is working on a related feature. On Mon, Nov 13, 2017 at 06:34:48PM +0800, Wei Wang wrote: > Ping for comments, thanks. > > On 11/03/2017 04:13 PM, Wei Wang wrote: > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the > > support of reporting hints

Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

You should Cc Nitesh who is working on a related feature. On Mon, Nov 13, 2017 at 06:34:48PM +0800, Wei Wang wrote: > Ping for comments, thanks. > > On 11/03/2017 04:13 PM, Wei Wang wrote: > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the > > support of reporting hints

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 9:26 AM, Mark Brown wrote: > > Actually one other thing that just occurred to me is that they might be > upset by the mails I send telling people I've applied their patches. If > that is the case I'm really not sure what to do. If those people then

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 9:26 AM, Mark Brown wrote: > > Actually one other thing that just occurred to me is that they might be > upset by the mails I send telling people I've applied their patches. If > that is the case I'm really not sure what to do. If those people then mark you as spam, then

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 9:16 AM, Mark Brown wrote: > > Are you sure you're seeing stuff from sirena.org.uk and not > sirena.co.uk? That's the envelope sender, I changed it after the last > time this happened to see if that helped. The hosts it goes through are > still on

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 9:16 AM, Mark Brown wrote: > > Are you sure you're seeing stuff from sirena.org.uk and not > sirena.co.uk? That's the envelope sender, I changed it after the last > time this happened to see if that helped. The hosts it goes through are > still on .org.uk though. I'm

RE: [PATCH] PCI: keystone: fix interrupt-controller-node lookup

-Original Message- From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] Sent: Monday, November 13, 2017 5:43 AM To: Johan Hovold Cc: Karicheri, Muralidharan; Bjorn Helgaas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; stable Subject: Re: [PATCH] PCI: keystone: fix

RE: [PATCH] PCI: keystone: fix interrupt-controller-node lookup

-Original Message- From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] Sent: Monday, November 13, 2017 5:43 AM To: Johan Hovold Cc: Karicheri, Muralidharan; Bjorn Helgaas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; stable Subject: Re: [PATCH] PCI: keystone: fix

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 05:16:14PM +, Mark Brown wrote: > On Mon, Nov 13, 2017 at 08:34:26AM -0800, Linus Torvalds wrote: > > Maybe that makes gmail say "dodgy site"? I do not know, and am just > > throwing out possible random guesses. > I've deleted that A record, hopefully that'll help.

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 05:16:14PM +, Mark Brown wrote: > On Mon, Nov 13, 2017 at 08:34:26AM -0800, Linus Torvalds wrote: > > Maybe that makes gmail say "dodgy site"? I do not know, and am just > > throwing out possible random guesses. > I've deleted that A record, hopefully that'll help.

Re: Regression in Linux next-20171113 with fbdev timer conversion

On Monday, November 13, 2017 09:07:14 AM Tony Lindgren wrote: > Hi, Hi Tony, > Looks like next-20171113 now has a NULL pointe dereference with commit > 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()"). > > See the error below, any ideas? S

Re: Regression in Linux next-20171113 with fbdev timer conversion

On Monday, November 13, 2017 09:07:14 AM Tony Lindgren wrote: > Hi, Hi Tony, > Looks like next-20171113 now has a NULL pointe dereference with commit > 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()"). > > See the error below, any ideas? S

Re: [RFC] hv_netvsc: safer orderly shutdown

On Mon, 13 Nov 2017 11:57:47 +0100 Vitaly Kuznetsov wrote: > Stephen Hemminger writes: > > > > > The NAPI disable is already handled by rndis close. > > Sorry, but I'm probably missing something: I can only see > netif_napi_del() call in

Re: [RFC] hv_netvsc: safer orderly shutdown

On Mon, 13 Nov 2017 11:57:47 +0100 Vitaly Kuznetsov wrote: > Stephen Hemminger writes: > > > > > The NAPI disable is already handled by rndis close. > > Sorry, but I'm probably missing something: I can only see > netif_napi_del() call in netvsc_device_remove() but this happens much > later.

Re: [PATCH v2 08/16] iommu: introduce device fault data

On 13/11/17 16:57, Jacob Pan wrote: > On Mon, 13 Nov 2017 13:06:24 + > Jean-Philippe Brucker wrote: > >> On 10/11/17 22:18, Jacob Pan wrote: >>> On Fri, 10 Nov 2017 13:54:59 + >>> Jean-Philippe Brucker wrote: >>> On

Re: [PATCH v2 08/16] iommu: introduce device fault data

On 13/11/17 16:57, Jacob Pan wrote: > On Mon, 13 Nov 2017 13:06:24 + > Jean-Philippe Brucker wrote: > >> On 10/11/17 22:18, Jacob Pan wrote: >>> On Fri, 10 Nov 2017 13:54:59 + >>> Jean-Philippe Brucker wrote: >>> On 09/11/17 19:36, Jacob Pan wrote: > On Tue, 7 Nov 2017

Re: [PATCH] fbcon: Initialize ops->info early

On Monday, November 13, 2017 10:45:46 AM Thierry Reding wrote: > From: Thierry Reding > > During console takeover, which happens for all DRM/KMS setups using the > fbdev helpers, fbcon_startup() is called before fbcon_init() and as a > result con2fb_acquire_newinfo() will not

Re: [PATCH] fbcon: Initialize ops->info early

On Monday, November 13, 2017 10:45:46 AM Thierry Reding wrote: > From: Thierry Reding > > During console takeover, which happens for all DRM/KMS setups using the > fbdev helpers, fbcon_startup() is called before fbcon_init() and as a > result con2fb_acquire_newinfo() will not be called

Re: [PATCHv4 0/6] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On 10.11.2017 00:48, Sergey Senozhatsky wrote: All Ack-s/Tested-by-s were dropped, since the patch set has been reworked. I'm kindly asking arch-s maintainers and developers to test it once again. Sorry for any inconveniences and thanks for your help in advance. I tested it

Re: [PATCHv4 0/6] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On 10.11.2017 00:48, Sergey Senozhatsky wrote: All Ack-s/Tested-by-s were dropped, since the patch set has been reworked. I'm kindly asking arch-s maintainers and developers to test it once again. Sorry for any inconveniences and thanks for your help in advance. I tested it

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 08:34:26AM -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 4:32 AM, Mark Brown wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > > tags/regmap-v4.15 > All three of your pull requests were marked as spam by

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 08:34:26AM -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 4:32 AM, Mark Brown wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > > tags/regmap-v4.15 > All three of your pull requests were marked as spam by gmail. > I think it's

Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration

On Mon, Nov 13, 2017 at 8:56 AM, Mathieu Desnoyers wrote: > > I figured out what you're pointing to: if exec() is executed by a previously > running thread, and there is no core serializing instruction between program > load and return to user-space, the kernel

Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration

On Mon, Nov 13, 2017 at 8:56 AM, Mathieu Desnoyers wrote: > > I figured out what you're pointing to: if exec() is executed by a previously > running thread, and there is no core serializing instruction between program > load and return to user-space, the kernel ends up acting like a JIT, indeed.

Re: [PATCH] ARM: dts: keystone-k2l: Add the second gpio bank node

On 11/9/2017 3:42 AM, Keerthy wrote: In case of k2l there are 2 more banks with 16 pins each. Adding the node as the da-vinci driver now supports multiple banks. Signed-off-by: Keerthy --- This is based on linux-next branch. Boot tested on keystone-k2l-evm. Will pick this

Re: [PATCH] ARM: dts: keystone-k2l: Add the second gpio bank node

On 11/9/2017 3:42 AM, Keerthy wrote: In case of k2l there are 2 more banks with 16 pins each. Adding the node as the da-vinci driver now supports multiple banks. Signed-off-by: Keerthy --- This is based on linux-next branch. Boot tested on keystone-k2l-evm. Will pick this up Keerthy !!

Re: [PATCH v5 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers

On 11/10/2017 8:39 AM, Russell King - ARM Linux wrote: On Mon, Oct 16, 2017 at 08:31:59AM -0700, Santosh Shilimkar wrote: Hi Russell, On 10/13/2017 1:59 PM, Dave Gerlach wrote: Certain SoCs like Texas Instruments AM335x and AM437x require parts of the EMIF PM code to run late in the suspend

Re: [PATCH v5 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers

On 11/10/2017 8:39 AM, Russell King - ARM Linux wrote: On Mon, Oct 16, 2017 at 08:31:59AM -0700, Santosh Shilimkar wrote: Hi Russell, On 10/13/2017 1:59 PM, Dave Gerlach wrote: Certain SoCs like Texas Instruments AM335x and AM437x require parts of the EMIF PM code to run late in the suspend

Re: [PATCH] mm: show stats for non-default hugepage sizes in /proc/meminfo

On 11/13/2017 08:03 AM, Roman Gushchin wrote: > To solve this problem, let's display stats for all hugepage sizes. > To provide the backward compatibility let's save the existing format > for the default size, and add a prefix (e.g. 1G_) for non-default sizes. Is there something keeping you from

Regression in Linux next-20171113 with fbdev timer conversion

Hi, Looks like next-20171113 now has a NULL pointe dereference with commit 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()"). See the error below, any ideas? Regards, Tony 8< -- Unable to handle kernel NULL pointer dereference at virtual address

Re: [PATCH] mm: show stats for non-default hugepage sizes in /proc/meminfo

On 11/13/2017 08:03 AM, Roman Gushchin wrote: > To solve this problem, let's display stats for all hugepage sizes. > To provide the backward compatibility let's save the existing format > for the default size, and add a prefix (e.g. 1G_) for non-default sizes. Is there something keeping you from

Regression in Linux next-20171113 with fbdev timer conversion

Hi, Looks like next-20171113 now has a NULL pointe dereference with commit 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()"). See the error below, any ideas? Regards, Tony 8< -- Unable to handle kernel NULL pointer dereference at virtual address

Re: [RFC 4/7] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss

On 11/10/2017 08:05 PM, Andy Lutomirski wrote: > -struct tss_struct doublefault_tss __cacheline_aligned = { > - .x86_tss = { > - .sp0= STACK_START, > - .ss0= __KERNEL_DS, > - .ldt= 0, ... > +struct x86_hw_tss

Re: [RFC 4/7] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss

On 11/10/2017 08:05 PM, Andy Lutomirski wrote: > -struct tss_struct doublefault_tss __cacheline_aligned = { > - .x86_tss = { > - .sp0= STACK_START, > - .ss0= __KERNEL_DS, > - .ldt= 0, ... > +struct x86_hw_tss

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

On Mon, 13 Nov 2017, Kirill A. Shutemov wrote: > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote: > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote: > > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless > > > userspace explicitly asked for it. > > > >

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

On Mon, 13 Nov 2017, Kirill A. Shutemov wrote: > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote: > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote: > > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless > > > userspace explicitly asked for it. > > > >

Re: [PATCH v2 08/16] iommu: introduce device fault data

On Mon, 13 Nov 2017 13:06:24 + Jean-Philippe Brucker wrote: > On 10/11/17 22:18, Jacob Pan wrote: > > On Fri, 10 Nov 2017 13:54:59 + > > Jean-Philippe Brucker wrote: > > > >> On 09/11/17 19:36, Jacob Pan wrote: > >>> On

Re: [PATCH v2 08/16] iommu: introduce device fault data

On Mon, 13 Nov 2017 13:06:24 + Jean-Philippe Brucker wrote: > On 10/11/17 22:18, Jacob Pan wrote: > > On Fri, 10 Nov 2017 13:54:59 + > > Jean-Philippe Brucker wrote: > > > >> On 09/11/17 19:36, Jacob Pan wrote: > >>> On Tue, 7 Nov 2017 11:38:50 + > >>> Jean-Philippe Brucker

Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration

- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Nov 10, 2017, at 4:36 PM, Linus Torvalds > torva...@linux-foundation.org > wrote: > >> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers >> wrote: >>> x86 can

Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration

- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Nov 10, 2017, at 4:36 PM, Linus Torvalds > torva...@linux-foundation.org > wrote: > >> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers >> wrote: >>> x86 can return to user-space through

Re: [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device()

On Wed, 8 Nov 2017, Zhenzhong Duan wrote: > There is no way a timer used as broadcast clockevent device is also used as > percpu tick clockevent device currently. Correct. > It's better to put related code in tick_install_broadcast_device(), but I feel > it's harmless to give it back to the

Re: [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device()

On Wed, 8 Nov 2017, Zhenzhong Duan wrote: > There is no way a timer used as broadcast clockevent device is also used as > percpu tick clockevent device currently. Correct. > It's better to put related code in tick_install_broadcast_device(), but I feel > it's harmless to give it back to the

[PATCH 2/2] /proc/module: fix building without kallsyms

As reported by kernelci and other build bots, we now get a link failure without CONFIG_KALLSYMS: module.c:(.text+0xf2c): undefined reference to `kallsyms_show_value' This adds a dummy helper with the same name that can be used for compilation. It's not entirely clear to me what this should

[PATCH 2/2] /proc/module: fix building without kallsyms

As reported by kernelci and other build bots, we now get a link failure without CONFIG_KALLSYMS: module.c:(.text+0xf2c): undefined reference to `kallsyms_show_value' This adds a dummy helper with the same name that can be used for compilation. It's not entirely clear to me what this should

[PATCH 1/2] kallsyms: fix building without printk

Building kallsyms fails without CONFIG_PRINTK due to a missing declaration: kernel/kallsyms.c: In function 'kallsyms_show_value': kernel/kallsyms.c:670:10: error: 'kptr_restrict' undeclared (first use in this function); did you mean 'keyring_restrict'? This moves the declaration outside of the

[PATCH 1/2] kallsyms: fix building without printk

Building kallsyms fails without CONFIG_PRINTK due to a missing declaration: kernel/kallsyms.c: In function 'kallsyms_show_value': kernel/kallsyms.c:670:10: error: 'kptr_restrict' undeclared (first use in this function); did you mean 'keyring_restrict'? This moves the declaration outside of the

Re: [PATCH] arm64: mm: Set MAX_PHYSMEM_BITS based on ARM64_VA_BITS

On 13/11/17 12:56, Robin Murphy wrote: On 13/11/17 10:32, Suzuki K Poulose wrote: On 12/11/17 17:55, Jerome Glisse wrote: On Fri, Nov 10, 2017 at 03:11:15PM +, Robin Murphy wrote: On 09/11/17 22:58, Krishna Reddy wrote: MAX_PHYSMEM_BITS greater than ARM64_VA_BITS is causing memory access

Re: [PATCH] arm64: mm: Set MAX_PHYSMEM_BITS based on ARM64_VA_BITS

On 13/11/17 12:56, Robin Murphy wrote: On 13/11/17 10:32, Suzuki K Poulose wrote: On 12/11/17 17:55, Jerome Glisse wrote: On Fri, Nov 10, 2017 at 03:11:15PM +, Robin Murphy wrote: On 09/11/17 22:58, Krishna Reddy wrote: MAX_PHYSMEM_BITS greater than ARM64_VA_BITS is causing memory access

[PATCH] docs: dev-tools: coccinelle: delete out of date wiki reference

The wiki is no longer available. Signed-off-by: Julia Lawall --- diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 37e474f..94f41c2 100644 --- a/Documentation/dev-tools/coccinelle.rst +++

[PATCH] docs: dev-tools: coccinelle: delete out of date wiki reference

The wiki is no longer available. Signed-off-by: Julia Lawall --- diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 37e474f..94f41c2 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -33,9 +33,6

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

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: > > > >> The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of > >> "coccicheck failed" error

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

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: > > > >> The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of > >> "coccicheck failed" error messages. > >> > >> I do not

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

On Tue, 14 Nov 2017, Masahiro Yamada wrote: > Hi Julia, > > > 2017-11-11 16:30 GMT+09:00 Julia Lawall : > > > > > > On Fri, 10 Nov 2017, Julia Lawall wrote: > > > >> > >> > >> On Thu, 9 Nov 2017, Masahiro Yamada wrote: > >> > >> > The command "make -j8 C=1

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

On Tue, 14 Nov 2017, Masahiro Yamada wrote: > Hi Julia, > > > 2017-11-11 16:30 GMT+09:00 Julia Lawall : > > > > > > On Fri, 10 Nov 2017, Julia Lawall wrote: > > > >> > >> > >> On Thu, 9 Nov 2017, Masahiro Yamada wrote: > >> > >> > The command "make -j8 C=1 CHECK=scripts/coccicheck" produces

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote: > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote: > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless > > userspace explicitly asked for it. > > > > Userspace can ask for allocation from full address space

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote: > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote: > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless > > userspace explicitly asked for it. > > > > Userspace can ask for allocation from full address space

[tip:timers/urgent] timekeeping: Eliminate the stale declaration of ktime_get_raw_and_real_ts64()

Commit-ID: 8a7a8e1eab929eb3a5b735a788a23b9731139046 Gitweb: https://git.kernel.org/tip/8a7a8e1eab929eb3a5b735a788a23b9731139046 Author: Dou Liyang AuthorDate: Mon, 13 Nov 2017 13:49:04 +0800 Committer: Thomas Gleixner CommitDate: Mon, 13

[tip:timers/urgent] timekeeping: Eliminate the stale declaration of ktime_get_raw_and_real_ts64()

Commit-ID: 8a7a8e1eab929eb3a5b735a788a23b9731139046 Gitweb: https://git.kernel.org/tip/8a7a8e1eab929eb3a5b735a788a23b9731139046 Author: Dou Liyang AuthorDate: Mon, 13 Nov 2017 13:49:04 +0800 Committer: Thomas Gleixner CommitDate: Mon, 13 Nov 2017 17:35:27 +0100 timekeeping: Eliminate

Re: [PATCH] mm: show stats for non-default hugepage sizes in /proc/meminfo

On Mon, Nov 13, 2017 at 05:11:02PM +0100, Michal Hocko wrote: > On Mon 13-11-17 16:03:02, Roman Gushchin wrote: > > Currently we display some hugepage statistics (total, free, etc) > > in /proc/meminfo, but only for default hugepage size (e.g. 2Mb). > > > > If hugepages of different sizes are

Re: [PATCH] mm: show stats for non-default hugepage sizes in /proc/meminfo

On Mon, Nov 13, 2017 at 05:11:02PM +0100, Michal Hocko wrote: > On Mon 13-11-17 16:03:02, Roman Gushchin wrote: > > Currently we display some hugepage statistics (total, free, etc) > > in /proc/meminfo, but only for default hugepage size (e.g. 2Mb). > > > > If hugepages of different sizes are

Re: linux-next: Tree for Nov 7

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: Mon Nov 13 17:06:24 2017 +0100 mm: introduce

Re: linux-next: Tree for Nov 7

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: Mon Nov 13 17:06:24 2017 +0100 mm: introduce MAP_FIXED_SAFE

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 8:34 AM, Linus Torvalds wrote: > > I'll add you explicitly as a contact, but if I see issues, others will too. Oh, I had already done that, and gmail thought you were spam anyway. You've really pissed off the email gods.

Re: [GIT PULL] regmap updates for v4.15

On Mon, Nov 13, 2017 at 8:34 AM, Linus Torvalds wrote: > > I'll add you explicitly as a contact, but if I see issues, others will too. Oh, I had already done that, and gmail thought you were spam anyway. You've really pissed off the email gods. Linus

Re: [GIT PULL] regmap updates for v4.15

Mark, On Mon, Nov 13, 2017 at 4:32 AM, Mark Brown wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > tags/regmap-v4.15 All three of your pull requests were marked as spam by gmail. I think it's the sirena.org.uk thing that triggers it,

Re: [GIT PULL] regmap updates for v4.15

Mark, On Mon, Nov 13, 2017 at 4:32 AM, Mark Brown wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > tags/regmap-v4.15 All three of your pull requests were marked as spam by gmail. I think it's the sirena.org.uk thing that triggers it, possibly made worse by the

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

Hi Julia, 2017-11-14 0:30 GMT+09:00 Julia Lawall : > > > On Thu, 9 Nov 2017, Masahiro Yamada wrote: > >> The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of >> "coccicheck failed" error messages. >> >> I do not know the coccinelle internals, but I guess

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

Hi Julia, 2017-11-14 0:30 GMT+09:00 Julia Lawall : > > > On Thu, 9 Nov 2017, Masahiro Yamada wrote: > >> The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of >> "coccicheck failed" error messages. >> >> I do not know the coccinelle internals, but I guess --jobs does not >> work

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

Hi Julia, 2017-11-11 16:30 GMT+09:00 Julia Lawall : > > > On Fri, 10 Nov 2017, Julia Lawall wrote: > >> >> >> On Thu, 9 Nov 2017, Masahiro Yamada wrote: >> >> > The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of >> > "coccicheck failed" error messages. >>

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

Hi Julia, 2017-11-11 16:30 GMT+09:00 Julia Lawall : > > > On Fri, 10 Nov 2017, Julia Lawall wrote: > >> >> >> On Thu, 9 Nov 2017, Masahiro Yamada wrote: >> >> > The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of >> > "coccicheck failed" error messages. >> >> The question is

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

On 30/10/2017 23:05, Luwei Kang wrote: > + 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 &=

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

On 30/10/2017 23:05, Luwei Kang wrote: > + 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 &=

[GIT PULL] afs: Filesystem driver overhaul

git/dhowells/linux-fs.git tags/afs-next-20171113 for you to fetch changes up to 98bf40cd99fcfed0705812b6cbdbb3b441a42970: afs: Protect call->state changes against signals (2017-11-13 15:38:21 +) AFS devel

[GIT PULL] afs: Filesystem driver overhaul

git/dhowells/linux-fs.git tags/afs-next-20171113 for you to fetch changes up to 98bf40cd99fcfed0705812b6cbdbb3b441a42970: afs: Protect call->state changes against signals (2017-11-13 15:38:21 +) AFS devel

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