[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: clone flags

On Thu, 2007-07-19 at 14:45 -0400, John D. Ramsdell wrote: 
> Eric Paris <eparis redhat com> writes:
> > Actually it's a problem with mapping things.  The flags are in a0.
> Eric, you seem to have nailed this issue.

> I played around with tracing the clone system call, and found
> something else since my last message.  I traced a program that creates
> threads within a single address space with clone, and that call puts
> the clone flags into a2.  The auparse library interprets these flags
> as one would expect.

Actually, not quite.  Its still the same mapping problem.  auparse is
busted and the flags are always in a0 for the audit log.  auparse is
actually giving you total and complete crap output.  Notice in auparse
you got a long list of flags.


And the strace output below only showed a short list of flags.  Also
note that one is NOT a sub/super set of the other.  CLONE_DETACHED above
and CLONE_FILES below?


Anyway I took the strace flags and worked it out:

#define CLONE_VM                 0x00000100
#define CLONE_FS                 0x00000200
#define CLONE_FILES              0x00000400
#define CLONE_SIGHAND            0x00000800
#define CLONE_THREAD             0x00010000
#define CLONE_SYSVSEM            0x00040000
#define CLONE_SETTLS             0x00080000
#define CLONE_PARENT_SETTID      0x00100000
#define CLONE_CHILD_CLEARTID     0x00200000


Low and behold the audit a0 is       3d0f00

Looks like auparse was wrongly trying to convert the pointer for
parent_tidptr=0xb7f7fbd8 (notice we had CLONE_PARENT_SETTID set) into
clone flags and that list of flags was the best it could do.  

So I'd say change all your stuff to look only at a0 for clone and
someone (sgrubb already knows) needs to fix auparse to look for the
flags in a0 not in a2.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]