[Patch v4] cifs: Allocate validate negotiation request through kmalloc

From: Long Li The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect address can't be detected by ib_dma_mapping_error. Sending data from this address to hardware will not

Re: Smatch check for Spectre stuff

Hi Dan, On 04/19/2018 12:15 AM, Dan Carpenter wrote: Several people have asked me to write this and I think one person was maybe working on writing it themselves... The point of this check is to find place which might be vulnerable to the Spectre vulnerability. In the kernel we have the

[Patch v4] cifs: Allocate validate negotiation request through kmalloc

From: Long Li The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect address can't be detected by ib_dma_mapping_error. Sending data from this address to hardware will not fail, but the remote

Re: Smatch check for Spectre stuff

Hi Dan, On 04/19/2018 12:15 AM, Dan Carpenter wrote: Several people have asked me to write this and I think one person was maybe working on writing it themselves... The point of this check is to find place which might be vulnerable to the Spectre vulnerability. In the kernel we have the

RE: kernel panics with 4.14.X versions

> From: Jan Kara > Sent: Thursday, April 19, 2018 13:23 > Good news guys, Robert has just spotted a bug which looks like what I'd > expect can cause your lockups / crashes. I've merged his patch to my tree > and will push it to Linus for -rc3 so eventually it should land in > appropriate stable

RE: kernel panics with 4.14.X versions

> From: Jan Kara > Sent: Thursday, April 19, 2018 13:23 > Good news guys, Robert has just spotted a bug which looks like what I'd > expect can cause your lockups / crashes. I've merged his patch to my tree > and will push it to Linus for -rc3 so eventually it should land in > appropriate stable

Re: [PATCH] serial: imx: fix cached UCR2 read on software reset

Hi Uwe, On 16.04.2018 17:35, Stefan Agner wrote: > To reset the UART the SRST needs be cleared (low active). According > to the documentation the bit will remain active for 4 module clocks > until it is cleared (set to 1). > > Hence the real register need to be read in case the cached register >

Re: [PATCH] serial: imx: fix cached UCR2 read on software reset

Hi Uwe, On 16.04.2018 17:35, Stefan Agner wrote: > To reset the UART the SRST needs be cleared (low active). According > to the documentation the bit will remain active for 4 module clocks > until it is cleared (set to 1). > > Hence the real register need to be read in case the cached register >

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

On Tue, Apr 03, 2018 at 08:02:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +) > Merge tag 'pm-4.17-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > syzbot

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

On Tue, Apr 03, 2018 at 08:02:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +) > Merge tag 'pm-4.17-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > syzbot

[PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG

On Thu, 19 Apr 2018, Michael S. Tsirkin wrote: > Maybe make it conditional on CONFIG_DEBUG_SG too? > Otherwise I think you just trigger a hard to debug memory corruption. OK, here I resend the patch with CONFIG_DEBUG_SG. With CONFIG_DEBUG_SG, the DMA API will print a stacktrace where the

[PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG

On Thu, 19 Apr 2018, Michael S. Tsirkin wrote: > Maybe make it conditional on CONFIG_DEBUG_SG too? > Otherwise I think you just trigger a hard to debug memory corruption. OK, here I resend the patch with CONFIG_DEBUG_SG. With CONFIG_DEBUG_SG, the DMA API will print a stacktrace where the

Re: [do_execve] attempted to set unsupported pgprot

On 04/18/2018 12:59 PM, Andrew Morton wrote: > Dave, fb43d6cb91ef57 ("x86/mm: Do not auto-massage page protections") > looks like a culprit? This looks like a problem when a 32-bit kernel runs on hardware without NX support. I'm digging into it but haven't found a root cause yet.

Re: [do_execve] attempted to set unsupported pgprot

On 04/18/2018 12:59 PM, Andrew Morton wrote: > Dave, fb43d6cb91ef57 ("x86/mm: Do not auto-massage page protections") > looks like a culprit? This looks like a problem when a 32-bit kernel runs on hardware without NX support. I'm digging into it but haven't found a root cause yet.

Re: kernel panics with 4.14.X versions

On Thu, Apr 19, 2018 at 2:16 PM, Pavlos Parissis wrote: > On 19/04/2018 10:23 μμ, Jan Kara wrote: >> On Wed 18-04-18 10:32:21, Pavlos Parissis wrote: >>> On 17/04/2018 02:12 μμ, Jan Kara wrote: On Tue 17-04-18 01:31:24, Pavlos Parissis wrote: > On 16/04/2018

Re: kernel panics with 4.14.X versions

On Thu, Apr 19, 2018 at 2:16 PM, Pavlos Parissis wrote: > On 19/04/2018 10:23 μμ, Jan Kara wrote: >> On Wed 18-04-18 10:32:21, Pavlos Parissis wrote: >>> On 17/04/2018 02:12 μμ, Jan Kara wrote: On Tue 17-04-18 01:31:24, Pavlos Parissis wrote: > On 16/04/2018 04:40 μμ, Jan Kara wrote:

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote: > On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman > wrote: >> I suspect you want to use __kernel_ulong_t here instead of a raw >> unsigned long. If nothing else it seems inconsistent to use typedefs

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote: > On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman > wrote: >> I suspect you want to use __kernel_ulong_t here instead of a raw >> unsigned long. If nothing else it seems inconsistent to use typedefs >> in one half of the structure and no

Re: [PATCH] nvme: fc: provide a descriptive error

On 4/19/2018 10:43 AM, Johannes Thumshirn wrote: Provide a descriptive error in case an lport to rport association isn't found when creating the FC-NVME controller. Currently it's very hard to debug the reason for a failed connect attempt without a look at the source. Signed-off-by: Johannes

Re: [PATCH] nvme: fc: provide a descriptive error

On 4/19/2018 10:43 AM, Johannes Thumshirn wrote: Provide a descriptive error in case an lport to rport association isn't found when creating the FC-NVME controller. Currently it's very hard to debug the reason for a failed connect attempt without a look at the source. Signed-off-by: Johannes

Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

On Thu, 19 Apr 2018, Andrew Morton wrote: > On Thu, 19 Apr 2018 12:12:38 -0400 (EDT) Mikulas Patocka > wrote: > > > The kvmalloc function tries to use kmalloc and falls back to vmalloc if > > kmalloc fails. > > > > Unfortunatelly, some kernel code has bugs - it uses

Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

On Thu, 19 Apr 2018, Andrew Morton wrote: > On Thu, 19 Apr 2018 12:12:38 -0400 (EDT) Mikulas Patocka > wrote: > > > The kvmalloc function tries to use kmalloc and falls back to vmalloc if > > kmalloc fails. > > > > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then > >

Re: kernel panics with 4.14.X versions

On 19/04/2018 10:23 μμ, Jan Kara wrote: > On Wed 18-04-18 10:32:21, Pavlos Parissis wrote: >> On 17/04/2018 02:12 μμ, Jan Kara wrote: >>> On Tue 17-04-18 01:31:24, Pavlos Parissis wrote: On 16/04/2018 04:40 μμ, Jan Kara wrote: >>> >>> >>> > How easily can you hit this? Very

Re: kernel panics with 4.14.X versions

On 19/04/2018 10:23 μμ, Jan Kara wrote: > On Wed 18-04-18 10:32:21, Pavlos Parissis wrote: >> On 17/04/2018 02:12 μμ, Jan Kara wrote: >>> On Tue 17-04-18 01:31:24, Pavlos Parissis wrote: On 16/04/2018 04:40 μμ, Jan Kara wrote: >>> >>> >>> > How easily can you hit this? Very

[PATCH] KVM: s390: reset crypto attributes for all vcpus

Introduces a new function to reset the crypto attributes for all vcpus whether they are running or not. Each vcpu in KVM will be removed from SIE prior to resetting the crypto attributes in its SIE state description. After all vcpus have had their crypto attributes reset the vcpus will be restored

[PATCH] KVM: s390: reset crypto attributes for all vcpus

Introduces a new function to reset the crypto attributes for all vcpus whether they are running or not. Each vcpu in KVM will be removed from SIE prior to resetting the crypto attributes in its SIE state description. After all vcpus have had their crypto attributes reset the vcpus will be restored

[PATCH v1 1/2] PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR

From: Bjorn Helgaas When in the ASPM L1.0 state (but not the PCI-PM L1.0 state), the most recent LTR value and the LTR_L1.2_THRESHOLD determines whether the link enters the L1.2 substate. If we don't have LTR enabled, prevent the use of ASPM L1.2. PCI-PM L1.2 may still be

[PATCH v1 1/2] PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR

From: Bjorn Helgaas When in the ASPM L1.0 state (but not the PCI-PM L1.0 state), the most recent LTR value and the LTR_L1.2_THRESHOLD determines whether the link enters the L1.2 substate. If we don't have LTR enabled, prevent the use of ASPM L1.2. PCI-PM L1.2 may still be used because it

[PATCH v1 2/2] PCI/ACPI: Request LTR control from platform before using it

From: Bjorn Helgaas Per the PCI Firmware spec r3.2, sec 4.5, an ACPI-based OS should use _OSC to request control of Latency Tolerance Reporting (LTR) before using it. Request control of LTR, and if the platform does not grant control, don't use it. N.B. If the hardware

[PATCH v1 2/2] PCI/ACPI: Request LTR control from platform before using it

From: Bjorn Helgaas Per the PCI Firmware spec r3.2, sec 4.5, an ACPI-based OS should use _OSC to request control of Latency Tolerance Reporting (LTR) before using it. Request control of LTR, and if the platform does not grant control, don't use it. N.B. If the hardware supports LTR and the

[PATCH v1 0/2] PCI/ASPM: Tighten up ASPM L1.2 and LTR usage

The ASPM L1.2 substate depends on LTR information. Per the PCI Firmware spec, the OS is supposed to negotiate with the platform for control of the LTR feature, but previously we didn't do that. In addition, we must not enable LTR in an endpoint unless the Root Complex and all intermediate

[PATCH v1 0/2] PCI/ASPM: Tighten up ASPM L1.2 and LTR usage

The ASPM L1.2 substate depends on LTR information. Per the PCI Firmware spec, the OS is supposed to negotiate with the platform for control of the LTR feature, but previously we didn't do that. In addition, we must not enable LTR in an endpoint unless the Root Complex and all intermediate

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On 04/19/2018 04:39 PM, Alexey Dobriyan wrote: >> >> Yes, that can probably help. >> >> This is the data from the problematic skylake server: >> >> model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz >> 56 sosreport-carevalo.02076935-20180413085327/proc/stat >> Interrupts: 5370 >> Interrupts

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On 04/19/2018 04:39 PM, Alexey Dobriyan wrote: >> >> Yes, that can probably help. >> >> This is the data from the problematic skylake server: >> >> model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz >> 56 sosreport-carevalo.02076935-20180413085327/proc/stat >> Interrupts: 5370 >> Interrupts

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On 04/19/2018 04:39 PM, Alexey Dobriyan wrote: > On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote: >> On 04/19/2018 03:55 PM, Alexey Dobriyan wrote: >>> On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote: On 04/19/2018 03:08 PM, Alexey Dobriyan wrote: >> Therefore,

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On 04/19/2018 04:39 PM, Alexey Dobriyan wrote: > On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote: >> On 04/19/2018 03:55 PM, Alexey Dobriyan wrote: >>> On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote: On 04/19/2018 03:08 PM, Alexey Dobriyan wrote: >> Therefore,

Re: [PATCH 2/2] tracing/events: block: dev_t via driver core for plug and unplug events

On Thu, 2018-04-19 at 12:24 -0700, Omar Sandoval wrote: > We quiesce and freeze the queue before tearing it down, so it won't be > NULL while we're still doing I/O. Cc'ing Bart in case I'm lying to you, > though ;) blk_cleanup_queue() waits until all I/O requests have finished. Since the block

Re: [PATCH 2/2] tracing/events: block: dev_t via driver core for plug and unplug events

On Thu, 2018-04-19 at 12:24 -0700, Omar Sandoval wrote: > We quiesce and freeze the queue before tearing it down, so it won't be > NULL while we're still doing I/O. Cc'ing Bart in case I'm lying to you, > though ;) blk_cleanup_queue() waits until all I/O requests have finished. Since the block

