From: Dilger, Andreas <andreas.dilger@intel.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] Possible minor bug
Date: Wed, 27 May 2015 20:55:27 +0000 [thread overview]
Message-ID: <D18B8A8A.F359D%andreas.dilger@intel.com> (raw)
On 2015/05/27, 2:03 PM, "Patrick Farrell" <paf at cray.com<mailto:paf@cray.com>> wrote:
While doing some other work, I noticed something I believe is a potential problem in the server side quota code.
Specifically, in qmt_glimpse_lock:
While the resource lock (a spin lock) is held, it does
OBD_ALLOC_PTR(work);
Since allocations can sleep, doesn't this allocation need to be atomic?
So, following the current Lustre convention, it should be:
LIBCFS_ALLOC_ATOMIC(work, sizeof(struct
ldlm_glimpse_work));
You could also use OBD_ALLOC_GFP(work, sizeof(*work), GFP_ATOMIC), which is equivalent, but at least keeps the same paradigm of other allocations in this code.
I have seen no actual bugs from this, but I hit a hang while modifying the equivalent code in ofd_intent_policy for lock ahead, and I think the same hang is theoretically possible here. My understanding is that, in general, doing allocations while holding a spin lock is not recommended.
Not only not recommended, but not allowed for GFP_NOFS allocations. Probably if you had CONFIG_DEBUG_SPINLOCK or similar enabled, you would get a warning here due to __might_sleep() in the allocation path.
I'm hoping for other input before I go further - Am I right that this is something which needs fixing? If so, I'll open an LU and submit a patch.
Yes, please do.
Cheers, Andreas
next reply other threads:[~2015-05-27 20:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 20:55 Dilger, Andreas [this message]
2015-05-27 21:15 ` [lustre-devel] Possible minor bug Patrick Farrell
-- strict thread matches above, loose matches on Subject: below --
2015-05-27 20:03 Patrick Farrell
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=D18B8A8A.F359D%andreas.dilger@intel.com \
--to=andreas.dilger@intel.com \
--cc=lustre-devel@lists.lustre.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.