Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753788AbbHaP1u (ORCPT ); Mon, 31 Aug 2015 11:27:50 -0400 Received: from mail.kernel.org ([198.145.29.136]:33549 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753114AbbHaP1t (ORCPT ); Mon, 31 Aug 2015 11:27:49 -0400 Date: Mon, 31 Aug 2015 12:27:44 -0300 From: Arnaldo Carvalho de Melo To: Jiri Olsa Cc: Jiri Olsa , lkml , David Ahern , Ingo Molnar , Namhyung Kim , Peter Zijlstra , Matt Fleming , =?iso-8859-1?Q?Rapha=EBl?= Beamonte Subject: Re: [PATCH 01/11] tools: Add err.h with ERR_PTR PTR_ERR interface Message-ID: <20150831152744.GA4423@kernel.org> References: <1440596813-12844-1-git-send-email-jolsa@kernel.org> <1440596813-12844-2-git-send-email-jolsa@kernel.org> <20150828162139.GE11407@kernel.org> <20150831073718.GF1787@krava.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150831073718.GF1787@krava.brq.redhat.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1851 Lines: 57 Em Mon, Aug 31, 2015 at 09:37:18AM +0200, Jiri Olsa escreveu: > On Fri, Aug 28, 2015 at 01:21:39PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Aug 26, 2015 at 03:46:43PM +0200, Jiri Olsa escreveu: > > > +++ b/tools/include/linux/err.h > > > @@ -0,0 +1,28 @@ > > > +#ifndef __TOOLS_LINUX_ERR_H > > > +#define __TOOLS_LINUX_ERR_H > > > + > > > +#include > > > +#include > > > + > > > +#include > > You deleted the comment in the kernel sources at this point: > right.. I did not want to bring too much attention :-)) :-) Please get the explanation about why it is safe (the unused hole bits) and merge it with the bits from the kernel comment that make sense, well, I think we can just do a s/Kernel//g and explain why that is so. > > /* > > * Kernel pointers have redundant information, so we can use a > > * scheme where we can return either an error code or a normal > > * pointer with the same return value. > > * > > * This should be a per-architecture thing, to allow different > > * error and pointer decisions. > > */ > > > +#define MAX_ERRNO 4095 > > Now we're dealing with user pointers, are we completely sure we can use > > this trick here? > it's safe for user as well, because 'error' pointers > fall down to the unused hole: > > Documentation/x86/x86_64/mm.txt: > ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole > > haven't checked for other archs, but since it's used > within generic code, it should be ok > > I'll put the comment back with additional explanation > wrt user space in v2 Thanks! - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/