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

From: Albert Cahalan
Date: Tue Mar 09 2004 - 20:56:47 EST

> We might, however, put the magic into the implicit padding
> of ac_flag (ugly, since this would require an arch dependant
> definition of stuct acct), or put it into the uppermost
> three bits of ac_flag itself

First of all, none of this matters much if the format
is given a sysctl. The old format is default for now,
and the new one is default (only?) in a couple years.
Sun appears to have done something like this.

When fixing it, note that a 5-bit binary exponent
with denormals would beat the current float format.

Regarding the existing struct though...

Let's take a close look at this. I think there are 2 bytes
of padding on all Linux ports, and another 2 available
on everything except maybe m68k and/or arm. (that is, ports
that will put a u32 on any u16 boundry) Here is the current
struct, compactly formatted with 64-bit blocking:

struct linux_acct {
char ac_flag; // Flags
// 1 pad byte
__u16 ac_uid; // Real User ID
__u16 ac_gid; // Real Group ID
__u16 ac_tty; // Control Terminal

__u32 ac_btime; // Process Creation Time
comp_t ac_utime; // User Time
comp_t ac_stime; // System Time

comp_t ac_etime; // Elapsed Time
comp_t ac_mem; // Average Memory Usage
comp_t ac_io; // Chars Transferred
comp_t ac_rw; // Blocks Read or Written

comp_t ac_minflt; // Minor Pagefaults
comp_t ac_majflt; // Major Pagefaults
comp_t ac_swaps; // Number of Swaps
// 2 pad bytes (except m68k or arm maybe?)

__u32 ac_exitcode; // Exitcode
// hppa might pad this
char ac_comm[17]; // Command Name
// hppa might pad this
char ac_pad[10]; // Padding Bytes
// 1 pad byte (maybe 6 for hppa)


So there you go. You have a pad byte after ac_flag
at a known location, and a pad byte after ac_pad that
might move a bit due to mis-alignments above it.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at