Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Thu, Apr 19, 2018 at 11:14:02AM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 08:01 PM, Dongwon Kim wrote: > >On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > >>On 04/17/2018 11:57 PM, Dongwon Kim wrote: > >>>On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel

Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Thu, Apr 19, 2018 at 11:14:02AM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 08:01 PM, Dongwon Kim wrote: > >On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > >>On 04/17/2018 11:57 PM, Dongwon Kim wrote: > >>>On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 19/04/2018 19:46, Michael S. Tsirkin wrote: >> This should be okay, but I wonder if there should be a virtio_wmb(...) >> or an "if (weak_barriers) wmb()" before the "writel" in vm_notify >> (drivers/virtio/virtio_mmio.c). >> >> Thanks, >> >> Paolo > That one uses weak barriers AFAIK. > > IIUC

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 19/04/2018 19:46, Michael S. Tsirkin wrote: >> This should be okay, but I wonder if there should be a virtio_wmb(...) >> or an "if (weak_barriers) wmb()" before the "writel" in vm_notify >> (drivers/virtio/virtio_mmio.c). >> >> Thanks, >> >> Paolo > That one uses weak barriers AFAIK. > > IIUC

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 19/04/2018 19:35, Michael S. Tsirkin wrote: > virtio is using barriers to order memory accesses, thus > dma_wmb/rmb is a good match. > > Build-tested on x86: Before > > [mst@tuck linux]$ size drivers/virtio/virtio_ring.o >textdata bss dec hex filename > 11392 820

Re: [PATCH] amdkfd: always select MMU_NOTIFIER

On 2018-04-19 06:56 AM, Anders Roxell wrote: > On 28 March 2018 at 18:04, Christian König wrote: >> Am 28.03.2018 um 17:53 schrieb Arnd Bergmann: >>> Building amdkfd without MMU notifiers is broken: >>> >>> In file included from

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 19/04/2018 19:35, Michael S. Tsirkin wrote: > virtio is using barriers to order memory accesses, thus > dma_wmb/rmb is a good match. > > Build-tested on x86: Before > > [mst@tuck linux]$ size drivers/virtio/virtio_ring.o >textdata bss dec hex filename > 11392 820

Re: [PATCH] amdkfd: always select MMU_NOTIFIER

On 2018-04-19 06:56 AM, Anders Roxell wrote: > On 28 March 2018 at 18:04, Christian König wrote: >> Am 28.03.2018 um 17:53 schrieb Arnd Bergmann: >>> Building amdkfd without MMU notifiers is broken: >>> >>> In file included from drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c:28: >>>

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On Thu, Apr 19, 2018 at 07:39:21PM +0200, Paolo Bonzini wrote: > On 19/04/2018 19:35, Michael S. Tsirkin wrote: > > virtio is using barriers to order memory accesses, thus > > dma_wmb/rmb is a good match. > > > > Build-tested on x86: Before > > > > [mst@tuck linux]$ size

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On Thu, Apr 19, 2018 at 07:39:21PM +0200, Paolo Bonzini wrote: > On 19/04/2018 19:35, Michael S. Tsirkin wrote: > > virtio is using barriers to order memory accesses, thus > > dma_wmb/rmb is a good match. > > > > Build-tested on x86: Before > > > > [mst@tuck linux]$ size

[PATCH] nvme: fc: provide a descriptive error

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 Thumshirn --- This actually

[PATCH] nvme: fc: provide a descriptive error

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 Thumshirn --- This actually happened to Hannes and

Re: [PATCH 0/2] nvmem: meson-efuse: add write support

Jerome Brunet writes: > This changeset adds write support to meson efuse driver. > The first patch just changes the way the nvmem data are allocated w/o > any functional changes. The second patches actually adds write support. > > The memory being an OTP, it is safer if it

Re: [PATCH 0/2] nvmem: meson-efuse: add write support

Jerome Brunet writes: > This changeset adds write support to meson efuse driver. > The first patch just changes the way the nvmem data are allocated w/o > any functional changes. The second patches actually adds write support. > > The memory being an OTP, it is safer if it remains read-only by

