From owner-svn-src-head@freebsd.org Sat Feb 4 05:29:34 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 A5D38CD071B; Sat, 4 Feb 2017 05:29:34 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 6A7181F8; Sat, 4 Feb 2017 05:29:34 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-ot0-x244.google.com with SMTP id 73so4565164otj.1; Fri, 03 Feb 2017 21:29:34 -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=gk010vl6EJwcICvv1ayMUmErJYVyyoHdo5+VvUMsgkA=; b=NYuTg9tmm1DA6H1XExg5S7tvUAwYGzkSS9fNq4j0sW4QRBkYW3mta1A8z59n0X8NHt 2fZNlFhr0VkGDSFVQqCR1Jt+hJnZA0mFMwLP16QGnxbC0hrJvPCi3rElNHhnX6uH3ari Fjkal9s7JpP4LuSaFxyaft9pldgLLO4UseoVPebkIFpBtGV7569+kACxxcyRQrTZDaVI v6Upv5SM5cCRA0lY8UqgAVUwnnbDGgB8d/mmW7k2hatOqKsahJOj8uZ1N30lEzq0IAh+ VA9UZDGdyag1GtITStCEtZ0Ky7Da5oy0RJk0iYCQpglWvyMF2dR+mMJsJg+oAXUBrDsC OKXQ== 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=gk010vl6EJwcICvv1ayMUmErJYVyyoHdo5+VvUMsgkA=; b=QOGO7RTr1sGZ7oLy57MenjaK/cvx/0XyH/PliTxqBBg7kC9jh6/sJB7V7gy0RXR8Gw URpBhE5OPTvZ9OfIelmWZoUl6d1z4fdGsGmvILH+Hfen/UoYwmtJmd6/b91tnYXxnnDT d2TBdcTK1CcId01lyvA9LvkTU5BcToc5+YaqrULr5gC/E9WPvEs9I5OKjXHTCi3+Nl7+ GAqUeKNcyDOwZ6qky/EsjuVaX/Khr4x7w7pZKA3WnwTysnfuFKQAA0ia7Hg0jc785vIq VBODaJuNAK3wO4SMtlJkPrYXsx7GCORwPiiToO77Id1jXOJ8ekf9NmpQaerkH+3BhyCc Pv3A== X-Gm-Message-State: AIkVDXIEdVu3ErZRz8bM8UHW2uL068uPzi732c1GDgz2AqX3JmpkRrNpHYPUMyy3TYPyZqznVf8Jh//iQOYsvQ== X-Received: by 10.157.7.53 with SMTP id 50mr239549ote.91.1486186173526; Fri, 03 Feb 2017 21:29:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.7 with HTTP; Fri, 3 Feb 2017 21:29:33 -0800 (PST) In-Reply-To: <20170203231238.0675c289@kan> References: <201702010332.v113WnYf041362@repo.freebsd.org> <20170203231238.0675c289@kan> From: Jason Harmening Date: Fri, 3 Feb 2017 21:29:33 -0800 Message-ID: Subject: Re: svn commit: r313037 - in head/sys: amd64/include kern mips/include net powerpc/include sparc64/include To: Alexander Kabaev Cc: "Jason A. Harmening" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 05:29:34 -0000 Hi, I'm a bit confused as to how this change breaks MIPS. The new function, get_pcpu() is intended to be used only to access the per-cpu data pointer locally. It returns pcpup, which is the per-cpu pointer wired into the local TLB to translate to the local CPU's physical data region, correct? This is the same value used by the per-CPU accessors such as PCPU_ADD and PCPU_GET. The MI portions of this change only use get_pcpu() to access the local CPU's data, e.g. under a critical section in the rmlock. It is not intended to be used for iterating all CPUs. If I've missed something and MIPS is truly broken by this, then I'll gladly revert, but (maybe because it's late) I'm not seeing where this goes wrong on MIPS. Thanks, Jason On Fri, Feb 3, 2017 at 8:12 PM, Alexander Kabaev wrote: > On Wed, 1 Feb 2017 03:32:49 +0000 (UTC) > "Jason A. Harmening" wrote: > > > Author: jah > > Date: Wed Feb 1 03:32:49 2017 > > New Revision: 313037 > > URL: https://svnweb.freebsd.org/changeset/base/313037 > > > > Log: > > Implement get_pcpu() for the remaining architectures and use it to > > replace pcpu_find(curcpu) in MI code. > > > > Modified: > > head/sys/amd64/include/pcpu.h > > head/sys/kern/kern_rmlock.c > > head/sys/mips/include/pcpu.h > > head/sys/net/netisr.c > > head/sys/powerpc/include/cpufunc.h > > head/sys/powerpc/include/pcpu.h > > head/sys/sparc64/include/pcpu.h > > > > Hi, > > this change was not reviewed nor testing was thought for all > architectures it touches. The change happens to break MIPS quite > thoroughly, since MIPS is using different pointers when accessing PCPU > area locally and when doing iterations using cpu_to_cpuid array. I > therefore officially am requesting this change to be reverted until > reasonable solution is found to unbreak architectures that use wired > TLBs to access local per-CPU data. > > -- > Alexander Kabaev >