Received: by 10.192.165.156 with SMTP id m28csp1006176imm; Mon, 16 Apr 2018 12:21:15 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+MYCRxQqK42h+/C7GGNcYMEHnmGHu+LBLxPYvsmgzCO/cQZ4Q+ZClNKZZDubov6rOYUie4 X-Received: by 10.99.64.3 with SMTP id n3mr13947756pga.13.1523906475866; Mon, 16 Apr 2018 12:21:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523906475; cv=none; d=google.com; s=arc-20160816; b=lBAvLmDeB8iGjiSv1eIA0XDv5Ltd7Xjft86unTK69aohTd1xkiIoEUz9VUHLI5XMDO jN57EgDcYd/iWwbImFGj3cYXMeTWINynXPhEDIYVES0wTCQUQcgqMkf3JG5kbf9edGpn hOXyI81uKVkeIPJY/fLSd4us716zikW8rxA0zUHwVzDox26FQ5YmmzSYjh1BmKfJyWp0 PJ2rUJ9JOA9ilpNRGQaphCOlS9TN0q4+rHuGIQWSAtFpKmJb3y8VyeAYtemlH3Knn3D+ mlzZH2N8CBiZ8jLQyDa7JRANM6rHvYXhV0M12flqj04Yub9+YRZG3uljat1X7hJyBn9n lMqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=/Lv1KrDKzRfdnvSulCfHz2QQQIlbHHUuD4BOnXzQ3Zc=; b=h4aCr5XBfAbf2SCu2I7yYFr8D3cMiRNCMD5AFfYkHQq01Hcoq6tOXq7cTUtvkYPt1I afrW5MJ7zQA+nXS+vBGVt/Y4Ynw73JZzmtAPO8UWGfv3uPmbI8CFuoc5WBOEaGBHnTiT yrJpXmcG/OwQ+2PUVY8G1cjY00GWtGef0K1od0lQah0LNM6isfs8wAL0nDnGUpUJfgKB PKEeInlEr/rLP5XDW5k/ziP3zceja193dDPCrQdfC6ZajIaaAWK52fjtw4BEErEvR9PN 26942l58dzHgnYUGV418hYPP6LpC7yJruqj6WlNWMiFP4VC7czC9FzQtnKxkKaFMsbKW aZkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=E/NxAk8q; dkim=fail header.i=@linux-foundation.org header.s=google header.b=BY8TnkIQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r1si11327851pfb.247.2018.04.16.12.21.01; Mon, 16 Apr 2018 12:21:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=E/NxAk8q; dkim=fail header.i=@linux-foundation.org header.s=google header.b=BY8TnkIQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753365AbeDPTTz (ORCPT + 99 others); Mon, 16 Apr 2018 15:19:55 -0400 Received: from mail-it0-f52.google.com ([209.85.214.52]:39071 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164AbeDPTTx (ORCPT ); Mon, 16 Apr 2018 15:19:53 -0400 Received: by mail-it0-f52.google.com with SMTP id 85-v6so10402495iti.4; Mon, 16 Apr 2018 12:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/Lv1KrDKzRfdnvSulCfHz2QQQIlbHHUuD4BOnXzQ3Zc=; b=E/NxAk8qcQ3oQ7p19yfnrozrYvhvsFy03Kmg9Qxxqc0YTxPWq1Ut5I7AqNruyYZr+9 1D0BW1s9NkQNiNgZqV0c4W1PQj6M0xIpiWhYBV+Skj8/OiX6T227HYHmL5itOqIBSq2z CLZT3Dei+8eZIfwnC+Jt7bqei/7O3rUZngjSTs3gXDokKbkkl9MJkDI2W6NpJInJ8Hup +QoPGJhcMAOyn7kVMAzLVIslGjf4/CQyqYRy/+4Ar3DQy8+vaodax7lx7oxV998CLOjG HbfR7fjgQ1qY3ATqGhc+12FhPRN54zL5sBGZNtXTuI8NrevyQSOW2/MDc04boAPjuBmf H7WQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/Lv1KrDKzRfdnvSulCfHz2QQQIlbHHUuD4BOnXzQ3Zc=; b=BY8TnkIQsUfeM8hK4W5rP0FUMYXQlBg0HXlHt+ZJHGp+iip4BCkWTgFTsM5F4ljypX w6XqGH5mwafwrB7t7qXwcUn46VPLmgMgSChhIWUcULTONpNpENzySO3lweCwCw6zi3uV Ib+Go/n4hVnjqDeIBtRtlGjmzjhnKS1y3ghkY= 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/Lv1KrDKzRfdnvSulCfHz2QQQIlbHHUuD4BOnXzQ3Zc=; b=iJUhFVsWYlsWEprh5Ghqw2sMpZU2gsW13DNqZLXIW+eK2Sa2jZTTFxL59Rxr6TGTUR /vM3QezlezWQvqRtjXw2+8rnQVNtAj+/Wn0jLg1muQEJvn4UDcoVzsPuql0yaZkR4hf0 4XhqDsakgE1rMcUNArCHI165rJ1QCquSQOYi9tS5mUyHkELvFLi7ZhgowwXU6wk2K9Zc 88uQ+fGjcPfS76pXYTlDvM6abscVWvjMy9195QgqthNrNAh/RlUh1dir5MTjZuo1N/Sk 9hcSOnChkKxdaE72hHBXMjCMda0NCIZ1P5giJxbww5/GGL0DJCZ+aVAM+1ZBoPHSl5A/ Wo9Q== X-Gm-Message-State: ALQs6tC85jaQTt3JkHNjdSoTwQjfbfsOmZO8wXc5rQGSxvNHfi+MP4+y nUepGrM2GUZEVvo9KTb7TGrpKH+wH4zMx8mAb/A= X-Received: by 2002:a24:19c9:: with SMTP id b192-v6mr16494448itb.1.1523906392453; Mon, 16 Apr 2018 12:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.95.15 with HTTP; Mon, 16 Apr 2018 12:19:51 -0700 (PDT) In-Reply-To: References: <20180416153031.GA5039@amd> <20180416155031.GX2341@sasha-vm> <20180416160608.GA7071@amd> <20180416122019.1c175925@gandalf.local.home> <20180416162757.GB2341@sasha-vm> <20180416163952.GA8740@amd> <20180416164310.GF2341@sasha-vm> <20180416125307.0c4f6f28@gandalf.local.home> <20180416170936.GI2341@sasha-vm> <20180416133321.40a166a4@gandalf.local.home> <20180416174236.GL2341@sasha-vm> <20180416142653.0f017647@gandalf.local.home> <20180416144117.5757ee70@gandalf.local.home> From: Linus Torvalds Date: Mon, 16 Apr 2018 12:19:51 -0700 X-Google-Sender-Auth: EkWwkiTk3vq9SzI2exhNB6ioCiE Message-ID: Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes To: Steven Rostedt Cc: Sasha Levin , Pavel Machek , Petr Mladek , "stable@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , Byungchul Park , Tejun Heo , Greg KH Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 16, 2018 at 11:52 AM, Linus Torvalds wrote: > > And yes, sometimes that means jumping through hoops. But that's what > it takes to keep users happy. The example of "jumping through hoops" I tend to give is the pipe "packet mode". The kernel actually has a magic pipe mode for "packet buffers", so that if you do two small writes, the other side of the pipe can actually say "I want to read not the pipe buffers, but the individual packets". Why would we do that? That's not how pipes work! If you want to send and receive messages, use a socket, for chrissake! A pipe is just a stream of bytes - as the elder Gods of Unix decreed! But it turns out that we added the notion of a packetized pipe writer, and you can actually access it in user space by setting the O_DIRECT flag (so after you do the "pipe()" system call, do a fcntl(SETFL, O_DIRECT) on it). Absolutely nobody uses it, afaik, because you'd be crazy to do it. What would be the point? sockets work, and are portable. So why do we have it? We have it for one single user: autofs. The way you talk to the kernel side of things is with a magic pipe that you get at mount time, and the user-space autofs daemon might be 32-bit even if the kernel is 64-bit, and we had a horrible ABI mistake which meant that sending the binary data over that pipe had different format for a 32-bit autofsd. And systemd and automount had different workarounds (or lack there-of), for the ABI issue. So the whole "ok, allow people to send packets, and read them as packets" came about purely because the ABI was broken, and there was no other way to fix things. See 64f371bc3107 ("autofs: make the autofsv5 packet file descriptor use a packetized pipe") for (some) of the sad details. That commit kind of makes it sound like it's a nice solution that just takes advantage of the packetized pipes. Nice and clean fix, right? No. The packetized pipes exist in the first place _purely_ to make that nice solution possible. It's literally just a "this allows us to be ABI compatible with two different users that were confused about the compatibility issue we had due to a broken binary structure format acrss x86-32 and x86-64". See commit 9883035ae7ed ("pipes: add a "packetized pipe" mode for writing") for the other side of that. All this just because _we_ made a mistake in our ABI, and then real life users started using that mistake, including one user that literally *knew* about the mistake and worked around it and started depending on the fact t hat our compatibility mode was buggy because of it. So it was a bug in our ABI. But since people depended on the bug, the bug was a feature, and needed to be kept around. In this case by adding a totally new and unrelated feature, and using that new feature to make those old users happy. The whole "set packetized mode on the autofs pipe" is all done transparently inside the kernel, and automount never knew or needed to care that we started to use a packetized pipe to get the data it sent us in the chunks it intended. Linus