From owner-svn-src-head@freebsd.org Mon Dec 18 22:50:47 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 7EEBEE8F6D2 for ; Mon, 18 Dec 2017 22:50:47 +0000 (UTC) (envelope-from 010001606bd2655b-88495d69-fea4-4969-97f0-62fccf339ca3-000000@amazonses.com) Received: from a8-52.smtp-out.amazonses.com (a8-52.smtp-out.amazonses.com [54.240.8.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37E0574F9B for ; Mon, 18 Dec 2017 22:50:46 +0000 (UTC) (envelope-from 010001606bd2655b-88495d69-fea4-4969-97f0-62fccf339ca3-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1513637439; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=uIYmuYS9PXNCHBxlQ9B0VQ1AyDtG9U9/EaX3nuWiU/0=; b=rcaeG7VqdUBWZYuvKjxjgTmn/1nndPupqSRssXWWm87ZOvcXKPFPBsiblg9j2kEx K5kygfima+GHje8qqnye2eXBdbjWApIKLIvV9dKLh7VUPUmMjrXdNUiqhC/j9Y/neuV Ft41Z2zcrwgxGxaHTWPj7yrZocM1L2kDio1eb7LM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1513637439; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=uIYmuYS9PXNCHBxlQ9B0VQ1AyDtG9U9/EaX3nuWiU/0=; b=lLGLilizNIrcK236fTctJRBM+l5BOSkpH6firsqP/8Iv+P5syJTPr/srVT2t7WiR jQPCme0dyOU/MVMP9HepOeLwe3nf8naZUM7rO/9BLL2vOgfwAQSLGbCn7/FKBr3lBts MhAR+OOCYDcjQaYV+wnpCxSqZ/w7DjMrvDZJQKK0= Subject: Re: svn commit: r325841 - in head/sys: conf dev/mlx4 dev/mlx4/mlx4_core dev/mlx4/mlx4_en dev/mlx4/mlx4_ib modules/mlx4 To: Hans Petter Selasky , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201711151114.vAFBEeUb015030@repo.freebsd.org> <0100016067e203d1-fa769584-f8a1-44f2-ac39-1572e8fff087-000000@email.amazonses.com> <6d9cacd6-0f98-54e0-86be-6f202f509b17@selasky.org> From: Colin Percival Message-ID: <010001606bd2655b-88495d69-fea4-4969-97f0-62fccf339ca3-000000@email.amazonses.com> Date: Mon, 18 Dec 2017 22:50:38 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <6d9cacd6-0f98-54e0-86be-6f202f509b17@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2017.12.18-54.240.8.52 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 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: Mon, 18 Dec 2017 22:50:47 -0000 On 12/18/17 00:15, Hans Petter Selasky wrote: > On 12/18/17 05:29, Colin Percival wrote: >> Also, it breaks some work I have in progress for instrumenting SYSINITs. >> Would you mind moving the DEFINE_MUTEX line to occur immediately prior to >> the set_port_type function, rather than being placed inside it? > > I'll have a look at this later today. Your point is valid! On further examination, it looks like DEFINE_MUTEX is something used in Linux kernel code, and the way it works there does allow it to be used inside a function. Is it possible to change the linuxkpi code to make it safe? (It looks like our mutex initialization is considerably more complicated than what Linux does, so maybe not...?) I have a feeling that we probably don't want to end up in a position of "every time we import code from Linux, we need to grep for DEFINE_MUTEX and hoist all of them out of functions". -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid