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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Mon, 16 Oct 2006 21:31:40 +0200
From:	Andreas Mohr <andi@...x01.fht-esslingen.de>
To:	Ralf Baechle <ralf@...ux-mips.org>
Cc:	"Randy.Dunlap" <rdunlap@...otime.net>,
	Andrew Morton <akpm@...l.org>,
	Erik Frederiksen <erik_frederiksen@...-sierra.com>,
	linux-kernel@...r.kernel.org
Subject: Re: IS_ERR Threshold Value

Hi,

On Thu, Jun 29, 2006 at 07:10:13PM +0100, Ralf Baechle wrote:
> On Wed, Jun 28, 2006 at 02:08:25PM -0700, Randy.Dunlap wrote:
> 
> > Hi,
> > Peter Anvin mentioned just a few days ago that this threshold value
> > should be 4095 for all arches.  I think we need to get that patch
> > done & submitted to Andrew for -mm.
> 
> So here the patch is:
> 
>  o Raise the maximum error number in IS_ERR_VALUE to 4095.
>  o Make that number available as a new constant MAX_ERRNO.
> 
> Signed-off-by: Ralf Baechle <ralf@...ux-mips.org>
> 
> diff --git a/include/linux/err.h b/include/linux/err.h
> index ff71d2a..cd3b367 100644
> --- a/include/linux/err.h
> +++ b/include/linux/err.h
> @@ -13,7 +13,9 @@ #include <asm/errno.h>
>   * This should be a per-architecture thing, to allow different
>   * error and pointer decisions.
>   */
> -#define IS_ERR_VALUE(x) unlikely((x) > (unsigned long)-1000L)
> +#define MAX_ERRNO	4095
> +
> +#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
>  
>  static inline void *ERR_PTR(long error)
>  {

# cat /proc/likely_prof |grep -v "^ "

Likely Profiling Results
[+- ] Type | # True | # False | Function:Filename@...e
+unlikely |     1872|        0  IS_ERR()@:include/linux/err.h@34
-likely   |       88|     1033  remove_from_swapped_list()@:mm/swap_prefetch.c@140
-likely   |      311|     2679  tcp_transmit_skb()@:net/ipv4/tcp_output.c@372
-likely   |        0|   175176  __switch_to_xtra()@:arch/i386/kernel/process.c@569
+unlikely |       20|       19  remap_pte_range()@:mm/memory.c@...2
+unlikely |        9|        0  signal_pending()@:include/linux/sched.h@...3
+unlikely |        9|        0  signal_pending()@:include/linux/sched.h@...3
-likely   |    15591|    44490  generic_file_buffered_write()@:mm/filemap.c@...0
+unlikely |       45|        0  ll_front_merge_fn()@:block/ll_rw_blk.c@...5
+unlikely |        1|        0  simple_pin_fs()@:fs/libfs.c@419
+unlikely |      216|        0  inotify_find_update_watch()@:fs/inotify.c@597
+unlikely |     1820|        0  get_locked_pte()@:mm/memory.c@...4
+unlikely |    82529|        0  ll_back_merge_fn()@:block/ll_rw_blk.c@...7
+unlikely |   416831|   116869  need_resched()@:include/linux/sched.h@...8
+unlikely | 28334365| 23531065  __lock_acquire()@:kernel/lockdep.c@...4

# uname -a
Linux andi 2.6.19-rc1-mm1 #1 Thu Oct 19 23:55:19 CEST 2006 i686 GNU/Linux

Athlon 1200, Debian


Hmmmmmm...
(I strongly believe I've seen this particular unlikely place trigger sometime
before already!)


Could this be because

+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)

should be made to be
#define IS_ERR_VALUE(x) unlikely((unsigned long)(x) >= (unsigned long)-MAX_ERRNO)
similar to what some other code in this discussion thread does?
(don't ask me which code is actually invoking this macro; obviously this
might be a problem due to unexpected (non-)failure which seems to be happening
here)


And some other (un)likely results here seem fishy as well, no matter
what kind of load I throw at my box... (pondering sending some patches
for the worst excesses). Any comments about those results above?

My results seem to strongly indicate that nobody else is doing unlikely
profiling??

Andreas Mohr
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