| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20090323165720.GC5393@buzzloop.caiaq.de> Date: Mon, 23 Mar 2009 17:57:20 +0100 From: Daniel Mack <daniel@...aq.de> To: Frederic Weisbecker <fweisbec@...il.com> Cc: linux-kernel@...r.kernel.org Subject: Re: [PATCH] kernel/trace/trace_functions_graph.c: fix nsecs_str buffer size Hi Frederic, On Mon, Mar 23, 2009 at 05:40:31PM +0100, Frederic Weisbecker wrote: > It can't really happen because nsecs_rem is a rest of a division > per 1000, so it will not exceed 3 digits (so it should be [4] and not > [5], btw). > > I must confess I should have added a better comment on this > area. > > We are printing a duration in usec with a part in nsec with the following > constraints: > > _ never exceed 7 characters unless we are are upper 9999999 usecs > _ always keep the usecs consistants > > Which means that while we have 4 or lesser digits for the usecs, we can > print the 3 digits of the nanosecs. > > If we need 5 for usecs, drop the least significant nanosec digit. > If we need 6 for usecs, drop the two least significant nanosec digits Ok, I see. I was just confused about the max len argument to snprintf() (and so was cppcheck), but at a closer look, this can't become a problem. Nevermind, drop the patch - but good that we talked about it :) Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists