From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E12EC3858C00; Mon, 26 Sep 2022 12:15:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E12EC3858C00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1664194506; bh=4lpuavWh9UbZ6+8GR1zEfQrzY+GQ3rE/BMvIp3YeLIA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=m16gg0+A3VcMNsyau3aBY0vl+V3US9PlDeM/99k/in+R5e3XUh7dw/XOkBOH30k2c KQjNM9mrp5DTR7YwhY1yjUoYjE0IxyJLxRCzpx4J59zq1VPXW7qPbOTHLKjHAj4e2j iadYV4S5F6Uh6x8gAdifciVj5akj6j4jgzdWnhy8= From: "mjbaars1977 at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/29585] sched_getcpu returns invalid results Date: Mon, 26 Sep 2022 12:15:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.35 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mjbaars1977 at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29585 --- Comment #10 from Mischa Baars --- (In reply to Florian Weimer from comment #9) > (In reply to Mischa Baars from comment #8) > > (In reply to Florian Weimer from comment #7) > > > You cannot call glibc function after creating a bare thread using clo= ne, you > > > need to use direct system calls. The bare thread does not have a prop= er > > > thread control block set up for glibc. > >=20 > > Ok, no problem. I can use syscalls to retrieve the processor the proces= s is > > running on, but shouldn't glibc check for the existence of this thread > > control block and return a -1 when it does not exist instead of a incor= rect > > processor number? >=20 > There is no efficient way to check if the TCB is safe to use from the > current thread. >=20 > > I think that a small note in the manual page about pthreads vs fork / c= lone > > would be in order. For example, if the existence of both pthread_yield = and > > sched_yield makes you think that sched_yield is not specifically intend= ed > > for use with pthreads, then why would sched_getcpu be? >=20 > sched_getcpu is not related to pthreads any more than the rest of glibc. But you just told me that the TCB is not bare thread related, so it must be pthread related. Never mind, I'll just use direct system calls to do the scheduling. --=20 You are receiving this mail because: You are on the CC list for the bug.=