"Catalin Marinas" <[EMAIL PROTECTED]> writes: > On 08/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: >> "Catalin Marinas" <[EMAIL PROTECTED]> writes: > > I think it's only the pid_chain and rcu member that could be placed in > a list and kmemleak scans the memory for these two offsets as well. > I'll check those lists anyway but I doubt it's a more fundamental > problem with how kmemleak handles struct pid as I should've probably > got more reports.
Right. I was pointing out the possibilities but because we do some tricky things. Mostly I was wondering about the hlist for the list of tasks. Now if a task is on that list we should have a struct pid_link pointing at our struct pid, so it shouldn't fool kmemleak but I'm still a little curious if all of those hlist_heads are NULL pointers. >> In most any other layer we cache pids indefinitely and a situation >> where we have a pointer to a struct pid with a ref count of 1 long >> after the process goes away is expected. > > Yes, indeed, but what kmemleak reports is that the pid structure > wasn't freed yet and there is no way to determine its pointer directly > or via container_of on members (by scanning the memory), hence it is > considered a leak. Yes that sounds like a leak. >> I don't understand your situation enough to guess what is going wrong >> yet. Hopefully I have given you enough information to get started. > > Yes, many thanks. I'll dig further and let you know. Thanks.... Eric - 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/