[PATCH] MAINTAINERS: Rakesh Iyer can't be reached anymore

The current mail address is rejected, last activity (with a different address) in git-history is from 2012. Remove this. Signed-off-by: Wolfram Sang --- If somebody knows a recent address, then we can simply update, of course. MAINTAINERS | 1 - 1 file changed, 1

[PATCH] MAINTAINERS: Rakesh Iyer can't be reached anymore

The current mail address is rejected, last activity (with a different address) in git-history is from 2012. Remove this. Signed-off-by: Wolfram Sang --- If somebody knows a recent address, then we can simply update, of course. MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH] atm: iphase: fix spelling mistake: "Tansmit" -> "Transmit"

From: Colin King Date: Wed, 18 Apr 2018 16:55:05 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in message text. > > Signed-off-by: Colin Ian King Applied, thanks.

Re: [PATCH] atm: iphase: fix spelling mistake: "Tansmit" -> "Transmit"

From: Colin King Date: Wed, 18 Apr 2018 16:55:05 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in message text. > > Signed-off-by: Colin Ian King Applied, thanks.

Re: [PATCH 0/4] ARM64: dts: meson: hhi syscon and clock controllers

Jerome Brunet writes: > The HHI register region provides more than just clocks. Several drivers may > need to access this region, such as the clock controllers and the display > driver. > > Meson-gx clock controllers has been developed and merged before we knew the > hhi

Re: [PATCH 0/4] ARM64: dts: meson: hhi syscon and clock controllers

Jerome Brunet writes: > The HHI register region provides more than just clocks. Several drivers may > need to access this region, such as the clock controllers and the display > driver. > > Meson-gx clock controllers has been developed and merged before we knew the > hhi could be needed

Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal.

SURPRISE!!! On 04/19/2018 11:45 AM, Borislav Petkov wrote: > On Thu, Apr 19, 2018 at 11:26:57AM -0500, Alex G. wrote: >> At a very high level, I'm working with Dell on improving server >> reliability, with a focus on NVME hotplug and surprise removal. One of >> the features we don't support is

Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal.

SURPRISE!!! On 04/19/2018 11:45 AM, Borislav Petkov wrote: > On Thu, Apr 19, 2018 at 11:26:57AM -0500, Alex G. wrote: >> At a very high level, I'm working with Dell on improving server >> reliability, with a focus on NVME hotplug and surprise removal. One of >> the features we don't support is

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

On 04/19/18 10:09, 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 it had over > 5k irqs. In that particular case, the majority of the

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

On 04/19/18 10:09, 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 it had over > 5k irqs. In that particular case, the majority of the

