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 thi
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, b
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 n
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 w
Bernd Petrovitsch wrote:
[]
> Pure K&R:
We can (and should) make it "const" too.
No "const" in K&R 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
Jan Engelhardt wrote:
>A pure K&R-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...
K&R doesn't have the \x escape, only \0 (octal).
--
To unsubscribe fr
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
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
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
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 de
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 decim
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
12 matches
Mail list logo
