Re: [[PATCH v1] 02/37] [CIFS] SMBD: Add structure for SMBD transport

Hi Long, >> It seems that the new transport is tied to it's caller regarding structures >> and >> naming conventions. >> >> I think it would be better to strictly separate them, as I'd like to use the >> SMBDirect transport also from the userspace for the client side e.g. in >> Samba's

Re: [[PATCH v1] 02/37] [CIFS] SMBD: Add structure for SMBD transport

Hi Li, thanks for providing this patchset, I guess it will be a huge win to have SMBDirect support for the kernel client! > Define a new structure for SMBD transport. This stucture will have all the > information on the transport, and it will be stored in the current SMB > session. ... > +/* >

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

Hi, >> This is great to see. Is there a Linux implementation of the server side (in >> Samba?) so that the client can be tested without needing a Windows server? > > I'm not aware of a Linux implementation on server side. Here's a very early work in progress branch:

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Am 19.12.2017 um 22:21 schrieb Long Li via samba-technical: >> depends on CIFS && INFINIBAND >> +depends on CIFS=m || INFINIBAND=y > > How about we change them to > > depends on CIFS=m && INFINIBAND || CIFS=y && INFINIBAND=y > > This makes it easy to read. I like it :-) metze

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Hi Arnd, > diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig > index 500fd69fb58b..3bfc55c08bef 100644 > --- a/fs/cifs/Kconfig > +++ b/fs/cifs/Kconfig > @@ -199,6 +199,7 @@ config CIFS_SMB311 > config CIFS_SMB_DIRECT > bool "SMB Direct support (Experimental)" > depends on CIFS &&

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Am 19.12.2017 um 11:56 schrieb Arnd Bergmann via samba-technical: > On Tue, Dec 19, 2017 at 11:33 AM, Stefan Metzmacher <me...@samba.org> wrote: >> Hi Arnd, >> >>> diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig >>> index 500fd69fb58b..3bfc55c08bef 100644 >

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

Hi, >> +    req->Channel = SMB2_CHANNEL_RDMA_V1_INVALIDATE; >> +    if (need_invalidate) >> +    req->Channel = SMB2_CHANNEL_RDMA_V1; >> +    req->ReadChannelInfoOffset = >> +    offsetof(struct smb2_read_plain_req, Buffer); >> +    req->ReadChannelInfoLength = >>

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

Hi Tom, >> I just tested that setting: >> >> mr->iova &= (PAGE_SIZE - 1); >> mr->iova |= 0x; >> >> after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to >> work. > > Good! As you know, we were concerned about it after seeing that > the ib_dma_map_sg() code was

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

> They're basically the same concept, it's a subtle difference. > > FRMR = Fast Register Memory Region > FRWR = Fast Register Work Request > > The memory region is the mr itself, this is created early on. > > The work request is built when actually binding the physical > pages to the region,

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

Hi, >> This is great to see. Is there a Linux implementation of the server side (in >> Samba?) so that the client can be tested without needing a Windows server? > > I'm not aware of a Linux implementation on server side. Here's a very early work in progress branch:

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Hi Arnd, > diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig > index 500fd69fb58b..3bfc55c08bef 100644 > --- a/fs/cifs/Kconfig > +++ b/fs/cifs/Kconfig > @@ -199,6 +199,7 @@ config CIFS_SMB311 > config CIFS_SMB_DIRECT > bool "SMB Direct support (Experimental)" > depends on CIFS &&

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Am 19.12.2017 um 11:56 schrieb Arnd Bergmann via samba-technical: > On Tue, Dec 19, 2017 at 11:33 AM, Stefan Metzmacher wrote: >> Hi Arnd, >> >>> diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig >>> index 500fd69fb58b..3bfc55c08bef 100644 >>> --- a

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Am 19.12.2017 um 22:21 schrieb Long Li via samba-technical: >> depends on CIFS && INFINIBAND >> +depends on CIFS=m || INFINIBAND=y > > How about we change them to > > depends on CIFS=m && INFINIBAND || CIFS=y && INFINIBAND=y > > This makes it easy to read. I like it :-) metze

Re: [[PATCH v1] 02/37] [CIFS] SMBD: Add structure for SMBD transport

Hi Li, thanks for providing this patchset, I guess it will be a huge win to have SMBDirect support for the kernel client! > Define a new structure for SMBD transport. This stucture will have all the > information on the transport, and it will be stored in the current SMB > session. ... > +/* >

Re: [[PATCH v1] 02/37] [CIFS] SMBD: Add structure for SMBD transport

Hi Long, >> It seems that the new transport is tied to it's caller regarding structures >> and >> naming conventions. >> >> I think it would be better to strictly separate them, as I'd like to use the >> SMBDirect transport also from the userspace for the client side e.g. in >> Samba's

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

Hi, >> +    req->Channel = SMB2_CHANNEL_RDMA_V1_INVALIDATE; >> +    if (need_invalidate) >> +    req->Channel = SMB2_CHANNEL_RDMA_V1; >> +    req->ReadChannelInfoOffset = >> +    offsetof(struct smb2_read_plain_req, Buffer); >> +    req->ReadChannelInfoLength = >>

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

Hi Tom, >> I just tested that setting: >> >> mr->iova &= (PAGE_SIZE - 1); >> mr->iova |= 0x; >> >> after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to >> work. > > Good! As you know, we were concerned about it after seeing that > the ib_dma_map_sg() code was

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

> They're basically the same concept, it's a subtle difference. > > FRMR = Fast Register Memory Region > FRWR = Fast Register Work Request > > The memory region is the mr itself, this is created early on. > > The work request is built when actually binding the physical > pages to the region,

Re: [PATCH 0/6] Allow signals for IO threads

Am 26.03.21 um 15:55 schrieb Jens Axboe: > On 3/26/21 8:53 AM, Jens Axboe wrote: >> On 3/26/21 8:45 AM, Stefan Metzmacher wrote: >>> Am 26.03.21 um 15:43 schrieb Stefan Metzmacher: >>>> Am 26.03.21 um 15:38 schrieb Jens Axboe: >>>>> On 3/26/21 7:59 AM

Re: [PATCH 0/6] Allow signals for IO threads

Am 26.03.21 um 13:56 schrieb Jens Axboe: > On 3/26/21 5:48 AM, Stefan Metzmacher wrote: >> >> Am 26.03.21 um 01:39 schrieb Jens Axboe: >>> Hi, >>> >>> As discussed in a previous thread today, the seemingly much saner approach >>> is just to allow

Re: [PATCH 0/6] Allow signals for IO threads

Am 26.03.21 um 15:43 schrieb Stefan Metzmacher: > Am 26.03.21 um 15:38 schrieb Jens Axboe: >> On 3/26/21 7:59 AM, Jens Axboe wrote: >>> On 3/26/21 7:54 AM, Jens Axboe wrote: >>>>> The KILL after STOP deadlock still exists. >>>> >>>&g

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

Am 26.03.21 um 16:01 schrieb Jens Axboe: > On 3/26/21 7:48 AM, Oleg Nesterov wrote: >> Jens, sorry, I got lost :/ > > Let's bring you back in :-) > >> On 03/25, Jens Axboe wrote: >>> >>> With IO threads accepting signals, including SIGSTOP, >> >> where can I find this change? Looks like I wasn't

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

Hi Jens, >> And /proc/$iothread/ should be read only and owned by root with >> "cmdline" and "exe" being empty. > > I know you brought this one up as part of your series, not sure I get > why you want it owned by root and read-only? cmdline and exe, yeah those > could be hidden, but is there

Re: [PATCH 0/6] Allow signals for IO threads

Am 26.03.21 um 15:38 schrieb Jens Axboe: > On 3/26/21 7:59 AM, Jens Axboe wrote: >> On 3/26/21 7:54 AM, Jens Axboe wrote: The KILL after STOP deadlock still exists. >>> >>> In which tree? Sounds like you're still on the old one with that >>> incremental you sent, which wasn't complete. >>>

Re: [PATCH 0/6] Allow signals for IO threads

Am 26.03.21 um 15:53 schrieb Jens Axboe: > On 3/26/21 8:45 AM, Stefan Metzmacher wrote: >> Am 26.03.21 um 15:43 schrieb Stefan Metzmacher: >>> Am 26.03.21 um 15:38 schrieb Jens Axboe: >>>> On 3/26/21 7:59 AM, Jens Axboe wrote: >>>>> On 3/26/21 7:54

Re: [PATCH 0/6] Allow signals for IO threads

Am 26.03.21 um 16:10 schrieb Jens Axboe: > On 3/26/21 9:08 AM, Stefan Metzmacher wrote: >> Am 26.03.21 um 15:55 schrieb Jens Axboe: >>> On 3/26/21 8:53 AM, Jens Axboe wrote: >>>> On 3/26/21 8:45 AM, Stefan Metzmacher wrote: >>>>> Am 26.03.21 um 15:43

Re: [PATCH AUTOSEL 5.11 42/44] signal: don't allow sending any signals to PF_IO_WORKER threads

t; thread. Linux does allow this kind of behavior for regular threads, but > it's really a compatability thing that we need not care about for the IO > threads. > > Reported-by: Stefan Metzmacher > Signed-off-by: Jens Axboe > Signed-off-by: Sasha Levin > --- > kernel/sig

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

Am 25.03.21 um 13:04 schrieb Eric W. Biederman: > Stefan Metzmacher writes: > >> Am 25.03.21 um 12:24 schrieb Sasha Levin: >>> From: "Eric W. Biederman" >>> >>> [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] >>> >&g

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

Am 25.03.21 um 14:38 schrieb Jens Axboe: > On 3/25/21 6:11 AM, Stefan Metzmacher wrote: >> >> Am 25.03.21 um 13:04 schrieb Eric W. Biederman: >>> Stefan Metzmacher writes: >>> >>>> Am 25.03.21 um 12:24 schrieb Sasha Levin: >>>>&

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

threads don't take > signals in general, and have no means of flushing out a stop either. > > Longer term, we may want to look into allowing stop of these threads, > as it relates to eg process freezing. For now, this prevents a spin > issue if a SIGSTOP is delivered to the parent task. &g

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

Am 26.03.21 um 16:29 schrieb Jens Axboe: > On 3/26/21 9:23 AM, Stefan Metzmacher wrote: >> Am 26.03.21 um 16:01 schrieb Jens Axboe: >>> On 3/26/21 7:48 AM, Oleg Nesterov wrote: >>>> Jens, sorry, I got lost :/ >>> >>> Let's bring you

Re: [PATCH 0/6] Allow signals for IO threads

Hi Jens, > root@ub1704-166:~# LANG=C gdb --pid 1320 > GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it.

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

Am 25.03.21 um 21:55 schrieb Eric W. Biederman: > Oleg Nesterov writes: > >> On 03/25, Linus Torvalds wrote: >>> >>> The whole "signals are very special for IO threads" thing has caused >>> so many problems, that maybe the solution is simply to _not_ make them >>> special? >> >> Or may be IO

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

Am 25.03.21 um 22:44 schrieb Jens Axboe: > On 3/25/21 2:40 PM, Jens Axboe wrote: >> On 3/25/21 2:12 PM, Linus Torvalds wrote: >>> On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds >>> wrote: On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds wrote: > > I don't know what the

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

Am 25.03.21 um 22:20 schrieb Stefan Metzmacher: > > Am 25.03.21 um 21:55 schrieb Eric W. Biederman: >> Oleg Nesterov writes: >> >>> On 03/25, Linus Torvalds wrote: >>>> >>>> The whole "signals are very special for IO threads" th

Re: [PATCH] Document that PF_KTHREAD _is_ ABI

Am 31.03.21 um 21:23 schrieb Alexey Dobriyan: > On Mon, Mar 22, 2021 at 07:53:10AM +, Christoph Hellwig wrote: >> On Sat, Mar 20, 2021 at 10:23:12AM -0700, Andy Lutomirski wrote: https://github.com/systemd/systemd/blob/main/src/basic/process-util.c#L354

Re: [PATCH 0/6] Allow signals for IO threads

Am 01.04.21 um 17:39 schrieb Linus Torvalds: > On Thu, Apr 1, 2021 at 7:58 AM Stefan Metzmacher wrote: >> >>> >>> Ok, the following makes gdb happy again: >>> >>> --- a/arch/x86/kernel/process.c >>> +++ b/arch/x86/kernel/process.c

Re: [PATCH 0/6] Allow signals for IO threads

Hi Jens, >> For help, type "help". >> Type "apropos word" to search for commands related to "word". >> Attaching to process 1320 >> [New LWP 1321] >> [New LWP 1322] >> >> warning: Selected architecture i386:x86-64 is not compatible with reported >> target architecture i386 >> >> warning:

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

Hi Jens, >> I know you brought this one up as part of your series, not sure I get >> why you want it owned by root and read-only? cmdline and exe, yeah those >> could be hidden, but is there really any point? >> >> Maybe I'm missing something here, if so, do clue me in! > > I looked through

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

Hi Jens, >>> I don't assume signals wanted by userspace should potentially handled in an >>> io_thread... >>> e.g. things set with fcntl(fd, F_SETSIG,) used together with F_SETLEASE? >> >> I guess we do actually need it, if we're not fiddling with >> wants_signal() for them. To quell Oleg's

Re: [PATCH 0/6] Allow signals for IO threads

Am 01.04.21 um 18:24 schrieb Linus Torvalds: > On Thu, Apr 1, 2021 at 9:00 AM Stefan Metzmacher wrote: >> >> I haven't tried it, but it seems gdb tries to use PTRACE_PEEKUSR >> against the last thread tid listed under /proc//tasks/ in order to >> get the architecture fo

Re: linux-next: Signed-off-by missing for commit in the block tree

Am 19.03.21 um 00:25 schrieb Jens Axboe: > On 3/18/21 5:16 PM, Stephen Rothwell wrote: >> Hi all, >> >> Commit >> >> c2c6c067c050 ("io_uring: remove structures from include/linux/io_uring.h") >> >> is missing a Signed-off-by from its author. > > Stefan, let me know if you're OK with me adding

Re: linux-next: Signed-off-by missing for commit in the block tree

Am 19.03.21 um 14:08 schrieb Jens Axboe: > On 3/19/21 2:02 AM, Stefan Metzmacher wrote: >> >> Am 19.03.21 um 00:25 schrieb Jens Axboe: >>> On 3/18/21 5:16 PM, Stephen Rothwell wrote: >>>> Hi all, >>>> >>>> Commit >>>> &g

Re: [Linux-cifsd-devel] [PATCH 2/5] cifsd: add server-side procedures for SMB3

Am 22.03.21 um 07:50 schrieb Christoph Hellwig: > On Mon, Mar 22, 2021 at 09:47:13AM +0300, Dan Carpenter wrote: >> On Mon, Mar 22, 2021 at 02:13:41PM +0900, Namjae Jeon wrote: >>> +static unsigned char >>> +asn1_octet_decode(struct asn1_ctx *ctx, unsigned char *ch) >>> +{ >>> + if

Re: [RFC PATCH v2 00/13] Add futex2 syscall

Hi André, > ** The wait on multiple problem > > The use case lies in the Wine implementation of the Windows NT interface > WaitMultipleObjects. This Windows API function allows a thread to sleep > waiting on the first of a set of event sources (mutexes, timers, signal, > console input,

Re: [RFC PATCH v2 00/13] Add futex2 syscall

Am 08.03.21 um 12:11 schrieb David Laight: > From: Stefan Metzmacher >> Sent: 07 March 2021 11:35 >> >> Hi André, >>> ** The wait on multiple problem >>> >>> The use case lies in the Wine implementation of the Windows NT interface >>&g

Re: [RFC PATCH v2 00/13] Add futex2 syscall

Am 07.03.21 um 12:56 schrieb Daurnimator: > On Sun, 7 Mar 2021 at 22:35, Stefan Metzmacher wrote: >> Instead of having a blocked futex_waitv() waiting on an fd (maybe a generic >> eventfd() or a new futex2fd()) >> would be a better interface? > > Like bring back F

Re: [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads

ust keep the values of the copy_thread() caller. Do you plan to do something about this before 5.12 final? metze Am 11.04.21 um 17:27 schrieb Stefan Metzmacher: > This allows gdb attach to userspace processes using io-uring, > which means that they have io_threads (PF_IO_WORKER), which appea

[PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads

Signed-off-by: Stefan Metzmacher cc: Linus Torvalds cc: Jens Axboe cc: linux-kernel@vger.kernel.org cc: io-ur...@vger.kernel.org --- arch/x86/kernel/process.c | 49 +++ 1 file changed, 49 insertions(+) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/proce

Re: [GIT PULL] cifs fixes

Am 12.02.21 um 21:39 schrieb Steve French: > Metze/Bjorn, > Linus is right - samba.org is down for me (I also verified with JRA). > Any ETA on when it gets back up? > > On Fri, Feb 12, 2021 at 2:05 PM Linus Torvalds > wrote: >> >> On Fri, Feb 12, 2021 at 10:16 AM Steve French wrote: >>> >>>

Re: [GIT PULL] cifs fixes

Hi Linus, >> The machine is running a 'AMD Ryzen Threadripper 2950X 16-Core Processor' >> and is freezing without any trace every view days. > > I don't think the first-gen Zen issues ever really got solved. There > were multiple ones, with random segfaults for the early ones (but > afaik those

Re: [GIT PULL] cifs fixes

Hi Linus, >> Do you know about the Zen3 status, I was thinking to replace the system >> by this one with AMD Ryzen 9 5950X: > > I have heard nothing but good things about Zen3 so far (apart from > apparently people complaining about availability), but it's only been > out a few months, so