[PATCH v16 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v16 5/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang Acked-by: Allen Hubbe Acked-by: Jon Mason ---

[PATCH v16 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko

[PATCH v16 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Cc: Jon Mason ---

[PATCH v16 1/7] iomap: Use non-raw io functions for io{read|write}XXbe

Fix an asymmetry in the io{read|write}XXbe functions in that the big-endian variants make use of the raw io accessors while the little-endian variants use the regular accessors. Some architectures implement barriers to order against both spinlocks and DMA accesses and for these case, the

[PATCH v16 1/7] iomap: Use non-raw io functions for io{read|write}XXbe

Fix an asymmetry in the io{read|write}XXbe functions in that the big-endian variants make use of the raw io accessors while the little-endian variants use the regular accessors. Some architectures implement barriers to order against both spinlocks and DMA accesses and for these case, the

[PATCH v16 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v16 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

Re: [PATCH V5] USB: Increment wakeup count on remote wakeup.

On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote: > On chromebooks we depend on wakeup count to identify the wakeup source. > But currently USB devices do not increment the wakeup count when they > trigger the remote wake. This patch addresses the same. > > Resume condition is reported

Re: [PATCH V5] USB: Increment wakeup count on remote wakeup.

On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote: > On chromebooks we depend on wakeup count to identify the wakeup source. > But currently USB devices do not increment the wakeup count when they > trigger the remote wake. This patch addresses the same. > > Resume condition is reported

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

Hi Jacob, On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: [...] > +/** > + * enum iommu_inv_granularity - Generic invalidation granularity > + * > + * When an invalidation request is sent to IOMMU to flush translation caches, > + * it may carry different granularity. These granularity

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

Hi Jacob, On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: [...] > +/** > + * enum iommu_inv_granularity - Generic invalidation granularity > + * > + * When an invalidation request is sent to IOMMU to flush translation caches, > + * it may carry different granularity. These granularity

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Fri, Apr 20, 2018 at 9:51 AM Vince Weaver wrote: > On Fri, 20 Apr 2018, Vince Weaver wrote: > > > AFAICT it works on Power and possibly ARM. > > > > at least some ARMs are a bit more honest about it than x86 > > > > ivybridge: > > Performance counter stats for

[PATCH 3/6] virtio_console: free buffers after reset

Console driver is out of spec. The spec says: A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to “unexpose” buffers). and it does exactly that by trying to detach unused buffers without doing a device reset first. Defer detaching the buffers

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Fri, Apr 20, 2018 at 9:51 AM Vince Weaver wrote: > On Fri, 20 Apr 2018, Vince Weaver wrote: > > > AFAICT it works on Power and possibly ARM. > > > > at least some ARMs are a bit more honest about it than x86 > > > > ivybridge: > > Performance counter stats for '/bin/ls': > >

[PATCH 3/6] virtio_console: free buffers after reset

Console driver is out of spec. The spec says: A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to “unexpose” buffers). and it does exactly that by trying to detach unused buffers without doing a device reset first. Defer detaching the buffers

[PATCH 4/6] virtio_console: drop custom control queue cleanup

We now cleanup all VQs on device removal - no need to handle the control VQ specially. Signed-off-by: Michael S. Tsirkin --- drivers/char/virtio_console.c | 17 - 1 file changed, 17 deletions(-) diff --git a/drivers/char/virtio_console.c

[PATCH 1/6] virtio_console: don't tie bufs to a vq

an allocated buffer doesn't need to be tied to a vq - only vq->vdev is ever used. Pass the function the just what it needs - the vdev. Signed-off-by: Michael S. Tsirkin --- drivers/char/virtio_console.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff

[PATCH 4/6] virtio_console: drop custom control queue cleanup

We now cleanup all VQs on device removal - no need to handle the control VQ specially. Signed-off-by: Michael S. Tsirkin --- drivers/char/virtio_console.c | 17 - 1 file changed, 17 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index

[PATCH 1/6] virtio_console: don't tie bufs to a vq

an allocated buffer doesn't need to be tied to a vq - only vq->vdev is ever used. Pass the function the just what it needs - the vdev. Signed-off-by: Michael S. Tsirkin --- drivers/char/virtio_console.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH 0/6] virtio-console: spec compliance fixes

Turns out virtio console tries to take a buffer out of an active vq. Works by sheer luck, and is explicitly forbidden by spec. And while going over it I saw that error handling is also broken - failure is easy to trigger if I force allocations to fail. Lightly tested. Michael S. Tsirkin (6):

[PATCH 0/6] virtio-console: spec compliance fixes

Turns out virtio console tries to take a buffer out of an active vq. Works by sheer luck, and is explicitly forbidden by spec. And while going over it I saw that error handling is also broken - failure is easy to trigger if I force allocations to fail. Lightly tested. Michael S. Tsirkin (6):

[PATCH 2/6] virtio: add ability to iterate over vqs

For cleanup it's helpful to be able to simply scan all vqs and discard all data. Add an iterator to do that. Signed-off-by: Michael S. Tsirkin --- include/linux/virtio.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/virtio.h b/include/linux/virtio.h index

[PATCH 2/6] virtio: add ability to iterate over vqs

For cleanup it's helpful to be able to simply scan all vqs and discard all data. Add an iterator to do that. Signed-off-by: Michael S. Tsirkin --- include/linux/virtio.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/virtio.h b/include/linux/virtio.h index 988c735..fa1b5da

[PATCH 5/6] virtio_console: move removal code

Will make it reusable for error handling. Signed-off-by: Michael S. Tsirkin --- drivers/char/virtio_console.c | 72 +-- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/drivers/char/virtio_console.c

[PATCH 5/6] virtio_console: move removal code

Will make it reusable for error handling. Signed-off-by: Michael S. Tsirkin --- drivers/char/virtio_console.c | 72 +-- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index

[PATCH 6/6] virtio_console: reset on out of memory

When out of memory and we can't add ctrl vq buffers, probe fails. Unfortunately the error handling is out of spec: it calls del_vqs without bothering to reset the device first. To fix, call the full cleanup function in this case. Cc: sta...@vger.kernel.org Signed-off-by: Michael S. Tsirkin

[PATCH 6/6] virtio_console: reset on out of memory

When out of memory and we can't add ctrl vq buffers, probe fails. Unfortunately the error handling is out of spec: it calls del_vqs without bothering to reset the device first. To fix, call the full cleanup function in this case. Cc: sta...@vger.kernel.org Signed-off-by: Michael S. Tsirkin ---

Re: [PATCH v2 2/2] selftests: sparc64: char: Selftest for privileged ADI driver

Doggonit!  Thanks, Wim. I'll send out a new revision shortly. Tom On 04/20/2018 12:08 PM, Wim Coekaerts wrote: Tom, you used the wrong GPL license header. Please fix that to be v2 not v3. The +# SPDX-License-Identifier: GPL-2.0 is correct but the adi-test.c one is not. On 04/20/2018

Re: [PATCH v2 2/2] selftests: sparc64: char: Selftest for privileged ADI driver

Doggonit!  Thanks, Wim. I'll send out a new revision shortly. Tom On 04/20/2018 12:08 PM, Wim Coekaerts wrote: Tom, you used the wrong GPL license header. Please fix that to be v2 not v3. The +# SPDX-License-Identifier: GPL-2.0 is correct but the adi-test.c one is not. On 04/20/2018

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd wrote: > Quoting Rob Herring (2018-04-18 15:29:05) >> diff --git a/Documentation/devicetree/bindings/example-schema.yaml >> b/Documentation/devicetree/bindings/example-schema.yaml >> new file mode 100644 >> index

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd wrote: > Quoting Rob Herring (2018-04-18 15:29:05) >> diff --git a/Documentation/devicetree/bindings/example-schema.yaml >> b/Documentation/devicetree/bindings/example-schema.yaml >> new file mode 100644 >> index ..fe0a3bd1668e >> ---

Re: [PATCH] parisc: time: Convert read_persistent_clock() to read_persistent_clock64()

On 20.04.2018 17:23, Arnd Bergmann wrote: > On Thu, Apr 19, 2018 at 8:51 AM, Baolin Wang wrote: >> The read_persistent_clock() uses a timespec, which is not year 2038 safe >> on 32bit systems. On parisc architecture, we have implemented generic RTC >> drivers that can be

Re: [PATCH] parisc: time: Convert read_persistent_clock() to read_persistent_clock64()

On 20.04.2018 17:23, Arnd Bergmann wrote: > On Thu, Apr 19, 2018 at 8:51 AM, Baolin Wang wrote: >> The read_persistent_clock() uses a timespec, which is not year 2038 safe >> on 32bit systems. On parisc architecture, we have implemented generic RTC >> drivers that can be used to compensate the

Re: [PATCH V3] USB: Increment wakeup count on remote wakeup.

On Fri, Apr 20, 2018 at 10:29 AM, Alan Stern wrote: > On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote: > >> On chromebooks we depend on wakeup count to identify the wakeup source. >> But currently USB devices do not increment the wakeup count when they >> trigger the

Re: [PATCH V3] USB: Increment wakeup count on remote wakeup.

On Fri, Apr 20, 2018 at 10:29 AM, Alan Stern wrote: > On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote: > >> On chromebooks we depend on wakeup count to identify the wakeup source. >> But currently USB devices do not increment the wakeup count when they >> trigger the remote wake. This patch

[PATCH V5] USB: Increment wakeup count on remote wakeup.

On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a

[PATCH V5] USB: Increment wakeup count on remote wakeup.

On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a

[PATCH v4] tracing: remove igrab() iput() call from uprobes.c

Caller of uprobe_register is required to keep the inode and containing mount point referenced. There was misuse of igrab() in uprobes.c and trace_uprobe.c. This is because igrab() will not prevent umount of the containing mount point. To fix this, we added path to struct trace_uprobe, which keeps

[PATCH v4] tracing: remove igrab() iput() call from uprobes.c

Caller of uprobe_register is required to keep the inode and containing mount point referenced. There was misuse of igrab() in uprobes.c and trace_uprobe.c. This is because igrab() will not prevent umount of the containing mount point. To fix this, we added path to struct trace_uprobe, which keeps

Re: [PATCH v2 2/2] selftests: sparc64: char: Selftest for privileged ADI driver

Tom, you used the wrong GPL license header. Please fix that to be v2 not v3. The +# SPDX-License-Identifier: GPL-2.0 is correct but the adi-test.c one is not. On 04/20/2018 10:34 AM, Tom Hromatka wrote: Add a selftest for the sparc64 privileged ADI driver. These tests verify the read(),

Re: [PATCH v2 2/2] selftests: sparc64: char: Selftest for privileged ADI driver

Tom, you used the wrong GPL license header. Please fix that to be v2 not v3. The +# SPDX-License-Identifier: GPL-2.0 is correct but the adi-test.c one is not. On 04/20/2018 10:34 AM, Tom Hromatka wrote: Add a selftest for the sparc64 privileged ADI driver. These tests verify the read(),

Re: [PATCH v2] x86/cpufeature: guard asm_volatile_goto usage with NO_BPF_WORKAROUND

On 4/20/18 1:19 AM, Peter Zijlstra wrote: On Sat, Apr 14, 2018 at 09:27:38PM -0700, Yonghong Song wrote: This patch adds a preprocessor guard NO_BPF_WORKAROUND around the asm_volatile_goto based static_cpu_has(). NO_BPF_WORKAROUND is set at toplevel Makefile when compiler supports asm-goto.

Re: [PATCH v2] x86/cpufeature: guard asm_volatile_goto usage with NO_BPF_WORKAROUND

On 4/20/18 1:19 AM, Peter Zijlstra wrote: On Sat, Apr 14, 2018 at 09:27:38PM -0700, Yonghong Song wrote: This patch adds a preprocessor guard NO_BPF_WORKAROUND around the asm_volatile_goto based static_cpu_has(). NO_BPF_WORKAROUND is set at toplevel Makefile when compiler supports asm-goto.

PROBLEM: error due to conflicting types during build of kselftests

hello, the following is the error found... --- protection_keys.c:421:5: error: conflicting types for ‘pkey_set’ int pkey_set(int pkey, unsigned long rights, unsigned long flags) ^~~~

PROBLEM: error due to conflicting types during build of kselftests

hello, the following is the error found... --- protection_keys.c:421:5: error: conflicting types for ‘pkey_set’ int pkey_set(int pkey, unsigned long rights, unsigned long flags) ^~~~

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON > >>Cc: Vivi, Rodrigo ;

Re: [PATCH] x86/MCE, EDAC/mce_amd: Save all aux registers on SMCA systems

On Fri, Apr 20, 2018 at 01:05:17PM +, Ghannam, Yazen wrote: > Okay, I can do that. What about using mce_rdmsrl()? The value gets set to > 0 and a user gets a single warning. This may be more clear to the user. Also, > it shouldn't affect code that checks for non-zero values, like in >

Re: [PATCH] x86/MCE, EDAC/mce_amd: Save all aux registers on SMCA systems

On Fri, Apr 20, 2018 at 01:05:17PM +, Ghannam, Yazen wrote: > Okay, I can do that. What about using mce_rdmsrl()? The value gets set to > 0 and a user gets a single warning. This may be more clear to the user. Also, > it shouldn't affect code that checks for non-zero values, like in >

Re: [PATCH] cifs: dir: fix memory leak in cifs_mknod

2018-04-20 10:37 GMT-07:00 Steve French : > I noticed a similar problem with the tcon link leak on that (which > Colin and Gustavo pointed out - thank you!) but also in another return > statement, so updated the original patch of Ronnie's merging the fixes > >

Re: [PATCH] cifs: dir: fix memory leak in cifs_mknod

2018-04-20 10:37 GMT-07:00 Steve French : > I noticed a similar problem with the tcon link leak on that (which > Colin and Gustavo pointed out - thank you!) but also in another return > statement, so updated the original patch of Ronnie's merging the fixes > >

BUG: unable to handle kernel paging request in build_segment_manager

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=83699adeb2d13579c31e C

BUG: unable to handle kernel paging request in build_segment_manager

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=83699adeb2d13579c31e C

[GIT PULL] arm64 fixes for 4.17-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.17-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On Tue, Apr 10, 2018 at 09:33:39AM +, Kirill A. Shutemov wrote: > AMD SME claims one bit from physical address to indicate whether the > page is encrypted or not. To achieve that we clear out the bit from > __PHYSICAL_MASK. > > The capability to adjust __PHYSICAL_MASK is required beyond AMD

Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME

On Tue, Apr 10, 2018 at 09:33:39AM +, Kirill A. Shutemov wrote: > AMD SME claims one bit from physical address to indicate whether the > page is encrypted or not. To achieve that we clear out the bit from > __PHYSICAL_MASK. > > The capability to adjust __PHYSICAL_MASK is required beyond AMD

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

2018-04-20 7:55 GMT-07:00 Tom Talpey : > Looks good, but I have two possibly style-related comments. > > > On 4/19/2018 5:38 PM, Long Li wrote: >> >> From: Long Li >> >> The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page >> will >>

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

2018-04-20 7:55 GMT-07:00 Tom Talpey : > Looks good, but I have two possibly style-related comments. > > > On 4/19/2018 5:38 PM, Long Li wrote: >> >> 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

test mail

this is a test mail -- software engineer rajagiri school of engineering and technology

test mail

this is a test mail -- software engineer rajagiri school of engineering and technology

RE: [PATCH] platform/x86: Kconfig: Fix dell-laptop dependency chain.

> -Original Message- > From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-x86- > ow...@vger.kernel.org] On Behalf Of Randy Dunlap > Sent: Friday, April 20, 2018 12:53 PM > To: Limonciello, Mario; dvh...@infradead.org; Andy Shevchenko > Cc: LKML;

RE: [PATCH] platform/x86: Kconfig: Fix dell-laptop dependency chain.

> -Original Message- > From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-x86- > ow...@vger.kernel.org] On Behalf Of Randy Dunlap > Sent: Friday, April 20, 2018 12:53 PM > To: Limonciello, Mario; dvh...@infradead.org; Andy Shevchenko > Cc: LKML;

Re: general protection fault in kernfs_kill_sb

On Fri, Apr 20, 2018 at 09:31:58AM +0200, Michal Hocko wrote: > On Fri 20-04-18 14:29:39, Tetsuo Handa wrote: > > Eric Biggers wrote: > > > But, there is still a related bug: when mounting sysfs, if > > > register_shrinker() > > > fails in sget_userns(), then kernfs_kill_sb() gets called, which

Re: general protection fault in kernfs_kill_sb

On Fri, Apr 20, 2018 at 09:31:58AM +0200, Michal Hocko wrote: > On Fri 20-04-18 14:29:39, Tetsuo Handa wrote: > > Eric Biggers wrote: > > > But, there is still a related bug: when mounting sysfs, if > > > register_shrinker() > > > fails in sget_userns(), then kernfs_kill_sb() gets called, which

Re: [PATCH ghak80 V1] audit: add syscall information to FEATURE_CHANGE records

On 2018-04-20 11:58, Paul Moore wrote: > On Fri, Apr 20, 2018 at 9:46 AM, Richard Guy Briggs wrote: > > On 2018-04-17 18:06, Paul Moore wrote: > >> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs > >> wrote: > >> > Tie syscall information to FEATURE_CHANGE

Re: [PATCH ghak80 V1] audit: add syscall information to FEATURE_CHANGE records

On 2018-04-20 11:58, Paul Moore wrote: > On Fri, Apr 20, 2018 at 9:46 AM, Richard Guy Briggs wrote: > > On 2018-04-17 18:06, Paul Moore wrote: > >> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs > >> wrote: > >> > Tie syscall information to FEATURE_CHANGE calls since it is a result of > >>

[PATCH V4] USB: Increment wakeup count on remote wakeup.

On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a

[PATCH V4] USB: Increment wakeup count on remote wakeup.

On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a

Re: [PATCH] platform/x86: Kconfig: Fix dell-laptop dependency chain.

On 04/20/18 10:42, Mario Limonciello wrote: > As reported by Randy Dunlap: >>> WARNING: unmet direct dependencies detected for DELL_SMBIOS >>> Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y] >>> && (DCDBAS [=m] || >>> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n) >>> Selected

Re: [PATCH] platform/x86: Kconfig: Fix dell-laptop dependency chain.

On 04/20/18 10:42, Mario Limonciello wrote: > As reported by Randy Dunlap: >>> WARNING: unmet direct dependencies detected for DELL_SMBIOS >>> Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y] >>> && (DCDBAS [=m] || >>> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n) >>> Selected

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Fri, Apr 20, 2018 at 7:50 PM, Catalin Marinas wrote: > On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote: >> __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now. >> But it's a wrong combination. As __GFP_NOFAIL is blockable, but >>

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Fri, Apr 20, 2018 at 7:50 PM, Catalin Marinas wrote: > On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote: >> __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now. >> But it's a wrong combination. As __GFP_NOFAIL is blockable, but >> __GFP_NORETY is not blockable, make

Re: [PATCH v3 2/2] tracing: remove igrab() iput() call from uprobes.c

On Fri, 20 Apr 2018 09:56:25 -0700 Song Liu wrote: > Caller of uprobe_register is required to keep the inode and containing > mount point referenced. I would add a little more background to why this is the case. Also a possible link to the conversation? Link:

Re: [PATCH v3 2/2] tracing: remove igrab() iput() call from uprobes.c

On Fri, 20 Apr 2018 09:56:25 -0700 Song Liu wrote: > Caller of uprobe_register is required to keep the inode and containing > mount point referenced. I would add a little more background to why this is the case. Also a possible link to the conversation? Link:

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote: > __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now. > But it's a wrong combination. As __GFP_NOFAIL is blockable, but > __GFP_NORETY is not blockable, make it self-contradiction. > > __GFP_NOFAIL means 'The VM

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote: > __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now. > But it's a wrong combination. As __GFP_NOFAIL is blockable, but > __GFP_NORETY is not blockable, make it self-contradiction. > > __GFP_NOFAIL means 'The VM

RE: kernel panics with 4.14.X versions

> From: Jan Kara > Sent: Friday, April 20, 2018 03:22 > On Thu 19-04-18 21:37:25, Dexuan Cui wrote: > > > 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 /

RE: kernel panics with 4.14.X versions

> From: Jan Kara > Sent: Friday, April 20, 2018 03:22 > On Thu 19-04-18 21:37:25, Dexuan Cui wrote: > > > 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

Re: [PATCH] cifs: dir: fix memory leak in cifs_mknod

Hi Steve, On 04/20/2018 12:37 PM, Steve French wrote: I noticed a similar problem with the tcon link leak on that (which Colin and Gustavo pointed out - thank you!) but also in another return statement, so updated the original patch of Ronnie's merging the fixes

Re: [PATCH] cifs: dir: fix memory leak in cifs_mknod

Hi Steve, On 04/20/2018 12:37 PM, Steve French wrote: I noticed a similar problem with the tcon link leak on that (which Colin and Gustavo pointed out - thank you!) but also in another return statement, so updated the original patch of Ronnie's merging the fixes

[PATCH] platform/x86: Kconfig: Fix dell-laptop dependency chain.

As reported by Randy Dunlap: >> WARNING: unmet direct dependencies detected for DELL_SMBIOS >> Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y] >> && (DCDBAS [=m] || >> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n) >> Selected by [y]: >> - DELL_LAPTOP [=y] && X86 [=y] &&

[PATCH] platform/x86: Kconfig: Fix dell-laptop dependency chain.

As reported by Randy Dunlap: >> WARNING: unmet direct dependencies detected for DELL_SMBIOS >> Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y] >> && (DCDBAS [=m] || >> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n) >> Selected by [y]: >> - DELL_LAPTOP [=y] && X86 [=y] &&

Re: [PATCH] Input: atmel_mxt_ts - fix reset-gpio for level based irqs

Hi Sebastian, On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote: > The current reset-gpio support triggers an interrupt storm on platforms > using the maxtouch with level based interrupt. The Motorola Droid 4, > which I used for some of the tests is not affected, since it uses a level >

Re: [PATCH] Input: atmel_mxt_ts - fix reset-gpio for level based irqs

Hi Sebastian, On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote: > The current reset-gpio support triggers an interrupt storm on platforms > using the maxtouch with level based interrupt. The Motorola Droid 4, > which I used for some of the tests is not affected, since it uses a level >

RE: linux-next: Tree for Apr 19 (dell smbios SMM)

> > Hi, > I've attached it here. > > thanks, > -- > ~Randy Thanks. Darren's patch. It was supposed to be prevented by 32d7b19bad9695c4c9026b0ceb3a384561ddee70 (see comment in Kconfig). # # The DELL_SMBIOS driver depends on

RE: linux-next: Tree for Apr 19 (dell smbios SMM)

> > Hi, > I've attached it here. > > thanks, > -- > ~Randy Thanks. Darren's patch. It was supposed to be prevented by 32d7b19bad9695c4c9026b0ceb3a384561ddee70 (see comment in Kconfig). # # The DELL_SMBIOS driver depends on

[PATCH 2/2] arm64: defconfig: Enable dw_mmc-bluefield driver

This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH] cifs: dir: fix memory leak in cifs_mknod

I noticed a similar problem with the tcon link leak on that (which Colin and Gustavo pointed out - thank you!) but also in another return statement, so updated the original patch of Ronnie's merging the fixes

[PATCH 2/2] arm64: defconfig: Enable dw_mmc-bluefield driver

This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig

Re: [PATCH] cifs: dir: fix memory leak in cifs_mknod

I noticed a similar problem with the tcon link leak on that (which Colin and Gustavo pointed out - thank you!) but also in another return statement, so updated the original patch of Ronnie's merging the fixes

Re: [ANNOUNCE] v4.14.34-rt27

On 2018-04-16 09:26:00 [+0200], Mike Galbraith wrote: > On Fri, 2018-04-13 at 23:52 +0200, Sebastian Andrzej Siewior wrote: > > > > - Inter-event (latency) fixes by Tom Zanussi. > >  CC  kernel/trace/trace_events_hist.o > kernel/trace/trace_events_hist.c: In function

Re: [ANNOUNCE] v4.14.34-rt27

On 2018-04-16 09:26:00 [+0200], Mike Galbraith wrote: > On Fri, 2018-04-13 at 23:52 +0200, Sebastian Andrzej Siewior wrote: > > > > - Inter-event (latency) fixes by Tom Zanussi. > >  CC  kernel/trace/trace_events_hist.o > kernel/trace/trace_events_hist.c: In function

Re: [PATCH] PCI: Add PCIe to pcie_print_link_status() messages

On Fri, Apr 13, 2018 at 11:16:38AM -0700, Jakub Kicinski wrote: > Currently the pcie_print_link_status() will print PCIe bandwidth > and link width information but does not mention it is pertaining > to the PCIe. Since this and related functions are used exclusively > by networking drivers today

Re: [PATCH] PCI: Add PCIe to pcie_print_link_status() messages

On Fri, Apr 13, 2018 at 11:16:38AM -0700, Jakub Kicinski wrote: > Currently the pcie_print_link_status() will print PCIe bandwidth > and link width information but does not mention it is pertaining > to the PCIe. Since this and related functions are used exclusively > by networking drivers today

Re: [PATCH V3] USB: Increment wakeup count on remote wakeup.

On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote: > On chromebooks we depend on wakeup count to identify the wakeup source. > But currently USB devices do not increment the wakeup count when they > trigger the remote wake. This patch addresses the same. > > Resume condition is reported

Re: [PATCH V3] USB: Increment wakeup count on remote wakeup.

On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote: > On chromebooks we depend on wakeup count to identify the wakeup source. > But currently USB devices do not increment the wakeup count when they > trigger the remote wake. This patch addresses the same. > > Resume condition is reported

[PATCH v2 0/2] sparc64: Add privileged ADI driver

ADI is a feature supported on SPARC M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data

[PATCH v2 0/2] sparc64: Add privileged ADI driver

ADI is a feature supported on SPARC M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data

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