Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1221714 > unrolled thread

Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:10 +0200
    [PATCH 06/13] Hide ep_take_care_of_epollwakeup() behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    [PATCH 11/13] Hide MAX_RAW_MINORS behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
      Re: [PATCH 11/13] Hide MAX_RAW_MINORS behind #ifdef __KERNEL__ David Howells <dhowells@redhat.com> - 2015-09-10 13:20 +0200
    [PATCH 02/13] Always expose __SYSCALL(... fork ...) Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    [PATCH 13/13] Re-enable and clean up "check_config()" in headers_check.pl Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    [PATCH 05/13] Hide some of "struct elf_prstatus" behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    [PATCH 03/13] Hide COMPAT_ATM_ADDPARTY behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    [PATCH 08/13] Hide MAX_SHARED_LIBS behind #ifdef __KERNEL__ Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-09 23:20 +0200
    Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h David Howells <dhowells@redhat.com> - 2015-09-10 13:20 +0200
      Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h David Howells <dhowells@redhat.com> - 2015-09-10 13:20 +0200
        Re: [PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 06/13] Move ep_take_care_of_epollwakeup() to fs/eventpoll.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 02/13] Use sys_ni.c instead of #ifdef to disable fork on CONFIG_NOMMU Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 01/13] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
    [PATCH 05/13] Split FDPIC "struct elf_prstatus" to "struct elf_fdpic_prstatus" Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      Re: [PATCH 05/13] Split FDPIC "struct elf_prstatus" to "struct elf_fdpic_prstatus" David Howells <dhowells@redhat.com> - 2015-09-17 12:20 +0200
    [PATCH v3] Remove #ifdef CONFIG_* from all userspace headers Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
        Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Peter Zijlstra <peterz@infradead.org> - 2015-09-15 10:10 +0200
          Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 20:50 +0200
            Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Peter Zijlstra <peterz@infradead.org> - 2015-09-15 21:40 +0200
              Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-17 06:00 +0200
          Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c Arnd Bergmann <arnd@arndb.de> - 2015-09-15 23:20 +0200
            Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c David Howells <dhowells@redhat.com> - 2015-09-17 12:30 +0200
      [PATCH 13/13] Re-enable and clean up "check_config()" in headers_check.pl Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
        Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-15 02:30 +0200
          Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 03:00 +0200
          Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Josh Triplett <josh@joshtriplett.org> - 2015-09-15 07:20 +0200
            Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-15 11:50 +0200
              Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace Josh Triplett <josh@joshtriplett.org> - 2015-09-15 16:20 +0200
                Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace David Howells <dhowells@redhat.com> - 2015-09-17 12:20 +0200
      [PATCH 08/13] Move MAX_SHARED_LIBS to fs/binfmt_flat.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      [PATCH 07/13] Make FB_BACKLIGHT_{LEVELS,MAX} always visible Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      [PATCH 12/13] Remove AT_VECTOR_SIZE_ARCH on x86 Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
        Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace "H. Peter Anvin" <hpa@zytor.com> - 2015-09-15 22:50 +0200
          Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-17 05:10 +0200
      [PATCH 10/13] Move USE_WCACHING to drivers/block/pktcdvd.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
      [PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-15 01:00 +0200
        Re: [PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c David Howells <dhowells@redhat.com> - 2015-09-17 12:00 +0200
          Re: [PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c Palmer Dabbelt <palmer@dabbelt.com> - 2015-09-17 23:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1224743 — Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
> 
> The names in here are so generic that I don't think it's a good idea
> to expose them to userspace (or even the rest of the kernel).  Since
> there's only one kernel user, it's been moved to that file.
> 
> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
> Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
> Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
> ---
>  include/uapi/linux/hw_breakpoint.h | 10 ----------
>  kernel/events/hw_breakpoint.c      | 10 ++++++++++
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
> index b04000a2296a..7a6a5a7f9511 100644
> --- a/include/uapi/linux/hw_breakpoint.h
> +++ b/include/uapi/linux/hw_breakpoint.h
> @@ -17,14 +17,4 @@ enum {
>  	HW_BREAKPOINT_INVALID   = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
>  };
>  
> -enum bp_type_idx {
> -	TYPE_INST 	= 0,
> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
> -	TYPE_DATA	= 0,
> -#else
> -	TYPE_DATA	= 1,
> -#endif
> -	TYPE_MAX
> -};

This is rather unfortunate; you are correct that the naming is too
generic (and I tend to agree), but I think these values are required by
userspace to fill out:

  perf_event_attr::bp_type

So removing them will break things.

Frederic?
--
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/

[toc] | [prev] | [next] | [standalone]

#1225504 — Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

On Tue, 15 Sep 2015 01:06:07 PDT (-0700), peterz@infradead.org wrote:
> On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
>> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
>>
>> The names in here are so generic that I don't think it's a good idea
>> to expose them to userspace (or even the rest of the kernel).  Since
>> there's only one kernel user, it's been moved to that file.
>>
>> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
>> Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
>> Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
>> ---
>>  include/uapi/linux/hw_breakpoint.h | 10 ----------
>>  kernel/events/hw_breakpoint.c      | 10 ++++++++++
>>  2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
>> index b04000a2296a..7a6a5a7f9511 100644
>> --- a/include/uapi/linux/hw_breakpoint.h
>> +++ b/include/uapi/linux/hw_breakpoint.h
>> @@ -17,14 +17,4 @@ enum {
>>  	HW_BREAKPOINT_INVALID   = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
>>  };
>>
>> -enum bp_type_idx {
>> -	TYPE_INST 	= 0,
>> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>> -	TYPE_DATA	= 0,
>> -#else
>> -	TYPE_DATA	= 1,
>> -#endif
>> -	TYPE_MAX
>> -};
>
> This is rather unfortunate; you are correct that the naming is too
> generic (and I tend to agree), but I think these values are required by
> userspace to fill out:
>
>   perf_event_attr::bp_type
>
> So removing them will break things.
>
> Frederic?

perf_event_open(2) says

       bp_type (since Linux 2.6.33)
              This chooses the breakpoint type.  It is one of:

              HW_BREAKPOINT_EMPTY
                     No breakpoint.

              HW_BREAKPOINT_R
                     Count when we read the memory location.

              HW_BREAKPOINT_W
                     Count when we write the memory location.

              HW_BREAKPOINT_RW
                     Count when we read or write the memory location.

              HW_BREAKPOINT_X
                     Count when we execute code at the memory location.

              The values can be combined via a bitwise or, but the combination
              of HW_BREAKPOINT_R or HW_BREAKPOINT_W  with  HW_BREAKPOINT_X  is
              not allowed.

so I think removing this enum from userspace is OK.  Did I miss
something?
--
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/

[toc] | [prev] | [next] | [standalone]

#1225520 — Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

On Tue, Sep 15, 2015 at 11:40:11AM -0700, Palmer Dabbelt wrote:
> On Tue, 15 Sep 2015 01:06:07 PDT (-0700), peterz@infradead.org wrote:
> > On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
> >> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
> >>
> >> The names in here are so generic that I don't think it's a good idea
> >> to expose them to userspace (or even the rest of the kernel).  Since
> >> there's only one kernel user, it's been moved to that file.
> >>
> >> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
> >> Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
> >> Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
> >> ---
> >>  include/uapi/linux/hw_breakpoint.h | 10 ----------
> >>  kernel/events/hw_breakpoint.c      | 10 ++++++++++
> >>  2 files changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
> >> index b04000a2296a..7a6a5a7f9511 100644
> >> --- a/include/uapi/linux/hw_breakpoint.h
> >> +++ b/include/uapi/linux/hw_breakpoint.h
> >> @@ -17,14 +17,4 @@ enum {
> >>  	HW_BREAKPOINT_INVALID   = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
> >>  };
> >>
> >> -enum bp_type_idx {
> >> -	TYPE_INST 	= 0,
> >> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
> >> -	TYPE_DATA	= 0,
> >> -#else
> >> -	TYPE_DATA	= 1,
> >> -#endif
> >> -	TYPE_MAX
> >> -};
> >
> > This is rather unfortunate; you are correct that the naming is too
> > generic (and I tend to agree), but I think these values are required by
> > userspace to fill out:
> >
> >   perf_event_attr::bp_type
> >
> > So removing them will break things.
> >
> > Frederic?
> 
> perf_event_open(2) says
> 
>        bp_type (since Linux 2.6.33)
>               This chooses the breakpoint type.  It is one of:
> 
>               HW_BREAKPOINT_EMPTY
>                      No breakpoint.
> 
>               HW_BREAKPOINT_R
>                      Count when we read the memory location.
> 
>               HW_BREAKPOINT_W
>                      Count when we write the memory location.
> 
>               HW_BREAKPOINT_RW
>                      Count when we read or write the memory location.
> 
>               HW_BREAKPOINT_X
>                      Count when we execute code at the memory location.
> 
>               The values can be combined via a bitwise or, but the combination
>               of HW_BREAKPOINT_R or HW_BREAKPOINT_W  with  HW_BREAKPOINT_X  is
>               not allowed.
> 
> so I think removing this enum from userspace is OK.  Did I miss
> something?

Nah, could've just been me not being awake. Unless Frederic says
otherwise I'll chalk it up to not having drank enough morning juice.
--
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/

[toc] | [prev] | [next] | [standalone]

#1226650 — Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

On Tue, 15 Sep 2015 12:39:10 PDT (-0700), peterz@infradead.org wrote:
> On Tue, Sep 15, 2015 at 11:40:11AM -0700, Palmer Dabbelt wrote:
>> On Tue, 15 Sep 2015 01:06:07 PDT (-0700), peterz@infradead.org wrote:
>> > On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
>> >> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
>> >>
>> >> The names in here are so generic that I don't think it's a good idea
>> >> to expose them to userspace (or even the rest of the kernel).  Since
>> >> there's only one kernel user, it's been moved to that file.
>> >>
>> >> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
>> >> Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
>> >> Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
>> >> ---
>> >>  include/uapi/linux/hw_breakpoint.h | 10 ----------
>> >>  kernel/events/hw_breakpoint.c      | 10 ++++++++++
>> >>  2 files changed, 10 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
>> >> index b04000a2296a..7a6a5a7f9511 100644
>> >> --- a/include/uapi/linux/hw_breakpoint.h
>> >> +++ b/include/uapi/linux/hw_breakpoint.h
>> >> @@ -17,14 +17,4 @@ enum {
>> >>  	HW_BREAKPOINT_INVALID   = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
>> >>  };
>> >>
>> >> -enum bp_type_idx {
>> >> -	TYPE_INST 	= 0,
>> >> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>> >> -	TYPE_DATA	= 0,
>> >> -#else
>> >> -	TYPE_DATA	= 1,
>> >> -#endif
>> >> -	TYPE_MAX
>> >> -};
>> >
>> > This is rather unfortunate; you are correct that the naming is too
>> > generic (and I tend to agree), but I think these values are required by
>> > userspace to fill out:
>> >
>> >   perf_event_attr::bp_type
>> >
>> > So removing them will break things.
>> >
>> > Frederic?
>>
>> perf_event_open(2) says
>>
>>        bp_type (since Linux 2.6.33)
>>               This chooses the breakpoint type.  It is one of:
>>
>>               HW_BREAKPOINT_EMPTY
>>                      No breakpoint.
>>
>>               HW_BREAKPOINT_R
>>                      Count when we read the memory location.
>>
>>               HW_BREAKPOINT_W
>>                      Count when we write the memory location.
>>
>>               HW_BREAKPOINT_RW
>>                      Count when we read or write the memory location.
>>
>>               HW_BREAKPOINT_X
>>                      Count when we execute code at the memory location.
>>
>>               The values can be combined via a bitwise or, but the combination
>>               of HW_BREAKPOINT_R or HW_BREAKPOINT_W  with  HW_BREAKPOINT_X  is
>>               not allowed.
>>
>> so I think removing this enum from userspace is OK.  Did I miss
>> something?
>
> Nah, could've just been me not being awake. Unless Frederic says
> otherwise I'll chalk it up to not having drank enough morning juice.

Well, I'm going to leave this alone, then -- as Arnd pointed out in a
later email that got mis-threaded, this would be super tricky to fix
if userspace actually relied on it (which is why I was scared I was
wrong).

v4 (which is hopefully the final version of the patch set) will leave
this as it is.
--
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/

[toc] | [prev] | [next] | [standalone]

#1225551 — Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

On Tuesday 15 September 2015 10:06:07 Peter Zijlstra wrote:
> > diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
> > index b04000a2296a..7a6a5a7f9511 100644
> > --- a/include/uapi/linux/hw_breakpoint.h
> > +++ b/include/uapi/linux/hw_breakpoint.h
> > @@ -17,14 +17,4 @@ enum {
> >       HW_BREAKPOINT_INVALID   = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
> >  };
> >  
> > -enum bp_type_idx {
> > -     TYPE_INST       = 0,
> > -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
> > -     TYPE_DATA       = 0,
> > -#else
> > -     TYPE_DATA       = 1,
> > -#endif
> > -     TYPE_MAX
> > -};
> 
> This is rather unfortunate; you are correct that the naming is too
> generic (and I tend to agree), but I think these values are required by
> userspace to fill out:
> 
>   perf_event_attr::bp_type
> 
> So removing them will break things.
> 
> Frederic?

If user space actually relies on the definition from this header file,
then it will use the wrong one on x86 and get 'TYPE_DATA = 1', while the
kernel uses 'TYPE_DATA = 0'.

That seems unlikely to work, so I suspect it gets a different definition.
If it uses this definition and it does work, we can probably use

#if defined(__KERNEL__) && defined(CONFIG_HAVE_MIXED_BREAKPOINTS_REGS)

but that requires a comment explaining exactly why that works.

	Arnd
--
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/

[toc] | [prev] | [next] | [standalone]

#1226885 — Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

Arnd Bergmann <arnd@arndb.de> wrote:

> That seems unlikely to work, so I suspect it gets a different definition.
> If it uses this definition and it does work, we can probably use
> 
> #if defined(__KERNEL__) && defined(CONFIG_HAVE_MIXED_BREAKPOINTS_REGS)
> 
> but that requires a comment explaining exactly why that works.

Are you suggesting wrapping the entire construct in this within the UAPI
header?

David
--
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/

[toc] | [prev] | [next] | [standalone]

#1224524 — [PATCH 13/13] Re-enable and clean up "check_config()" in headers_check.pl

I recently got bit by a CONFIG_ in userspace bug.  This has apparently
happened before, but the check got disabled for triggering too much.
In order to reduce false positives, I added some hueristics to avoid
detecting comments.

Since these tests all pass, I've now re-enabled them.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
---
 scripts/headers_check.pl | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl
index 62320f93e903..dd413ad9c850 100755
--- a/scripts/headers_check.pl
+++ b/scripts/headers_check.pl
@@ -40,7 +40,7 @@ foreach my $file (@files) {
 		&check_asm_types();
 		&check_sizetypes();
 		&check_declarations();
-		# Dropped for now. Too much noise &check_config();
+		&check_config();
 	}
 	close $fh;
 }
@@ -76,9 +76,24 @@ sub check_declarations
 	}
 }
 
