headers
Kyle McMartin | 1 Jun 05:07

Re: [PATCH] Introduce O_CLOEXEC (take >2)

On Fri, Jun 01, 2007 at 11:38:40AM +1000, Stephen Rothwell wrote:
> This also breaks Alpha (which uses 02000000 for O_DIRECT) and parisc
> (which uses 02000000 for O_RSYNC).  So you ether need to choose a
> different value or define O_CLOEXEC for those two architectures.
> 

That's easy enough to fix...

Signed-off-by: Kyle McMartin <kyle <at> parisc-linux.org>

diff --git a/include/asm-parisc/fcntl.h b/include/asm-parisc/fcntl.h
index 317851f..4ca0fb0 100644
--- a/include/asm-parisc/fcntl.h
+++ b/include/asm-parisc/fcntl.h
@@ -14,6 +14,7 @@
 #define O_DSYNC		01000000 /* HPUX only */
 #define O_RSYNC		02000000 /* HPUX only */
 #define O_NOATIME	04000000
+#define O_CLOEXEC	08000000 /* set close_on_exec */

 #define O_DIRECTORY	00010000 /* must be a directory */
 #define O_NOFOLLOW	00000200 /* don't follow links */
Permalink | Reply | 0 comments |
headers
Sébastien Bernard | 1 Jun 08:19
Gravatar

-pie is broken on hppa

Hi,
I discovered that the breakage of portmap on hppa is related to the
-pie linkage.
Every program linked with the -pie option segfaults at start.
Unfortunately, portmap is unconditionnaly built with this option.
I suspect nscd is in the same case.

How can I go further in investigation ?
I would like to identify the responsible component between the toolchain 
and the glibc.

Any hint is welcome.
Permalink | Reply | 0 comments |
headers
John David Anglin | 1 Jun 15:05
Picon

Re: -pie is broken on hppa

> Hi,
> I discovered that the breakage of portmap on hppa is related to the
> -pie linkage.
> Every program linked with the -pie option segfaults at start.
> Unfortunately, portmap is unconditionnaly built with this option.
> I suspect nscd is in the same case.

This problem was fixed sometime ago.  I don't see it with libc6
2.3.6.ds1-13.  Also, nscd doesn't segfault on my system.  Make sure
the libc6 and binutils packages on your system are up to date.

If they are up to date and you still have the problem, provide testcase
and details on libc6, gcc and binutils versions.

The problem was in crt1.o and related to the handling of R_PARISC_PLABEL21L
and R_PARISC_PLABEL14R relocations.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
Byron Stanoszek | 1 Jun 21:17
Favicon

Re: [PATCH] Introduce O_CLOEXEC (take >2)

On Thu, 31 May 2007, Kyle McMartin wrote:

> On Fri, Jun 01, 2007 at 11:38:40AM +1000, Stephen Rothwell wrote:
>> This also breaks Alpha (which uses 02000000 for O_DIRECT) and parisc
>> (which uses 02000000 for O_RSYNC).  So you ether need to choose a
>> different value or define O_CLOEXEC for those two architectures.
>>
>
> That's easy enough to fix...
>
> Signed-off-by: Kyle McMartin <kyle <at> parisc-linux.org>
>
> diff --git a/include/asm-parisc/fcntl.h b/include/asm-parisc/fcntl.h
> index 317851f..4ca0fb0 100644
> --- a/include/asm-parisc/fcntl.h
> +++ b/include/asm-parisc/fcntl.h
> @@ -14,6 +14,7 @@
> #define O_DSYNC		01000000 /* HPUX only */
> #define O_RSYNC		02000000 /* HPUX only */
> #define O_NOATIME	04000000
> +#define O_CLOEXEC	08000000 /* set close_on_exec */
>
> #define O_DIRECTORY	00010000 /* must be a directory */
> #define O_NOFOLLOW	00000200 /* don't follow links */

These are octal values, so you really want to use 010000000 instead of
08000000. :-)

While looking at that file further, I noticed these two flags share the same
value. I don't know DMAPI/XDSM, but could they potentially conflict?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyle McMartin | 2 Jun 00:55

Re: [PATCH] Introduce O_CLOEXEC (take >2)

On Fri, Jun 01, 2007 at 03:17:03PM -0400, Byron Stanoszek wrote:
> These are octal values, so you really want to use 010000000 instead of
> 08000000. :-)
> 

Wow. I am totally a dumbass, I saw a 'x' there. Sigh.

diff --git a/include/asm-parisc/fcntl.h b/include/asm-parisc/fcntl.h
index 317851f..7089507 100644
--- a/include/asm-parisc/fcntl.h
+++ b/include/asm-parisc/fcntl.h
@@ -14,6 +14,7 @@
 #define O_DSYNC		01000000 /* HPUX only */
 #define O_RSYNC		02000000 /* HPUX only */
 #define O_NOATIME	04000000
+#define O_CLOEXEC	010000000	/* set close_on_exec */

 #define O_DIRECTORY	00010000 /* must be a directory */
 #define O_NOFOLLOW	00000200 /* don't follow links */
Permalink | Reply | 0 comments |
headers
John David Anglin | 2 Jun 03:19
Picon

Re: -pie is broken on hppa

> I discovered that the breakage of portmap on hppa is related to the
> -pie linkage.
> Every program linked with the -pie option segfaults at start.
> Unfortunately, portmap is unconditionnaly built with this option.

I advise not updating to libc6 2.5-9.  More than pie apps seem
affected.  For example, svn is broken on my system.  _start in
*crt1.o needs fixing.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
Matthew Wilcox | 2 Jun 03:55

Re: -pie is broken on hppa

On Fri, Jun 01, 2007 at 09:19:20PM -0400, John David Anglin wrote:
> > I discovered that the breakage of portmap on hppa is related to the
> > -pie linkage.
> > Every program linked with the -pie option segfaults at start.
> > Unfortunately, portmap is unconditionnaly built with this option.
> 
> I advise not updating to libc6 2.5-9.  More than pie apps seem
> affected.  For example, svn is broken on my system.  _start in
> *crt1.o needs fixing.

This is a matter of some urgency -- I heard glibc 2.5 moved into Debian
Testing today.
Permalink | Reply | 0 comments |
headers
John David Anglin | 2 Jun 04:03
Picon

Re: -pie is broken on hppa

> > I advise not updating to libc6 2.5-9.  More than pie apps seem
> > affected.  For example, svn is broken on my system.  _start in
> > *crt1.o needs fixing.
> 
> This is a matter of some urgency -- I heard glibc 2.5 moved into Debian
> Testing today.

Yes.  I just did an apt-get update about 30 minutes ago.

This is what I see when I do a gcc_update:
dave <at> mx3210:~/gnu/gcc-4.3/gcc$ contrib/gcc_update
Updating SVN tree
At revision 125275.
svn: Can't read directory '.': Partial results are valid but processing is incomplete
Adjusting file timestamps

Lock files are getting messed up and svn cleanup fails.  A full checkout
does work but that's several hundred megabytes.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
John David Anglin | 3 Jun 18:06
Picon

Re: -pie is broken on hppa

> > > I advise not updating to libc6 2.5-9.  More than pie apps seem
> > > affected.  For example, svn is broken on my system.  _start in
> > > *crt1.o needs fixing.
> > 
> > This is a matter of some urgency -- I heard glibc 2.5 moved into Debian
> > Testing today.
> 
> Yes.  I just did an apt-get update about 30 minutes ago.

As a further update, this system has now crashed three times since
the update.  It was stable prior to the glibc update and had run
several months without needing a reboot.  It was doing gcc builds
almost continuously.

The first two crashes were building gcc and led to file system
corruption.  I tried looking at the log files but there's a gap.
On the console, there's a continuous stream of messages:

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
     PSW: 00001000000001101111111100001111 Not tainted
r00-03  000000ff0806ff0f 000000004036c000 0000000040104edc 00000000c0601048
r04-07  00000000403d79d4 00000000403d89d4 000000000002c258 0000000000000000
r08-11  000000000002a3f4 000000000002a3f4 0000000000000001 0000000000000000
r12-15  000000000002a3f4 0000000000000000 0000000000000001 000000000002c258
r16-19  000000000002a3f4 000000000002a3f4 000000000002a3f4 0000000000000000
r20-23  000000000000012a 000000004029c000 0000000040357594 000000000002c268
r24-27  00000000c0601048 0000000000000058 000000000002c258 0000000040503fc0
r28-31  00000000403daf60 000000007c744170 000000007c744180 00000000403575e3
sr00-03  00000000000eb800 0000000000000000 0000000000000000 00000000000eb800
sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
(Continue reading)

Permalink | Reply | 0 comments |
headers
John David Anglin | 3 Jun 20:28
Picon

Re: -pie is broken on hppa

> On the console, there's a continuous stream of messages:
> 
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>      PSW: 00001000000001101111111100001111 Not tainted
> r00-03  000000ff0806ff0f 000000004036c000 0000000040104edc 00000000c0601048
> r04-07  00000000403d79d4 00000000403d89d4 000000000002c258 0000000000000000
> r08-11  000000000002a3f4 000000000002a3f4 0000000000000001 0000000000000000
> r12-15  000000000002a3f4 0000000000000000 0000000000000001 000000000002c258
> r16-19  000000000002a3f4 000000000002a3f4 000000000002a3f4 0000000000000000
> r20-23  000000000000012a 000000004029c000 0000000040357594 000000000002c268
> r24-27  00000000c0601048 0000000000000058 000000000002c258 0000000040503fc0
> r28-31  00000000403daf60 000000007c744170 000000007c744180 00000000403575e3
> sr00-03  00000000000eb800 0000000000000000 0000000000000000 00000000000eb800
> sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 
> IASQ: 0000000000000000 0000000000000000 IAOQ: 0000000000000000 0000000000000004
>  IIR: 00000000    ISR: 00000000000eb800  IOR: 0000000000000000
>  CPU:        0   CR30: 000000007c744000 CR31: 00000000404c4000
>  ORIG_R28: 0000000040155a7c
>  IAOQ[0]: 0x0
>  IAOQ[1]: 0x4
>  RP(r2): syscall_exit+0x0/0x14

The kernel is 2.6.20-gfb60ab85-dirty.  The above appears to be a
syscall that's not hooked up.   The number appears to be 0x12a (298).

I believe that we aren't allowed to fault on the gateway page.
If we have holes in the syscall table, I think we need a check
for this since the following code will fault if r19 is zero:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane