On Thu, 18 May 2000, Alan Cox wrote:
> > > Locking on getcwd
> > Details, please? I'm currently dealing with that area, so if you give some
> > details I could check this one.
>
> current->fs->pwd can change under the getcwd call. We take a copy of pwd
> but nothing I can see stops pwd being deleted as we use it. We even sleep
> and do memory allocations in the loop that might cause dcache cleaning.
>
> What stops this occuring if thread1/2 share current->fs
Ah, that one... Fixed in the current set of patches - I hope that will go
in -pre9-3. There was a bunch of such animals; fix being dget()+mntget(),
indeed. Later we will need a spinlock for atomic *get/assignment to
(root,rootmnt) and (pwd,pwdmnt), but that will become really needed when
we'll thread chdir()/chroot().
I'm mostly done with dget()/dput()/d_alloc(). d_lookup() and d_move()
require interesting precautions, so they will go in the second batch
(basically, we need to analyse the places where we access foo->d_parent
and figure out which may happen when d_move(foo,bar) or d_move(bar,foo)
is executed on other CPU - moderately nasty, but for now I'ld rather get
the first three functions SMP-safe).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:16 EST