Re: [PATCH] Re: 2.6.x BSD Process Accounting w/High UID

[Tim Schmielau]

[Cc: trimmed]

On Sun, 7 Mar 2004, Arthur Corliss wrote:

> On Sun, 7 Mar 2004, Tim Schmielau wrote:
> 
> > But the current tools are only broken for the few people using high UIDs
> > (and generally on 64 bit archs, but that's a different story).
> 
> This is broken on x86 as well.  I guess I still have to question the logic of
> logging bad data, even if you think the data is infrequent at best.

Seems like I didn't get your point. What is broken on x86 other than high 
UIDs?

> > We shouldn't require people to recompile their userspace tools in the
> > middle of a stable kernel series. (OK, 2.6 has just started, but we don't
> > want to offend people upgrading from 2.4, either.)
> 
> I can understand this argument, and I would certainly agree for things that
> are commonly used.  But given the state of the BSD accounting tools (a package
> that hasn't had a public update since 1998, and which has non-high uid broken
> bits in it as well) I would hazard a guess that the impacted users is going to
> be minimal, at best.

In which way are the BSD accounting tools broken? I'm unfamiliar with 
them, but this might indeed allow us to estimate the user base.

> > How about the patch below? It requires a change to userspace tools if you
> > want to use high uids, but it dosn't break binary compatibility. It even
> > allows userspace to check whether high UIDs are supported, and allows
> > future incompatible format changes to be detected.
> 
> I like it, and the addition of ac_version is a great idea.  I might alter the
> comment about 64-bit machines in acct.c, though.  32-bit UIDs affects 32-bit
> machines as well.

The chunk with the 64-bit comment actually is independent of the high UID
problem. It's there to prevent logging of wromng data on 64-bit arches, 
and is completely optimized away by the compiler on 32 bit ones.
I could as well separate it into a different patch.

I'll do a new version of the patch anyways, as I missed to change another 
comment.

> > Well, they are not totally meaningless since we clip at the maximum
> > representable value instead of wrapping around.
> 
> :-P I don't look at this any different than the byte-clipping we're doing with
> UIDs.  If we're logging data that's wrong, then you can't do accurate
> accounting, period.

Yes, but how often do your users use more that 49 days of cputime?

I'll wait a bit to see whether my other posting generates any feedback.

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