Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753667AbcCYP6t (ORCPT ); Fri, 25 Mar 2016 11:58:49 -0400 Received: from arcturus.aphlor.org ([188.246.204.175]:46654 "EHLO arcturus.aphlor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753295AbcCYP6s (ORCPT ); Fri, 25 Mar 2016 11:58:48 -0400 Date: Fri, 25 Mar 2016 11:58:44 -0400 From: Dave Jones To: Andy Lutomirski Cc: Andrew Lutomirski , X86 ML , Linux Kernel Subject: Re: x32 processes, with CONFIG_X86_X32 not set Message-ID: <20160325155844.GB13116@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Andy Lutomirski , Andrew Lutomirski , X86 ML , Linux Kernel References: <20160325154835.GA13116@codemonkey.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "arcturus.aphlor.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Fri, Mar 25, 2016 at 08:51:39AM -0700, Andy Lutomirski wrote: > On Fri, Mar 25, 2016 at 8:48 AM, Dave Jones wrote: > > I had a trinity process get stuck last overnight. > > The reason for it getting stuck is my bug (I think), but > > there's an odd unrelated thing I noticed while debugging this.. > > > > $ strace -p 20966 > > strace: Process 20966 attached > > strace: [ Process PID=20966 runs in x32 mode. ] > > > > So I don't use that new-fangled x32 stuff. > > I don't even have CONFIG_X86_X32 compiled in. > > > > Is this strace getting confused, or did we somehow screw > > up the syscall entry code ? > > > > Dave > > > > I think you're just seeing an oddity of how x32 works. Unlike > "compat", x32-ness of the current syscall isn't a special magic state > variable; it's just but 31 in the syscall nr. So trying to do an x32 > syscall on a non-x32 syscall should still show bit 31 set to ptracers, > and the strace probably decodes this as being in x32 mode. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1444 Lines: 35 On Fri, Mar 25, 2016 at 08:51:39AM -0700, Andy Lutomirski wrote: > On Fri, Mar 25, 2016 at 8:48 AM, Dave Jones wrote: > > I had a trinity process get stuck last overnight. > > The reason for it getting stuck is my bug (I think), but > > there's an odd unrelated thing I noticed while debugging this.. > > > > $ strace -p 20966 > > strace: Process 20966 attached > > strace: [ Process PID=20966 runs in x32 mode. ] > > > > So I don't use that new-fangled x32 stuff. > > I don't even have CONFIG_X86_X32 compiled in. > > > > Is this strace getting confused, or did we somehow screw > > up the syscall entry code ? > > > > Dave > > > > I think you're just seeing an oddity of how x32 works. Unlike > "compat", x32-ness of the current syscall isn't a special magic state > variable; it's just but 31 in the syscall nr. So trying to do an x32 > syscall on a non-x32 syscall should still show bit 31 set to ptracers, > and the strace probably decodes this as being in x32 mode. But this is an x86-64 binary, and it's the main process, not one of the fuzzing child processes. It shouldn't be even trying to do anything weird. It creates a bunch of fd's, then enters a loop forking/reaping children. (In this case it actually hung while creating the fd's) Trinity doesn't actually have any knowledge of x32 at all, mostly because it's been irrelevant to me (and most other people). Dave