RE: [RFC PATCH 05/09] Change RDMA send to regonize page offset in the 1st page

> Subject: Re: [RFC PATCH 05/09] Change RDMA send to regonize page offset > in the 1st page > > On 5/17/2018 5:22 PM, Long Li wrote: > > From: Long Li > > There's a typo "recognize" in the patch title > > > > When doing RDMA send, the offset needs to be checked as data

RE: [RFC PATCH 05/09] Change RDMA send to regonize page offset in the 1st page

> Subject: Re: [RFC PATCH 05/09] Change RDMA send to regonize page offset > in the 1st page > > On 5/17/2018 5:22 PM, Long Li wrote: > > From: Long Li > > There's a typo "recognize" in the patch title > > > > When doing RDMA send, the offset needs to be checked as data may start > > in an

Re: [PATCH 1/2] m68k: Set default dma mask for platform devices

On Fri, 18 May 2018, Christoph Hellwig wrote: > > This implementation of arch_setup_pdev_archdata() differs from the > > powerpc one, in that this one avoids clobbering a device dma mask > > which has already been initialized. > > I think your implementation should move into the generic

Re: [PATCH 1/2] m68k: Set default dma mask for platform devices

On Fri, 18 May 2018, Christoph Hellwig wrote: > > This implementation of arch_setup_pdev_archdata() differs from the > > powerpc one, in that this one avoids clobbering a device dma mask > > which has already been initialized. > > I think your implementation should move into the generic

atención

usuarios de webmail Tenga en cuenta que el 95% de sus correos electrónicos recibidos después de actualizar el servidor webmail recientemente en nuestra base de datos se han suspendido. Reciba su mensaje regularmente. Nuestro personal técnico actualizará su cuenta dentro de los tres días

atención

usuarios de webmail Tenga en cuenta que el 95% de sus correos electrónicos recibidos después de actualizar el servidor webmail recientemente en nuestra base de datos se han suspendido. Reciba su mensaje regularmente. Nuestro personal técnico actualizará su cuenta dentro de los tres días

Re: [PATCH v2 1/4] seccomp: add a return code to trap to userspace

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

Re: [PATCH v2 1/4] seccomp: add a return code to trap to userspace

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

