Jeff Layton wrote:
> Might be nice to look at some profiles to confirm all of that. I'd also
> be curious how much variation there was in the results above, as they're
> pretty close.
>
The above is just a random representative sample. The results are
pretty close when running
Jeff Layton wrote:
Might be nice to look at some profiles to confirm all of that. I'd also
be curious how much variation there was in the results above, as they're
pretty close.
The above is just a random representative sample. The results are
pretty close when running this
Sasha Levin wrote:
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo wrote:
> Hello,
>
> Just some nitpicks.
>
> On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit
kernels. */
>> +#define hash_min(val,
Sasha Levin wrote:
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo t...@kernel.org wrote:
Hello,
Just some nitpicks.
On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
+/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit
kernels. */
+#define
Theodore Ts'o wrote:
The problem is this code isn't done yet, and journal_checksum is
really not ready for prime time. When it is ready, my plan is to wire
it up so it is enabled by default; at the moment, it was intended for
developer experimentation only. As I said, it's my fault for
Theodore Ts'o wrote:
The problem is this code isn't done yet, and journal_checksum is
really not ready for prime time. When it is ready, my plan is to wire
it up so it is enabled by default; at the moment, it was intended for
developer experimentation only. As I said, it's my fault for
Jan Engelhardt wrote:
Your way does not function as originally desired.
* base10len(i) no longer expands to a compile-time constant
* you will definitely have a variable base10len_vals in your
objects, so you waste a read operation whenever it is used.
No, I meant my original
Bernd Petrovitsch wrote:
[]
> Pure K:
We can (and should) make it "const" too.
No "const" in K either. But I think we can assume the kernel will be
compiled with something a bit more advance.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Jan Engelhardt wrote:
>A pure K version would use a string:
>#define base10len(i) "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)]
>(if I converted them properly into hexadecimal)
The syntax is \x01\x03\x05...
K doesn't have the \x escape, only \0 (octal).
--
To unsubscribe from
Bernd Petrovitsch wrote:
On Mon, 2012-09-10 at 08:19 +0200, Jan Engelhardt wrote:
> On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote:
[...]
> >+/*
> >+ * length of the decimal representation of an unsigned integer. Just an
> >+ * approximation, but it's right for types of size 1 to
Bernd Petrovitsch wrote:
On Mon, 2012-09-10 at 08:19 +0200, Jan Engelhardt wrote:
On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote:
[...]
+/*
+ * length of the decimal representation of an unsigned integer. Just an
+ * approximation, but it's right for types of size 1 to 36
Jan Engelhardt wrote:
A pure KR-C version would use a string:
#define base10len(i) \0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14[sizeof(i)]
(if I converted them properly into hexadecimal)
The syntax is \x01\x03\x05...
KR doesn't have the \x escape, only \0 (octal).
--
To unsubscribe from
Bernd Petrovitsch wrote:
[]
Pure KR:
We can (and should) make it const too.
No const in KR either. But I think we can assume the kernel will be
compiled with something a bit more advance.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Jan Engelhardt wrote:
Your way does not function as originally desired.
* base10len(i) no longer expands to a compile-time constant
* you will definitely have a variable base10len_vals in your
objects, so you waste a read operation whenever it is used.
No, I meant my original
Al Viro wrote:
On Tue, Aug 21, 2012 at 05:22:27PM -0400, Jim Rees wrote:
> J. Bruce Fields wrote:
>
> From: "J. Bruce Fields"
>
> I've seen a couple examples recently where we've gotten this wrong.
> Maybe something like this would hel
J. Bruce Fields wrote:
From: "J. Bruce Fields"
I've seen a couple examples recently where we've gotten this wrong.
Maybe something like this would help? Is there some better way?
(Approximation due to Jim Rees).
Please add Suggested-by: Jim Rees . I'm thinking of
J. Bruce Fields wrote:
From: J. Bruce Fields bfie...@redhat.com
I've seen a couple examples recently where we've gotten this wrong.
Maybe something like this would help? Is there some better way?
(Approximation due to Jim Rees).
Please add Suggested-by: Jim Rees r...@umich.edu
Al Viro wrote:
On Tue, Aug 21, 2012 at 05:22:27PM -0400, Jim Rees wrote:
J. Bruce Fields wrote:
From: J. Bruce Fields bfie...@redhat.com
I've seen a couple examples recently where we've gotten this wrong.
Maybe something like this would help? Is there some better
Sasha Levin wrote:
> Learning from what happened in this specific case, there are actually 2
issues here:
>
> - Array size was constant and too small, which is solved by the patch
above.
> - We were blindly trying to sprintf() into that array, this issue may pop
back up if someone
Dave Jones wrote:
On Wed, Jul 18, 2012 at 04:00:49PM -0400, Jim Rees wrote:
> You could use something like:
>
> char tbuf[sizeof (unsigned long) * 24 / 10 + 1 + 2]; /* + 2 for final
"\n\0" */
>
> since there are roughly 10 bits f
J. Bruce Fields wrote:
On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
> The buffer size in read_flush() is too small for the longest possible values
> for it. This can lead to a kernel stack corruption:
Thanks!
>
> diff --git a/net/sunrpc/cache.c
J. Bruce Fields wrote:
On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
The buffer size in read_flush() is too small for the longest possible values
for it. This can lead to a kernel stack corruption:
Thanks!
diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
Dave Jones wrote:
On Wed, Jul 18, 2012 at 04:00:49PM -0400, Jim Rees wrote:
You could use something like:
char tbuf[sizeof (unsigned long) * 24 / 10 + 1 + 2]; /* + 2 for final
\n\0 */
since there are roughly 10 bits for every 3 decimal digits.
But I'm
Sasha Levin wrote:
Learning from what happened in this specific case, there are actually 2
issues here:
- Array size was constant and too small, which is solved by the patch
above.
- We were blindly trying to sprintf() into that array, this issue may pop
back up if someone
24 matches
Mail list logo
