Re: More better in mount(2)

Re: More better in mount(2)

[Daniel Phillips]

Nathan Scott wrote:
> On Jan 5,  3:26am, Daniel Phillips wrote:
> > ...
> > This filesystem mount option parsing code is completely ad hoc, and uses
> > strtok which is horribly horribly broken.  (Do man strtok and read the
> > 'Bugs' section.)
> >
> > It would be worth thinking about how to do this better.
> 
> hmm ... can't claim I wrote this code, just looked at it.
> are you saying the kernel strtok is horribly broken or just
> the way its being used here?  (and why?)

>From the man page:

BUGS        Never use this function. If you do, note that:  
            This function modifies its first argument.  
            The identity of the delimiting character is lost.  
            This functions cannot be used on constant  strings.  
            The  strtok  () function uses a static buffer while
            parsing, so it's not thread safe. Use  strtok_r  ()
            if this matters to
you.                                                                                                        
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: More better in mount(2)

[Andreas Dilger]

Daniel writes:
> [re strtok for mount option parsing]
> 
> BUGS        Never use this function. If you do, note that:  
>             This function modifies its first argument.  
>             The identity of the delimiting character is lost.  
>             This functions cannot be used on constant  strings.  
>             The  strtok() function uses a static buffer while
>             parsing, so it's not thread safe. Use  strtok_r()
>             if this matters to you.

Luckily, when mount(8) is trying to mount a filesystem, it passes the
mount options into the kernel each time, which does copy_from_user(),
so the fact that strtok() breaks the data is OK.  The only time this
is bad is with Stephen's ext3 rootflags option...

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: xfs mount opts (was: More better in mount(2))

[Nathan Scott]

hi,

On Jan 5,  3:51pm, Daniel Phillips wrote:
> Subject: Re: More better in mount(2)
> Nathan Scott wrote:
> > On Jan 5,  3:26am, Daniel Phillips wrote:
> > > ...
> > > This filesystem mount option parsing code is completely ad hoc, and uses
> > > strtok which is horribly horribly broken.  (Do man strtok and read the
> > > 'Bugs' section.)
> > >
> > > It would be worth thinking about how to do this better.
> > 
> > hmm ... can't claim I wrote this code, just looked at it.
> > are you saying the kernel strtok is horribly broken or just
> > the way its being used here?  (and why?)
> 
> >From the man page:
> ...

yup, I did see that.  I've gone through the code and I can't
see anything wrong with it (tell me if I've missed something).
If the problem is simply that its using strtok, then this must
just be a perceived problem rather than an actual problem (the
data is copied, and noone uses it other than the parsing code,
afaict).

>From a look through how the other filesystems do this, it
seems most use strtok (including ext2).

cheers.

-- 
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/