Re: [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

On 04/02/2018 02:26 PM, Lyude Paul wrote: While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to

Re: [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

On 04/02/2018 02:26 PM, Lyude Paul wrote: While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to

Re: [PATCH] dlm: prompt the user SCTP is experimental

Hi David, >>> > On Thu, Mar 22, 2018 at 10:27:56PM -0600, Gang He wrote: >> Hello David, >> >> Do you agree to add this prompt to the user? >> Since sometimes customers attempted to setup SCTP protocol with two rings, >> but they could not get the expected result, then it maybe bring some

Re: [PATCH] dlm: prompt the user SCTP is experimental

Hi David, >>> > On Thu, Mar 22, 2018 at 10:27:56PM -0600, Gang He wrote: >> Hello David, >> >> Do you agree to add this prompt to the user? >> Since sometimes customers attempted to setup SCTP protocol with two rings, >> but they could not get the expected result, then it maybe bring some

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

Hi all, Today's linux-next merge of the pci tree got a conflict in: drivers/bus/Makefile between commit: 1888d3ddc3d6 ("drivers/bus: Move Arm CCN PMU driver") from the arm-soc tree and commit: 38e3446c5d06 ("HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings") from the

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

Hi all, Today's linux-next merge of the pci tree got a conflict in: drivers/bus/Makefile between commit: 1888d3ddc3d6 ("drivers/bus: Move Arm CCN PMU driver") from the arm-soc tree and commit: 38e3446c5d06 ("HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings") from the

WARNING: bad unlock balance in xfs_iunlock

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

WARNING in up_write

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

WARNING in up_write

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

WARNING: bad unlock balance in xfs_iunlock

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

Re: [GIT PULL] EFI updates for v4.17

On Mon, Apr 2, 2018 at 3:41 AM, Ingo Molnar wrote: > > - Use efi_switch_mm() on x86 instead of manipulating %cr3 directly This seems to cause new warnings, both on my laptop and my desktop. I'm surprised you don't see them. Looks like this: WARNING: CPU: 0 PID: 0 at

Re: [GIT PULL] EFI updates for v4.17

On Mon, Apr 2, 2018 at 3:41 AM, Ingo Molnar wrote: > > - Use efi_switch_mm() on x86 instead of manipulating %cr3 directly This seems to cause new warnings, both on my laptop and my desktop. I'm surprised you don't see them. Looks like this: WARNING: CPU: 0 PID: 0 at

Read and Respond Quickly

I am a banker and am writing you today in full confidence, i want to know if you have a valid bank account that can accept millions of US Dollars. If you do, respond quickly so that i can intimate you on this deal that is absolutely risk-free but highly secret. It is only between me and you. No

Read and Respond Quickly

I am a banker and am writing you today in full confidence, i want to know if you have a valid bank account that can accept millions of US Dollars. If you do, respond quickly so that i can intimate you on this deal that is absolutely risk-free but highly secret. It is only between me and you. No

Re: [PATCH v4 04/24] fpga: add device feature list support

On Mon, Apr 02, 2018 at 02:06:56PM -0500, Alan Tull wrote: > On Sun, Apr 1, 2018 at 11:22 PM, Wu Hao wrote: > > On Thu, Mar 29, 2018 at 04:57:22PM -0500, Alan Tull wrote: > >> On Mon, Mar 26, 2018 at 9:35 PM, Wu Hao wrote: > >> > >> Hi Hao, > >> > >> Currently

Re: [GIT PULL] Kernel lockdown for secure boot

> On Apr 2, 2018, at 5:59 PM, Kees Cook wrote: > >> On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski wrote: >>> On 03/30/2018 05:46 PM, James Morris wrote: >>> On Sat, 31 Mar 2018, David Howells wrote: Date: Thu, 26 Oct 2017 17:37:38

Re: [PATCH v4 04/24] fpga: add device feature list support

On Mon, Apr 02, 2018 at 02:06:56PM -0500, Alan Tull wrote: > On Sun, Apr 1, 2018 at 11:22 PM, Wu Hao wrote: > > On Thu, Mar 29, 2018 at 04:57:22PM -0500, Alan Tull wrote: > >> On Mon, Mar 26, 2018 at 9:35 PM, Wu Hao wrote: > >> > >> Hi Hao, > >> > >> Currently there is one set of functions that

Re: [GIT PULL] Kernel lockdown for secure boot

> On Apr 2, 2018, at 5:59 PM, Kees Cook wrote: > >> On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski wrote: >>> On 03/30/2018 05:46 PM, James Morris wrote: >>> On Sat, 31 Mar 2018, David Howells wrote: Date: Thu, 26 Oct 2017 17:37:38 +0100 Hi James, Can

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Mon, Apr 02, 2018 at 12:32:44AM +, Sasha Levin wrote: > On Sun, Apr 01, 2018 at 08:02:45AM +1000, Dave Chinner wrote: > >On Fri, Mar 30, 2018 at 02:47:05AM +, Sasha Levin wrote: > >> On Thu, Mar 29, 2018 at 10:05:35AM +1100, Dave Chinner wrote: > >> >On Wed, Mar 28, 2018 at 07:30:06PM

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Mon, Apr 02, 2018 at 12:32:44AM +, Sasha Levin wrote: > On Sun, Apr 01, 2018 at 08:02:45AM +1000, Dave Chinner wrote: > >On Fri, Mar 30, 2018 at 02:47:05AM +, Sasha Levin wrote: > >> On Thu, Mar 29, 2018 at 10:05:35AM +1100, Dave Chinner wrote: > >> >On Wed, Mar 28, 2018 at 07:30:06PM

Re: [PATCH v2 71/75] staging: ks7010: Remove dummy address set.

On Sat, Mar 31, 2018 at 11:46:40AM +0300, Dan Carpenter wrote: > On Fri, Mar 30, 2018 at 11:08:51PM -0700, Quytelda Kahja wrote: > > Setting a dummy address during the driver probe is not necessary. > > The dev_addr field is already zeroed out from alloc_etherdev(). > > > > Signed-off-by:

Re: [PATCH v2 71/75] staging: ks7010: Remove dummy address set.

On Sat, Mar 31, 2018 at 11:46:40AM +0300, Dan Carpenter wrote: > On Fri, Mar 30, 2018 at 11:08:51PM -0700, Quytelda Kahja wrote: > > Setting a dummy address during the driver probe is not necessary. > > The dev_addr field is already zeroed out from alloc_etherdev(). > > > > Signed-off-by:

Re: [PATCH v2 1/2] perf: riscv: preliminary RISC-V support

This works for cycle and instruction counts. Alex On Mon, Apr 2, 2018 at 5:31 AM, Alan Kao wrote: > > This patch provide a basic PMU, riscv_base_pmu, which supports two > general hardware event, instructions and cycles. Furthermore, this > PMU serves as a reference

Re: [PATCH v2 1/2] perf: riscv: preliminary RISC-V support

This works for cycle and instruction counts. Alex On Mon, Apr 2, 2018 at 5:31 AM, Alan Kao wrote: > > This patch provide a basic PMU, riscv_base_pmu, which supports two > general hardware event, instructions and cycles. Furthermore, this > PMU serves as a reference implementation to ease the

[PATCH i2c/slave-mqueue v4] i2c: slave-mqueue: add a slave backend to receive and queue messages

Some protocols over I2C are designed for bi-directional transferring messages by using I2C Master Write protocol. Like the MCTP (Management Component Transport Protocol) and IPMB (Intelligent Platform Management Bus), they both require that the userspace can receive messages from I2C dirvers under

[PATCH i2c/slave-mqueue v4] i2c: slave-mqueue: add a slave backend to receive and queue messages

Some protocols over I2C are designed for bi-directional transferring messages by using I2C Master Write protocol. Like the MCTP (Management Component Transport Protocol) and IPMB (Intelligent Platform Management Bus), they both require that the userspace can receive messages from I2C dirvers under

Looking for way to program external MMU from userspace (or viable alternative)

Hi kernel community, We have an external PCIe board with a custom coprocessor on it. We also have code for a kernel driver for it. We have thought about upstreaming it, but we realized that we can instead convert the driver to a userspace driver using UIO. However, there's one aspect of the

Looking for way to program external MMU from userspace (or viable alternative)

Hi kernel community, We have an external PCIe board with a custom coprocessor on it. We also have code for a kernel driver for it. We have thought about upstreaming it, but we realized that we can instead convert the driver to a userspace driver using UIO. However, there's one aspect of the

Re: [GIT PULL] x86/build changes for v4.17

El Mon, Apr 02, 2018 at 03:38:21PM -0700 Matthias Kaehlcke ha dit: > El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > >

Re: [GIT PULL] x86/build changes for v4.17

El Mon, Apr 02, 2018 at 03:38:21PM -0700 Matthias Kaehlcke ha dit: > El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > > effectively > > >

Re: [PATCH v4 4/6] perf version: Print the compiled-in status of libraries

On 4/3/2018 12:47 AM, Arnaldo Carvalho de Melo wrote: Em Fri, Mar 30, 2018 at 05:27:14PM +0800, Jin Yao escreveu: This patch checks the values passed by CFLAGS (-DHAVE_XXX) and then print the status of libraries. For example, if HAVE_DWARF_SUPPORT is defined, that means the library "dwarf"

Re: [PATCH v4 4/6] perf version: Print the compiled-in status of libraries

On 4/3/2018 12:47 AM, Arnaldo Carvalho de Melo wrote: Em Fri, Mar 30, 2018 at 05:27:14PM +0800, Jin Yao escreveu: This patch checks the values passed by CFLAGS (-DHAVE_XXX) and then print the status of libraries. For example, if HAVE_DWARF_SUPPORT is defined, that means the library "dwarf"

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

[+Cc Lorenzo] Hi Neil, On 2018/4/3 1:59, Neil Leeder wrote: > Hi Hanjun, > > On 4/2/2018 10:24 AM, Hanjun Guo wrote: > >> >> I think we need to wait for the new version of IORT spec, >> which includes the fix for the two base address for SMMUv3 >> PMCG (now just represent one). >> >> Thanks >>

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

[+Cc Lorenzo] Hi Neil, On 2018/4/3 1:59, Neil Leeder wrote: > Hi Hanjun, > > On 4/2/2018 10:24 AM, Hanjun Guo wrote: > >> >> I think we need to wait for the new version of IORT spec, >> which includes the fix for the two base address for SMMUv3 >> PMCG (now just represent one). >> >> Thanks >>

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On (04/02/18 17:15), Andy Shevchenko wrote: > > > > Hmm, I have never seen the error code in this form. > > We have limited space to print it and error numbers currently can be up > to 0xfff (4095). So, I have no better idea how to squeeze them while > thinking that "(efault)" is much harder to

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On (04/02/18 17:15), Andy Shevchenko wrote: > > > > Hmm, I have never seen the error code in this form. > > We have limited space to print it and error numbers currently can be up > to 0xfff (4095). So, I have no better idea how to squeeze them while > thinking that "(efault)" is much harder to

Re: [GIT PULL] Kernel lockdown for secure boot

On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski wrote: > On 03/30/2018 05:46 PM, James Morris wrote: >> >> On Sat, 31 Mar 2018, David Howells wrote: >> >>> Date: Thu, 26 Oct 2017 17:37:38 +0100 >>> >>> Hi James, >>> >>> Can you pull this patchset into security/next please? It

Re: [GIT PULL] Kernel lockdown for secure boot

On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski wrote: > On 03/30/2018 05:46 PM, James Morris wrote: >> >> On Sat, 31 Mar 2018, David Howells wrote: >> >>> Date: Thu, 26 Oct 2017 17:37:38 +0100 >>> >>> Hi James, >>> >>> Can you pull this patchset into security/next please? It has been in >>>

Re: [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs

On 04/02/2018 04:17 PM, Kirill Marinushkin wrote: Hello Pierre-Louis, I explicitly clarified with Takashi: to have this patch series merged, we need a tag "Reviewed-by" from you. I am fine with the changes, but maybe while we are at it, we should clarify what mclk_direction means?     __u8

Re: [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs

On 04/02/2018 04:17 PM, Kirill Marinushkin wrote: Hello Pierre-Louis, I explicitly clarified with Takashi: to have this patch series merged, we need a tag "Reviewed-by" from you. I am fine with the changes, but maybe while we are at it, we should clarify what mclk_direction means?     __u8

Re: [PATCH] Input: synaptics-rmi4 - Fix an unchecked out of memory error path

On 04/02/2018 07:03 AM, Christophe JAILLET wrote: When extending the rmi_spi buffers, we must check that no out of memory error occurs, otherwise we may access data above the currently allocated memory. Propagate the error code returned by 'rmi_spi_manage_pools()' instead. Yep, that

Re: [PATCH] Input: synaptics-rmi4 - Fix an unchecked out of memory error path

On 04/02/2018 07:03 AM, Christophe JAILLET wrote: When extending the rmi_spi buffers, we must check that no out of memory error occurs, otherwise we may access data above the currently allocated memory. Propagate the error code returned by 'rmi_spi_manage_pools()' instead. Yep, that

Re: [PATCH v7] fs: Add VirtualBox guest shared folder (vboxsf) support

Hi Hans, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16 next-20180329] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v7] fs: Add VirtualBox guest shared folder (vboxsf) support

Hi Hans, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16 next-20180329] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On 11/10/2017 01:02 PM, Mimi Zohar wrote: If the kernel is locked down and IMA-appraisal is not enabled, prevent loading of unsigned firmware. diff --git a/security/fw_lockdown/Kconfig b/security/fw_lockdown/Kconfig new file mode 100644 index ..d6aef6ce8fee --- /dev/null +++

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On 11/10/2017 01:02 PM, Mimi Zohar wrote: If the kernel is locked down and IMA-appraisal is not enabled, prevent loading of unsigned firmware. diff --git a/security/fw_lockdown/Kconfig b/security/fw_lockdown/Kconfig new file mode 100644 index ..d6aef6ce8fee --- /dev/null +++

Re: [GIT PULL] Kernel lockdown for secure boot

On 03/30/2018 05:46 PM, James Morris wrote: On Sat, 31 Mar 2018, David Howells wrote: Date: Thu, 26 Oct 2017 17:37:38 +0100 Hi James, Can you pull this patchset into security/next please? It has been in linux-next since the beginning of March. It adds kernel lockdown support for EFI secure

Re: [GIT PULL] Kernel lockdown for secure boot

On 03/30/2018 05:46 PM, James Morris wrote: On Sat, 31 Mar 2018, David Howells wrote: Date: Thu, 26 Oct 2017 17:37:38 +0100 Hi James, Can you pull this patchset into security/next please? It has been in linux-next since the beginning of March. It adds kernel lockdown support for EFI secure

Re: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth

On Mon, Apr 2, 2018 at 7:05 AM, Bjorn Helgaas wrote: > +/* PCIe speed to Mb/s reduced by encoding overhead */ > +#define PCIE_SPEED2MBS_ENC(speed) \ > + ((speed) == PCIE_SPEED_16_0GT ? (16000*(128/130)) : \ > +(speed) == PCIE_SPEED_8_0GT ? (8000*(128/130)) : \

Re: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth

On Mon, Apr 2, 2018 at 7:05 AM, Bjorn Helgaas wrote: > +/* PCIe speed to Mb/s reduced by encoding overhead */ > +#define PCIE_SPEED2MBS_ENC(speed) \ > + ((speed) == PCIE_SPEED_16_0GT ? (16000*(128/130)) : \ > +(speed) == PCIE_SPEED_8_0GT ? (8000*(128/130)) : \ > +(speed)

Re: [PATCH v3 1/5] mm: page_alloc: remain memblock_next_valid_pfn() when CONFIG_HAVE_ARCH_PFN_VALID is enable

On Mon, Apr 02, 2018 at 05:17:35PM +0800, Jia He wrote: > > >On 4/2/2018 4:12 PM, Wei Yang Wrote: >> On Wed, Mar 28, 2018 at 05:49:23PM +0800, Jia He wrote: >> > >> > On 3/28/2018 5:18 PM, Wei Yang Wrote: >> > > Oops, I should reply this thread. Forget about the reply on another >> > > thread.

Re: [PATCH v3 1/5] mm: page_alloc: remain memblock_next_valid_pfn() when CONFIG_HAVE_ARCH_PFN_VALID is enable

On Mon, Apr 02, 2018 at 05:17:35PM +0800, Jia He wrote: > > >On 4/2/2018 4:12 PM, Wei Yang Wrote: >> On Wed, Mar 28, 2018 at 05:49:23PM +0800, Jia He wrote: >> > >> > On 3/28/2018 5:18 PM, Wei Yang Wrote: >> > > Oops, I should reply this thread. Forget about the reply on another >> > > thread.

Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock

On Tue, 13 Mar 2018, Laurent Dufour wrote: > This change is inspired by the Peter's proposal patch [1] which was > protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in > that particular case, and it is introducing major performance degradation > due to excessive scheduling

Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock

On Tue, 13 Mar 2018, Laurent Dufour wrote: > This change is inspired by the Peter's proposal patch [1] which was > protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in > that particular case, and it is introducing major performance degradation > due to excessive scheduling

kernel BUG at fs/hfs/inode.c:LINE!

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

kernel BUG at fs/hfs/inode.c:LINE!

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

Re: [PATCH v9 16/24] mm: Introduce __page_add_new_anon_rmap()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > When dealing with speculative page fault handler, we may race with VMA > being split or merged. In this case the vma->vm_start and vm->vm_end > fields may not match the address the page fault is occurring. > > This can only happens when the VMA is

Re: [PATCH v9 16/24] mm: Introduce __page_add_new_anon_rmap()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > When dealing with speculative page fault handler, we may race with VMA > being split or merged. In this case the vma->vm_start and vm->vm_end > fields may not match the address the page fault is occurring. > > This can only happens when the VMA is

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds wrote: > > We should probably have at least switched it to "unsigned long int" I meant just "unsigned int", of course. Right now we occasionally have a silly 64-bit field just for a couple of flags. Of course, we do

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds wrote: > > We should probably have at least switched it to "unsigned long int" I meant just "unsigned int", of course. Right now we occasionally have a silly 64-bit field just for a couple of flags. Of course, we do have cases where 64-bit

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

Hi All, On Mon, 19 Mar 2018 14:06:57 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/bus/arm-cci.c > > between commit: > > 3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver") > > from the arm-soc tree and

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

Hi All, On Mon, 19 Mar 2018 14:06:57 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/bus/arm-cci.c > > between commit: > > 3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver") > > from the arm-soc tree and commit: > >

Re: [PATCH] autofs4: use wake_up() instead of wake_up_interruptible

On 01/04/18 14:21, Andrei Vagin wrote: > On Sun, Apr 01, 2018 at 10:01:41AM +0800, Ian Kent wrote: >> On 01/04/18 09:31, Ian Kent wrote: >>> On 31/03/18 10:28, Andrei Vagin wrote: In "autofs4: use wait_event_killable", wait_event_interruptible() was replaced by wait_event_killable(),

Re: [PATCH] autofs4: use wake_up() instead of wake_up_interruptible

On 01/04/18 14:21, Andrei Vagin wrote: > On Sun, Apr 01, 2018 at 10:01:41AM +0800, Ian Kent wrote: >> On 01/04/18 09:31, Ian Kent wrote: >>> On 31/03/18 10:28, Andrei Vagin wrote: In "autofs4: use wait_event_killable", wait_event_interruptible() was replaced by wait_event_killable(),

RE: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

> kernel unaligned access to 0xe0031660fd74, ip=0xa001000f23e0 > kernel unaligned access to 0xe0033bdffbcc, ip=0xa001000f2370 Here's the disassembly of dequeu_task_fair() in case it would help to see which two instructions are getting all the faults: a001000f21c0 :

RE: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

> kernel unaligned access to 0xe0031660fd74, ip=0xa001000f23e0 > kernel unaligned access to 0xe0033bdffbcc, ip=0xa001000f2370 Here's the disassembly of dequeu_task_fair() in case it would help to see which two instructions are getting all the faults: a001000f21c0 :

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 2, 2018 at 3:58 PM, Omar Sandoval wrote: > > Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}() > which uses memset() when the start and length are constants aligned to a > byte. This is wrong on big-endian systems; Ugh, yes. In retrospect, I

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 2, 2018 at 3:58 PM, Omar Sandoval wrote: > > Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}() > which uses memset() when the start and length are constants aligned to a > byte. This is wrong on big-endian systems; Ugh, yes. In retrospect, I do wish I had just

v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

v4.16 boots cleanly. But with the first bunch of merges (Linus HEAD = 46e0d28bdb8e6d00e27a0fe9e1d15df6098f0ffb) I see a bunch of: ia64_handle_unaligned: 4863 callbacks suppressed kernel unaligned access to 0xe0031660fd74, ip=0xa001000f23e0 kernel unaligned access to 0xe0033bdffbcc,

v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

v4.16 boots cleanly. But with the first bunch of merges (Linus HEAD = 46e0d28bdb8e6d00e27a0fe9e1d15df6098f0ffb) I see a bunch of: ia64_handle_unaligned: 4863 callbacks suppressed kernel unaligned access to 0xe0031660fd74, ip=0xa001000f23e0 kernel unaligned access to 0xe0033bdffbcc,

[PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

We would be passing 0 instead of NULL as the rsp argument to mt7530_fdb_cmd(), fix that. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Florian Fainelli --- drivers/net/dsa/mt7530.c | 6 +++--- 1 file changed, 3

[PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

We would be passing 0 instead of NULL as the rsp argument to mt7530_fdb_cmd(), fix that. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Florian Fainelli --- drivers/net/dsa/mt7530.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

linux-next: manual merge of the asm-generic tree with Linus' tree

Hi Arnd, Today's linux-next merge of the asm-generic tree got a conflict in: lib/Kconfig.debug between commits: f07cbebb6daf ("locking/Kconfig: Add LOCK_DEBUGGING_SUPPORT to make it more readable") 19193bcad8dc ("locking/Kconfig: Restructure the lock debugging menu") from Linus' tree

linux-next: manual merge of the asm-generic tree with Linus' tree

Hi Arnd, Today's linux-next merge of the asm-generic tree got a conflict in: lib/Kconfig.debug between commits: f07cbebb6daf ("locking/Kconfig: Add LOCK_DEBUGGING_SUPPORT to make it more readable") 19193bcad8dc ("locking/Kconfig: Restructure the lock debugging menu") from Linus' tree

Re: [Intel-gfx] [PATCH v5 04/10] drm/dp_mst: Remove all evil duplicate state pointers

On Mon, 2018-04-02 at 18:47 -0400, Lyude Paul wrote: > There's no reason to track the atomic state three times. Unfortunately, > this is currently what we're doing, and even worse is that there is only > one actually correct state pointer: the one in mst_state->base.state. > mgr->state never seems

Re: [Intel-gfx] [PATCH v5 04/10] drm/dp_mst: Remove all evil duplicate state pointers

On Mon, 2018-04-02 at 18:47 -0400, Lyude Paul wrote: > There's no reason to track the atomic state three times. Unfortunately, > this is currently what we're doing, and even worse is that there is only > one actually correct state pointer: the one in mst_state->base.state. > mgr->state never seems

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote: > Just like with PCI options ROMs, which we save in the setup_efi_pci* > functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself > sometimes may contain data which is useful/necessary for peripheral drivers > to have

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote: > Just like with PCI options ROMs, which we save in the setup_efi_pci* > functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself > sometimes may contain data which is useful/necessary for peripheral drivers > to have

Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index a84ddc218bbd..73b8b99f482b 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1263,8 +1263,11 @@ struct zap_details { > pgoff_t last_index; /*

Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index a84ddc218bbd..73b8b99f482b 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1263,8 +1263,11 @@ struct zap_details { > pgoff_t last_index; /*

[PATCH net] net: dsa: b53: Fix sparse warnings in b53_mmap.c

sparse complains about the following warnings: drivers/net/dsa/b53/b53_mmap.c:33:31: warning: incorrect type in initializer (different address spaces) drivers/net/dsa/b53/b53_mmap.c:33:31:expected unsigned char [noderef] [usertype] *regs drivers/net/dsa/b53/b53_mmap.c:33:31:got void *priv

[PATCH net] net: dsa: b53: Fix sparse warnings in b53_mmap.c

sparse complains about the following warnings: drivers/net/dsa/b53/b53_mmap.c:33:31: warning: incorrect type in initializer (different address spaces) drivers/net/dsa/b53/b53_mmap.c:33:31:expected unsigned char [noderef] [usertype] *regs drivers/net/dsa/b53/b53_mmap.c:33:31:got void *priv

Re: [PATCH v9 14/24] mm: Introduce __maybe_mkwrite()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index dfa81a638b7c..a84ddc218bbd 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -684,13 +684,18 @@ void free_compound_page(struct page *page); > * pte_mkwrite. But

Re: [PATCH v9 14/24] mm: Introduce __maybe_mkwrite()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index dfa81a638b7c..a84ddc218bbd 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -684,13 +684,18 @@ void free_compound_page(struct page *page); > * pte_mkwrite. But

Re: [PATCH v9 13/24] mm: Introduce __lru_cache_add_active_or_unevictable

On Tue, 13 Mar 2018, Laurent Dufour wrote: > The speculative page fault handler which is run without holding the > mmap_sem is calling lru_cache_add_active_or_unevictable() but the vm_flags > is not guaranteed to remain constant. > Introducing __lru_cache_add_active_or_unevictable() which has the

Re: [PATCH v9 13/24] mm: Introduce __lru_cache_add_active_or_unevictable

On Tue, 13 Mar 2018, Laurent Dufour wrote: > The speculative page fault handler which is run without holding the > mmap_sem is calling lru_cache_add_active_or_unevictable() but the vm_flags > is not guaranteed to remain constant. > Introducing __lru_cache_add_active_or_unevictable() which has the

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 02, 2018 at 03:58:31PM -0700, Omar Sandoval wrote: > From: Omar Sandoval > > Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}() > which uses memset() when the start and length are constants aligned to a > byte. This is wrong on big-endian systems;

Re: [PATCH v9 12/24] mm/migrate: Pass vm_fault pointer to migrate_misplaced_page()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > migrate_misplaced_page() is only called during the page fault handling so > it's better to pass the pointer to the struct vm_fault instead of the vma. > > This way during the speculative page fault path the saved vma->vm_flags > could be used. > >

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

syzbot writes: > Hello, > > syzbot hit the following crash on upstream commit > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +) > Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client > syzbot dashboard

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 02, 2018 at 03:58:31PM -0700, Omar Sandoval wrote: > From: Omar Sandoval > > Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}() > which uses memset() when the start and length are constants aligned to a > byte. This is wrong on big-endian systems; our bitmaps are

Re: [PATCH v9 12/24] mm/migrate: Pass vm_fault pointer to migrate_misplaced_page()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > migrate_misplaced_page() is only called during the page fault handling so > it's better to pass the pointer to the struct vm_fault instead of the vma. > > This way during the speculative page fault path the saved vma->vm_flags > could be used. > >

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

syzbot writes: > Hello, > > syzbot hit the following crash on upstream commit > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +) > Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client > syzbot dashboard link: >

[PATCH net 0/2] net: Broadcom drivers sparse fixes

Hi all, This patch series fixes the same warning reported by sparse in bcmsysport and bcmgenet in the code that deals with inserting the TX checksum pointers: drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: warning: cast from restricted __be16

[PATCH net 0/2] net: Broadcom drivers sparse fixes

Hi all, This patch series fixes the same warning reported by sparse in bcmsysport and bcmgenet in the code that deals with inserting the TX checksum pointers: drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: warning: cast from restricted __be16

[PATCH net 2/2] net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb()

skb->protocol is a __be16 which we would be calling htons() against, while this is not wrong per-se as it correctly results in swapping the value on LE hosts, this still upsets sparse. Adopt a similar pattern to what other drivers do and just assign ip_ver to skb->protocol, and then use htons()

[PATCH net 2/2] net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb()

skb->protocol is a __be16 which we would be calling htons() against, while this is not wrong per-se as it correctly results in swapping the value on LE hosts, this still upsets sparse. Adopt a similar pattern to what other drivers do and just assign ip_ver to skb->protocol, and then use htons()

[PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

skb->protocol is a __be16 which we would be calling htons() against, while this is not wrong per-se as it correctly results in swapping the value on LE hosts, this still upsets sparse. Adopt a similar pattern to what other drivers do and just assign ip_ver to skb->protocol, and then use htons()

[PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

skb->protocol is a __be16 which we would be calling htons() against, while this is not wrong per-se as it correctly results in swapping the value on LE hosts, this still upsets sparse. Adopt a similar pattern to what other drivers do and just assign ip_ver to skb->protocol, and then use htons()

[PATCH] bitmap: fix memset optimization on big-endian systems

From: Omar Sandoval Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}() which uses memset() when the start and length are constants aligned to a byte. This is wrong on big-endian systems; our bitmaps are arrays of unsigned long, so bit n is not at byte n / 8 in

[PATCH] bitmap: fix memset optimization on big-endian systems

From: Omar Sandoval Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}() which uses memset() when the start and length are constants aligned to a byte. This is wrong on big-endian systems; our bitmaps are arrays of unsigned long, so bit n is not at byte n / 8 in memory. This

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