From owner-freebsd-arch@freebsd.org Mon Feb 26 22:21:48 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C736CF27D47; Mon, 26 Feb 2018 22:21:48 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 3A7C96D61D; Mon, 26 Feb 2018 22:21:45 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id m5so22864888wrg.1; Mon, 26 Feb 2018 14:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=7TEoEkKjF6un0YpEEQyLNTPUSN2yMd4r1fJ9DUhImI4=; b=BY0DVDXg9TTOe33IW6ld49mJMYBXtn1NQcXC6epwAPfAMexeWzB1E/aCngOcjtP3o5 PscU8MorYlimJpfpuQc0cTY3PYDT0EXlT3U4rW7iTEB6vU1ZzBpckUNZ91ikqI65WC0y Z/o+pDVjAkg9XJyvav0+WFBMFXvDrn4c1JtxtM1L/JDmwqM7pxHGyY1qXEKUZacdR5rD mpGZfIan1Aym79DwSHip//BC1LIopWl7OaTVIMpC2Ne20MhQOmn7OqQePuAmHOcRMpOC 2XytGVTlGaNYGsdbs5EjIfHMUaFXfTJSe8EcCyUbFcO8FQ+MT0Dcgx4FPR1EDx41OU8J wbjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:message-id:subject:from:to:cc:date :in-reply-to:references:mime-version:content-transfer-encoding; bh=7TEoEkKjF6un0YpEEQyLNTPUSN2yMd4r1fJ9DUhImI4=; b=kxq+hMTT/cuKKzTMoTrx0m97tGRvvrwle9UIDQZ+CRASkjXwNS2PN8n59r5H0YJOrP /H5oWCtMEHzf5al8/goA6ZHhlMIvt6uGBM7Y6iXpxpL8LyuFZLhKwNBvirVd+vsHxuKE sLzQCuGq3s7sVjjowIJC7Ohr/elvnqEgtKLfJLPrfOy4J7vQZglMALmGL+eO3s9d0sHD tFht5Okj9JcIRzS8334J0z1zPtSNpZic3w3Fnd7RMzqtIovjohmLWEsjldtWcS45KC9b aPkXCXYgihH7OYmUqRHS/LPShtHwPop28BcMiOY0uHumuC3ykHpHJOx4xkANLdFhFXM0 FadA== X-Gm-Message-State: APf1xPBxU5S+oYZTYmSY/CJcQawBefZVj2c1gqDvrF2PeaVu5CyC+TZl N9Y+BaFNy4I8qnkGbR7ibHQ= X-Google-Smtp-Source: AH8x226LoVJEauXUt4YqcUbLSOPMj9wYZwyu5yBg3oVrVapL2tH6I0Vad2kp1lAHSjqJ3xKphJhnOA== X-Received: by 10.223.166.171 with SMTP id t40mr11543427wrc.49.1519683703340; Mon, 26 Feb 2018 14:21:43 -0800 (PST) Received: from dwarf (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id l22sm12108176wre.52.2018.02.26.14.21.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Feb 2018 14:21:42 -0800 (PST) Sender: Navdeep Parhar Message-ID: <1519683699.47932.5.camel@FreeBSD.org> Subject: Re: [HEADS UP] - OFED/RDMA stack update From: Navdeep Parhar To: Meny Yossefi , "'freebsd-infiniband@freebsd.org'" , "'FreeBSD-stable@FreeBSD.org'" , freebsd-arch Cc: freebsd-drivers Date: Mon, 26 Feb 2018 14:21:39 -0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.2 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 22:21:49 -0000 +freebsd-arch@ Hi Meny, Can you please post the KPI/KBI analysis that you generated to some public location and provide a link here? A straight MFC would be a major break of KPI/KBI in -STABLE and the options we're looking at are: a) Ignore the breakage and let downstream consumers deal with the fallout. This obviously isn't ideal in a -STABLE branch. b) Provide compat shims to at least preserve the KPI. One challenge is that the changes include functions with the same name but different signature/behavior. See, for example, ib_create_cq in Meny's list once he publishes it. c) Have two versions of the OFED interfaces in 11-STABLE and not break existing downstream consumers at all. I've reached out to users that I know of and know will be affected. If you use OFED and FreeBSD 11 this would be a good time to weigh in with your thoughts, ideas, concerns etc.. Regards, Navdeep On Mon, 2018-02-26 at 14:49 +0000, Meny Yossefi wrote: > Hi, > > We are currently working on MFC'ing the OFED/RDMA stack update > mentioned below to FreeBSD11-STABLE. > > We already have working version in 'projects/bsd_rdma_4_9_stable_11' > (pending iWARP updates) and currently working on ULP integration. > > Again, as always, for any concern/comments you might have, please > don't hesitate contacting us. > > freebsd-drivers@mellanox.com > > > Regards, > > Meny Yossefi, > Mellanox technologies > > > -----Original Message----- > From: Meny Yossefi > Sent: Monday, November 13, 2017 11:09 AM > To: 'freebsd-infiniband@freebsd.org' ; > 'freebsd-current@freebsd.org' > Cc: freebsd-drivers > Subject: [HEADS UP] - OFED/RDMA stack update > > Hi, > > This is to inform you that by end of this week we plan to merge the > OFED/RDMA stack update from the project - 'bsd_rdma_4_9' into 12- > CURRENT. > The update aligns the OFED common code and RDMA vendor drivers with > Linux v4.9. > > We are still working on final modifications and build testing it prior > to submission. > > > For any concern/comments you might have, please don't hesitate > contacting us. > > freebsd-drivers@mellanox.com > > > Regards, > > Meny Yossefi, > Mellanox technologies > _______________________________________________ > freebsd-infiniband@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-infiniband > To unsubscribe, send any mail to "freebsd-infiniband-unsubscribe@freeb > sd.org" From owner-freebsd-arch@freebsd.org Mon Feb 26 22:43:27 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0D82F29C9D; Mon, 26 Feb 2018 22:43:27 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F18DB7086C; Mon, 26 Feb 2018 22:43:26 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1QMhBXt073562 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Feb 2018 00:43:14 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1QMhBXt073562 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1QMhBvk073561; Tue, 27 Feb 2018 00:43:11 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Tue, 27 Feb 2018 00:43:11 +0200 From: Konstantin Belousov To: Navdeep Parhar Cc: Meny Yossefi , "'freebsd-infiniband@freebsd.org'" , "'FreeBSD-stable@FreeBSD.org'" , freebsd-arch , freebsd-drivers Subject: Re: [HEADS UP] - OFED/RDMA stack update Message-ID: <20180226224311.GT94212@kib.kiev.ua> References: <1519683699.47932.5.camel@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1519683699.47932.5.camel@FreeBSD.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 22:43:27 -0000 On Mon, Feb 26, 2018 at 02:21:39PM -0800, Navdeep Parhar wrote: > +freebsd-arch@ > > Hi Meny, > > Can you please post the KPI/KBI analysis that you generated to some > public location and provide a link here? A straight MFC would be a > major break of KPI/KBI in -STABLE and the options we're looking at are: I put the report at https://kib.kiev.ua/kib/ibcore_11_to_11_merged_compat_report.html > > a) Ignore the breakage and let downstream consumers deal with the > fallout. This obviously isn't ideal in a -STABLE branch. > > b) Provide compat shims to at least preserve the KPI. One challenge is > that the changes include functions with the same name but different > signature/behavior. See, for example, ib_create_cq in Meny's list once > he publishes it. Project did handled similar issues already. One of the approaches is to renname the ib_create_cq with the new signature to ib_create_cq_n12 and check for (e.g.) _WANT_NEW_OFED symbol and to select one or another: #ifdef _WANT_NEW_OFED #define ib_create_cq(new args there) ib_create_cq_n21(new args there) #else #define ib_create_cq (ib_create_cq) #endif Then ULP that wants new KPI defines _WANT_NEW_OFED. > > c) Have two versions of the OFED interfaces in 11-STABLE and not break > existing downstream consumers at all. It is possible to make them loadable simultaneously as modules, but it is quite confusing to users, because Mellanox clearly wants mlx5_ib and mlx4_ib to work only with new OFED, while cxgbe would use old OFED ? Also, either we would need to mess with the ibcore.ko module name, or with version. I am not sure that our module handling is robust enough to make the version trick possible. > > I've reached out to users that I know of and know will be affected. > If you use OFED and FreeBSD 11 this would be a good time to weigh > in with your thoughts, ideas, concerns etc.. From owner-freebsd-arch@freebsd.org Tue Feb 27 00:44:06 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88C4FF3148F for ; Tue, 27 Feb 2018 00:44:06 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id E29E47571D; Tue, 27 Feb 2018 00:44:05 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id w1R0hxZB071486; Mon, 26 Feb 2018 18:43:59 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201802270043.w1R0hxZB071486@mail.karels.net> To: John Baldwin cc: freebsd-arch@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: ps output line length change In-reply-to: Your message of Wed, 21 Feb 2018 16:59:24 -0800. <3369243.YQvd3VYPi2@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71484.1519692239.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Feb 2018 18:43:59 -0600 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 00:44:06 -0000 jhb wrote: > On Wednesday, February 21, 2018 02:47:15 PM Cy Schubert wrote: > > Iirc cem@ committed the original patch. Maybe someone should ask him t= o revert. > Mike has. This thread is to determine what the consensus is. > My preference is for the old behavior. Everyone who expressed an opinion about reversion of r314685 on arch@ said that they prefered the old behavior. There were similar results on the committers list earlier. Accordingly, I have put a change that reverts r314685 and adds comments explaining the old behavior up for review. It is https://reviews.freebsd.org/D14530. Mike From owner-freebsd-arch@freebsd.org Sat Mar 3 03:33:27 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0FABF3B604 for ; Sat, 3 Mar 2018 03:33:26 +0000 (UTC) (envelope-from whoistalg@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 68A596A4BF for ; Sat, 3 Mar 2018 03:33:26 +0000 (UTC) (envelope-from whoistalg@gmail.com) Received: by mail-it0-x230.google.com with SMTP id c11so3837355ith.4 for ; Fri, 02 Mar 2018 19:33:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=3QOfvlIWtxbzorhLeEfNSBCKe4RfjA+WYmepvPGMYgg=; b=oJ47SspiEB0nPoUNqAU6cjYxRfAnCUhqHNp54on7tuSEVZMmUq84V50IErdXOSMySm /Lq00FDnZ8j+YtMhEU89WSwFymbvxR5N0MGXyhlzATcH8t7uAEZACqSSHG8HdvO1cKO+ dFHjppHKyFcRl62LEaqCwA2B1UXsTGhFAnRsAX1dGon77gj305iNL8ymxU2OVKxKaoc8 jhUqJBXxSHpoA0vr2Di2jBPyuVrWPBvJAfTbcRz9lJ82qlbgRex5vgiTF1csN/VplloJ 7lABiy+zyUBSFiBCjSQ1ybo/wQ9NzHIQWlgJhuNQIeu2hcBfTuO/UBUnu87+e5ESblUN yU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=3QOfvlIWtxbzorhLeEfNSBCKe4RfjA+WYmepvPGMYgg=; b=B2behDb+QtdgvL92Pcz+MCtVQX3x000nypZXvbfY3dPGqwRENyE6chIXzjrisQTKzJ uMoRuXcA16qBs048/z/nva9wb6ncyN9bOpzobOcAtUaRGvYkIMjepetdLSOrAAjlASkt mHeyAA1h2kB5Vm4Z5JWMjDCkMI52BVtf+zmhDxAkGTZjQLhZZ7fU9WO3id0vb5JfPS99 ipaMCsvw/ANKLY6XOe9xNFNfMHTeYkv/sSTNei7HO2XhDLuf8cKTfKOHDjPSpsYTza7O UY2FANwW5Ids1zkSXW94DIwpRl8eiT8DcRSOyfEnf2TIfslUZMH8xW0THre1NlQKsTRL JVdw== X-Gm-Message-State: AElRT7FMHXnb2PkwVwPA/ZiPoiDx7DkEq6J7NPrZbxWUEcvKSJTkJxqP 67XMfAN8k601Gr73fNMrUCKDyOg+oj5wDWrEQc6MuQ== X-Google-Smtp-Source: AG47ELu1eqkFyaT7kmJSBsWIxFwKGCIYGMCjnarSIS+LcYnY2/FIW5zuwdgb5eGeBQU+ejWpdMCC7VSpIzsOSlzDRmQ= X-Received: by 10.36.135.195 with SMTP id f186mr5518333ite.100.1520048005186; Fri, 02 Mar 2018 19:33:25 -0800 (PST) MIME-Version: 1.0 Sender: whoistalg@gmail.com Received: by 10.107.149.76 with HTTP; Fri, 2 Mar 2018 19:32:44 -0800 (PST) From: Tal Garfinkel Date: Fri, 2 Mar 2018 19:32:44 -0800 X-Google-Sender-Auth: utW9l_FQWy4Zm6yX-w3pSU-sKa4 Message-ID: Subject: Feedback on adding SAL annotations to syscalls.master To: freebsd-arch@freebsd.org Cc: Brooks Davis Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 03:33:27 -0000 Hi all, I recently put a patch up on Phabricator with SAL annotations for syscalls.master and small modification to makesyscalls.sh to strip out the annotations. https://reviews.freebsd.org/D14285 The annotations were originally written by Brooks Davis, for the cheribsd project, I just made a few changes to bring them up to speed with freebsd current with help from Brooks. The immediate motivation for this is to support automatically generating code for a record/replay system that will stay consistent with the system call interface. Other potential uses include: dynamic bound checking system call inputs (the original motivation in cheribsd), static analysis (the original use for SAL), automatic test generation (which Brooks has a student looking at), and a variety of other potential uses where one would like to automatically generate code to deal with the system call interface without having to deal with the tedium and error prone nature of doing the by hand, and have to worry about this drifting from version to version. What is the impact: Since these annotations are stripped out before code is generated from syscalls.master their impact on the system is minimal. Tal From owner-freebsd-arch@freebsd.org Sat Mar 3 07:12:09 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24070F45C0D for ; Sat, 3 Mar 2018 07:12:09 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B225F71FFD for ; Sat, 3 Mar 2018 07:12:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 736F0F45C0A; Sat, 3 Mar 2018 07:12:08 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F5F3F45C07 for ; Sat, 3 Mar 2018 07:12:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (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 E3D9471FFA for ; Sat, 3 Mar 2018 07:12:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f41.google.com with SMTP id w19so4144540ite.0 for ; Fri, 02 Mar 2018 23:12:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:content-transfer-encoding; bh=6ytfk+bnxc2vC40GCJizBzd8121W3YUYkxoCj2jWbj8=; b=H5Jl3QO+yAkhcpsli1PGkevgKy9OC4GBVRFg6FFq2PAx4auQq7YPaz6aQ1Ra49BqaD cGaHaEFT6d+6e4hA92BfGebOSQJt67W3uByeid40l7dMCQpcpTWDkKfJJASMSvlblU1/ 0e+fEWoxgd/ONPfykAaBkwcbZzF/hIKZHS/biCP6WXbnPsihP0xl17Gh10u9OX5+qZzu zWiNm7V5dZ9xr1rJndnxCUd6MQUh7O678qinGoDsRJ7wVtu0QdJDFpFysOgiSJG3/VVH WNn3A8/TdwYVoqGSSvs5o8hXFH66ksV831rwMt+VnXLeYyn9PKMneHffVTX2BGCNqGDJ kNiQ== X-Gm-Message-State: AElRT7EFPtgyvCSVxcSht+nhSzs5zPTncWmLs9SVXsfNtjmiLDq9D/fB f1FDEezdD2sYuXxx9f5zrz04zh/S X-Google-Smtp-Source: AG47ELudPgNyKlDkDUqGHKWG+AqCrLQNhhS3S7fqOKQCk/UfUvKs6ZsEURFLqYkdTGm0a4Ida699Jw== X-Received: by 10.36.166.10 with SMTP id q10mr5665658ite.132.1520061121464; Fri, 02 Mar 2018 23:12:01 -0800 (PST) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com. [209.85.214.50]) by smtp.gmail.com with ESMTPSA id u129sm1762409itb.5.2018.03.02.23.12.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 23:12:01 -0800 (PST) Received: by mail-it0-f50.google.com with SMTP id w19so4144530ite.0 for ; Fri, 02 Mar 2018 23:12:01 -0800 (PST) X-Received: by 10.36.92.205 with SMTP id q196mr2112408itb.135.1520061121040; Fri, 02 Mar 2018 23:12:01 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Fri, 2 Mar 2018 23:12:00 -0800 (PST) From: Conrad Meyer Date: Fri, 2 Mar 2018 23:12:00 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Proposal: deregulate secteam, random team To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 07:12:09 -0000 Hi all, Being on secteam, essentially a post-release engineering team, is a thankless job no one wants to do. It's largely keeping quiet about embargoes and issuing patches and EN to releases. However, due to a number of factors, our secteam can't seem to operate effectively. We struggle to communicate effectively to the wider FreeBSD organization and the community; we seem unable to reliably produce patches by the time embargoes lift. Some factors help explain this: 1. First and foremost: we're not always getting included in embargoes anymore. This is exemplified by the Spectre/Meltdown FUBAR. 2. secteam is tiny and workload tends to alternate suddenly between "no work" and "everything is on fire." Are there more than *two* active members at this time? No one on secteam is full time. 3. Historical policies about not commenting on active vulns when a patch was not prepared. This is just historical stupidity we haven't managed to leave behind =E2=80=94 if a vuln is being exploited in the wild,= we *must* comment on it. Even if we have to say, "we don't have a mitigation prepared yet and don't have an ETA." This kind of policy makes secteam look not just opaque, but foolish. 4. FreeBSD is dying ;-). The lack of communication is killer. Maybe secteam is incredibly active and efficient, but *no one can tell*, because they have zero communication with the rest of the project. Adding on to the burden: for some bizarre reason, we've also foisted the responsibility of code review of arbitrary parts of the kernel tree on this post-release engineering team via SVN commit hook. (And, segueing into the subject of this email, the random team as well). Secteam hardly has time to triage security bugs and issue ENs. Turn around time on any code review involving secteam is measured in *weeks* or *months.* Meanwhile, there is a wide body of security-conscious developers who are capable of reviewing and evaluating crypto and security code. They may not be interested in pushing ENs to releases, or their availability may be irregular. But they may be motivated to help, and are totally unable to contribute in the status quo framework. Furthermore, the review-gating ends up as a big double standard. Anyone in the outgroup waits weeks on even the most trivial change to be reviewed, but secteam or random team members are free to jump in and commit things that breaks the tree with no review. (Not to name any names, but, r285422. And all commits with "Approved by: so (/dev/random blanket)" in the commit message are examples of this special privilege, if not a sure sign of breakage.) I propose deregulating secteam and random team and stripping them of their review authority. 1. Remove "blocking reviewer" (Phab Herald and svn commit hooks) status for teams that can't demonstrate consistent, timely review. That's all of the above mentioned teams. 2. Active pruning of inactive team members. If membership is too low to meet the mandate of the teams, *padding the membership with inactive members does not fix the problem*. 3. Lift access restrictions on security bugzilla to all src committers. More security-interested eyeballs can be triaging, prototyping, reviewing, and evaluating security solutions. a. If there are ports security issues tracked in security bugzilla, access can be extended to relevant porters on a bug-by-bug person-by-person basis. 4. Maybe just get rid of security bugzilla entirely? Tracking our security bug work in the open at least provides transparency, and maybe transparency helps motivate results. Flameproof pants on; please go ahead and bikeshed. Yours, Conrad