Re: [PATCH 7/7] i2c: pnx: move header into the driver

Hi Wolfram, On 04/19/2018 11:00 PM, Wolfram Sang wrote: > There are no platform_data users anymore. Move the structs into the > driver. > > Signed-off-by: Wolfram Sang Acked-by: Vladimir Zapolskiy Thank you for the nice change! -- With best wishes,

Re: [PATCH 7/7] i2c: pnx: move header into the driver

Hi Wolfram, On 04/19/2018 11:00 PM, Wolfram Sang wrote: > There are no platform_data users anymore. Move the structs into the > driver. > > Signed-off-by: Wolfram Sang Acked-by: Vladimir Zapolskiy Thank you for the nice change! -- With best wishes, Vladimir

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote: > On 04/19/2018 03:55 PM, Alexey Dobriyan wrote: > > On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote: > >> On 04/19/2018 03:08 PM, Alexey Dobriyan wrote: > Therefore, application performance can be impacted if the

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote: > On 04/19/2018 03:55 PM, Alexey Dobriyan wrote: > > On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote: > >> On 04/19/2018 03:08 PM, Alexey Dobriyan wrote: > Therefore, application performance can be impacted if the

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On 4/19/2018 4:26 PM, Jason Gunthorpe wrote: > On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote: >> The infiniband adapter might be connected to a PCI hotplug slot. Performing >> secondary bus reset on a hotplug slot causes PCI link up/down interrupts. >> >> Hotplug driver removes the

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On 4/19/2018 4:26 PM, Jason Gunthorpe wrote: > On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote: >> The infiniband adapter might be connected to a PCI hotplug slot. Performing >> secondary bus reset on a hotplug slot causes PCI link up/down interrupts. >> >> Hotplug driver removes the

