Re: [RFC][PATCH -mm] IPC: fix error checking in all new xxx_lock() functions

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

 



Pierre Peiffer wrote:
In the new implementation of the [sem|shm|msg]_lock[_check]() routines,
we use the return value of ipc_lock() in container_of() without any check.
But ipc_lock may return a errcode. The use of this errcode in container_of()
may alter this errcode, and we don't want this.

Today, there is no problem because the member used in these container_of()
is the first member of its container (offset == 0), the errcode isn't changed
then. But in the general case, we can't count on this assumption and this
may lead later to a real bug if we don't correct this.

In fact, the proposed solution is simple and correct. But it has the drawback
of adding one more check ('if' statement) in the chain: we do a first check in
ipc_lock(), now in xxx_lock() and then one later in the caller of xxx_lock()
That's why I send this as RFC, may be another approach could be considered.


This is really what disturbs me this solution: the same check will be done several times. But is true that we have to do something. So why not simply adding a BIG COMMENT before the msg_queue, sem_array and shmid_ds stating that the kern_ipc_perm should stay at the beinnign of the structure?

Will try to look for another solution.

Regards,
Nadia

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux