[OpenAFS-devel] Re: [OpenAFS] 2.6 kernel support anytime soon? Workarounds?

Jeffrey Hutzelman jhutz@cmu.edu
Tue, 11 May 2004 11:27:10 -0400


On Monday, May 10, 2004 22:11:03 -0400 Garrett Wollman 
<wollman@khavrinen.lcs.mit.edu> wrote:

> <<On Mon, 10 May 2004 19:02:26 -0400, Jeffrey Hutzelman <jhutz@cmu.edu>
> said:
>
>> But note that it's not exact.  Your proposed afs_assign_process_label()
>> doesn't actually provide a means to control what label is assigned.
>
> Intentionally -- the AFS code should not preclude a model in which
> PAGs are actually addresses, which gives you a way to guarantee
> uniqueness in an SMP-friendly manner.  Near as I can tell, except for
> the niggling little bits where AFS tries to fit uids and PAGs into the
> same name space, the kernel code just uses the PAG numbers as nonces,
> so it matters little if the numbers actually represent pointers.

That's correct.


> When
> I was last looking at the code, about six months ago, I thought that
> the uid versus PAG confusion was fixable fairly easily: just lazily
> create a pseudo-PAG for every uid that touches AFS.

Yes, that would work.

> If the system
> provides the right sort of hooks (FreeBSD does not, at the moment) you
> can even GC them easily.

I don't think that's a big deal.  There's not currently any benefit to 
GC'ing PAG's, since they're just numbers in a namespace we don't expect 
ever to reuse.  The tokens themselves will be GC'd once they are expired 
for some period of time, so the memory use is not an issue.

>
>> And, afs_get_label() expects to operate on a process, where what we
>> currently want is a struct ucred or whatever passes for it.  But
>> then, that's platform-dependent code anyway, so it's not that big a
>> deal.
>
> That was a mistake on my part, since there are a number of places in
> the filesystem code where all you have is a credential and not a
> process anyway.

Ah.  Yes, the main example of such a place is the NFS translator code, 
where we have the credential of the NFS client, but the current process 
(some NFS worker thread) is not relevant.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA