Skip to contentSkip to conversation

Personality

DISCUSSION Carsten Langgaard 4 participants 7 messages Jul 16, 2002 – Jul 17, 2002 1 message not in the archive MIPS

lore
Share & tools
lore
#0 lore raw

The include/linux/personality.h file has changed between the 2.4.3 and the 2.4.18 kernel.
Now there is a define of personality (#define personality(pers) (pers & PER_MASK), but that breaks things for the users, if they include this file.
The user wishes to call the glibc personality function (which do the syscall), and not use the above definition.

So I guess we need a "#ifdef __KERNEL__" around some of the code in include/linux/personality.h (at least around the define of personality), which then has to go into the glibc kernel header files.

Any comments ?

/Carsten

--

_    _ ____  ___   Carsten Langgaard   Mailto:[email protected]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com
#1 lore raw
Quoted 8 lines · Carsten Langgaard

The include/linux/personality.h file has changed between the 2.4.3 and the 2.4.18 kernel.
Now there is a define of personality (#define personality(pers) (pers & PER_MASK), but that breaks things for the users, if they include this file.
The user wishes to call the glibc personality function (which do the syscall), and not use the above definition.

Quoted 5 lines

So I guess we need a "#ifdef __KERNEL__" around some of the code in include/linux/personality.h (at least around the define of personality), which then has to go into the glibc kernel header files.

Any comments ?

Why is the user program including <linux/personality.h> in the first place?

The right thing to do here is to provide the necessary bits in a glibc header, probably in bits/personality.h or so.

Signature · 2 lines
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
#2 lore raw
Quoted 9 lines · Daniel Jacobowitz
Quoted 8 lines · Carsten Langgaard

The include/linux/personality.h file has changed between the 2.4.3 and the 2.4.18 kernel.
Now there is a define of personality (#define personality(pers) (pers & PER_MASK), but that breaks things for the users, if they include this file.
The user wishes to call the glibc personality function (which do the syscall), and not use the above definition.

Quoted 9 lines
Quoted 5 lines

So I guess we need a "#ifdef __KERNEL__" around some of the code in include/linux/personality.h (at least around the define of personality), which then has to go into the glibc kernel header files.

Any comments ?

Why is the user program including <linux/personality.h> in the first place?

It need some personality type defines.

Quoted 4 lines

The right thing to do here is to provide the necessary bits in a glibc header, probably in bits/personality.h or so.

Agree, that is probably the right way to do it.

Quoted 4 lines

--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer

--

_    _ ____  ___   Carsten Langgaard   Mailto:[email protected]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com
#3 lore raw
In reply to Carsten Langgaard
Quoted 11 lines · Carsten Langgaard

The include/linux/personality.h file has changed between the 2.4.3 and the 2.4.18 kernel.
Now there is a define of personality (#define personality(pers) (pers & PER_MASK), but that breaks things for the users, if they include this file.
The user wishes to call the glibc personality function (which do the syscall), and not use the above definition.

So I guess we need a "#ifdef __KERNEL__" around some of the code in include/linux/personality.h (at least around the define of personality), which then has to go into the glibc kernel header files.

The general policy about such problems is to not use kernel include files from user applications directly. Hjl - maybe time for <sys/personality.h>?

Ralf

A message that is not in the archive (sent off-list or not yet received): [email protected]

#5 lore raw

Re: PATCH: Add sys/personality (Re: Personality)

Thanks.
Now that we are at it, what should personality return in case it's called with a value, which isn't defined in the personality.h file.
Should it return -EINVAL ?
I don't think, that is the case at the moment, I believe you can set personality to anything.

/Carsten

Quoted 27 lines · H. J. Lu
Quoted 10 lines · Ralf Baechle
Quoted 8 lines · Carsten Langgaard

The include/linux/personality.h file has changed between the 2.4.3 and the 2.4.18 kernel.
Now there is a define of personality (#define personality(pers) (pers & PER_MASK), but that breaks things for the users, if they include this file.
The user wishes to call the glibc personality function (which do the syscall), and not use the above definition.

Quoted 7 lines
Quoted 3 lines

So I guess we need a "#ifdef __KERNEL__" around some of the code in include/linux/personality.h (at least around the define of personality), which then has to go into the glibc kernel header files.

The general policy about such problems is to not use kernel include files from user applications directly. Hjl - maybe time for <sys/personality.h>?

Here is a patch.

H.J.

------------------------------------------------------------------------

glibc-personality.patchName: glibc-personality.patch
Type: Plain Text (text/plain)

#6 lore raw

Re: PATCH: Add sys/personality (Re: Personality)

Quoted 7 lines · Carsten Langgaard

Thanks.
Now that we are at it, what should personality return in case it's called with a value, which isn't defined in the personality.h file.
Should it return -EINVAL ?
I don't think, that is the case at the moment, I believe you can set personality to anything.

Like this?

H.J.
---

exec_domain.c renamed from exec_domain.c.per +2 -1
@@ -223,7 +223,8 @@ sys_personality(u_long personality)
 
 	if (personality != 0xffffffff) {
 		set_personality(personality);
-		if (current->personality != personality)
+		if (personality < current->exec_domain->pers_low
+		    || personality > current->exec_domain->pers_high)
 			return -EINVAL;
 	}
 
#7 lore raw

Re: PATCH: Add sys/personality (Re: Personality)

Quoted 11 lines · H. J. Lu
Quoted 7 lines · Carsten Langgaard

Thanks.
Now that we are at it, what should personality return in case it's called with a value, which isn't defined in the personality.h file.
Should it return -EINVAL ?
I don't think, that is the case at the moment, I believe you can set personality to anything.

Like this?

No, I don't think the patch is correct.
I don't know how this actually should work, maybe someone who do know can help out here.
But it look like the idea is, that we have a default execution domain (linux), which have pers_low = 0 (PER_LINUX) and pers_high = 0.
If one want other execution domains, one much call the register_exec_domain to register the execution domain and personality.
So if personality is call with a value that isn't register, it then accept the personality and sets the execution domain to the default settings (which is linux). So the question is should personality, return -EINVAL, if it got a personality value which hasn't been registered or should it accept the personality, but set the execution domain to the default setting ?
If the later is true, should it also accept values outside the values defined in the personality.h file ?

So what should the following user calls return, if not registered in the kernel?

personality(PER_BSD):
personality(0x47):

Could someone with a better understand than I, please comment this.

Quoted 6 lines

H.J.
---

exec_domain.c Tue Jul 16 19:06:13 2002 sys_personality(u_long personality) · line 230

Quoted 9 lines
exec_domain.c Tue Jul 16 19:06:13 2002 renamed from exec_domain.c.per Mon Jun 10 10:05:27 2002 +2 -1
@@ -223,7 +223,8 @@ sys_personality(u_long personality)
 
        if (personality != 0xffffffff) {
                set_personality(personality);
-               if (current->personality != personality)
+               if (personality < current->exec_domain->pers_low
+                   || personality > current->exec_domain->pers_high)
                        return -EINVAL;
        }
 

--

_    _ ____  ___   Carsten Langgaard   Mailto:[email protected]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com