Suspicious shifting of sempid in try_atomic_semop()

• Next message: Hanna Linder: "lockmeter results comparing 2.4.17, 2.5.3, and 2.5.5"
• Previous message: Andreas Happe: "problems with new input api"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

In ipc/sem.c:try_atomic_semop() there is the following code:

        for (sop = sops; sop < sops + nsops; sop++) {
                ...
                curr->sempid = (curr->sempid << 16) | pid;
                ....
        }

it's undone in the error case:

        while (sop >= sops) {
                ...
                curr->sempid >>= 16;
                ...
        }

the problem is that in some cases we seem to end up with a sempid
of zero which leads to wrong returns of semctl(..., GETPID, ...)
like in

        http://www.freestandards.org/lsb/test/results/index.php?testcaseid=732

Is there a specific reason we use this shift method I have missed?

        Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

• Next message: Hanna Linder: "lockmeter results comparing 2.4.17, 2.5.3, and 2.5.5"
• Previous message: Andreas Happe: "problems with new input api"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:38 EST