[PATCH v2 1/2] [usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver

The ALWAYS_SYNC flag is currently honored by the usb-storage driver but not UAS and is required to work around devices that become unstable upon being queried for cache. This code is taken straight from: drivers/usb/storage/scsiglue.c:284 Signed-off-by: Alexander Kappner ---

[PATCH v2 2/2] [usb-storage] Add compatibility quirk flags for G-Technologies G-Drive

The "G-Drive" (sold by G-Technology) external USB 3.0 drive hangs on write access under UAS and usb-storage: [ 136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current] [

[PATCH v2 0/2] Re: usb-storage: Add quirks to make G-Technology "G-Drive" work

v2 of this patch implements the FL_ALWAYS_SYNC flag in the UAS driver, and then adds the flag as quirks for the device at issue. This allows the G-Drive to work under both UAS and usb-storage. Alexander Kappner (2): [usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver

[PATCH v2 1/2] [usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver

The ALWAYS_SYNC flag is currently honored by the usb-storage driver but not UAS and is required to work around devices that become unstable upon being queried for cache. This code is taken straight from: drivers/usb/storage/scsiglue.c:284 Signed-off-by: Alexander Kappner ---

[PATCH v2 2/2] [usb-storage] Add compatibility quirk flags for G-Technologies G-Drive

The "G-Drive" (sold by G-Technology) external USB 3.0 drive hangs on write access under UAS and usb-storage: [ 136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current] [

[PATCH v2 0/2] Re: usb-storage: Add quirks to make G-Technology "G-Drive" work

v2 of this patch implements the FL_ALWAYS_SYNC flag in the UAS driver, and then adds the flag as quirks for the device at issue. This allows the G-Drive to work under both UAS and usb-storage. Alexander Kappner (2): [usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver

Re: [PATCH 5/6] x86: refcount: prevent gcc distortions

Hi Nadav, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc5 next-20180517] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 5/6] x86: refcount: prevent gcc distortions

Hi Nadav, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc5 next-20180517] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 9:12 PM Linus Torvalds < torva...@linux-foundation.org> wrote: > (So we'd still have a "sb_maxbytes" that filesystems would fill in, but it > would only be used as a "fill in inode value for regular files for this > superblock"). Actually, maybe we could just make

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 9:12 PM Linus Torvalds < torva...@linux-foundation.org> wrote: > (So we'd still have a "sb_maxbytes" that filesystems would fill in, but it > would only be used as a "fill in inode value for regular files for this > superblock"). Actually, maybe we could just make

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 8:43 PM Al Viro wrote: > Not quite. The things like > if (unlikely(*ppos >= inode->i_sb->s_maxbytes)) > return 0; > iov_iter_truncate(iter, inode->i_sb->s_maxbytes); > protect most of the regular files (see

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 8:43 PM Al Viro wrote: > Not quite. The things like > if (unlikely(*ppos >= inode->i_sb->s_maxbytes)) > return 0; > iov_iter_truncate(iter, inode->i_sb->s_maxbytes); > protect most of the regular files (see mm/filemap.c). And for

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 08:33:37PM -0700, Linus Torvalds wrote: > On Fri, May 18, 2018 at 8:20 PM Linus Torvalds < > torva...@linux-foundation.org> wrote: > > > I'd *much* rather just set FMODE_UNSIGNED_OFFSET for /proc/vmcore _only_, > > rather than open up all proc files to issues with 4G+

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 08:33:37PM -0700, Linus Torvalds wrote: > On Fri, May 18, 2018 at 8:20 PM Linus Torvalds < > torva...@linux-foundation.org> wrote: > > > I'd *much* rather just set FMODE_UNSIGNED_OFFSET for /proc/vmcore _only_, > > rather than open up all proc files to issues with 4G+

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 8:20 PM Linus Torvalds < torva...@linux-foundation.org> wrote: > I'd *much* rather just set FMODE_UNSIGNED_OFFSET for /proc/vmcore _only_, > rather than open up all proc files to issues with 4G+ offsets. Hmm. I was going to point to the s_maxbytes check in

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 8:20 PM Linus Torvalds < torva...@linux-foundation.org> wrote: > I'd *much* rather just set FMODE_UNSIGNED_OFFSET for /proc/vmcore _only_, > rather than open up all proc files to issues with 4G+ offsets. Hmm. I was going to point to the s_maxbytes check in

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 8:15 PM Vasily Gorbik wrote: > Commit be83bbf80682 ("mmap: introduce sane default mmap limits") > introduced "pgoff" limits checks for mmap, considering fs max file size > as upper limit, which made it impossible to mmap /proc/vmcore file > contents

Re: [PATCH] procfs: fix mmap() for /proc/vmcore

On Fri, May 18, 2018 at 8:15 PM Vasily Gorbik wrote: > Commit be83bbf80682 ("mmap: introduce sane default mmap limits") > introduced "pgoff" limits checks for mmap, considering fs max file size > as upper limit, which made it impossible to mmap /proc/vmcore file > contents above 2Gb

[PATCH] procfs: fix mmap() for /proc/vmcore

Procfs does not set max file size (s_maxbytes) and ends up with default value of MAX_NON_LFS ((1UL<<31) - 1) Commit be83bbf80682 ("mmap: introduce sane default mmap limits") introduced "pgoff" limits checks for mmap, considering fs max file size as upper limit, which made it impossible to

[PATCH] procfs: fix mmap() for /proc/vmcore

Procfs does not set max file size (s_maxbytes) and ends up with default value of MAX_NON_LFS ((1UL<<31) - 1) Commit be83bbf80682 ("mmap: introduce sane default mmap limits") introduced "pgoff" limits checks for mmap, considering fs max file size as upper limit, which made it impossible to

[v4.17-rc5][bisected] be83bbf80682 breaks /proc/vmcore mmap

Greetings, be83bbf80682 "mmap: introduce sane default mmap limits" introduced a problem with mapping /proc/vmcore if it is bigger than 2gb. This breaks s390 kernel zfcpdump. But it should be a general problem. Please consider the following one-liner fix, if it makes sense. Vasily Gorbik (1):

[v4.17-rc5][bisected] be83bbf80682 breaks /proc/vmcore mmap

Greetings, be83bbf80682 "mmap: introduce sane default mmap limits" introduced a problem with mapping /proc/vmcore if it is bigger than 2gb. This breaks s390 kernel zfcpdump. But it should be a general problem. Please consider the following one-liner fix, if it makes sense. Vasily Gorbik (1):

Re: [PATCH] net: sched: don't disable bh when accessing action idr

On Fri, May 18, 2018 at 8:45 AM, Vlad Buslov wrote: > Underlying implementation of action map has changed and doesn't require > disabling bh anymore. Replace all action idr spinlock usage with regular > calls that do not disable bh. Please explain explicitly why it is not

Re: [PATCH] net: sched: don't disable bh when accessing action idr

On Fri, May 18, 2018 at 8:45 AM, Vlad Buslov wrote: > Underlying implementation of action map has changed and doesn't require > disabling bh anymore. Replace all action idr spinlock usage with regular > calls that do not disable bh. Please explain explicitly why it is not required, don't let

[PATCH 05/12] arm: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit. Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato

[PATCH 05/12] arm: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit. Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Will

[PATCH 06/12] arm64: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit. Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato

[PATCH 09/12] xtensa: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato

[PATCH 06/12] arm64: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit. Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Will

[PATCH 09/12] xtensa: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Will

[PATCH 12/12] perf/breakpoint: Clean up and consolidate modify_user_hw_breakpoint_check()

Remove the dance around old and new attributes. Just don't modify the previous breakpoint at all until we have verified everything. Reported-by: Linus Torvalds Original-patch-by: Andy Lutomirski Signed-off-by: Frederic Weisbecker

[PATCH 10/12] perf/breakpoint: Remove default hw_breakpoint_arch_parse()

All architectures have implemented it, we can now remove the poor weak version. Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker

[PATCH 08/12] sh: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato

[PATCH 12/12] perf/breakpoint: Clean up and consolidate modify_user_hw_breakpoint_check()

Remove the dance around old and new attributes. Just don't modify the previous breakpoint at all until we have verified everything. Reported-by: Linus Torvalds Original-patch-by: Andy Lutomirski Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc:

[PATCH 10/12] perf/breakpoint: Remove default hw_breakpoint_arch_parse()

All architectures have implemented it, we can now remove the poor weak version. Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Will Deacon Cc: Mark Rutland Cc: Max Filippov Cc: Chris

[PATCH 08/12] sh: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Will

[PATCH 11/12] perf/breakpoint: Pass new breakpoint type to modify_breakpoint_slot()

We soon won't be able to rely on bp->attr anymore to get the new type of the modifying breakpoint because the new attributes are going to be copied only once we successfully modified the breakpoint slot. This will fix the current misdesigned layout where the new attr are copied to the modifying

[PATCH 11/12] perf/breakpoint: Pass new breakpoint type to modify_breakpoint_slot()

We soon won't be able to rely on bp->attr anymore to get the new type of the modifying breakpoint because the new attributes are going to be copied only once we successfully modified the breakpoint slot. This will fix the current misdesigned layout where the new attr are copied to the modifying

[PATCH 03/12] x86: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit. Original-patch-by: Andy Lutomirski Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc:

[PATCH 02/12] perf/breakpoint: Pass arch breakpoint struct to arch_check_bp_in_kernelspace()

We can't pass the breakpoint directly on arch_check_bp_in_kernelspace() anymore because its architecture internal datas (struct arch_hw_breakpoint) are not yet filled by the time we call the function, and most implementation need this backend to be up to date. So arrange the function to take the

[PATCH 03/12] x86: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit. Original-patch-by: Andy Lutomirski Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo

[PATCH 02/12] perf/breakpoint: Pass arch breakpoint struct to arch_check_bp_in_kernelspace()

We can't pass the breakpoint directly on arch_check_bp_in_kernelspace() anymore because its architecture internal datas (struct arch_hw_breakpoint) are not yet filled by the time we call the function, and most implementation need this backend to be up to date. So arrange the function to take the

[PATCH 04/12] powerpc: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato

[PATCH 07/12] sh: Remove "struct arch_hw_breakpoint::name" unused field

This field seem to be unused, perhaps a leftover from old code... Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc:

[PATCH 04/12] powerpc: Implement hw_breakpoint_arch_parse()

Migrate to the new API in order to remove arch_validate_hwbkpt_settings() that clumsily mixes up architecture validation and commit Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Will

[PATCH 07/12] sh: Remove "struct arch_hw_breakpoint::name" unused field

This field seem to be unused, perhaps a leftover from old code... Signed-off-by: Frederic Weisbecker Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: Rich Felker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Will Deacon Cc: Mark Rutland Cc: Max Filippov Cc: Chris Zankel Cc:

[PATCH 01/12] perf/breakpoint: Split attribute parse and commit

arch_validate_hwbkpt_settings() mixes up attribute check and commit into a single code entity. Therefore the validation may return an error due to incorrect atributes while still leaving halfway modified architecture breakpoint data. This is harmless when we deal with a new breakpoint but it

[PATCH 01/12] perf/breakpoint: Split attribute parse and commit

arch_validate_hwbkpt_settings() mixes up attribute check and commit into a single code entity. Therefore the validation may return an error due to incorrect atributes while still leaving halfway modified architecture breakpoint data. This is harmless when we deal with a new breakpoint but it

[PATCH 00/12] breakpoint: Rework arch validation v2

Changes since v1: - Avoid arch code duplication between check and commit. Use a temporary struct arch_hw_breakpoint to fill up arch data on the fly (Mark Rutland) - Start with a default weak version of hw_breakpoint_arch_parse() that architectures override one by one (Peter Zijlstra, Andy

[PATCH 00/12] breakpoint: Rework arch validation v2

Changes since v1: - Avoid arch code duplication between check and commit. Use a temporary struct arch_hw_breakpoint to fill up arch data on the fly (Mark Rutland) - Start with a default weak version of hw_breakpoint_arch_parse() that architectures override one by one (Peter Zijlstra, Andy

Re: [PATCH 8/9] perf/breakpoint: Split breakpoint "check" and "commit"

On Tue, May 15, 2018 at 09:58:03PM -0700, Andy Lutomirski wrote: > > > > On May 15, 2018, at 8:11 PM, Frederic Weisbecker > > wrote: > > > >> On Wed, May 09, 2018 at 11:17:03AM +0200, Peter Zijlstra wrote: > >>> On Sun, May 06, 2018 at 09:19:54PM +0200, Frederic

Re: [PATCH 8/9] perf/breakpoint: Split breakpoint "check" and "commit"

On Tue, May 15, 2018 at 09:58:03PM -0700, Andy Lutomirski wrote: > > > > On May 15, 2018, at 8:11 PM, Frederic Weisbecker > > wrote: > > > >> On Wed, May 09, 2018 at 11:17:03AM +0200, Peter Zijlstra wrote: > >>> On Sun, May 06, 2018 at 09:19:54PM +0200, Frederic Weisbecker wrote: > >>>

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 3:25 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: >> Here is the function: >> 00400842 : >> 400842: 53 push %rbx >> 400843: 55 push %rbp >> 400844: 41 54 push %r12 >> 400846: 41

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 3:25 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: >> Here is the function: >> 00400842 : >> 400842: 53 push %rbx >> 400843: 55 push %rbp >> 400844: 41 54 push %r12 >> 400846: 41

Re: [RFC v4 3/5] virtio_ring: add packed ring support

On Sat, May 19, 2018 at 09:12:30AM +0800, Jason Wang wrote: > On 2018年05月18日 22:33, Tiwei Bie wrote: > > On Fri, May 18, 2018 at 09:17:05PM +0800, Jason Wang wrote: > > > On 2018年05月18日 19:29, Tiwei Bie wrote: > > > > On Thu, May 17, 2018 at 08:01:52PM +0800, Jason Wang wrote: > > > > > On

Re: [RFC v4 3/5] virtio_ring: add packed ring support

On Sat, May 19, 2018 at 09:12:30AM +0800, Jason Wang wrote: > On 2018年05月18日 22:33, Tiwei Bie wrote: > > On Fri, May 18, 2018 at 09:17:05PM +0800, Jason Wang wrote: > > > On 2018年05月18日 19:29, Tiwei Bie wrote: > > > > On Thu, May 17, 2018 at 08:01:52PM +0800, Jason Wang wrote: > > > > > On

Re: Tasks RCU vs Preempt RCU

On Fri, May 18, 2018 at 11:36:23AM -0700, Joel Fernandes wrote: > Hi, > > I was thinking about tasks-RCU and why its needed. Since preempt-RCU allows > tasks to be preempted in read-sections, can we not just reuse that mechanism > for the trampolines since we track all preempted tasks so we would

Re: Tasks RCU vs Preempt RCU

On Fri, May 18, 2018 at 11:36:23AM -0700, Joel Fernandes wrote: > Hi, > > I was thinking about tasks-RCU and why its needed. Since preempt-RCU allows > tasks to be preempted in read-sections, can we not just reuse that mechanism > for the trampolines since we track all preempted tasks so we would

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 3:22 GMT+01:00 Dmitry Safonov : > On Fri, 2018-05-18 at 19:05 -0700, Andy Lutomirski wrote: >> > On May 18, 2018, at 4:10 PM, Dmitry Safonov <0x7f454...@gmail.com> >> > cpu family: 6 >> > model: 142 >> > model name: Intel(R) Core(TM) i7-7600U CPU @

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 3:22 GMT+01:00 Dmitry Safonov : > On Fri, 2018-05-18 at 19:05 -0700, Andy Lutomirski wrote: >> > On May 18, 2018, at 4:10 PM, Dmitry Safonov <0x7f454...@gmail.com> >> > cpu family: 6 >> > model: 142 >> > model name: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz >> > But I

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

On Fri, 2018-05-18 at 19:05 -0700, Andy Lutomirski wrote: > > On May 18, 2018, at 4:10 PM, Dmitry Safonov <0x7f454...@gmail.com> > > cpu family: 6 > > model: 142 > > model name: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz > > But I usually test kernels in VM. So, I use virt-manager as

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

On Fri, 2018-05-18 at 19:05 -0700, Andy Lutomirski wrote: > > On May 18, 2018, at 4:10 PM, Dmitry Safonov <0x7f454...@gmail.com> > > cpu family: 6 > > model: 142 > > model name: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz > > But I usually test kernels in VM. So, I use virt-manager as

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

> On May 18, 2018, at 4:10 PM, Dmitry Safonov <0x7f454...@gmail.com> wrote: > Hi Andy, > 2018-05-18 23:03 GMT+01:00 Andy Lutomirski : >>> On Thu, May 17, 2018 at 4:40 PM Dmitry Safonov wrote: >>> Some selftests are failing, but the same way as before the patch

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

> On May 18, 2018, at 4:10 PM, Dmitry Safonov <0x7f454...@gmail.com> wrote: > Hi Andy, > 2018-05-18 23:03 GMT+01:00 Andy Lutomirski : >>> On Thu, May 17, 2018 at 4:40 PM Dmitry Safonov wrote: >>> Some selftests are failing, but the same way as before the patch >>> (ITOW, it's not regression):

Re: [PATCH 03/18] printk: Convert pr_fmt from blank define to KBUILD_MODNAME

On Fri, 2018-05-18 at 23:29 +0300, Andy Shevchenko wrote: > On Fri, May 18, 2018 at 12:10 PM, Joe Perches wrote: > > On Fri, 2018-05-18 at 10:42 +0200, Petr Mladek wrote: > > > On Thu 2018-05-10 08:45:29, Joe Perches wrote: > > > [0.00] libftrace: ftrace: allocating

Re: [PATCH 03/18] printk: Convert pr_fmt from blank define to KBUILD_MODNAME

On Fri, 2018-05-18 at 23:29 +0300, Andy Shevchenko wrote: > On Fri, May 18, 2018 at 12:10 PM, Joe Perches wrote: > > On Fri, 2018-05-18 at 10:42 +0200, Petr Mladek wrote: > > > On Thu 2018-05-10 08:45:29, Joe Perches wrote: > > > [0.00] libftrace: ftrace: allocating 40753 entries in 160

Re: [v0 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver

Hi Taniya, Thank you for the patch! Yet something to improve: [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.17-rc5 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [v0 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver

Hi Taniya, Thank you for the patch! Yet something to improve: [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.17-rc5 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

MANAGER AUDIT AND ACCOUNTING DEPARTMENT

FROM MR NELSON CAPPER MANAGER AUDIT AND ACCOUNTING DEPARTMENT KOREA DEVELOPMENT BANK (K.D.B) LONDON U.K PLEASE READ CAREFULLY This message might meet you in utmost surprise. However, it’s just my urgent need for foreign partner that made me to contact you for this transaction. I am Mr, Nelson

MANAGER AUDIT AND ACCOUNTING DEPARTMENT

FROM MR NELSON CAPPER MANAGER AUDIT AND ACCOUNTING DEPARTMENT KOREA DEVELOPMENT BANK (K.D.B) LONDON U.K PLEASE READ CAREFULLY This message might meet you in utmost surprise. However, it’s just my urgent need for foreign partner that made me to contact you for this transaction. I am Mr, Nelson

Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option

On 5/18/2018 1:58 PM, Long Li wrote: Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option On Fri, May 18, 2018 at 12:00 PM, Long Li via samba-technical wrote: Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option On Thu, May 17, 2018 at 05:22:14PM -0700, Long Li

Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option

On 5/18/2018 1:58 PM, Long Li wrote: Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option On Fri, May 18, 2018 at 12:00 PM, Long Li via samba-technical wrote: Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option On Thu, May 17, 2018 at 05:22:14PM -0700, Long Li

[PATCH v3] usbip: vhci_sysfs: fix potential Spectre v1

pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis'

[PATCH v3] usbip: vhci_sysfs: fix potential Spectre v1

pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis'

Re: [RFC v4 3/5] virtio_ring: add packed ring support

On 2018年05月18日 22:33, Tiwei Bie wrote: On Fri, May 18, 2018 at 09:17:05PM +0800, Jason Wang wrote: On 2018年05月18日 19:29, Tiwei Bie wrote: On Thu, May 17, 2018 at 08:01:52PM +0800, Jason Wang wrote: On 2018年05月16日 22:33, Tiwei Bie wrote: On Wed, May 16, 2018 at 10:05:44PM +0800, Jason Wang

Re: [RFC v4 3/5] virtio_ring: add packed ring support

On 2018年05月18日 22:33, Tiwei Bie wrote: On Fri, May 18, 2018 at 09:17:05PM +0800, Jason Wang wrote: On 2018年05月18日 19:29, Tiwei Bie wrote: On Thu, May 17, 2018 at 08:01:52PM +0800, Jason Wang wrote: On 2018年05月16日 22:33, Tiwei Bie wrote: On Wed, May 16, 2018 at 10:05:44PM +0800, Jason Wang

Re: [RFC PATCH 05/09] Change RDMA send to regonize page offset in the 1st page

On 5/17/2018 5:22 PM, Long Li wrote: From: Long Li There's a typo "recognize" in the patch title When doing RDMA send, the offset needs to be checked as data may start in an offset in the 1st page. Doesn't this patch alter the generic smb2pdu.c code too? I think

Re: [RFC PATCH 05/09] Change RDMA send to regonize page offset in the 1st page

On 5/17/2018 5:22 PM, Long Li wrote: From: Long Li There's a typo "recognize" in the patch title When doing RDMA send, the offset needs to be checked as data may start in an offset in the 1st page. Doesn't this patch alter the generic smb2pdu.c code too? I think this should note "any"

Re: [PATCH net] tuntap: raise EPOLLOUT on device up

On 2018年05月18日 22:46, Michael S. Tsirkin wrote: On Fri, May 18, 2018 at 10:11:54PM +0800, Jason Wang wrote: On 2018年05月18日 22:06, Michael S. Tsirkin wrote: On Fri, May 18, 2018 at 10:00:31PM +0800, Jason Wang wrote: On 2018年05月18日 21:26, Jason Wang wrote: On 2018年05月18日 21:13, Michael S.

Re: [PATCH net] tuntap: raise EPOLLOUT on device up

On 2018年05月18日 22:46, Michael S. Tsirkin wrote: On Fri, May 18, 2018 at 10:11:54PM +0800, Jason Wang wrote: On 2018年05月18日 22:06, Michael S. Tsirkin wrote: On Fri, May 18, 2018 at 10:00:31PM +0800, Jason Wang wrote: On 2018年05月18日 21:26, Jason Wang wrote: On 2018年05月18日 21:13, Michael S.

[PATCH v1] gpu: host1x: Skip IOMMU initialization if firewall is enabled

Host1x's CDMA can't access the command buffers if IOMMU and Host1x firewall are enabled in the kernels config because firewall doesn't map the copied buffer into IOVA space. Fix this by skipping IOMMU initialization if firewall is enabled as firewall merges sparse cmdbufs into a single contiguous

[PATCH v1] gpu: host1x: Skip IOMMU initialization if firewall is enabled

Host1x's CDMA can't access the command buffers if IOMMU and Host1x firewall are enabled in the kernels config because firewall doesn't map the copied buffer into IOVA space. Fix this by skipping IOMMU initialization if firewall is enabled as firewall merges sparse cmdbufs into a single contiguous

Re: [RFC PATCH 00/09] Implement direct user I/O interfaces for RDMA

On 5/17/2018 11:03 PM, Long Li wrote: Subject: Re: [RFC PATCH 00/09] Implement direct user I/O interfaces for RDMA On 5/17/2018 8:22 PM, Long Li wrote: From: Long Li This patchset implements direct user I/O through RDMA. In normal code path (even with cache=none), CIFS

Re: [RFC PATCH 00/09] Implement direct user I/O interfaces for RDMA

On 5/17/2018 11:03 PM, Long Li wrote: Subject: Re: [RFC PATCH 00/09] Implement direct user I/O interfaces for RDMA On 5/17/2018 8:22 PM, Long Li wrote: From: Long Li This patchset implements direct user I/O through RDMA. In normal code path (even with cache=none), CIFS copies I/O data from

Re: [RFC PATCH 02/09] Change wdata alloc to support direct pages

On 5/17/2018 5:22 PM, Long Li wrote: From: Long Li When using direct pages from user space, there is no need to allocate pages. Just ping those user pages for RDMA. Did you mean "pin" those user pages? If so, where does that pinning occur, it's not in this patch.

Re: [RFC PATCH 02/09] Change wdata alloc to support direct pages

On 5/17/2018 5:22 PM, Long Li wrote: From: Long Li When using direct pages from user space, there is no need to allocate pages. Just ping those user pages for RDMA. Did you mean "pin" those user pages? If so, where does that pinning occur, it's not in this patch. Perhaps this should just

[BUG] 4.17-rcX delays during boot and memory mapping errors

Apologies for not having more in the way of diagnostic info. Every one of the 4.17-rcX series has hung during boot at the point where "acpid" starts up. Beginning with -rc5, the boot actually proceeds to completion after an "uncomfortably" long delay. Attempting to run the X11 server results in

[BUG] 4.17-rcX delays during boot and memory mapping errors

Apologies for not having more in the way of diagnostic info. Every one of the 4.17-rcX series has hung during boot at the point where "acpid" starts up. Beginning with -rc5, the boot actually proceeds to completion after an "uncomfortably" long delay. Attempting to run the X11 server results in

Re: [PATCH v1] gpu: host1x: Utilize IOMMU mapping for firewall-copied buffers

On 19.05.2018 02:52, Dmitry Osipenko wrote: > Map firewall-copied buffers into Host1x's IOVA space, otherwise Host1x > CDMA can't access the command buffers and all submitted jobs fail if IOMMU > and Host1x firewall are enabled in the kernels config. > > Signed-off-by: Dmitry Osipenko

Re: [PATCH v1] gpu: host1x: Utilize IOMMU mapping for firewall-copied buffers

On 19.05.2018 02:52, Dmitry Osipenko wrote: > Map firewall-copied buffers into Host1x's IOVA space, otherwise Host1x > CDMA can't access the command buffers and all submitted jobs fail if IOMMU > and Host1x firewall are enabled in the kernels config. > > Signed-off-by: Dmitry Osipenko > --- >

[PATCH] usb: dwc2: Fix HiKey regression caused by power_down feature

In 4.17-rc, commit 03ea6d6e9e1f ("usb: dwc2: Enable power down") caused the HiKey board to not correctly handle switching between usb-gadget and usb-host mode. Unplugging the OTG port would result in: [ 42.240973] dwc2 f72c.usb: dwc2_restore_host_registers: no host registers to restore [

[PATCH] usb: dwc2: Fix HiKey regression caused by power_down feature

In 4.17-rc, commit 03ea6d6e9e1f ("usb: dwc2: Enable power down") caused the HiKey board to not correctly handle switching between usb-gadget and usb-host mode. Unplugging the OTG port would result in: [ 42.240973] dwc2 f72c.usb: dwc2_restore_host_registers: no host registers to restore [

  1   2   3   4   5   6   7   8   9   10   >