apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Date Sat, 25 Jan 2014 00:42:00 GMT
Those who use ftok(, 1) externally like httpd will face the bug soon or
later too (unless they use the same filenames each time).
I think some (at least) will like this to be fixed, so the current code is
fine for me.


On Sat, Jan 25, 2014 at 12:50 AM, Jim Jagielski <jim@jagunet.com> wrote:

> I think it could be debated on whether or not ftok(...,1) is
> part of the ABI or not. The more I think about it,
> it's not. But the fact that both slotmem and mod_fcgid, which
> are *our* projects, "use" that knowledge, makes me wonder
> who else makes that assumption.
>
> What do others think...? It would be easy to make our
> generation of a shmkey more robust by "breaking" that
> agreement, and to handle slotmem we add apr_shm_perms()
> to APR 1.5.1 and have httpd 2.4.8 require 1.5.1 or later...
>
> Or we just consider it all a limitation of SysV based
> shm and just keep things as is.
>
> On Jan 24, 2014, at 6:40 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> > Why couldn't APR document on using ftok(filename,
> filename[strlen(filename)-1]) for released versions, and do the right thing
> in trunk?
> > Is ftok(filename, 1) part of the ABI since the change would break
> existing consumers?
> > I can't see any solution if that's the case.
> >
> >
> > On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <jim@jagunet.com> wrote:
> > It's easy to generate something unique... the problem is that
> > external APR users (such as mod_fcgid, etc) occasionally need
> > to adjust the segment resources, and thus call ftok(...). Unless
> > both APR *and* the users use the same proj_id, then they won't
> > get the right segment (if at all).
> >
> > I just couldn't think of an easy way to get around that
> > except for having 1.5.1 break ABI.
> >
> > What we need is apr_shm_ftok() that replaces ftok, both
> > internally to unix/shmem.c as well as to users. We still
> > would need to worry about versioning there as well since
> > APR consumers would need to be aware if that function
> > exists or not.
> >
> > On Jan 24, 2014, at 6:00 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >
> > > According to the man (
> http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html),
> ftok() uses only the low-order 8-bits of the id.
> > > Maybe the APR could use the last char of the filename instead, so that
> the users knows and can choose it.
> > > For APR's internal/choosen filenames (if any), this byte could be
> generated randomly.
> > >
> > >
> > > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <jim@jagunet.com>
> wrote:
> > > On httpd there was a discussion regarding versioning, and
> > > this got me thinking...
> > >
> > > Included in the APR 1.5.1 changes is an internal change
> > > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > > calculates the key (via ftok())...
> > >
> > > The problem (see the Bugz report) was that using the constant
> > > 1 would cause collisions, so I adjusted it to use a hash
> > > of the filename. The problem there is that any external
> > > APR users that needed to also determine the key needs to
> > > be aware of that. And from what I can see, there is no
> > > easy way to do that.
> > >
> > > So I will be pulling that from 2.0-dev and 1.5-dev until
> > > we can figure out a better way. Ideas appreciated.
> > >
> >
> >
>
>

Mime
View raw message