From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161641AbdEWVcn (ORCPT ); Tue, 23 May 2017 17:32:43 -0400 Received: from mail-co1nam03on0060.outbound.protection.outlook.com ([104.47.40.60]:46832 "EHLO NAM03-CO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1034214AbdEWVcf (ORCPT ); Tue, 23 May 2017 17:32:35 -0400 Authentication-Results: landley.net; dkim=none (message not signed) header.d=none;landley.net; dmarc=none action=none header.from=caviumnetworks.com; Date: Wed, 24 May 2017 00:32:15 +0300 From: Yury Norov To: Rob Landley Cc: Andrew Morton , "linux-kernel@vger.kernel.org" , Prarit Bhargava , Yang Shi , Rasmus Villemoes , Kees Cook , Emese Revfy , Petr Mladek , Fabian Frederick Subject: Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot Message-ID: <20170523213215.qmfnbf4bseqiwkky@yury-N73SV> References: <20170522120550.ekrq6ipfmkdtlxjo@yury-N73SV> <7d91fb6b-9a21-ceb6-6c08-4bc14a15ada2@landley.net> <20170523080159.2yetdh4qqt2pmha6@yury-N73SV> <66dd96ec-b170-0bf6-7746-5466270b3e15@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66dd96ec-b170-0bf6-7746-5466270b3e15@landley.net> User-Agent: NeoMutt/20170113 (1.7.2) X-Originating-IP: [176.59.52.37] X-ClientProxiedBy: DB6PR02CA0002.eurprd02.prod.outlook.com (10.170.218.143) To BY1PR0701MB1272.namprd07.prod.outlook.com (10.160.108.18) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR0701MB1272: X-MS-Office365-Filtering-Correlation-Id: 7eb89ba8-014e-4d2d-bf1f-08d4a2233624 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:BY1PR0701MB1272; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1272;3:6+CWRlks0NTmK3pkkQKDcPK/AnMUh5lAywzs3HLu125AP1jgHC98EM+T+QHoGNMyQtKES6y14euC3rCNFH9ev6A0Fm4u1U57UcoJ6AIXOME5r6MW65ydirIVKrXP2mjgC4ELkajTwRLYQEu1/3Cd3/sFL2fyznKJIt+nv0pGrH7bhaRYU36KRP23WeWHc7lhhLXHGnJU8ENOCnfJRAzgA2EICD48D+BWNjoSAvtVURWPaljBZHcjKvsS5N3aQa0aUNTZiEOaZpetLr7a2UeQLNLPcBaDPX8G9m4Wb2HOCxI2hSd8xxdQWlYD4aCCP00t61WDv/ja1/n+U6lV16L8Ew==;25:2dN5lW7x74LP0WS7R4uG4TmgWkf75W+zdhOQ29rSojmVQm7Cx5ftxhICTRdV6mXBNcgeDIBSsM43PeiKTGV8Q1ACYp9mEDGyypuJc6Pq1syxMNAx/INgoRUfwIjcllZSJw+06ULgebXVin9ELlUr0IlDi4RwxNIHSfLPGonHAeRTKUibHogSjn3mdBAQDEVZFm67yE88Plz34MsOcw38hHJaEtxjqUu34+tNivIj+1MTezdybjPIkVMe3b+CLCWjTjt+vDYWUx9LYmqUuTtA54cKTVXF22NWP3nm4kSKYDTSt4ZPU8MnutrOFTx7tUjthrx5tktEmTFnZINUzvT6cfQoMvaBJBSZTbS6KL75zm0Zf++EbxQZ68dNjy1OXCdwj00o9cqgQM1gs6Q1Nfb672ysdM3FeNK6uYQMK/0irkL2XiABsLgYE8fUN8NjO3wo1552nxUFF/WR1PPtA9J9vKQ515fK+ERnlyNSV2QWMRo= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1272;31:cSs7qTTjFdG18igkahApv3qrVmH6Ff87zatsEiL0mX26Cex2Z9ITifZFF5FKGyEuM9AeS/VzCJ8BC7x36UKEtOKoje1oKnUNm/AZYfriBMYHznrP+2FuQElZqt4duFaOj5si6e/xCg/o0cIpLl2RW3IsVDt+ERMiXW07GNu1n0TBmArNhTtZy+cncv+t5kv0RuLpRJ7iLYQwjTupnuSox2hOeOyxaVEdTnjmjPai6PATIoij0LeGFbVFgpUB6tyZUZqIOOW4b/LkqOdQZkrvhQ==;20:aYm99/AM+pdh7n1ODW5ip6VHkjq/z18K3dWVcAqyWZZ+m3i3YVTtmoSEVovx14QIZfrH/PVeQzzG3OgBFGhVUPndfRqXYSHPTMeRHFo5oapW7yPv2JSClu9N7qQ8OMIQE9XreStcD0UKqxaBBTxMklB285GkdqDw9OK/M8imIttVj2mQmrnD2TAIjvVCqjClam59YfOOL7OdflebT5S4qcBTO/DtnCVi9gQi6bngT5Fra1bP57UJFBzUspgf9aUTYpX22lLXZtPSYXu8qG80tQNwkb3YwwkFWJcvMmrxKNHwzicbOwnYa4SqRJ94wbIYQXfIJCGxvdDJIOK33/yToydO4/2m3TnDUD0j2lAWBVVt7vWFb1fxpiqtK153nkiMwpid5FadFMhNMgsCN/jH5HFB73yuerrv8kYfrVPFi1hq2fE8TDBkFwUi+Gg2M2G/iYHxeSq0+9YXJc4nUmMaLyb2S4Ba2O8mkFWO2h8iEg13SynWt1PSGZOlILgV25Q9ENPzE0WnFkoQ4uEK0FTgGJXCGFdA9D6MSQDnHwPRhbmGy6xrUpvbcH0U+YamhDUkzQdBmOQaHlyI+PWs6pGrsw6RSkV5Q8W/lpDR862oR/E= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(6041248)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148);SRVR:BY1PR0701MB1272;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1272; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1272;4:jgryWHyjwnQ3Ln37dJZRJi//XyiaBhU1HTMST3cRnS3rAjVhFvnwJ7PuAfncsdBJqq+R/LXcrnZCaZz5/ER1Xa8YHB7Iv4a/4zumSFOoLNZLT35ICMm9otIgo0q9N3i7yOJuH8kww0rIGeWXKn1p0KoTIelxmmgcigxQwUlQeUYg7Mo/pKMD4wKCGj5qXvJnyEPr8vluxFiG/EtsdlPGqkZSVivWVPpxIMImx2A0nRnutuO0kMAgOZG/VQB7Aa8NFqV/7xeXN08WxZckZ1lEArOE1DnZNBZU7yWv/WPsDk6PTi4xglTV4gEfr8rYyHXwm9sWYsd4Gkr9VTPRqWjtF9Pkhf4ZMMpe+Jhka/HUd3RwhOalo73EGuVMRhR0XM1sWVAHdLHtkDEGvwoT3M5a+Avdn9oaqeNxJNzOhkBuuTWcOPHX3E4BuFiugcMmI5OYXTgiV5x9WoSoGS6YMXs4p71GizTyHgAeTuotAzDwjTBLo45a9zwVLcxpt3G7r5XjmJeLJnbxX2qj+uZ979yIQ8ZI/MuB/NHUBSoQyjc/cGHarkxIqdkwNIg4om0/jn/MFEtQMAYdQtFsoIMLFDB5Hw1w+3PTS8mkTS79QkFPTnZxq/k562E2dmjmmp7TULPPjoUuLfrKVcFYleCvHXirl4VJxYPrFOWcgyObYqtGUd7fo4cIUkBik4aHHN9zn0NrmXVc+0D/LNQ5bfsUJNJ3vZkmho63GTXkfJ0ebbHBp6I78jgf5M3iDBroIbNsDoE+Tj50FqDMUWR5xM3LfaANOA== X-Forefront-PRVS: 0316567485 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6069001)(39850400002)(39840400002)(39400400002)(39410400002)(39450400003)(24454002)(377454003)(38730400002)(110136004)(72206003)(966005)(6496005)(53936002)(6246003)(478600001)(4001350100001)(50986999)(54356999)(33716001)(76176999)(81166006)(8676002)(5890100001)(189998001)(2906002)(66066001)(53546009)(6486002)(305945005)(47776003)(83506001)(25786009)(33646002)(5660300001)(76506005)(42882006)(2950100002)(6916009)(1076002)(6666003)(7416002)(42186005)(3846002)(4326008)(6116002)(54906002)(23726003)(9686003)(7736002)(229853002)(6306002)(50466002);DIR:OUT;SFP:1101;SCL:1;SRVR:BY1PR0701MB1272;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY1PR0701MB1272;23:7DIQRgU8LWDCISV/zUAwXgPzat97Sn8vBstHQTk?= =?us-ascii?Q?2rK2Fu6HrBcxc1Qi5+UtqY0RjpEYnhpe4/sMqfTTyS1J2+ghIe8BCLX8QY9+?= =?us-ascii?Q?DU4c3XWzXmmL59sWG9OGIw/vxh1O8j/L4AAGYRbUxwZNrhHzhvSxxpS9fw22?= =?us-ascii?Q?uwGS4LacCQJoTbfaLCdKh5VLXMDT6B8Ca9eaxTsGgusEjDhSz4ucBSAhuFCn?= =?us-ascii?Q?KlSzuz03DTuRWvGAqQPjVW/vZJjJ/5tkuzMuvM9i8kPsXQFLHOlxMKLfnrby?= =?us-ascii?Q?keyKbl5loeOVT4onxC56LRqMP2352EUP6Kf+wXGoGykK4mL4YgLrLpflfErG?= =?us-ascii?Q?WjiMD1YPIfu65XaKQFtgdhHD5dZ7dyWjUOW4UBOQ3+mZ0JxratBPB5rGNCo3?= =?us-ascii?Q?bc7MyWbsyd339m1tJeK8UMduFLNYhgRq41/kncXuMRuUxtvYZelk9baHMfLn?= =?us-ascii?Q?315AgbF+kSe39QX5p2JSbUmbgyPE5EAPsds6Gs8aGO2rWX1hogPbgKgOnaQr?= =?us-ascii?Q?EPCWGQumsT15UNJtp9pFM9bkNuJsuZYC8kD++M6DvbxDrOjEILXsbkDoz4iJ?= =?us-ascii?Q?DpiIzZld0Cw0I8YmQZmx3Rd+x2ouM9CaieZWpijtUtczNRN4sNCQfBAAvJRJ?= =?us-ascii?Q?W1NulS97XVekNRela69PbAruRZ9Cz0wHzH7m5vpgMT9DMd30JlweIvgzui58?= =?us-ascii?Q?qUgAnPPhTWOXkGu4J5IktcDeYky3DLcjlpXQP3zvMyxVxNorAQJD1Gk/+2Tk?= =?us-ascii?Q?V7GPUY2Pr6F+rsxPLdbDj1R9DNhFl6ll4W3eN1HA1e8gxjaoIT9sZQSl3+6l?= =?us-ascii?Q?CL/jjHg0hpPbsN9e/EqgatPdkbZbfLOzRYLJUT4cLfOWVpNCcNEMLJ/Fo+7A?= =?us-ascii?Q?IFRt/AP2TQafUh8aypkB4E0dJeFpOJrbprP4ZkKT1LIDSUVK7Q3Xyu0xyOuX?= =?us-ascii?Q?G5VtHDddNh0gMEfI9CMVNG4O3pcw6qwgqn3YqYsb9sQeeG/gjy6Ph02Vw0gn?= =?us-ascii?Q?r0KMNbBsY94kiigDZPNrqDy2bsHV7UFXJzSjST7KQheG460Fk0ZryHt0SmOY?= =?us-ascii?Q?dq12RfzlECKaLf2+mWesBptaGLslfW525pbQuj4XG5Qy//jIpvvbcqCBKA5u?= =?us-ascii?Q?YXPkzokHN/xUqOlXGt/D+nbVVONU7rwHPsWiKFr/HrJUJKM/+wA5JzUr/4if?= =?us-ascii?Q?EomWCm4zxONPsU9lbQ0VtkrXgyZ+h9F6shKfV1UAHwXeFDSXe17n0gcC7JD+?= =?us-ascii?Q?TGrJvOmKTpICLFw/GwS3MmGVzO+JQF+TCH3Ik9o8U6cYCcsjFyMKZKuMC7u/?= =?us-ascii?Q?uQEkx72Ge3nYu+Ngb9HQDSw9U/zscu/eryfHfZiumdHzi?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1272;6:FtiPe8MyOuUuD47MGG1OOYNsR81tvIFD4sCQnj33vCluQdEX6LpWfEFK7ewiqu6vScWAro5eLKH+huejrQ3E7TNodRgRCCe4LqkpSwuQMP7/pkV8kUjLmxQtkKjO6Y/eCiGpLzveXbVHdcPDF2MdAlh9wFQLdn4prbQdfZC1nlxjaV5WSU/skeNqbA9gWoPv+uMdhM7f172/kl5bNjydTYNP1Z1FYaUQDPxvjLjFpuobIUUNXQTdDsc8FBEPOPSo7cDbTzwixhX1xwvYs4ChynNR8K4dwprALkV2FSnGkorqrKrAkaK8BxwacIiNZlWiCgwm3M8zVyMBvDKmFujYWECWeW40N3rjpbM/zHFWMFqblpikXbOWJuSJdGR/L7h93oC9wB6EDLB25Fu/6l1LIFrWClmd7WKWFNlMkCiGCGENpjrQteCgA84RMwA4fpOYxVpURbn/eRMdYPPKElitGlYkbkumbPSIvaPkiQ8MsrT5u3CDTGhjShL8oZfDr8ozCiRMX3Gcfy3Q2aoI4Su/gw==;5:oSqp3Ral+cnO6GSnJa/1AxrJkT9KvnM1Rmo+XZn1WskK/6a2h5Zd6YLjdeXqR9RKFJoEiUtWHxjrcWKlq59exqIYtLEMxAoPHcqY7xTIVhkoCgwvlMETNHdbKIjV1lC/G4QYGGB7NUUVkkOCtNHevr1lXsYBmQ6UHptDqjz9CDI=;24:qkDErocP1DZNtbqhGiOmDmRiCK8P0KBXfSX6kDfyKDw2kd1THNZir/o+s3bwQtD+77157A0esSoxmq052wU9A+UlP5CBo5NYM0OWpuTsNNs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1272;7:F6y3ch6Jz9fE514WQRZSxwPD+y62KxE3iFBWWTZKhqhTNUcUwa8lmnwXYmcQGdlIRI0Ta4dw9a6JA1SWs+b+Cik1gpamzACvulEwXvS7ZfH8AWzxV2UzGz9ACpEa2jaz8hViRZfa2GAyXh/NLU4/9yGef9vKJHF41P25vkMtUqIaGep81slO2lbxz21k9VkbYabnf6DxFywQR6gyT0VeiizxFa7flXHACMwBcMQXsmxXORk+mJ2fCuvq2VJVoZ1NpccELP5j/tDb39xSP8txUVUK5zIpAfugVm+vfToS7tg0dvJo7PXjPgtkzDZHb5ZhRyCHTDbJLUmOGorVsA3H6w== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2017 21:32:27.5765 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1272 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 23, 2017 at 12:40:04PM -0500, Rob Landley wrote: > On 05/23/2017 03:01 AM, Yury Norov wrote: > > On Mon, May 22, 2017 at 09:07:54PM -0500, Rob Landley wrote: > >> Your userspace mounted a tmpfs over /dev when it couldn't mount a second > >> identical instance of devtmpfs over itself. If you had a static /dev in > >> initramfs but didn't configure _in_ devtmpfs to your kernel, your broken > >> error path would have taken that out too with a pointless tmpfs mount. > > > > CONFIG_DEVTMPFS_MOUNT is enabled on my machine, so I think your > > suggestion is correct. But I didn't do that specifically - I run > > almost default kernel based on Ubuntu 14.04 config and environment. > > I.E. ubuntu has a bug: they enabled CONFIG_DEVTMPFS_MOUNT and then > launchd an initramfs instead (which didn't do the automount they > requested so why request it), but if CONFIG_DEVTMPFS_MOUNT actually > starts working in initramfs they have an insane error path that breaks > the system, and does nothing _except_ break the system. > > > Grepping the kernel code shows that arc, arm, arm64, m86k, metag, > > mips, nios2, openrisc, parisc, powerpc, sh, tile, um, x86 and xetensa > > enable it by default. > > Most of which Ubuntu doesn't support, so none of them could trigger the > broken error path in ubuntu's init script. > > Wait, are you saying you're doing a "make defconfig" on x86-64 and > booting ubuntu from the result? (Or is this arm?) Is _that_ the config > you still haven't specified in this conversation? I thought you were > using the /boot/config-4.4.0-78-generic and friends ubuntu installs. > (Which yes, also switch this symbol on.) No, I'm not saying it. I run arm64 with the config attached below. > I can add a "default n" line to drivers/base/Kconfig if "make defconfig" > is what you're building from. (This symbol never specified a default in > the first place, so I dunno which way it falls, but it's repeated in a > gazillion defconfig files and not present in others... meaning I still > dunno which way the default goes. When I do a "make defconfig" it uses > arch/x86/configs/x86_64_defconfig because the kernel has multiple > codepaths to accomplish the same thing. I'm not sure the built-in > "default y" lines are used at all anymore? What a mess...) > > But again, I'm just guessing what config you're using because you still > haven't _said_. I'm still trying to guess what you're doing when you hit > Ubuntu's bug. > > > So it means for me that (at least) users why run > > Ubuntu 14.04 will have bricked system one day after updating the > > kernel. > > Unless when they build their new kernel they open up menuconfig and > switch this symbol off. Which can't be done because...? > > Or you could add the devtmpfs.mount=0 argument to your kernel command > line, as documented in the CONFIG_DEVTMPFS_MOUNT menuconfig help text. > > The kernel already provides multiple workarounds for Ubuntu's bug, and > the issue only hits people who are manually building a new kernel from > source. If ubuntu provides a new kernel, I assume they'll tweak their > config _and_ fix their initramfs error path (which is just plain wrong). > > > If you say that currently CONFIG_DEVTMPFS_MOUNT is ignored by kernel, > > It's not _me_ saying it, it's the kernel doing it. The patch is > conceptually a straightforward fix on the kernel side to make it _not_ > ignore that symbol in that context. > > > I think you cannot relay on it anymore because people may have it > > enabled or disabled randomly. > > I expected configs would have it randomly set, but the bug here is a > broken error path that does something actively harmful rather than going > "oh, we got a static /dev from somewhere, let's just leave it alone". > This error path goes out of its way to blank the contents of /dev by > mounting an empty tmpfs over it and leaving it empty, and then > complaining that /dev is blank _because_it_blanked_it_. > > If Ubuntu meant to intentionally halt the proceedings the script could > have done that explicitly. What did the author of that error path think > would happen, exactly? > > > So the proper way is to remove broken > > config option and introduce new one. BTW, I see it is used once in > > drivers/base/devtmpfs.c. > > How does removing the broken config option (or renaming it to > CONFIG_DEFTMPFS_UBUNTU_IS_BROKEN) _not_ impact systems that were > previously happily using it in the contexts where it already worked? > > If it's too much to ask people to switch it off when it was previously > on (but shouldn't have been), how is asking them to manually switch it > back on when it was previously on and needs to stay on better? (And if > you arrange it so "make oldconfig" migrates the old symbol to the new > one automatically, how would that work around the broken error path in > ubuntu's initramfs script? The rename becomes a NOP.) > > If you're saying it should default to "n" I can send a patch. If you > want me to tweak every arch/*/configs file that redundantly includes the > same darn symbol, I can do that too. (Makes the patch big but it's just > a sed invocation to do it.) > > >> By the way, _why_ are you mounting a tmpfs over /dev on _initramfs_? > >> That can already be tmpfs. (Commits 137fdcc18a59 through 6e19eded3684.) > > > > Have no idea. This is how default Ubuntu works. > > Can you switch this symbol off in your kernel config and see if it boots > then? (Or are you using some sort of ubuntu kernel build tool that can > build -rc2 but not let you change config symbols? I still have no idea > how you're building this because you haven't said.) > > I don't know how the kernel higher-ups want to deal with this because > it's more a political issue than a technical one. Enabling > DEVTMPFS_MOUNT for initramfs triggers a pair of bugs in Ubuntu: their > config was wrong and their error checking was wrong. Fixing _either_ > would let the system boot, and there's also the command line workaround. > The issue only affects people who manually install new kernels on an old > system using the old (broken) config verbatim, and the simplest fix is > to flip the config symbol in menuconfig. > > If you're building a defconfig the kernel supplies, we can edit that to > work around Ubuntu's bug. If you're building from a config ubuntu > supplies, _they_ have to edit it and then maybe bumping it a release > until Ubuntu can fix its breakage sounds reasonable. But so does letting > people manually adjust their configs when they manually upgrade the > kernel outside the normal ubuntu kernel uprade process. (When open > source breaks, you get to keep the pieces.) > > > Yury > > Rob It was 2 years ago, but AFAIR I took the Ubuntu image here: http://cdimage.ubuntu.com/ubuntu-base/releases/14.04.1/release/ubuntu-base-14.04.1-core-arm64.tar.gz Kernel config is attached. I build the kernel with simple 'make'. Yury