From: Matthew Wilcox <willy@infradead.org>
To: Namjae Jeon <namjae.jeon@samsung.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-cifs@vger.kernel.org,
linux-cifsd-devel@lists.sourceforge.net, 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,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steve French <stfrench@microsoft.com>
Subject: Re: [PATCH 2/5] cifsd: add server-side procedures for SMB3
Date: Mon, 22 Mar 2021 08:34:45 +0000 [thread overview]
Message-ID: <20210322083445.GJ1719932@casper.infradead.org> (raw)
In-Reply-To: <20210322051344.1706-3-namjae.jeon@samsung.com>
On Mon, Mar 22, 2021 at 02:13:41PM +0900, Namjae Jeon wrote:
> +++ b/fs/cifsd/mgmt/ksmbd_ida.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2018 Samsung Electronics Co., Ltd.
> + */
> +
> +#include "ksmbd_ida.h"
> +
> +struct ksmbd_ida *ksmbd_ida_alloc(void)
> +{
> + struct ksmbd_ida *ida;
> +
> + ida = kmalloc(sizeof(struct ksmbd_ida), GFP_KERNEL);
> + if (!ida)
> + return NULL;
> +
> + ida_init(&ida->map);
> + return ida;
> +}
... why? Everywhere that you call ksmbd_ida_alloc(), you would
be better off just embedding the struct ida into the struct that
currently has a pointer to it. Or declaring it statically. Then
you can even initialise it statically using DEFINE_IDA() and
eliminate the initialiser functions.
I'd remove the ksmbd_ida abstraction, although I like this wrapper:
> +int ksmbd_acquire_smb2_tid(struct ksmbd_ida *ida)
> +{
> + int id;
> +
> + do {
> + id = __acquire_id(ida, 0, 0);
> + } while (id == 0xFFFF);
> +
> + return id;
Very clever, given your constraint. I might do it as:
int id = ida_alloc(ida, GFP_KERNEL);
if (id == 0xffff)
id = ida_alloc(ida, GFP_KERNEL);
return id;
Although ...
> + tree_conn = ksmbd_alloc(sizeof(struct ksmbd_tree_connect));
> + if (!tree_conn) {
> + status.ret = -ENOMEM;
> + goto out_error;
> + }
> +
> + tree_conn->id = ksmbd_acquire_tree_conn_id(sess);
> + if (tree_conn->id < 0) {
> + status.ret = -EINVAL;
> + goto out_error;
> + }
> +
> + peer_addr = KSMBD_TCP_PEER_SOCKADDR(sess->conn);
> + resp = ksmbd_ipc_tree_connect_request(sess,
> + sc,
> + tree_conn,
> + peer_addr);
> + if (!resp) {
> + status.ret = -EINVAL;
> + goto out_error;
> + }
> +
> + status.ret = resp->status;
> + if (status.ret != KSMBD_TREE_CONN_STATUS_OK)
> + goto out_error;
> +
> + tree_conn->flags = resp->connection_flags;
> + tree_conn->user = sess->user;
> + tree_conn->share_conf = sc;
> + status.tree_conn = tree_conn;
> +
> + list_add(&tree_conn->list, &sess->tree_conn_list);
This is basically the only function which calls that, and this is a relatively
common anti-pattern when using the IDA -- you've allocated a unique ID,
but then you stuff the object in a list and ...
> +struct ksmbd_tree_connect *ksmbd_tree_conn_lookup(struct ksmbd_session *sess,
> + unsigned int id)
> +{
> + struct ksmbd_tree_connect *tree_conn;
> + struct list_head *tmp;
> +
> + list_for_each(tmp, &sess->tree_conn_list) {
> + tree_conn = list_entry(tmp, struct ksmbd_tree_connect, list);
> + if (tree_conn->id == id)
> + return tree_conn;
> + }
... walk the linked list looking for an ID match. You'd be much better
off using an allocating XArray:
https://www.kernel.org/doc/html/latest/core-api/xarray.html
Then you could lookup tree connections in O(log(n)) time instead of
O(n) time.
next prev parent reply other threads:[~2021-03-22 8:36 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20210322052203epcas1p21fe2d04c4df5396c466c38f4d57d8bb8@epcas1p2.samsung.com>
2021-03-22 5:13 ` [PATCH 0/5] cifsd: introduce new SMB3 kernel server Namjae Jeon
[not found] ` <CGME20210322052204epcas1p1382cadbfe958d156c0ad9f7fcb8532b7@epcas1p1.samsung.com>
2021-03-22 5:13 ` [PATCH 1/5] cifsd: add server handler and tranport layers Namjae Jeon
2021-03-22 22:18 ` Matthew Wilcox
2021-03-23 3:01 ` Namjae Jeon
2021-03-23 3:12 ` Matthew Wilcox
2021-03-23 3:16 ` Namjae Jeon
[not found] ` <CGME20210322052206epcas1p438f15851216f07540537c5547a0a2c02@epcas1p4.samsung.com>
2021-03-22 5:13 ` [PATCH 2/5] cifsd: add server-side procedures for SMB3 Namjae Jeon
2021-03-22 6:47 ` Dan Carpenter
2021-03-22 6:50 ` Christoph Hellwig
2021-03-22 13:25 ` [Linux-cifsd-devel] " Stefan Metzmacher
2021-03-22 23:20 ` Namjae Jeon
2021-03-22 23:17 ` Namjae Jeon
2021-03-23 7:19 ` Dan Carpenter
2021-03-25 5:25 ` Sebastian Gottschall
2021-03-22 8:34 ` Matthew Wilcox [this message]
2021-03-22 10:27 ` Sergey Senozhatsky
2021-03-22 13:12 ` Matthew Wilcox
[not found] ` <CGME20210322052207epcas1p3f0a5bdfd2c994a849a67b465479d0721@epcas1p3.samsung.com>
2021-03-22 5:13 ` [PATCH 3/5] cifsd: add file operations Namjae Jeon
2021-03-22 6:55 ` Al Viro
2021-03-23 0:12 ` Namjae Jeon
2021-03-22 7:02 ` Al Viro
2021-03-22 9:26 ` Sergey Senozhatsky
2021-03-22 7:04 ` Dan Carpenter
2021-03-22 9:39 ` Sergey Senozhatsky
2021-03-22 8:15 ` Matthew Wilcox
2021-03-22 9:03 ` Sergey Senozhatsky
2021-03-22 13:02 ` Matthew Wilcox
2021-03-22 13:57 ` Christoph Hellwig
2021-03-22 14:40 ` Matthew Wilcox
2021-03-22 17:09 ` Matthew Wilcox
2021-03-23 0:05 ` Sergey Senozhatsky
2021-03-22 16:16 ` Schaufler, Casey
2021-03-23 0:21 ` Namjae Jeon
[not found] ` <CGME20210322052208epcas1p430b2e93761d5194844c533c61d43242d@epcas1p4.samsung.com>
2021-03-22 5:13 ` [PATCH 4/5] cifsd: add Kconfig and Makefile Namjae Jeon
[not found] ` <CGME20210322052209epcas1p377f1542bcc9ec50219d2e57aa92d944b@epcas1p3.samsung.com>
2021-03-22 5:13 ` [PATCH 5/5] MAINTAINERS: add cifsd kernel server Namjae Jeon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210322083445.GJ1719932@casper.infradead.org \
--to=willy@infradead.org \
--cc=aaptel@suse.com \
--cc=aurelien.aptel@gmail.com \
--cc=colin.king@canonical.com \
--cc=dan.carpenter@oracle.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=hyc.lee@gmail.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-cifsd-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=rdunlap@infradead.org \
--cc=ronniesahlberg@gmail.com \
--cc=sandeen@sandeen.net \
--cc=senozhatsky@chromium.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=smfrench@gmail.com \
--cc=stfrench@microsoft.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).