[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241016073340.42565-1-lizhe.67@bytedance.com>
Date: Wed, 16 Oct 2024 15:33:40 +0800
From: lizhe.67@...edance.com
To: hch@...radead.org
Cc: akpm@...ux-foundation.org,
boqun.feng@...il.com,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
lizhe.67@...edance.com,
longman@...hat.com,
mingo@...hat.com,
peterz@...radead.org,
will@...nel.org
Subject: Re: [RFC 1/2] rwsem: introduce upgrade_read interface
On Tue, 15 Oct 2024 21:56:51 -0700, hch@...radead.org wrote:
>On Wed, Oct 16, 2024 at 12:35:59PM +0800, lizhe.67@...edance.com wrote:
>> From: Li Zhe <lizhe.67@...edance.com>
>>
>> Introduce a new rwsem interface upgrade_read(). We can call it
>
>It's obviously a try_upgrade_read, right?
Yes, try_upgrade_read is a better name, I will fix it in v2. Thanks!
>
>> +extern int upgrade_read(struct rw_semaphore *sem);
>
>No need for the extern. Also please make any new advanced funtionality
Sorry I don't understand why extern is not needed. If we remove it,
we will encounter the following compilation error:
mm/khugepaged.c:1145:6: error: implicit declaration of function 'upgrade_read'; did you mean 'i_gid_read'? [-Werror=implicit-function-declaration]
if (upgrade_read(&mm->mmap_lock)) {
^~~~~~~~~~~~
>like this an EXPORT_SYMBO_GPL. That is if you actually had a modular
>user, the current one is built-in. (although we could use this in
>XFS if it lands).
I see all advanced functionality in kernel/locking/rwsem.c is tagged with
EXPORT_SYMBOL (which is used in my patch), and I'm not sure if I need to
change it to EXPORT_SYMBO_GPL.
Hope to see this interface used by XFS.
Powered by blists - more mailing lists