Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp4867476pxy; Tue, 27 Apr 2021 14:40:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyaHEbihLLAZvdeLsA8qsiHFnXt0fQty6IDt2uPYOlpNkcWdYf/4OZ8pBjvSXE5uy/hxozY X-Received: by 2002:a65:6704:: with SMTP id u4mr23644941pgf.169.1619559615446; Tue, 27 Apr 2021 14:40:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619559615; cv=none; d=google.com; s=arc-20160816; b=cypyf6pY+3L08GvDdWE/zqgtTU1eBc8kxwxFzXdMZulPIGWS27dix7bKmlqx3TNVCz LdJUyLYZI7y3iLSMSAqpXEA6PEmYkig02P1Kb0GqYV+YHBwP+di2g4iXivXiZ2ZJt6gA mYOOlx56KImnTu8fzO1BYFdyRy02crr61Qa3m8NxHRaF6Z8b/VBIzDD7she+wbPNN1mF 57WsUiQi4C5/2nr/D8dTBO7euzhYTwonfbU4RtEemJY3tzOnE02jqZh/8xXvIHjG/JaV ZOM0I6WiquY6y5ei6LBmaP6ql7Yj+Kgp0FfK/XZyeCxmKLU3a1wdNb5hujYJ8jnpABuA VNNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:references :in-reply-to:mime-version:dkim-signature; bh=qdpDUn5ezW0j726jAO7KF9UbIxDQl/G9gOVaKtdZWgo=; b=jDWpOgAt7xfNfGhlFPjMg6jJ3W+Y1hK2dx8uEvMIe3KdE/7HL78Ijw4gq26Y06uF8i ARToUw6lwXw2XSmmU8BZzgozLjCHXvfgPHzwjUwTaK1DXnFXrpIazZ1x+//86JymEV/z Ubf/TQpczTxtzNdR/znLcNI4dzwEVoa4x37kq0p6aMU4UfV6cR4ZCD0pOyuo0VsoBKt7 Wp+f+sg7VxEIuqwI/6owZ75MxroW9XODkd/Gz/vg8goKoYKM5AisrCJThgj5aZ3wXBcM 0n/TVsz3MBC7fSFfurFOHEjW0oyUHoVweaS3h5Ho8F/j6+E76qJDR56ng4dzTG4rFvNi NKKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iNyWAwMF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o17si357382plc.319.2021.04.27.14.39.35; Tue, 27 Apr 2021 14:40:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iNyWAwMF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237057AbhD0Vjm (ORCPT + 99 others); Tue, 27 Apr 2021 17:39:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:60066 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235440AbhD0Vjl (ORCPT ); Tue, 27 Apr 2021 17:39:41 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 63925613F3; Tue, 27 Apr 2021 21:38:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619559537; bh=aUfr3GP9dA2zXaLKx1mJB3E43MKs8lwDI9xZH9AGtOk=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=iNyWAwMF+zHV/1KSrTJiOgzRwBnUGQDiJPF5ksQ3GcRJWuQ+5vxOCnbNE8+lrwpgr ItSJD84GIfVQ0yej/nzQ1xTS/KbOOrSabkUz7QXsFzirgOd+HiVlHHpZrpnXjMFy0X REd1FDKpQRndzfbjo+IS9A3167mrXuhU/UMr9do38CYhCmJ5xuR+ArVWMZBsCOQTIf 2FGFsxT5Cu3P/fuX0uQzKKWLL9Y6zU5f2eIgR5En2SG/uTz6qEmLKycKm0DN0eNLiI 5hN2cbEJ/+g+XFNoUAgpMmEOdDQ/TQLv0UrVj3GuBf5hVPCKDkmamR7uriDXrob5yi jYlkDTL96DxsQ== Received: by mail-vs1-f44.google.com with SMTP id 2so30799712vsh.4; Tue, 27 Apr 2021 14:38:57 -0700 (PDT) X-Gm-Message-State: AOAM532Q4RapeJUwdpJtWBAcgjdCKgOxLMn7TGN5Tv1qsny+QVPSDrYi z6X5+Yqeqznd40vbOSHlIwWfySo43hh3TaPJyM8= X-Received: by 2002:a05:6102:2050:: with SMTP id q16mr20858559vsr.37.1619559536574; Tue, 27 Apr 2021 14:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6102:21b7:0:0:0:0 with HTTP; Tue, 27 Apr 2021 14:38:55 -0700 (PDT) In-Reply-To: <20210427205331.GA15168@fieldses.org> References: <20210422002824.12677-1-namjae.jeon@samsung.com> <20210427205331.GA15168@fieldses.org> From: Namjae Jeon Date: Wed, 28 Apr 2021 06:38:55 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 00/10] cifsd: introduce new SMB3 kernel server To: "J. Bruce Fields" Cc: Namjae Jeon , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, smfrench@gmail.com, senozhatsky@chromium.org, hyc.lee@gmail.com, viro@zeniv.linux.org.uk, hch@lst.de, hch@infradead.org, ronniesahlberg@gmail.com, aurelien.aptel@gmail.com, aaptel@suse.com, sandeen@sandeen.net, dan.carpenter@oracle.com, colin.king@canonical.com, rdunlap@infradead.org, willy@infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2021-04-28 5:53 GMT+09:00, J. Bruce Fields : > On Thu, Apr 22, 2021 at 09:28:14AM +0900, Namjae Jeon wrote: >> This is the patch series for cifsd(ksmbd) kernel server. >> >> What is cifsd(ksmbd) ? >> ====================== >> >> The SMB family of protocols is the most widely deployed >> network filesystem protocol, the default on Windows and Macs (and even >> on many phones and tablets), with clients and servers on all major >> operating systems, but lacked a kernel server for Linux. For many >> cases the current userspace server choices were suboptimal >> either due to memory footprint, performance or difficulty integrating >> well with advanced Linux features. >> >> ksmbd is a new kernel module which implements the server-side of the SMB3 >> protocol. >> The target is to provide optimized performance, GPLv2 SMB server, better >> lease handling (distributed caching). The bigger goal is to add new >> features more rapidly (e.g. RDMA aka "smbdirect", and recent encryption >> and signing improvements to the protocol) which are easier to develop >> on a smaller, more tightly optimized kernel server than for example >> in Samba. The Samba project is much broader in scope (tools, security >> services, >> LDAP, Active Directory Domain Controller, and a cross platform file >> server >> for a wider variety of purposes) but the user space file server portion >> of Samba has proved hard to optimize for some Linux workloads, including >> for smaller devices. This is not meant to replace Samba, but rather be >> an extension to allow better optimizing for Linux, and will continue to >> integrate well with Samba user space tools and libraries where >> appropriate. >> Working with the Samba team we have already made sure that the >> configuration >> files and xattrs are in a compatible format between the kernel and >> user space server. >> >> >> Architecture >> ============ >> >> |--- ... >> --------|--- ksmbd/3 - Client 3 >> |-------|--- ksmbd/2 - Client 2 >> | | >> ____________________________________________________ >> | | |- Client 1 >> | >> <--- Socket ---|--- ksmbd/1 <<= Authentication : NTLM/NTLM2, Kerberos >> | >> | | | | <<= SMB engine : SMB2, SMB2.1, SMB3, >> SMB3.0.2, | >> | | | | SMB3.1.1 >> | >> | | | >> |____________________________________________________| >> | | | >> | | |--- VFS --- Local Filesystem >> | | >> KERNEL |--- ksmbd/0(forker kthread) >> ---------------||--------------------------------------------------------------- >> USER || >> || communication using NETLINK >> || ______________________________________________ >> || | | >> ksmbd.mountd <<= DCE/RPC(srvsvc, wkssvc, samr, lsarpc) | >> ^ | <<= configure shares setting, user accounts | >> | |______________________________________________| >> | >> |------ smb.conf(config file) >> | >> |------ ksmbdpwd.db(user account/password file) >> ^ >> ksmbd.adduser ---------------| >> >> The subset of performance related operations(open/read/write/close etc.) >> belong >> in kernelspace(ksmbd) and the other subset which belong to >> operations(DCE/RPC, >> user account/share database) which are not really related with performance >> are >> handled in userspace(ksmbd.mountd). >> >> When the ksmbd.mountd is started, It starts up a forker thread at >> initialization >> time and opens a dedicated port 445 for listening to SMB requests. >> Whenever new >> clients make request, Forker thread will accept the client connection and >> fork >> a new thread for dedicated communication channel between the client and >> the server. > > Judging from the diagram above, all those threads are kernel threads, is > that right? So a kernel thread gets each call first, then uses netlink > to get help from ksmbd.mountd if necessary, is that right? Yes, That's right. > > --b. >