From: Paul Aurich <paul@darkrain42.org>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: "Aurélien Aptel" <aaptel@suse.com>,
linux-cifs@vger.kernel.org, linux-sparse@vger.kernel.org,
sfrench@samba.org, "Ronnie Sahlberg" <lsahlber@redhat.com>
Subject: Re: lock checking issues (was: Re: [PATCH v3] cifs: Fix leak when handling lease break for cached root fid)
Date: Tue, 7 Jul 2020 13:34:01 -0700 [thread overview]
Message-ID: <20200707203401.GA409312@haley.home.arpa> (raw)
In-Reply-To: <20200707130509.om7rgkm75baszqye@ltop.local>
On 2020-07-07 15:05:09 +0200, Luc Van Oostenryck wrote:
>> To be honnest I'm not sure, these seem counterproductive. If you are
>> indicating you are acquiring X but lock Y the next line it feels like we
>> are fighting the tool instead of letting it help us.
>
>__acquire() & __release() should only be used by locking primitives.
Alright, thanks! (I did see several other locations in the kernel that seemed
to be doing this, though I agree with Aurélien that it didn't feel right to be
fighting sparse, and it's possible my attempt was more egregious.)
I will try to find a better way to organize the functionality that satisfies
both the functionality and sparse.
Thanks,
~Paul
prev parent reply other threads:[~2020-07-07 20:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200702164411.108672-1-paul@darkrain42.org>
[not found] ` <878sfx6o64.fsf@suse.com>
[not found] ` <20200706192642.GA110607@haley.home.arpa>
2020-07-07 7:03 ` lock checking issues (was: Re: [PATCH v3] cifs: Fix leak when handling lease break for cached root fid) Aurélien Aptel
2020-07-07 13:05 ` Luc Van Oostenryck
2020-07-07 20:34 ` Paul Aurich [this message]
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=20200707203401.GA409312@haley.home.arpa \
--to=paul@darkrain42.org \
--cc=aaptel@suse.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=lsahlber@redhat.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=sfrench@samba.org \
/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