Re: [PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

From: Pawel Dembicki Date: Wed, 18 Apr 2018 16:03:24 +0200 > This modem is embedded on dlink dwr-960 router. > The oem configuration states: ... > Tested on openwrt distribution > > Signed-off-by: Pawel Dembicki Applied and queued up for

Re: [PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

From: Pawel Dembicki Date: Wed, 18 Apr 2018 16:03:24 +0200 > This modem is embedded on dlink dwr-960 router. > The oem configuration states: ... > Tested on openwrt distribution > > Signed-off-by: Pawel Dembicki Applied and queued up for -stable.

[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

virtio is using barriers to order memory accesses, thus dma_wmb/rmb is a good match. Build-tested on x86: Before [mst@tuck linux]$ size drivers/virtio/virtio_ring.o textdata bss dec hex filename 11392 820 0 122122fb4 drivers/virtio/virtio_ring.o After

[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

virtio is using barriers to order memory accesses, thus dma_wmb/rmb is a good match. Build-tested on x86: Before [mst@tuck linux]$ size drivers/virtio/virtio_ring.o textdata bss dec hex filename 11392 820 0 122122fb4 drivers/virtio/virtio_ring.o After

Re: [PATCH net-next] net-next/hinic: add arm64 support

From: Zhao Chen Date: Wed, 18 Apr 2018 06:07:39 -0400 > This patch enables arm64 platform support for the HINIC driver. > > Signed-off-by: Zhao Chen Applied, thank you.

Re: [PATCH net-next] net-next/hinic: add arm64 support

From: Zhao Chen Date: Wed, 18 Apr 2018 06:07:39 -0400 > This patch enables arm64 platform support for the HINIC driver. > > Signed-off-by: Zhao Chen Applied, thank you.

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

> -Original Message- > From: Pandruvada, Srinivas [mailto:srinivas.pandruv...@intel.com] > Sent: Wednesday, April 18, 2018 11:37 PM > To: dgilm...@redhat.com; linux-kernel@vger.kernel.org; linux- > a...@vger.kernel.org; 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: Wednesday, April 18, 2018 11:37 PM > To: dgilm...@redhat.com; linux-kernel@vger.kernel.org; linux- > a...@vger.kernel.org; Limonciello, Mario > Subject: Re: issues with suspend on Dell XPS 13

Re: WARNING: kernel stack frame pointer has bad value

On Thu, Apr 19, 2018 at 5:57 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 48023102b7078a6674516b1fe0d639669336049d (Fri Apr 13 23:55:41 2018 +) > Merge branch 'overlayfs-linus' of >

Re: WARNING: kernel stack frame pointer has bad value

On Thu, Apr 19, 2018 at 5:57 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 48023102b7078a6674516b1fe0d639669336049d (Fri Apr 13 23:55:41 2018 +) > Merge branch 'overlayfs-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs > syzbot

[PATCH] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

tg_rt_schedulable() iterates over all child task groups, while tg_has_rt_tasks() iterates over all linked tasks. In case of systems with big number of tasks, this may take a lot of time. I observed hard LOCKUP on machine with 2+ processes after write to "cpu.rt_period_us" of cpu cgroup with

[PATCH] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

tg_rt_schedulable() iterates over all child task groups, while tg_has_rt_tasks() iterates over all linked tasks. In case of systems with big number of tasks, this may take a lot of time. I observed hard LOCKUP on machine with 2+ processes after write to "cpu.rt_period_us" of cpu cgroup with

Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

Quoting Sean Wang (2018-04-18 20:50:02) > On Wed, 2018-04-18 at 20:18 -0700, Stephen Boyd wrote: > > Quoting sean.w...@mediatek.com (2018-04-18 03:24:54) > > > From: Sean Wang > > > > > > Add bindings to g3dsys providing necessary clock and reset control to > > >

Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

Quoting Sean Wang (2018-04-18 20:50:02) > On Wed, 2018-04-18 at 20:18 -0700, Stephen Boyd wrote: > > Quoting sean.w...@mediatek.com (2018-04-18 03:24:54) > > > From: Sean Wang > > > > > > Add bindings to g3dsys providing necessary clock and reset control to > > > Mali-450. > > > > > >

Re: [PATCH 1/2] blkcg: small fix on comment in blkcg_init_queue

On 4/19/18 11:10 AM, Randy Dunlap wrote: > On 04/19/18 07:52, Jens Axboe wrote: >> On 4/18/18 10:04 PM, Jiang Biao wrote: >>> The comment before blkg_create() in blkcg_init_queue() was moved >>> from blkcg_activate_policy() by commit ec13b1d6f0a0457312e615, but >>> it does not suit for the new

Re: [PATCH 1/2] blkcg: small fix on comment in blkcg_init_queue

On 4/19/18 11:10 AM, Randy Dunlap wrote: > On 04/19/18 07:52, Jens Axboe wrote: >> On 4/18/18 10:04 PM, Jiang Biao wrote: >>> The comment before blkg_create() in blkcg_init_queue() was moved >>> from blkcg_activate_policy() by commit ec13b1d6f0a0457312e615, but >>> it does not suit for the new

Re: [PATCH v3 4/7] mailbox: Add support for Qualcomm SDM845 SoCs

On Wed 14 Mar 02:21 PDT 2018, Sibi S wrote: > Add the corresponding APCS offset for SDM845 SoC > > Signed-off-by: Sibi S Full name please. > --- > drivers/mailbox/qcom-apcs-ipc-mailbox.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH v3 4/7] mailbox: Add support for Qualcomm SDM845 SoCs

On Wed 14 Mar 02:21 PDT 2018, Sibi S wrote: > Add the corresponding APCS offset for SDM845 SoC > > Signed-off-by: Sibi S Full name please. > --- > drivers/mailbox/qcom-apcs-ipc-mailbox.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c >

Re: [PATCH] kernel/module: silence a gcc warning

Hi Jessica, On Mon, Apr 16, 2018 at 7:11 PM, Jessica Yu wrote: > +++ Mathieu Malaterre [11/04/18 21:05 +0200]: >> >> In commit 8c8ef42aee8f ("module: include other structures in module >> version >> check"), the function `struct_module` was renamed to `module_layout` but >> no

Re: [PATCH] kernel/module: silence a gcc warning

Hi Jessica, On Mon, Apr 16, 2018 at 7:11 PM, Jessica Yu wrote: > +++ Mathieu Malaterre [11/04/18 21:05 +0200]: >> >> In commit 8c8ef42aee8f ("module: include other structures in module >> version >> check"), the function `struct_module` was renamed to `module_layout` but >> no >> prototype was

[PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA

The performance drop is observed with long hours iperf testing using 40G cards. This is mainly due to long iterations in finding the free iova range in 32bit address space. In current implementation for 64bit PCI devices, there is always first attempt to allocate iova from 32bit(SAC preferred

[PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA

The performance drop is observed with long hours iperf testing using 40G cards. This is mainly due to long iterations in finding the free iova range in 32bit address space. In current implementation for 64bit PCI devices, there is always first attempt to allocate iova from 32bit(SAC preferred

Re: [PATCH net] net: mvpp2: Fix DMA address mask size

From: Maxime Chevallier Date: Wed, 18 Apr 2018 11:14:44 +0200 > PPv2 TX/RX descriptors uses 40bits DMA addresses, but 41 bits masks were > used (GENMASK_ULL(40, 0)). > > This commit fixes that by using the correct mask. > > Fixes: e7c5359f2eed ("net: mvpp2:

Re: [PATCH net] net: mvpp2: Fix DMA address mask size

From: Maxime Chevallier Date: Wed, 18 Apr 2018 11:14:44 +0200 > PPv2 TX/RX descriptors uses 40bits DMA addresses, but 41 bits masks were > used (GENMASK_ULL(40, 0)). > > This commit fixes that by using the correct mask. > > Fixes: e7c5359f2eed ("net: mvpp2: introduce PPv2.2 HW descriptors and

Re: [PATCH 1/2] blkcg: small fix on comment in blkcg_init_queue

On 04/19/18 07:52, Jens Axboe wrote: > On 4/18/18 10:04 PM, Jiang Biao wrote: >> The comment before blkg_create() in blkcg_init_queue() was moved >> from blkcg_activate_policy() by commit ec13b1d6f0a0457312e615, but >> it does not suit for the new context. > > Applied - btw, in the future, if you

Re: [PATCH 1/2] blkcg: small fix on comment in blkcg_init_queue

On 04/19/18 07:52, Jens Axboe wrote: > On 4/18/18 10:04 PM, Jiang Biao wrote: >> The comment before blkg_create() in blkcg_init_queue() was moved >> from blkcg_activate_policy() by commit ec13b1d6f0a0457312e615, but >> it does not suit for the new context. > > Applied - btw, in the future, if you

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

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 it had over 5k irqs. In that particular case, the majority of the CPU cycles for reading /proc/stat was spent in

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

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 it had over 5k irqs. In that particular case, the majority of the CPU cycles for reading /proc/stat was spent in

KMSAN: uninit-value in __udp4_lib_rcv

Hello, syzbot hit the following crash on https://github.com/google/kmsan.git/master commit 35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +) Merge pull request #11 from parkerduckworth/readme syzbot dashboard link:

KMSAN: uninit-value in __udp4_lib_rcv

Hello, syzbot hit the following crash on https://github.com/google/kmsan.git/master commit 35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +) Merge pull request #11 from parkerduckworth/readme syzbot dashboard link:

WARNING in __device_add_disk

Hello, syzbot hit the following crash on upstream commit 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +) Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=3337db851ace689ceb50

WARNING in __device_add_disk

Hello, syzbot hit the following crash on upstream commit 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +) Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=3337db851ace689ceb50

Clang arm64 build is broken

Hi Marc! Your recent commit [1] broke clang build on arm64. The issue is that clang doesn't know about the "S" asm constraint. I reported this to clang [2], and hopefully this will get fixed. In the meantime, would it possible to work around using the "S" constraint in the kernel? While we're

Clang arm64 build is broken

Hi Marc! Your recent commit [1] broke clang build on arm64. The issue is that clang doesn't know about the "S" asm constraint. I reported this to clang [2], and hopefully this will get fixed. In the meantime, would it possible to work around using the "S" constraint in the kernel? While we're

KMSAN: uninit-value in dccp_invalid_packet

Hello, syzbot hit the following crash on https://github.com/google/kmsan.git/master commit e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +) kmsan: temporarily disable visitAsmInstruction() to help syzbot syzbot dashboard link:

KMSAN: uninit-value in dccp_invalid_packet

Hello, syzbot hit the following crash on https://github.com/google/kmsan.git/master commit e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +) kmsan: temporarily disable visitAsmInstruction() to help syzbot syzbot dashboard link:

Re: WARNING in unlock_new_inode

syzbot has found reproducer for the following crash on upstream commit 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +) Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7

Re: WARNING in unlock_new_inode

syzbot has found reproducer for the following crash on upstream commit 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +) Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7

[PATCH v4 2/3] lan78xx: Read LED states from Device Tree

Add support for DT property "microchip,led-modes", a vector of zero to four cells (u32s) in the range 0-15, each of which sets the mode for one of the LEDs. Some possible values are: 0=link/activity 1=link1000/activity 2=link100/activity 3=link10/activity

[PATCH v4 2/3] lan78xx: Read LED states from Device Tree

Add support for DT property "microchip,led-modes", a vector of zero to four cells (u32s) in the range 0-15, each of which sets the mode for one of the LEDs. Some possible values are: 0=link/activity 1=link1000/activity 2=link100/activity 3=link10/activity

kernel BUG at fs/ntfs/aops.c:LINE!

Hello, syzbot hit the following crash on upstream commit 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +) Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=6a5a7672f663cce8b156 So far

Re: [v2 1/1] i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()

On 19.04.2018 16:49, Uwe Kleine-König wrote: > On Thu, Apr 19, 2018 at 03:29:22PM +0300, Alexander Popov wrote: >> i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which >> returns ZERO_SIZE_PTR if i2c_msg.len is zero. >> >> Currently i2cdev_ioctl_rdwr() always dereferences the buf

kernel BUG at fs/ntfs/aops.c:LINE!

Hello, syzbot hit the following crash on upstream commit 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +) Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=6a5a7672f663cce8b156 So far

Re: [v2 1/1] i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()

On 19.04.2018 16:49, Uwe Kleine-König wrote: > On Thu, Apr 19, 2018 at 03:29:22PM +0300, Alexander Popov wrote: >> i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which >> returns ZERO_SIZE_PTR if i2c_msg.len is zero. >> >> Currently i2cdev_ioctl_rdwr() always dereferences the buf

[PATCH v4 0/3] lan78xx: Read configuration from Device Tree

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. This patch set adds support for

[PATCH v4 0/3] lan78xx: Read configuration from Device Tree

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. This patch set adds support for

[PATCH v4 3/3] dt-bindings: Document the DT bindings for lan78xx

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. Document the supported properties in

[PATCH v4 3/3] dt-bindings: Document the DT bindings for lan78xx

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. Document the supported properties in

[PATCH v4 1/3] lan78xx: Read MAC address from DT if present

There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell

Re: [PATCH] drm: clarify adjusted_mode documentation for bridges

On Thursday 19 April 2018 09:20 PM, Philippe CORNU wrote: Hi Archit & Andrzej, May I ask you please a short review of this documentation update. Many thanks Philippe :-) On 04/09/2018 05:24 PM, Philippe Cornu wrote: This patch clarifies the adjusted_mode documentation for bridges.

[PATCH v4 1/3] lan78xx: Read MAC address from DT if present

There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell ---

Re: [PATCH] drm: clarify adjusted_mode documentation for bridges

On Thursday 19 April 2018 09:20 PM, Philippe CORNU wrote: Hi Archit & Andrzej, May I ask you please a short review of this documentation update. Many thanks Philippe :-) On 04/09/2018 05:24 PM, Philippe Cornu wrote: This patch clarifies the adjusted_mode documentation for bridges.

Re: [PATCH] ARM: dts: stm32: Add DAC support to stm32mp157c

Hi Fabrice, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v4.17-rc1 next-20180419] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH] ARM: dts: stm32: Add DAC support to stm32mp157c

Hi Fabrice, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v4.17-rc1 next-20180419] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[PATCH] ACPI / bus: ignore rather than fail bus driver registrations on non-ACPI boot

When building ACPI bus drivers such as button.ko into the core kernel, other drivers that depend on its symbols are loadable even when booting with ACPI disabled. For instance, nouveau.ko has a link time dependency on acpi_lid_open() on ACPI capable kernels, and calls it regardless of whether the

[PATCH] ACPI / bus: ignore rather than fail bus driver registrations on non-ACPI boot

When building ACPI bus drivers such as button.ko into the core kernel, other drivers that depend on its symbols are loadable even when booting with ACPI disabled. For instance, nouveau.ko has a link time dependency on acpi_lid_open() on ACPI capable kernels, and calls it regardless of whether the

Re: [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow)

On 19.04.2018 19:44, Al Viro wrote: > On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote: > >> IOW, we only get there if our vfsmount was an MNT_INTERNAL one. >> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in >> ->mnt_pins of some other mount. Which, AFAICS, means that >> it

Re: [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow)

On 19.04.2018 19:44, Al Viro wrote: > On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote: > >> IOW, we only get there if our vfsmount was an MNT_INTERNAL one. >> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in >> ->mnt_pins of some other mount. Which, AFAICS, means that >> it

