> 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
> 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
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
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
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
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
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:
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:
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
---
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]
[
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
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
---
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]
[
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
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:
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:
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
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
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
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
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+
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+
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
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
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
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
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
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
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):
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):
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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:
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
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
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
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
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:
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
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:
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
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
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
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
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
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:
> >>>
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
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
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
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
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
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
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 @
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
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
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
> 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
> 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):
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
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
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:
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:
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
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
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
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
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'
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'
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
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
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
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"
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.
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.
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
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
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
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
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.
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
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
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
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
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
> ---
>
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
[
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 - 100 of 2450 matches
Mail list logo