Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Odd issue with pod2man when building on Fedora build
server (Julien ?LIE)
2. Re: Odd issue with pod2man when building on Fedora build
server (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 May 2013 19:50:12 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Cc: Jochen Schmitt <[email protected]>
Subject: Re: Odd issue with pod2man when building on Fedora build
server
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> --- inn-2.5.2/storage/cnfs/cnfs.h.posix 2010-03-24 21:10:36.000000000
>> +0100
>> +++ inn-2.5.2/storage/cnfs/cnfs.h 2010-06-28 17:33:11.106804964 +0200
>> @@ -18,4 +18,12 @@ void cnfs_printfiles(FILE *file, TOKEN t
>> char *cnfs_explaintoken(const TOKEN token);
>> void cnfs_shutdown(void);
>>
>> +/* Patch for POSIX */
>> +
>> +#ifndef MADV_SEQUENTAL
>> + #ifdef POSIX_MADV_SEQENTIAL
>> + #define MADV_SEQUITIAL POSIX_MADV_SEQUENTIAL
>> + #endif
>> +#endif
>> +
>> #endif
>
>> => I will have a look at this one. Is there a specific architecture
>> that needs this definition?
>
> This change is only correct if the calls to madvise are also being changed
> to posix_madvise.
So in fact if include/portable/mmap.h uses posix_madvise, if available.
Which means changing:
#if HAVE_MADVISE
# define madvise(p, l, o) madvise((void *)(p), (l), (o))
#else
# define madvise(p, l, o) /* empty */
#endif
to:
#if HAVE_MADVISE
# ifndef MADV_SEQUENTIAL
# ifdef POSIX_MADV_SEQUENTIAL
# define madvise(p, l, o) posix_madvise((void *)(p), (l), (o))
# else
# define madvise(p, l, o) madvise((void *)(p), (l), (o))
# endif
# else
# define madvise(p, l, o) madvise((void *)(p), (l), (o))
# endif
#else
# define madvise(p, l, o) /* empty */
#endif
or something else that does not depend on MADV_SEQUENTIAL?
Maybe it is wisest not changing anything about that and going on with
the current code.
> I'm not sure why one would do that, though. I suppose
> we could do that more generally if posix_madvise is now more portable than
> madvise or should be used by preference for portability, but that doesn't
> seem like a change specific to a particular distribution.
Besides, the patch for Fedora does not currently work because of typos
in the names: MADV_SEQUENTAL, POSIX_MADV_SEQENTIAL, MADV_SEQUITIAL.
>> --- inn-2.5.1/storage/buffindexed/ovmethod.mk.shared 2009-12-01
>> 16:50:37.174811272 +0100
>> +++ inn-2.5.1/storage/buffindexed/ovmethod.mk 2009-12-01
>> 16:53:24.914809560 +0100
>> @@ -1,8 +1,8 @@
>> # This rule requires a compiler that supports -o with -c. Since it's
>> normally
>> # used by developers, that should be acceptable.
>> -buffindexed/buffindexed_d.o: buffindexed/buffindexed.c
>> - $(CC) $(CFLAGS) -DBUFF_DEBUG -c -o $@ buffindexed/buffindexed.c
>> +buffindexed/buffindexed_d.$(EXTOBJ): buffindexed/buffindexed.c
>> + $(LIBCC) $(CFLAGS) -DBUFF_DEBUG -c -o $@ buffindexed/buffindexed.c
>
>> => Do you have a specific need for shared libraries?
>
> This is probably a correct change regardless, though.
Would it be useful to have it in upstream?
> I suspect this is because INN is setuid. However, I don't think there's
> any reason not to build all of INN with -fPIE -pie if that's what you want
> (and likewise with other hardening flags), so I would just put that into
> CFLAGS during configure time.
Isn't there a risk that building with '-fPIE -pie' introduces
instability at runtime? I read at
<https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags>
that some code does not function properly when PIE is used. Probably
code that is position-dependant, but how can we be sure that no part of
INN uses that?
--
Julien ?LIE
? Et maintenant nous sommes roul?s. ? (Ast?rix)
------------------------------
Message: 2
Date: Mon, 27 May 2013 11:49:29 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Odd issue with pod2man when building on Fedora build
server
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> So in fact if include/portable/mmap.h uses posix_madvise, if available.
> Which means changing:
> #if HAVE_MADVISE
> # define madvise(p, l, o) madvise((void *)(p), (l), (o))
> #else
> # define madvise(p, l, o) /* empty */
> #endif
> to:
> #if HAVE_MADVISE
> # ifndef MADV_SEQUENTIAL
> # ifdef POSIX_MADV_SEQUENTIAL
> # define madvise(p, l, o) posix_madvise((void *)(p), (l), (o))
> # else
> # define madvise(p, l, o) madvise((void *)(p), (l), (o))
> # endif
> # else
> # define madvise(p, l, o) madvise((void *)(p), (l), (o))
> # endif
> #else
> # define madvise(p, l, o) /* empty */
> #endif
> or something else that does not depend on MADV_SEQUENTIAL?
> Maybe it is wisest not changing anything about that and going on with the
> current code.
It doesn't seem horribly beneficial to try to change, although I will note
that the posix_madvise API is supposed to be more portable in the long run
and I think our usage fits entirely within that API. If we were to make
this change, though, we should change all the calls in INN to be
posix_madvise and use the POSIX_* constants, and then use portable/mmap.h
to rewrite those to madvise and the MADVISE_* constants on platforms
without the POSIX interface (following the normal INN coding convention of
using the most standard interface by default and then fixing it up behind
the scenes).
>> I'm not sure why one would do that, though. I suppose we could do that
>> more generally if posix_madvise is now more portable than madvise or
>> should be used by preference for portability, but that doesn't seem
>> like a change specific to a particular distribution.
> Besides, the patch for Fedora does not currently work because of typos in
> the names: MADV_SEQUENTAL, POSIX_MADV_SEQENTIAL, MADV_SEQUITIAL.
Ah, I missed that. So clearly the patch wasn't actually needed. There's
a lot of other things to work on, so I'm dubious whether it's worth doing
the conversion mentioned above unless someone has problems.
>>> --- inn-2.5.1/storage/buffindexed/ovmethod.mk.shared 2009-12-01
>>> 16:50:37.174811272 +0100
>>> +++ inn-2.5.1/storage/buffindexed/ovmethod.mk 2009-12-01
>>> 16:53:24.914809560 +0100
>>> @@ -1,8 +1,8 @@
>>> # This rule requires a compiler that supports -o with -c. Since it's
>>> normally
>>> # used by developers, that should be acceptable.
>>> -buffindexed/buffindexed_d.o: buffindexed/buffindexed.c
>>> - $(CC) $(CFLAGS) -DBUFF_DEBUG -c -o $@ buffindexed/buffindexed.c
>>> +buffindexed/buffindexed_d.$(EXTOBJ): buffindexed/buffindexed.c
>>> + $(LIBCC) $(CFLAGS) -DBUFF_DEBUG -c -o $@ buffindexed/buffindexed.c
>>
>>> => Do you have a specific need for shared libraries?
>>
>> This is probably a correct change regardless, though.
> Would it be useful to have it in upstream?
Yes. Basically, there's no reason not to build the debugging version so
that it can be included in a shared library if desired.
>> I suspect this is because INN is setuid. However, I don't think
>> there's any reason not to build all of INN with -fPIE -pie if that's
>> what you want (and likewise with other hardening flags), so I would
>> just put that into CFLAGS during configure time.
> Isn't there a risk that building with '-fPIE -pie' introduces
> instability at runtime? I read at
> <https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags>
> that some code does not function properly when PIE is used. Probably
> code that is position-dependant, but how can we be sure that no part of
> INN uses that?
My experience is that you'll know if this happens, since the binary will
exit immediately with a bus error when run. I build all my packages for
Debian with PIE by default now, and have only run into one package (GNU
Backgammon) that didn't work, and I suspect that's because it has some
assembly for speeding up some parts of the game engine. If you're writing
straight C and not doing anything exciting, PIE really should work.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 51, Issue 7
******************************************
