From owner-svn-src-head@freebsd.org Sat Feb 4 21:34:21 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE8DACD02F3; Sat, 4 Feb 2017 21:34:21 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98537299; Sat, 4 Feb 2017 21:34:21 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-it0-x243.google.com with SMTP id e137so4802733itc.0; Sat, 04 Feb 2017 13:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NgWGi9AQOO+WCRLgPn8mfmFPopErTFXhJFLJfmCITt8=; b=HGuxgv8vh8u+wXk3WLsgDRPh0CvutijD3F/59ROcqvwXO0nDE+6YrW0tha0DzZ9NsN 1O8rLUa52wp5uVdp8h+RNGUmJgSv52l4lKtYbbpV+7NX6lmoimdwjN5j5T1AsxCTUDXn +I2m7E4pZb+Yt2jsc8j+Jh6b7HyDYR05aK1Z20dqkHIe3PYhArB9Qiy2X3p/f8obB+Vx Ld8i5CH4P3lMT0JrX0taPCQ+OWlIQ/gudcqHK753awquWqKby8LGyaQa6vEdVP+tYO20 dfQkw2h3yJZwIKfWN3XtBVY03AYPHI1w3jgB9KAuBW3GgyoFpZwgyu/ncpjkO1e2+CQV JWVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NgWGi9AQOO+WCRLgPn8mfmFPopErTFXhJFLJfmCITt8=; b=XOl3Sage+W+wRKOkY+AMdk+iS44Tyy2MlzABWhE0/ol2v7fc/JQgVs+sjiZQkt4iRJ ewYa8id3tWVqS18gxXWWi9O8gkR0YBY54BxWhUUnUoki000KMvAb1RqgDPAadAou3Vlp cLkDD9ZOABKvsbEgjT/sbJlZzLO3KPv2jl0hOab5NjWyNxs8hqA7vMyxoyez98UFmsUy 7zWbQV2yv8tBgeWLg8L/M8XEMWfUIKYLsm+p24XRyhlmBtPZEfh3OmVsjX/g+sxoKXr4 /Pp3n9L+N3uWoTrLaN2j7A3D6Vao0LiF7vqTYUjiLrrV11knbsw4ENGn6B5t5iKxfhrJ PFsw== X-Gm-Message-State: AIkVDXIi7o4YPSe212xZx7bcEdEE/bJ5pWFnb9ytdip3Tr0U7HlxpfyJX5FDuDUMAtn8inRwPM34sFQok/psGQ== X-Received: by 10.36.40.198 with SMTP id h189mr2440181ith.114.1486244060930; Sat, 04 Feb 2017 13:34:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.101.194 with HTTP; Sat, 4 Feb 2017 13:34:20 -0800 (PST) In-Reply-To: References: <201702010332.v113WnYf041362@repo.freebsd.org> <20170203231238.0675c289@kan> <8523aaa5-6c30-9f9f-40f0-fdf82cdf1669@pix.net> <6bf86e46-9714-c7e9-8d47-845761e2de24@FreeBSD.org> <8a2f7f7d-14c3-8e75-e060-fc41213ce389@FreeBSD.org> From: Svatopluk Kraus Date: Sat, 4 Feb 2017 22:34:20 +0100 Message-ID: Subject: Re: svn commit: r313037 - in head/sys: amd64/include kern mips/include net powerpc/include sparc64/include To: Jason Harmening Cc: Andreas Tobler , Kurt Lidl , Alexander Kabaev , "Jason A. Harmening" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Ed Maste , Justin Hibbits Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 05 Feb 2017 04:05:46 +0000 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 21:34:22 -0000 Probably not related. But when I took short look to the patch to see what could go wrong, I walked into the following comment in _rm_wlock(): "Assumes rm->rm_writecpus update is visible on other CPUs before rm_cleanIPI is called." There is no explicit barrier to ensure it. However, there might be some barriers inside of smp_rendezvous_cpus(). I have no idea what could happened if this assumption is not met. Note that rm_cleanIPI() is affected by the patch. On Sat, Feb 4, 2017 at 9:39 PM, Jason Harmening wrote: > Can you post an example of such panic? Only 2 MI pieces were changed, > netisr and rmlock. I haven't seen problems on my own amd64/i386/arm testing > of this, so a backtrace might help to narrow down the cause. > > On Sat, Feb 4, 2017 at 12:22 PM, Andreas Tobler > wrote: >> >> On 04.02.17 20:54, Jason Harmening wrote: >>> >>> I suspect this broke rmlocks for mips because the rmlock implementation >>> takes the address of the per-CPU pc_rm_queue when building tracker >>> lists. That address may be later accessed from another CPU and will >>> then translate to the wrong physical region if the address was taken >>> relative to the globally-constant pcpup VA used on mips. >>> >>> Regardless, for mips get_pcpup() should be implemented as >>> pcpu_find(curcpu) since returning an address that may mean something >>> different depending on the CPU seems like a big POLA violation if >>> nothing else. >>> >>> I'm more concerned about the report of powerpc breakage. For powerpc we >>> simply take each pcpu pointer from the pc_allcpu list (which is the same >>> value stored in the cpuid_to_pcpu array) and pass it through the ap_pcpu >>> global to each AP's startup code, which then stores it in sprg0. It >>> should be globally unique and won't have the variable-translation issues >>> seen on mips. Andreas, are you certain this change was responsible the >>> breakage you saw, and was it the same sort of hang observed on mips? >> >> >> I'm really sure. 313036 booted fine, allowed me to execute heavy >> compilation jobs, np. 313037 on the other side gave me various patterns of >> panics. During startup, but I also succeeded to get into multiuser and then >> the panic happend during port building. >> >> I have no deeper inside where pcpu data is used. Justin mentioned netisr? >> >> Andreas >> >