[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YkHwmhOaSHuXPemP@slm.duckdns.org>
Date: Mon, 28 Mar 2022 07:30:02 -1000
From: Tejun Heo <tj@...nel.org>
To: Imran Khan <imran.f.khan@...cle.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v7 7/8] kernfs: Replace per-fs rwsem with hashed
rwsems.
On Mon, Mar 28, 2022 at 11:15:30AM +1100, Imran Khan wrote:
> Hello Al,
>
> On 22/3/22 1:40 pm, Al Viro wrote:
> [...]
> >
> > Sorry, misread that thing - the reason it copies the damn thing at all is
> > the use of strsep(). Yecch... Rule of the thumb regarding strsep() use,
> > be it in kernel or in the userland: don't. It's almost never the right
> > primitive to use.
> >
> > Lookups should use qstr; it has both the length and place for hash.
> > Switch kernfs_find_ns() to that (and lift the calculation of length
> > into the callers that do not have it - note that kernfs_iop_lookup()
> > does) and you don't need the strsep() shite (or copying) anymore.
> >
>
> Regarding using qstr in kernfs_find_ns, do you mean that I should remove
> ->name and ->hash with a ->qstr in kernfs_node and further modify
> kernfs_name_compare to make use of qstr.name and qstr.hash.
>
> Also the suggestion about removing buffer copying from kernfs_walk_ns is
> not clear to me because kernfs_walk_ns invokes kernfs_find_ns with
> individual path components so we need some mechanism to separate path
> components.
>
> Sorry if I have missed or misunderstood something in your suggestion.
qstr encodes the lenght of the string and doesn't need the terminating '\0',
so we can just walk qstr over the passed in path instead of copying and
overwriting '\0'. This is rather separate and we can revisit this later tho.
Thanks.
--
tejun
Powered by blists - more mailing lists