From: Mark Hills <mark-UrrBsZIrrsb10XsdtD+oqA@public.gmane.org>
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [PATCH 6/7] Temporary fix to pr_latency()
Date: Sat, 10 Sep 2011 14:45:38 +0100 [thread overview]
Message-ID: <1315662339-3115-6-git-send-email-mark@pogo.org.uk> (raw)
In-Reply-To: <1315662339-3115-1-git-send-email-mark-UrrBsZIrrsb10XsdtD+oqA@public.gmane.org>
The following compile errors are caused by pr_latency (gcc 4.5.2):
block/bcache.c: In function 'fill_bucket_work':
block/bcache.c:2510:2: error: initializer element is not constant
block/bcache.c:2510:2: error: (near initialization for '_rs.lock')
[...]
This is caused by printk_ratelimited() when compiled with --std=gnu99.
Although it is not clear why; the pre-processed code seems to be
constant. Perhaps this is even a bug in GCC.
This patch fixes the build in this case, by using regular printk
instead.
But the correct fix is to remove the specialised compile flag on bcache
code. It is mainly required by variables initialised in for loops.
---
block/bcache_util.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/bcache_util.h b/block/bcache_util.h
index 872ca56..c7e72d0 100644
--- a/block/bcache_util.h
+++ b/block/bcache_util.h
@@ -414,7 +414,7 @@ extern unsigned latency_warn_ms;
do { \
int _ms = jiffies_to_msecs(jiffies - (j)); \
if (j && latency_warn_ms && (_ms) > (int) latency_warn_ms) \
- printk_ratelimited(KERN_DEBUG "bcache: %i ms latency " \
+ printk(KERN_DEBUG "bcache: %i ms latency " \
"called from %pf for " fmt "\n", _ms, \
__builtin_return_address(0), ##__VA_ARGS__); \
} while (0)
--
1.7.4.4
next prev parent reply other threads:[~2011-09-10 13:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-10 13:44 First observations with bcache Mark Hills
[not found] ` <1109101110320.2733-4jfXtw+jRJ582hYKe6nXyg@public.gmane.org>
2011-09-10 13:45 ` [PATCH 1/7] Use exported call to up/down read Mark Hills
[not found] ` <1315662339-3115-1-git-send-email-mark-UrrBsZIrrsb10XsdtD+oqA@public.gmane.org>
2011-09-10 13:45 ` [PATCH 2/7] Provide 64-bit arithmetic functions Mark Hills
2011-09-10 13:45 ` [PATCH 3/7] Break fuzz test to allow building as module Mark Hills
2011-09-10 13:45 ` [PATCH 4/7] Don't require linkage against closure_lock Mark Hills
2011-09-10 13:45 ` [PATCH 5/7] Allow closure debugging without CONFIG_DEBUG_FS Mark Hills
2011-09-10 13:45 ` Mark Hills [this message]
2011-09-10 13:45 ` [PATCH 7/7] Don't require latency_warn_ms from bcache_util.o Mark Hills
2011-09-10 21:39 ` [PATCH 1/7] Use exported call to up/down read Kent Overstreet
2011-09-22 6:13 ` First observations with bcache Kent Overstreet
2011-09-22 23:14 ` Mark Hills
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=1315662339-3115-6-git-send-email-mark@pogo.org.uk \
--to=mark-urrbszirrsb10xsdtd+oqa@public.gmane.org \
--cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.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