+my $check_config_in_multiline_comment = 0;
 sub check_config
 {
-	if ($line =~ m/[^a-zA-Z0-9_]+CONFIG_([a-zA-Z0-9_]+)[^a-zA-Z0-9_]/) {
+	my $nocomments = $line;
+	$nocomments =~ s/\/\*.*\*\///; # Remove ANSI-style comments (/* to */)
+	$nocomments =~ s/\/\/.*//;     # Remove C99-style comments (// to EOL)
+
+	# Check to see if we're within a multiline comment, and if so
+	# just remove the whole line.  I tried matching on '^ * ', but
+	# there's one header that doesn't prepend multi-line comments
+	# with * so that won't work.
+	if ($nocomments =~ m/\/\*/) { $check_config_in_multiline_comment = 1; }
+	if ($nocomments =~ m/\*\//) { $check_config_in_multiline_comment = 0; }
+	if ($check_config_in_multiline_comment == 1) { $nocomments = "" }
+
+	# Check to see if there is something that looks like CONFIG_
+	# inside a userspace-accessible header file and if so, print that out.
+	if ($nocomments =~ m/[^a-zA-Z0-9_]+CONFIG_([a-zA-Z0-9_]+)[^a-zA-Z0-9_]/) {
 		printf STDERR "$filename:$lineno: leaks CONFIG_$1 to userspace where it is not valid\n";
 	}
 }
-- 
2.4.6

--
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/

[toc] | [prev] | [next] | [standalone]

#1224527 — [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
userspace wouldn't actually ever see it be non-zero.  While I could
have kept hiding it, the man pages seem to indicate that
MAP_UNINITIALIZED should be visible:

  mmap(2)
  MAP_UNINITIALIZED (since Linux 2.6.33)
    Don't clear anonymous pages.  This flag is intended to improve
    performance on embedded devices.  This flag is honored only if the
    kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
    option.  Because of the security implications, that option is
    normally enabled only on embedded devices (i.e., devices where one
    has complete control of the contents of user memory).

and since the only time it shows up in my /usr/include is in this
header I believe this should have been visible to userspace (as
non-zero, which wouldn't do anything when or'd into the flags) all
along.

This change also applies to the xtensa version of this definition,
whic is the same as the generic one.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
---
 arch/xtensa/include/uapi/asm/mman.h    | 4 +---
 include/uapi/asm-generic/mman-common.h | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h
index 201aec0e0446..2cbc1e717082 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -55,11 +55,9 @@
 #define MAP_NONBLOCK	0x20000		/* do not block on IO */
 #define MAP_STACK	0x40000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x80000		/* create a huge page mapping */
-#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
+#ifndef MAP_UNINITIALIZED
 # define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be
 					 * uninitialized */
-#else
-# define MAP_UNINITIALIZED 0x0		/* Don't support this flag */
 #endif
 
 /*
diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
index ddc3b36f1046..7aeeb12db193 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -19,10 +19,8 @@
 #define MAP_TYPE	0x0f		/* Mask for type of mapping */
 #define MAP_FIXED	0x10		/* Interpret addr exactly */
 #define MAP_ANONYMOUS	0x20		/* don't use a file */
-#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
+#ifndef MAP_UNINITIALIZED
 # define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be uninitialized */
-#else
-# define MAP_UNINITIALIZED 0x0		/* Don't support this flag */
 #endif
 
 #define MS_ASYNC	1		/* sync memory asynchronously */
-- 
2.4.6

--
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/

[toc] | [prev] | [next] | [standalone]

#1224560 — Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
> This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
> userspace wouldn't actually ever see it be non-zero.  While I could
> have kept hiding it, the man pages seem to indicate that
> MAP_UNINITIALIZED should be visible:
> 
>   mmap(2)
>   MAP_UNINITIALIZED (since Linux 2.6.33)
>     Don't clear anonymous pages.  This flag is intended to improve
>     performance on embedded devices.  This flag is honored only if the
>     kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
>     option.  Because of the security implications, that option is
>     normally enabled only on embedded devices (i.e., devices where one
>     has complete control of the contents of user memory).
> 
> and since the only time it shows up in my /usr/include is in this
> header I believe this should have been visible to userspace (as
> non-zero, which wouldn't do anything when or'd into the flags) all
> along.

Are you sure about "wouldn't do anything"?
Suspiciously, 0x4000000 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any
architecture has order-1 huge pages, but still looks like we have conflict
here.

I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which
potentially can handle multiple users. Or non-trivial user space in
general.

Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's
possible to have single ABI for MMU and MMU-less systems anyway. And we
can avoid conflict with MAP_HUGE_SHIFT this way.

P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
mailing list on why it was allowed. 
But that's other topic.

-- 
 Kirill A. Shutemov
--
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/

[toc] | [prev] | [next] | [standalone]

#1224565 — Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

On Mon, 14 Sep 2015 17:23:58 PDT (-0700), kirill@shutemov.name wrote:
> On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
>> This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
>> userspace wouldn't actually ever see it be non-zero.  While I could
>> have kept hiding it, the man pages seem to indicate that
>> MAP_UNINITIALIZED should be visible:
>>
>>   mmap(2)
>>   MAP_UNINITIALIZED (since Linux 2.6.33)
>>     Don't clear anonymous pages.  This flag is intended to improve
>>     performance on embedded devices.  This flag is honored only if the
>>     kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
>>     option.  Because of the security implications, that option is
>>     normally enabled only on embedded devices (i.e., devices where one
>>     has complete control of the contents of user memory).
>>
>> and since the only time it shows up in my /usr/include is in this
>> header I believe this should have been visible to userspace (as
>> non-zero, which wouldn't do anything when or'd into the flags) all
>> along.
>
> Are you sure about "wouldn't do anything"?

That was bad writing for me.  I'd originally written something like "I
believe this should have been visible to userspace all along", but
then added the ()'s.  I meant to say:

 * I think MAP_UNINITIALIZED should have been non-zero in userspace.
 * MAP_UNINITAILIZED was zero in userspace.
 * A zero MAP_UNINITIALIZED does nothing when OR'd in.

> Suspiciously, 0x4000000 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any
> architecture has order-1 huge pages, but still looks like we have conflict
> here.
>
> I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which
> potentially can handle multiple users. Or non-trivial user space in
> general.

This doesn't have MAP_UNINITIALIZED do anything by default, it just
defines the flag the same way on all systems.  I was under the
impression that this just happened if I set MAP_UNINITIALIZED.
Looking at MAP_HUGE_SHIFT it mmap.c, that's definitely why my mmap()
test case ignored the set MAP_UNINITIALIZED on my PC.

I'm going to make this

 #ifndef MAP_UNINITAILIZED
 #define MAP_UNINITAILIZED 0
 #endif

and then leave Xtensa's port alone.  This is what Arnd suggested
originally, sorry for the extra work!

> Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's
> possible to have single ABI for MMU and MMU-less systems anyway. And we
> can avoid conflict with MAP_HUGE_SHIFT this way.

The whole goal here was to eliminate "#ifndef CONFIG_*" from the
user-visible headers.  This all started because I got bit by a very
similar-looking bug (see patch #1), so I'd prefer not to go down that
route.

> P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> mailing list on why it was allowed.
> But that's other topic.
--
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/

[toc] | [prev] | [next] | [standalone]

#1224642 — Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
> > This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
> > userspace wouldn't actually ever see it be non-zero.  While I could
> > have kept hiding it, the man pages seem to indicate that
> > MAP_UNINITIALIZED should be visible:
> > 
> >   mmap(2)
> >   MAP_UNINITIALIZED (since Linux 2.6.33)
> >     Don't clear anonymous pages.  This flag is intended to improve
> >     performance on embedded devices.  This flag is honored only if the
> >     kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
> >     option.  Because of the security implications, that option is
> >     normally enabled only on embedded devices (i.e., devices where one
> >     has complete control of the contents of user memory).
> > 
> > and since the only time it shows up in my /usr/include is in this
> > header I believe this should have been visible to userspace (as
> > non-zero, which wouldn't do anything when or'd into the flags) all
> > along.
> 
> Are you sure about "wouldn't do anything"?
> Suspiciously, 0x4000000 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any
> architecture has order-1 huge pages, but still looks like we have conflict
> here.
> 
> I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which
> potentially can handle multiple users. Or non-trivial user space in
> general.

The flag should always exist.  If it was defined to conflict with
something else, that's a serious ABI problem.  But the flag
should always exist, even if the kernel ends up ignoring it.

> Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's
> possible to have single ABI for MMU and MMU-less systems anyway. And we
> can avoid conflict with MAP_HUGE_SHIFT this way.

No; even if you have an MMU (which is useful for things like fork()), a
system without user separation (for instance, without CONFIG_MULTIUSER)
can reasonably use MAP_UNINITIALIZED.

> P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> mailing list on why it was allowed.

That's what the config option *and* explicit flag are for; there are
more than enough warnings about the implications.

- Josh Triplett
--
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/

[toc] | [prev] | [next] | [standalone]

#1224932 — Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

On Mon, Sep 14, 2015 at 10:19:19PM -0700, Josh Triplett wrote:
> On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
> > > This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
> > > userspace wouldn't actually ever see it be non-zero.  While I could
> > > have kept hiding it, the man pages seem to indicate that
> > > MAP_UNINITIALIZED should be visible:
> > > 
> > >   mmap(2)
> > >   MAP_UNINITIALIZED (since Linux 2.6.33)
> > >     Don't clear anonymous pages.  This flag is intended to improve
> > >     performance on embedded devices.  This flag is honored only if the
> > >     kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
> > >     option.  Because of the security implications, that option is
> > >     normally enabled only on embedded devices (i.e., devices where one
> > >     has complete control of the contents of user memory).
> > > 
> > > and since the only time it shows up in my /usr/include is in this
> > > header I believe this should have been visible to userspace (as
> > > non-zero, which wouldn't do anything when or'd into the flags) all
> > > along.
> > 
> > Are you sure about "wouldn't do anything"?
> > Suspiciously, 0x4000000 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any
> > architecture has order-1 huge pages, but still looks like we have conflict
> > here.
> > 
> > I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which
> > potentially can handle multiple users. Or non-trivial user space in
> > general.
> 
> The flag should always exist.

Sure. And 0 is perfectly fine value for the flag. Like with MAP_FILE.

> If it was defined to conflict with
> something else, that's a serious ABI problem.  But the flag
> should always exist, even if the kernel ends up ignoring it.
> 
> > Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's
> > possible to have single ABI for MMU and MMU-less systems anyway. And we
> > can avoid conflict with MAP_HUGE_SHIFT this way.
> 
> No; even if you have an MMU (which is useful for things like fork()), a
> system without user separation (for instance, without CONFIG_MULTIUSER)
> can reasonably use MAP_UNINITIALIZED.

Can? Yes. Reasonably? I don't think so.

> > P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> > mailing list on why it was allowed.
> 
> That's what the config option *and* explicit flag are for; there are
> more than enough warnings about the implications.

I think it's misdesigned. It doesn't require explicid opt-in from a
process who owned the page allocated in MAP_UNINITIALIZED mapping before.

#define MAP_LEAK_ME_SOME_DATA MAP_UNINITIALIZED

-- 
 Kirill A. Shutemov
--
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/

[toc] | [prev] | [next] | [standalone]

#1225157 — Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

On Tue, Sep 15, 2015 at 12:42:00PM +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 14, 2015 at 10:19:19PM -0700, Josh Triplett wrote:
> > On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> > > On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
> > > > This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
> > > > userspace wouldn't actually ever see it be non-zero.  While I could
> > > > have kept hiding it, the man pages seem to indicate that
> > > > MAP_UNINITIALIZED should be visible:
> > > > 
> > > >   mmap(2)
> > > >   MAP_UNINITIALIZED (since Linux 2.6.33)
> > > >     Don't clear anonymous pages.  This flag is intended to improve
> > > >     performance on embedded devices.  This flag is honored only if the
> > > >     kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
> > > >     option.  Because of the security implications, that option is
> > > >     normally enabled only on embedded devices (i.e., devices where one
> > > >     has complete control of the contents of user memory).
> > > > 
> > > > and since the only time it shows up in my /usr/include is in this
> > > > header I believe this should have been visible to userspace (as
> > > > non-zero, which wouldn't do anything when or'd into the flags) all
> > > > along.
> > > 
> > > Are you sure about "wouldn't do anything"?
> > > Suspiciously, 0x4000000 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any
> > > architecture has order-1 huge pages, but still looks like we have conflict
> > > here.
> > > 
> > > I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which
> > > potentially can handle multiple users. Or non-trivial user space in
> > > general.
> > 
> > The flag should always exist.
> 
> Sure. And 0 is perfectly fine value for the flag. Like with MAP_FILE.

Rephrasing: the flag should always exist with the correct value.
Whether the kernel handles it or not, the kernel *headers* shouldn't
change to match the kernel, not least of which because they don't
necessarily match the running kernel.  Just like we define the
prototypes for syscalls that the running kernel may return ENOSYS for.

> > If it was defined to conflict with
> > something else, that's a serious ABI problem.  But the flag
> > should always exist, even if the kernel ends up ignoring it.
> > 
> > > Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's
> > > possible to have single ABI for MMU and MMU-less systems anyway. And we
> > > can avoid conflict with MAP_HUGE_SHIFT this way.
> > 
> > No; even if you have an MMU (which is useful for things like fork()), a
> > system without user separation (for instance, without CONFIG_MULTIUSER)
> > can reasonably use MAP_UNINITIALIZED.
> 
> Can? Yes. Reasonably? I don't think so.

Not all systems care.  Otherwise you should be complaining more bitterly
about options like CONFIG_MMU=n, which (*gasp*) allow access to *arbitrary
memory*.

> > > P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> > > mailing list on why it was allowed.
> > 
> > That's what the config option *and* explicit flag are for; there are
> > more than enough warnings about the implications.
> 
> I think it's misdesigned. It doesn't require explicid opt-in from a
> process who owned the page allocated in MAP_UNINITIALIZED mapping before.
> 
> #define MAP_LEAK_ME_SOME_DATA MAP_UNINITIALIZED

Hence why it has a config option.

The userspace option exists primarily because otherwise userspace might
get surprised by receiving a non-zeroed page.  On a system with the
config option turned on, processes have access to arbitrary freed
memory, as long as they say they can handle not having their memory
pre-zeroed.

- Josh Triplett
--
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/

[toc] | [prev] | [next] | [standalone]

#1226871 — Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

Josh Triplett <josh@joshtriplett.org> wrote:

> > Sure. And 0 is perfectly fine value for the flag. Like with MAP_FILE.
> 
> Rephrasing: the flag should always exist with the correct value.
> Whether the kernel handles it or not, the kernel *headers* shouldn't
> change to match the kernel, not least of which because they don't
> necessarily match the running kernel.  Just like we define the
> prototypes for syscalls that the running kernel may return ENOSYS for.

Josh is correct.

CONFIG_xxx *should* *not* be seen in UAPI headers, except inside #ifdef
__KERNEL__ guards under special circumstances - and #ifdef __KERNEL__ guards
*should* *not* be seen in UAPI headers except under special circumstances.

In terms of such special circumstances, take a peek in
include/uapi/linux/acct.h at struct acct with this:

	/* m68k had no padding here. */
	#if !defined(CONFIG_M68K) || !defined(__KERNEL__)
		__u16		ac_ahz;			/* AHZ */
	#endif

in the middle of it...

Or include/{,uapi/}linux/agpgart.h where it defines two different but
same-named variants of several structs.

Now, some of these - particularly things like the latter - can be fixed by
someone who has the time.

David
--
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/

[toc] | [prev] | [next] | [standalone]

#1224528 — [PATCH 08/13] Move MAX_SHARED_LIBS to fs/binfmt_flat.c

I'm not sure what this is, but it doesn't feel like something that
should be exposed to userspace here.  I'm assuming this file was
exposed for the structure in it, which doesn't depend on
MAX_SHARED_LIBS.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
---
 fs/binfmt_flat.c          | 6 ++++++
 include/uapi/linux/flat.h | 6 ------
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index f723cd3a455c..e89fb43c2a10 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -72,6 +72,12 @@
 #define RELOC_FAILED 0xff00ff01		/* Relocation incorrect somewhere */
 #define UNLOADED_LIB 0x7ff000ff		/* Placeholder for unused library */
 
+#ifdef CONFIG_BINFMT_SHARED_FLAT
+#define	MAX_SHARED_LIBS			(4)
+#else
+#define	MAX_SHARED_LIBS			(1)
+#endif
+
 struct lib_info {
 	struct {
 		unsigned long start_code;		/* Start of text segment */
diff --git a/include/uapi/linux/flat.h b/include/uapi/linux/flat.h
index 88cd6baba8f3..1b177c7637c4 100644
--- a/include/uapi/linux/flat.h
+++ b/include/uapi/linux/flat.h
@@ -13,12 +13,6 @@
 
 #define	FLAT_VERSION			0x00000004L
 
-#ifdef CONFIG_BINFMT_SHARED_FLAT
-#define	MAX_SHARED_LIBS			(4)
-#else
-#define	MAX_SHARED_LIBS			(1)
-#endif
-
 /*
  * To make everything easier to port and manage cross platform
  * development,  all fields are in network byte order.
-- 
2.4.6

--
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/

[toc] | [prev] | [next] | [standalone]

#1224529 — [PATCH 07/13] Make FB_BACKLIGHT_{LEVELS,MAX} always visible

Nothing else in the kernel defines this, and this header is visible to
userspace.  Rather than hiding it in an #ifdef, I think it's sane to
just make this visible to userspace.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
---
 include/uapi/linux/fb.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h
index fb795c3b3c17..8926f13bc19f 100644
--- a/include/uapi/linux/fb.h
+++ b/include/uapi/linux/fb.h
@@ -392,11 +392,8 @@ struct fb_cursor {
 	struct fb_image	image;	/* Cursor image */
 };
 
-#ifdef CONFIG_FB_BACKLIGHT
 /* Settings for the generic backlight code */
 #define FB_BACKLIGHT_LEVELS	128
 #define FB_BACKLIGHT_MAX	0xFF
-#endif
-
 
 #endif /* _UAPI_LINUX_FB_H */
-- 
2.4.6

--
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/

[toc] | [prev] | [next] | [standalone]

#1224530 — [PATCH 12/13] Remove AT_VECTOR_SIZE_ARCH on x86

It looks like there aren't actually users of this macro anywhere:

 * The kernel doesn't use it on x86 because we don't suppor ELF FDPIC.

 * The only Google results point to LMKL patches, both the one that
   wrote this (from 2010) and my patch to hide it behind __KERNEL__.

 * I grep'd through all the source tarballs on my machine, and the
   only packages that matched were the kernel and crui (which copied a
   PPC kernel header).

Since I'm not sure how to actually provide the right answer (if I
understand correctly, CONFIG_IA32_EMULATION is not __i386__), the only
thing I can think of to do is to just remove the definition.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
---
 arch/x86/include/uapi/asm/auxvec.h | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/x86/include/uapi/asm/auxvec.h b/arch/x86/include/uapi/asm/auxvec.h
index 77203ac352de..1316b4c35425 100644
--- a/arch/x86/include/uapi/asm/auxvec.h
+++ b/arch/x86/include/uapi/asm/auxvec.h
@@ -9,11 +9,4 @@
 #endif
 #define AT_SYSINFO_EHDR		33
 
-/* entries in ARCH_DLINFO: */
-#if defined(CONFIG_IA32_EMULATION) || !defined(CONFIG_X86_64)
-# define AT_VECTOR_SIZE_ARCH 2
-#else /* else it's non-compat x86-64 */
-# define AT_VECTOR_SIZE_ARCH 1
-#endif
-
 #endif /* _ASM_X86_AUXVEC_H */
-- 
2.4.6

--
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/

[toc] | [prev] | [next] | [standalone]

#1224531 — [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace

While I don't think this was ever meant to be exposed to userspace, if
anyone is using it then this will at least provide a correct (if
unlikely) definition.

MAX_RAW_MINORS used to be used in the kernel, where it's been replaced
with CONFIG_MAX_RAW_MINORS.

Note that there's a checkpatch.pl warning about a split config string
here, but I've left that alone.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
---
 drivers/char/raw.c       | 7 ++++---
 include/uapi/linux/raw.h | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/char/raw.c b/drivers/char/raw.c
index 60316fbaf295..362d7a6511b9 100644
--- a/drivers/char/raw.c
+++ b/drivers/char/raw.c
@@ -36,7 +36,7 @@ static struct raw_device_data *raw_devices;
 static DEFINE_MUTEX(raw_mutex);
 static const struct file_operations raw_ctl_fops; /* forward declaration */
 
-static int max_raw_minors = MAX_RAW_MINORS;
+static int max_raw_minors = CONFIG_MAX_RAW_MINORS;
 
 module_param(max_raw_minors, int, 0);
 MODULE_PARM_DESC(max_raw_minors, "Maximum number of raw devices (1-65536)");
@@ -317,8 +317,9 @@ static int __init raw_init(void)
 
 	if (max_raw_minors < 1 || max_raw_minors > 65536) {
 		printk(KERN_WARNING "raw: invalid max_raw_minors (must be"
-			" between 1 and 65536), using %d\n", MAX_RAW_MINORS);
-		max_raw_minors = MAX_RAW_MINORS;
+			" between 1 and 65536), using %d\n",
+		       CONFIG_MAX_RAW_MINORS);
+		max_raw_minors = CONFIG_MAX_RAW_MINORS;
 	}
 
 	raw_devices = vzalloc(sizeof(struct raw_device_data) * max_raw_minors);
diff --git a/include/uapi/linux/raw.h b/include/uapi/linux/raw.h
index 62d543e70603..f0390b3e8530 100644
--- a/include/uapi/linux/raw.h
+++ b/include/uapi/linux/raw.h
@@ -13,6 +13,6 @@ struct raw_config_request
 	__u64	block_minor;
 };
 
-#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
+#define MAX_RAW_MINORS 65535
 
 #endif /* __LINUX_RAW_H */
-- 
2.4.6

--
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/

[toc] | [prev] | [next] | [standalone]

#1225544 — Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace

On 09/14/2015 03:50 PM, Palmer Dabbelt wrote:
> While I don't think this was ever meant to be exposed to userspace, if
> anyone is using it then this will at least provide a correct (if
> unlikely) definition.
> 
> MAX_RAW_MINORS used to be used in the kernel, where it's been replaced
> with CONFIG_MAX_RAW_MINORS.
> 
> Note that there's a checkpatch.pl warning about a split config string
> here, but I've left that alone.

From a UAPI perspective I would think the right value would be 2^20.

	-hpa


--
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/

[toc] | [prev] | [next] | [standalone]

#1226642 — Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace

On Tue, 15 Sep 2015 13:42:47 PDT (-0700), hpa@zytor.com wrote:
> On 09/14/2015 03:50 PM, Palmer Dabbelt wrote:
>> While I don't think this was ever meant to be exposed to userspace, if
>> anyone is using it then this will at least provide a correct (if
>> unlikely) definition.
>>
>> MAX_RAW_MINORS used to be used in the kernel, where it's been replaced
>> with CONFIG_MAX_RAW_MINORS.
>>
>> Note that there's a checkpatch.pl warning about a split config string
>> here, but I've left that alone.
>
> From a UAPI perspective I would think the right value would be 2^20.

Wow, I'm super surprised.  For some reason I thought major/minor
numbers were 16 bits, but according to glibc I just have no idea what
I'm doing :).

Thanks for catching this!
--
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/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web