[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