From owner-p4-projects@FreeBSD.ORG Mon Aug 27 21:24:13 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 1DDD016A46C; Mon, 27 Aug 2007 21:24:13 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA8F616A41B; Mon, 27 Aug 2007 21:24:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 810C413C4A3; Mon, 27 Aug 2007 21:24:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l7RLNwq6085539; Mon, 27 Aug 2007 17:23:58 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: perforce@FreeBSD.org Date: Mon, 27 Aug 2007 17:23:54 -0400 User-Agent: KMail/1.6.2 References: <200708021130.l72BUHrY077198@repoman.freebsd.org> <200708271416.08455.jkim@FreeBSD.org> <1188241044.56896.46.camel@opus.cse.buffalo.edu> In-Reply-To: <1188241044.56896.46.camel@opus.cse.buffalo.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200708271723.56871.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4078/Mon Aug 27 16:37:54 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Kostik Belousov , Roman Divacky , Ken Smith , re@FreeBSD.org Subject: Re: PERFORCE change 124529 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 21:24:13 -0000 On Monday 27 August 2007 02:57 pm, Ken Smith wrote: > On Mon, 2007-08-27 at 14:16 -0400, Jung-uk Kim wrote: > > sched_{get,set}affinity() are very misleading syscalls. Userland > > (glibc) and kernel have different definitions and Roman's patch > > implemented linux 2.6 kernel behaviour, AFAIK. Glibc wraps all > > differences between kernel versions. See the following link: > > > > http://jeff.squyres.com/journal/archives/2005/10/linux_processor. > >html > > Wow, "misleading" may be the understatement of the year... :-( > > My only interest is not committing something that a user-level > Linux binary running on FreeBSD will be confused by if it were to > go through our compat layers. To that end I'm going to be a bit of > a jerk on this and I apologize for that. As far as I can tell you > are exactly right that this syscall in Linux is extremely > confusing. What I ask is someone to point me at something that > suggests what the submitted patch implements was at least in use in > *some* Linux kernel, preferrably one that saw semi-widespread use. > :-) > > I did follow up on this a bit myself by downloading what appears to > be the bleeding edge of the Linux kernel which is probably not the > right thing to do. Its implementation in that kernel > (linux-2.6.22) is this: > > long sched_getaffinity(pid_t pid, cpumask_t *mask) > { > struct task_struct *p; > int retval; > > mutex_lock(&sched_hotcpu_mutex); > read_lock(&tasklist_lock); > > retval = -ESRCH; > p = find_process_by_pid(pid); > if (!p) > goto out_unlock; > > retval = security_task_getscheduler(p); > if (retval) > goto out_unlock; > > cpus_and(*mask, p->cpus_allowed, cpu_online_map); > > out_unlock: > read_unlock(&tasklist_lock); > mutex_unlock(&sched_hotcpu_mutex); > if (retval) > return retval; > > return 0; > } > > The security_task_getscheduler() call seems to be a no-op at the > moment (a work in progress - as far as I can tell there is only one > task_getscheduler() function implemented at the moment and it > always returns 0). > > As the reference you provided said there does seem to be the > possibility of "interference" from the glibc code but as far as I > can tell from what I have access to none of the various options > would wind up returning anything other than zero in the case of > success and that is what has me worried. If anyone can point me at > something that shows a case where the size of the mask really winds > up being the return value upon success I'm totally willing to > approve this. > > Sorry for the hassle. Thanks. You missed actual syscall entry point: http://lxr.linux.no/source/kernel/sched.c#L4542 It actually returns sizeof(cpumask_t). ;-) Jung-uk Kim