Re: [PATCH v2 net 0/3] virtio: ctrl buffer fixes

From: "Michael S. Tsirkin" Date: Thu, 19 Apr 2018 08:30:47 +0300 > Here are a couple of fixes related to the virtio control buffer. > Lightly tested on x86 only. Thanks for taking care of the control buffer DMA'ability issue. Want any of these queued up for -stable?

Re: [PATCH v2 net 0/3] virtio: ctrl buffer fixes

From: "Michael S. Tsirkin" Date: Thu, 19 Apr 2018 08:30:47 +0300 > Here are a couple of fixes related to the virtio control buffer. > Lightly tested on x86 only. Thanks for taking care of the control buffer DMA'ability issue. Want any of these queued up for -stable?

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

On Thu, Apr 19, 2018 at 9:31 AM, David Howells wrote: > Add LSM hooks for use by the filesystem context code. This includes: > > (1) Hooks to handle allocation, duplication and freeing of the security > record attached to a filesystem context. > > (2) A hook to snoop

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

On Thu, Apr 19, 2018 at 9:31 AM, David Howells wrote: > Add LSM hooks for use by the filesystem context code. This includes: > > (1) Hooks to handle allocation, duplication and freeing of the security > record attached to a filesystem context. > > (2) A hook to snoop a mount options in

Re: [PATCH] net: hns: Avoid action name truncation

