netdev - Re: [PATCH net-next v3 1/2] mctp: make __mctp_dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7ee44e4ca9340943e88306542326f0e3b756837.camel@codeconstruct.com.au>
Date:   Wed, 23 Feb 2022 12:22:58 +0800
From:   Jeremy Kerr <jk@...econstruct.com.au>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Matt Johnston <matt@...econstruct.com.au>, netdev@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next v3 1/2] mctp: make __mctp_dev_get() take a
 refcount hold

Hi Jakub,

> Jeremy, did you have any specific semantics or naming scheme in mind
> here? PTAL. Is it better to make __mctp_dev_get() "safe" or create
> mctp_dev_get()? etc

The __ prefix is (was?) more about the requirement for the RCU read lock
there. That's still the case, so the __ may still be applicable.

We only have one non-test usage of a contender for a RCU-locked
mctp_dev_get(), ie, currently:

  rcu_read_lock();
  dev = __mctp_dev_get();
  rcu_read_unlock();

 - so I'm not sure it's worthwhile adding a separate function for that
at present, and I'm OK with this patch retaining the __.

I guess the question is really: as per existing conventions, does __
more imply an unlocked accessor, or a non-reference-counting accessor?

Cheers,

Jeremy