Re: [PATCH 11/11] x86/pti: leave kernel text global for !PCID

On Thu, Apr 19, 2018 at 9:02 AM, Dave Hansen wrote: > On 04/18/2018 05:11 PM, Kees Cook wrote: >> On Fri, Apr 6, 2018 at 1:55 PM, Dave Hansen >> wrote: >>> +/* >>> + * For some configurations, map all of kernel text into the user page

Re: [PATCH 11/11] x86/pti: leave kernel text global for !PCID

On Thu, Apr 19, 2018 at 9:02 AM, Dave Hansen wrote: > On 04/18/2018 05:11 PM, Kees Cook wrote: >> On Fri, Apr 6, 2018 at 1:55 PM, Dave Hansen >> wrote: >>> +/* >>> + * For some configurations, map all of kernel text into the user page >>> + * tables. This reduces TLB misses, especially on

Re: [PATCH] regulator: tps6586x: Add support for TPS658624

On Thu, Apr 19, 2018 at 12:18:50PM -0400, ryang wrote: > This version is exists in the Samsung Galaxy Tab 10.1 which is based on the > Nvidia Tegra 2 board. The TPS658624 has the same SM2 voltage table as > TPS658623. > Signed-off-by: ryang > --- >

Re: [PATCH] regulator: tps6586x: Add support for TPS658624

On Thu, Apr 19, 2018 at 12:18:50PM -0400, ryang wrote: > This version is exists in the Samsung Galaxy Tab 10.1 which is based on the > Nvidia Tegra 2 board. The TPS658624 has the same SM2 voltage table as > TPS658623. > Signed-off-by: ryang > --- > drivers/regulator/tps6586x-regulator.c | 1 + >

Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal.

On Thu, Apr 19, 2018 at 11:26:57AM -0500, Alex G. wrote: > At a very high level, I'm working with Dell on improving server > reliability, with a focus on NVME hotplug and surprise removal. One of > the features we don't support is surprise removal of NVME drives; > hotplug is supported with

Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal.

On Thu, Apr 19, 2018 at 11:26:57AM -0500, Alex G. wrote: > At a very high level, I'm working with Dell on improving server > reliability, with a focus on NVME hotplug and surprise removal. One of > the features we don't support is surprise removal of NVME drives; > hotplug is supported with

Re: [PATCH] ext4 : fix comments in ext4_swap_extents

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 > > This seems to have fallen through

Re: [PATCH] ext4 : fix comments in ext4_swap_extents

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 > > This seems to have fallen through cracks. The patch looks

Re: [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow)

On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote: > IOW, we only get there if our vfsmount was an MNT_INTERNAL one. > So we have mnt->mnt_umount of some MNT_INTERNAL mount found in > ->mnt_pins of some other mount. Which, AFAICS, means that > it used to be mounted on that other mount.

Re: [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow)

On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote: > IOW, we only get there if our vfsmount was an MNT_INTERNAL one. > So we have mnt->mnt_umount of some MNT_INTERNAL mount found in > ->mnt_pins of some other mount. Which, AFAICS, means that > it used to be mounted on that other mount.

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

On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote: > > > On Wed, 18 Apr 2018, Mikulas Patocka wrote: > > > > > > > On Wed, 18 Apr 2018, David Miller wrote: > > > > > From: Mikulas Patocka > > > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT) > > > > > > > The

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

On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote: > > > On Wed, 18 Apr 2018, Mikulas Patocka wrote: > > > > > > > On Wed, 18 Apr 2018, David Miller wrote: > > > > > From: Mikulas Patocka > > > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT) > > > > > > > The structure net_device

[PATCH 0/3] Rework write error handling in pblk

From: Hans Holmberg This patch series fixes the(currently incomplete) write error handling in pblk by: * queuing and re-submitting failed writes in the write buffer * evacuating valid data data in lines with write failures, so the chunk(s) with write failures

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

On Thu, Apr 19, 2018 at 04:22:22PM +0200, Greg KH wrote: > On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote: > > On Thu 19-04-18 15:59:43, Greg KH wrote: > > > On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: > > > > Den 16-04-2018 kl. 19:19, skrev Sasha Levin: > > > > > On

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

On Thu, Apr 19, 2018 at 04:22:22PM +0200, Greg KH wrote: > On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote: > > On Thu 19-04-18 15:59:43, Greg KH wrote: > > > On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: > > > > Den 16-04-2018 kl. 19:19, skrev Sasha Levin: > > > > > On

[PATCH 0/3] Rework write error handling in pblk

From: Hans Holmberg This patch series fixes the(currently incomplete) write error handling in pblk by: * queuing and re-submitting failed writes in the write buffer * evacuating valid data data in lines with write failures, so the chunk(s) with write failures can be reset to a known state

Re: [RFC PATCH v2 2/4] acpi: apei: Split GHES handlers outside of ghes_do_proc

On Thu, Apr 19, 2018 at 10:46:15AM -0500, Alex G. wrote: > The bulk of the function is the if/else mapping from UUID to error > handler. I don't see how that can be easily split up, hence why I > originally resorted to the mapping. As you said, we'll keep it simple at > first. So that function is

Re: [RFC PATCH v2 2/4] acpi: apei: Split GHES handlers outside of ghes_do_proc

On Thu, Apr 19, 2018 at 10:46:15AM -0500, Alex G. wrote: > The bulk of the function is the if/else mapping from UUID to error > handler. I don't see how that can be easily split up, hence why I > originally resorted to the mapping. As you said, we'll keep it simple at > first. So that function is

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