Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764181AbXKUB0K (ORCPT ); Tue, 20 Nov 2007 20:26:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932356AbXKUBVn (ORCPT ); Tue, 20 Nov 2007 20:21:43 -0500 Received: from idcmail-mo1so.shaw.ca ([24.71.223.10]:6229 "EHLO pd4mo1so.prod.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932434AbXKUBVj (ORCPT ); Tue, 20 Nov 2007 20:21:39 -0500 Date: Tue, 20 Nov 2007 19:21:36 -0600 From: Robert Hancock Subject: Re: 2.6.24-rc3: find complains about /proc/net In-reply-to: To: "Eric W. Biederman" Cc: Ulrich Drepper , Roland McGrath , Guillaume Chazarain , Ingo Molnar , Pavel Emelyanov , "Rafael J. Wysocki" , Pavel Machek , kernel list , netdev Message-id: <47438820.5010300@shaw.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1914 Lines: 44 Eric W. Biederman wrote: > Could you elaborate a bit on how the semantics of returning the > wrong information are more useful? > > In particular if a thread does the logical equivalent of: > grep Pid: /proc/self/status. It always get the tgid despite > having a different process id. The POSIX-defined userspace concept of a PID requires that all threads appear to have the same PID. This is something that Linux didn't comply with under the old LinuxThreads implementation and was finally fixed with NPTL. This isn't a POSIX-defined interface, but I assume it's trying to be consistent with getpid(), etc. > How can that possibly be useful or correct? > > From the kernel side I really think the current semantics of /proc/self > in the context of threads is a bug and confusing. All of the kernel > developers first reaction when this was pointed out was that this > is a regression. > > If it is truly useful to user space we can preserve this API design > bug forever. I just want to make certain we are not being bug > compatible without a good reason. > > Currently we have several kernel side bugs with threaded > programs because /proc/self does not do the intuitive thing. Unless > something has changed recently selinux will cause accesses by a > non-leader thread to fail when accessing files through /proc/self. > > So far the more I look at the current /proc/self behavior the > more I am convinced it is broken, and useless. Please help me see > where it is useful, so we can justify keeping it. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ - 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/