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 <linux/compiler.h> > > > +#include <linux/types.h> > > > + > > > +#include <asm/errno.h>
> > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