From: dann frazier Date: Wed, 18 Apr 2018 21:55:41 -0600 > When longer interface names are used, the action names exposed in > /proc/interrupts and /proc/irq/* maybe truncated. For example, when > using the predictable name algorithm in systemd on a HiSilicon D05, > I

Re: [PATCH] net: hns: Avoid action name truncation

From: dann frazier Date: Wed, 18 Apr 2018 21:55:41 -0600 > When longer interface names are used, the action names exposed in > /proc/interrupts and /proc/irq/* maybe truncated. For example, when > using the predictable name algorithm in systemd on a HiSilicon D05, > I see: > > ubuntu@d05-3:~$

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote: > The infiniband adapter might be connected to a PCI hotplug slot. Performing > secondary bus reset on a hotplug slot causes PCI link up/down interrupts. > > Hotplug driver removes the device from system when a link down interrupt > is

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote: > The infiniband adapter might be connected to a PCI hotplug slot. Performing > secondary bus reset on a hotplug slot causes PCI link up/down interrupts. > > Hotplug driver removes the device from system when a link down interrupt > is

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

* Wolfram Sang [180419 20:02]: > This header only contains platform_data. Move it to the proper directory. Acked-by: Tony Lindgren

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

* Wolfram Sang [180419 20:02]: > This header only contains platform_data. Move it to the proper directory. Acked-by: Tony Lindgren

Re: [PATCH 4/7] i2c: i2c-omap: move header to platform_data

* Wolfram Sang [180419 20:02]: > This header only contains platform_data. Move it to the proper directory. Acked-by: Tony Lindgren

Re: [PATCH 4/7] i2c: i2c-omap: move header to platform_data

* Wolfram Sang [180419 20:02]: > This header only contains platform_data. Move it to the proper directory. Acked-by: Tony Lindgren

Re: kernel panics with 4.14.X versions

On Wed 18-04-18 10:32:21, Pavlos Parissis wrote: > On 17/04/2018 02:12 μμ, Jan Kara wrote: > > On Tue 17-04-18 01:31:24, Pavlos Parissis wrote: > >> On 16/04/2018 04:40 μμ, Jan Kara wrote: > > > > > > > >>> How easily can you hit this? > >> > >> Very easily, I only need to wait 1-2 days for a

Re: kernel panics with 4.14.X versions

On Wed 18-04-18 10:32:21, Pavlos Parissis wrote: > On 17/04/2018 02:12 μμ, Jan Kara wrote: > > On Tue 17-04-18 01:31:24, Pavlos Parissis wrote: > >> On 16/04/2018 04:40 μμ, Jan Kara wrote: > > > > > > > >>> How easily can you hit this? > >> > >> Very easily, I only need to wait 1-2 days for a

Re: [PATCH/RFC 0/2] regulator: bd9571mwv: Add support for toggle power switches

On Wed 2018-04-18 15:00:41, Mark Brown wrote: > On Wed, Apr 18, 2018 at 03:29:36PM +0200, Geert Uytterhoeven wrote: > > > Any comments/suggestions? > > > In case you lost the patches from the thread: > > https://www.spinics.net/lists/linux-renesas-soc/msg24955.html > > Please don't send content

Re: [PATCH/RFC 0/2] regulator: bd9571mwv: Add support for toggle power switches

On Wed 2018-04-18 15:00:41, Mark Brown wrote: > On Wed, Apr 18, 2018 at 03:29:36PM +0200, Geert Uytterhoeven wrote: > > > Any comments/suggestions? > > > In case you lost the patches from the thread: > > https://www.spinics.net/lists/linux-renesas-soc/msg24955.html > > Please don't send content

Re: [PATCH] ext4 : fix comments in ext4_swap_extents

On Thu 19-04-18 12:44:56, Theodore Y. Ts'o wrote: > On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote: > > On Mon 19-03-18 16:34:09, zhenwei.pi wrote: > > > "mark_unwritten" in comment and "unwritten" in variable > > > argument lists is mismatch. > > > > > > Signed-off-by: zhenwei.pi

Re: [PATCH] ext4 : fix comments in ext4_swap_extents

On Thu 19-04-18 12:44:56, Theodore Y. Ts'o wrote: > On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote: > > On Mon 19-03-18 16:34:09, zhenwei.pi wrote: > > > "mark_unwritten" in comment and "unwritten" in variable > > > argument lists is mismatch. > > > > > > Signed-off-by: zhenwei.pi > >

Re: [Xen-devel] [PATCH] xen-netfront: Fix hang on device removal

Jason Andryuk: > On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser > wrote: >> Jason Andryuk: >>> A toolstack may delete the vif frontend and backend xenstore entries >>> while xen-netfront is in the removal code path. In that case, the >>> checks for

Re: [Xen-devel] [PATCH] xen-netfront: Fix hang on device removal

Jason Andryuk: > On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser > wrote: >> Jason Andryuk: >>> A toolstack may delete the vif frontend and backend xenstore entries >>> while xen-netfront is in the removal code path. In that case, the >>> checks for xenbus_read_driver_state would return

Re: [PATCH 59/61] watchdog: simplify getting .drvdata

On Thu, Apr 19, 2018 at 04:06:29PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Reviewed-by: Guenter Roeck >

Re: [PATCH 59/61] watchdog: simplify getting .drvdata

On Thu, Apr 19, 2018 at 04:06:29PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Reviewed-by: Guenter Roeck > --- > > Build tested only. buildbot is happy. Please

Re: [PATCH 4.9 00/66] 4.9.95-stable review

On Thu, Apr 19, 2018 at 04:03:05PM +0200, Greg Kroah-Hartman wrote: > On Thu, Apr 19, 2018 at 04:42:56PM +0530, Naresh Kamboju wrote: > > > > > > Can you try 'git bisect'? I'll hold off on releasing 4.9.y until this > > > gets figured out. > > > > After reverting this patch, network started

Re: [PATCH 4.9 00/66] 4.9.95-stable review

On Thu, Apr 19, 2018 at 04:03:05PM +0200, Greg Kroah-Hartman wrote: > On Thu, Apr 19, 2018 at 04:42:56PM +0530, Naresh Kamboju wrote: > > > > > > Can you try 'git bisect'? I'll hold off on releasing 4.9.y until this > > > gets figured out. > > > > After reverting this patch, network started

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 12:43:19PM -0700, Andrew Morton wrote: > On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote: > > > It was found that reading /proc/stat could be time consuming on > > systems with a lot of irqs. For example, reading /proc/stat in a > > certain

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 12:43:19PM -0700, Andrew Morton wrote: > On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote: > > > It was found that reading /proc/stat could be time consuming on > > systems with a lot of irqs. For example, reading /proc/stat in a > > certain 2-socket Skylake server

[PATCH 3/7] i2c: i2c-ocores: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- Documentation/i2c/busses/i2c-ocores| 2 +- drivers/i2c/busses/i2c-ocores.c| 2 +- drivers/mfd/timberdale.c | 2 +-

[PATCH 3/7] i2c: i2c-ocores: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- Documentation/i2c/busses/i2c-ocores| 2 +- drivers/i2c/busses/i2c-ocores.c| 2 +- drivers/mfd/timberdale.c | 2 +- include/linux/{ =>

[PATCH 2/7] i2c: i2c-mux-gpio: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- Documentation/i2c/muxes/i2c-mux-gpio | 4 ++-- MAINTAINERS | 2 +- drivers/i2c/busses/i2c-i801.c| 2

[PATCH 4/7] i2c: i2c-omap: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- MAINTAINERS | 4 ++-- arch/arm/mach-omap1/common.h | 2 +- arch/arm/mach-omap1/i2c.c| 2 +-

[PATCH 2/7] i2c: i2c-mux-gpio: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- Documentation/i2c/muxes/i2c-mux-gpio | 4 ++-- MAINTAINERS | 2 +- drivers/i2c/busses/i2c-i801.c| 2 +-

[PATCH 4/7] i2c: i2c-omap: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- MAINTAINERS | 4 ++-- arch/arm/mach-omap1/common.h | 2 +- arch/arm/mach-omap1/i2c.c| 2 +- arch/arm/mach-omap2/common.h

[PATCH 7/7] i2c: pnx: move header into the driver

There are no platform_data users anymore. Move the structs into the driver. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-pnx.c | 21 - include/linux/i2c-pnx.h | 38 -- 2 files changed, 20 insertions(+),

[PATCH 7/7] i2c: pnx: move header into the driver

There are no platform_data users anymore. Move the structs into the driver. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-pnx.c | 21 - include/linux/i2c-pnx.h | 38 -- 2 files changed, 20 insertions(+), 39 deletions(-)

[PATCH 5/7] i2c: i2c-pca-platform: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- arch/sh/boards/board-sh7785lcr.c | 2 +- drivers/i2c/busses/i2c-pca-platform.c| 2 +- include/linux/{ =>

[PATCH 5/7] i2c: i2c-pca-platform: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- arch/sh/boards/board-sh7785lcr.c | 2 +- drivers/i2c/busses/i2c-pca-platform.c| 2 +- include/linux/{ => platform_data}/i2c-pca-platform.h | 0 3 files

[PATCH 6/7] i2c: i2c-xiic: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-xiic.c| 2 +- drivers/mfd/timberdale.c | 2 +- include/linux/{ => platform_data}/i2c-xiic.h | 0 3 files

[PATCH 6/7] i2c: i2c-xiic: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-xiic.c| 2 +- drivers/mfd/timberdale.c | 2 +- include/linux/{ => platform_data}/i2c-xiic.h | 0 3 files changed, 2 insertions(+),

[PATCH 1/7] i2c: i2c-gpio: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- MAINTAINERS | 2 +- arch/arm/mach-ks8695/board-acs5k.c | 2 +- arch/arm/mach-omap1/board-htcherald.c| 2 +-

[PATCH 1/7] i2c: i2c-gpio: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang --- MAINTAINERS | 2 +- arch/arm/mach-ks8695/board-acs5k.c | 2 +- arch/arm/mach-omap1/board-htcherald.c| 2 +-

[PATCH 0/7] i2c: clean up include/linux/i2c-*

Move all plain platform_data includes to the platform_data-dir (except for i2c-pnx which can be moved into the driver itself). My preference is to take these patches via the i2c tree. I can provide an immutable branch if needed. But we can also discuss those going in via arch-trees if

[PATCH 0/7] i2c: clean up include/linux/i2c-*

Move all plain platform_data includes to the platform_data-dir (except for i2c-pnx which can be moved into the driver itself). My preference is to take these patches via the i2c tree. I can provide an immutable branch if needed. But we can also discuss those going in via arch-trees if

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On 04/19/2018 03:43 PM, Andrew Morton wrote: > On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote: > >> It was found that reading /proc/stat could be time consuming on >> systems with a lot of irqs. For example, reading /proc/stat in a >> certain 2-socket Skylake server took

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On 04/19/2018 03:43 PM, Andrew Morton wrote: > On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote: > >> It was found that reading /proc/stat could be time consuming on >> systems with a lot of irqs. For example, reading /proc/stat in a >> certain 2-socket Skylake server took about 4.6ms because

[PATCH 2/2] PCI/AER: Try slot reset before secondary bus reset

The endpoint observing AER_FATAL error might be connected to a PCI hotplug slot. Performing secondary bus reset on a hotplug slot causes PCI link up/down interrupts. Hotplug driver removes the device from system when a link down interrupt is observed and performs re-enumeration when link up

[PATCH 2/2] PCI/AER: Try slot reset before secondary bus reset

The endpoint observing AER_FATAL error might be connected to a PCI hotplug slot. Performing secondary bus reset on a hotplug slot causes PCI link up/down interrupts. Hotplug driver removes the device from system when a link down interrupt is observed and performs re-enumeration when link up

[PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

The infiniband adapter might be connected to a PCI hotplug slot. Performing secondary bus reset on a hotplug slot causes PCI link up/down interrupts. Hotplug driver removes the device from system when a link down interrupt is observed and performs re-enumeration when link up interrupt is

[PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

The infiniband adapter might be connected to a PCI hotplug slot. Performing secondary bus reset on a hotplug slot causes PCI link up/down interrupts. Hotplug driver removes the device from system when a link down interrupt is observed and performs re-enumeration when link up interrupt is

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote: > On 04/19/2018 03:08 PM, Alexey Dobriyan wrote: > >> Therefore, application performance can be impacted if the application > >> reads /proc/stat rather frequently. > > [nods] > > Text interfaces can be designed in a very stupid way. > >

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote: > On 04/19/2018 03:08 PM, Alexey Dobriyan wrote: > >> Therefore, application performance can be impacted if the application > >> reads /proc/stat rather frequently. > > [nods] > > Text interfaces can be designed in a very stupid way. > >

Re: [RFC PATCH 31/35] Revert "vfs: add d_real_inode() helper"

On Wed, Apr 18, 2018 at 03:49:02PM +0200, Miklos Szeredi wrote: > On Wed, Apr 18, 2018 at 3:38 PM, Steven Rostedt wrote: > > On Wed, 18 Apr 2018 13:42:03 +0200 > > Miklos Szeredi wrote: > > > >> On Wed, Apr 18, 2018 at 10:19 AM, Amir Goldstein

Re: [RFC PATCH 31/35] Revert "vfs: add d_real_inode() helper"

On Wed, Apr 18, 2018 at 03:49:02PM +0200, Miklos Szeredi wrote: > On Wed, Apr 18, 2018 at 3:38 PM, Steven Rostedt wrote: > > On Wed, 18 Apr 2018 13:42:03 +0200 > > Miklos Szeredi wrote: > > > >> On Wed, Apr 18, 2018 at 10:19 AM, Amir Goldstein > >> wrote: > >> > On Thu, Apr 12, 2018 at 6:08

Re: [PATCH] vfio iommu type1: no need to check task->mm if task has been destroyed

On Thu, 19 Apr 2018 10:19:26 -0600 Alex Williamson wrote: > [cc +Kirti] > > On Wed, 18 Apr 2018 18:55:45 +0800 > Xu Yandong wrote: > > > The task structure in vfio_dma struct used to identify the same > > task who map it or other task who

Re: [PATCH] vfio iommu type1: no need to check task->mm if task has been destroyed

On Thu, 19 Apr 2018 10:19:26 -0600 Alex Williamson wrote: > [cc +Kirti] > > On Wed, 18 Apr 2018 18:55:45 +0800 > Xu Yandong wrote: > > > The task structure in vfio_dma struct used to identify the same > > task who map it or other task who shares same adress space is > > allowed to unmap. But

RE: issues with suspend on Dell XPS 13 2-in-1

> -Original Message- > From: Pandruvada, Srinivas [mailto:srinivas.pandruv...@intel.com] > Sent: Thursday, April 19, 2018 2:46 PM > To: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; > dgilm...@redhat.com; Limonciello, Mario > Subject: Re: issues with suspend on Dell XPS 13

RE: issues with suspend on Dell XPS 13 2-in-1

> -Original Message- > From: Pandruvada, Srinivas [mailto:srinivas.pandruv...@intel.com] > Sent: Thursday, April 19, 2018 2:46 PM > To: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; > dgilm...@redhat.com; Limonciello, Mario > Subject: Re: issues with suspend on Dell XPS 13

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