From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752387AbdLNNR0 (ORCPT ); Thu, 14 Dec 2017 08:17:26 -0500 Received: from upbd19pa07.eemsg.mail.mil ([214.24.27.82]:55275 "EHLO upbd19pa07.eemsg.mail.mil" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751999AbdLNNRY (ORCPT ); Thu, 14 Dec 2017 08:17:24 -0500 X-Greylist: delayed 602 seconds by postgrey-1.27 at vger.kernel.org; Thu, 14 Dec 2017 08:17:23 EST X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="7118384" IronPort-PHdr: =?us-ascii?q?9a23=3A1dSLnh3/riiekLZZsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?sesVIvTxwZ3uMQTl6Ol3ixeRBMOHs6sC07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9JDffxhEiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD?= =?us-ascii?q?8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfVwZKPdec4RS3RHUMhfSidNBpqw?= =?us-ascii?q?Y5UTA+YEO+tTsovzqEYUrRamBgeiGePhxCFGiHD006061PguHwbJ0wIvBN8OrH?= =?us-ascii?q?fZoc/pOKoITey4zq/FxijDYfNM3jf97ZDFfA09of6SRbJwcdTeyU8yHA3Yi1Wf?= =?us-ascii?q?s4jlPzeL2eUNrmOW6PFgWv+0i2M8twFwoiSgxscrioXTgIIV0UrL+T92wIYyO9?= =?us-ascii?q?21UUh2asOnHptIryyWKoR7T8w4T2xopSo20KMKtJGlcCQQ1ZgqwQPUZeadfIiS?= =?us-ascii?q?+B3jUf6cITJ/hH14Zr2ynw2y8U28yu3kUcm0zUpKojJFktbSsnAN0ATe6tSdRf?= =?us-ascii?q?tn/0ehxC2P2xrP6uBEPU80la3bJ4QnwrEsjZocrV7PHir3mEXylKOWd0Mk9fa0?= =?us-ascii?q?6+n/f7nrqZCRO5V0hw3jKKgihMOyDfoiPgQTR2Sb/P6z1Lzn/U33WrVKifg2n7?= =?us-ascii?q?HCsJ/HPsQWvbK5Ag9J3YYj7BazFTGm0M8CknUdI1JFfwyHg5DzO17SOPD4Eeu/?= =?us-ascii?q?g1O0nTdvxvDGOKDhA5rUInjAjrjhZ7B95FBYyAco09Bf6IxbCqsbLPLwREDxrt?= =?us-ascii?q?rYAQE9MwCuxObnEtp93JsEWW2TGq+ZLL/SsViQ6+I3J+mDfpIVuCrnK/c+/fHj?= =?us-ascii?q?lmU5lkEAcqmpx5QXdGq0EehhI0WceXDsmMsOEX8WvgoiS+znkFmCUSBJZ3moRK?= =?us-ascii?q?0z+C00BZm8DYjdW4+tgKaO3DuhEpJKYWBGD0iGEW30eIWcR/cMdCWSL9d8nT0K?= =?us-ascii?q?T7ehT5Qh1RG1uQ/g1bVoM+rU9TcEtZ75yNd14OjTnwko9TNoF8Sdz32NT2Zsk2?= =?us-ascii?q?wWXz85xrp/oU1mylqYyah3meZYFd1I5/NRVgc1L4LTwPJgB9D1QALBcc+DSEy6?= =?us-ascii?q?TdW+HTExUtUxzscWY0lnBtWiigvO3zKwDL8Ik7yHHZk08qXb33jrOclx0WrJ1K?= =?us-ascii?q?4kj1M+WMtAKXWmhrJj9wjUH4PIk1+Wl6CldaQe3S7N9GCDzWyBvE1FSwNwUbjF?= =?us-ascii?q?UmoRZ0TIrNT1/F/NT7irCedvDgwU2MeEJalLatrvgh0SVf7lN9bfY2W3lD6YBQ?= =?us-ascii?q?uB2b6NKoHtfjNZlG/FAVUAuxga4HLDMA85HCrnqGXbRnQ6DVvyZ2v0+PR67Xa8?= =?us-ascii?q?SVU5iQqNahsln/C44hcPhOe0U/oJ36kcvC4qpnNzBln3l4bbE9OaphFJZKxGYM?= =?us-ascii?q?gl5F5M2CTerQMretTqNK1mh1gDYyxrrkju0FNxEYwGns805jt+1wd2KKSFwHtd?= =?us-ascii?q?ZjiY2tb2IbSRJW7sqlTnR6fQ21zamPTexa4L8/Rw/1n8tQWyFmI4/nln2sUT2H?= =?us-ascii?q?yZsNGCKBcRWIm5bFw+/RVx7+XefDM07Y7f/WdhPam9rnnJ3Nd/QKMdxwq6N/NW?= =?us-ascii?q?Lb+eHgb5E4VOH8ynNfAwkVGBdB8IPOlOsqUzOpX1WeGB3fuQIOt4nD+gxV9C6Y?= =?us-ascii?q?R531PEozFwUcbUzp0FxLeexQLBWDDi2gTy+vvrkJxJMGlBVlG0zjLpUcsIPPV/?= X-IPAS-Result: =?us-ascii?q?A2DTBAAodjJa/wHyM5BdGQEBAQEBAQEBAQEBAQcBAQEBAYM?= =?us-ascii?q?SLIElNYQpmSdGBoExkiCHC4VFAoR2QxQBAQEBAQEBAQEBaihCDgGBZyQBgkcBB?= =?us-ascii?q?SMPAUYQCxgCAh8HAgJXBgEth2+CEw2pJYInhBYBAYZIAQEBAQYBAQEBASOBD4J?= =?us-ascii?q?Rgg6BDoIxgyuIMoJjBZMpj3yVKpNsSJdgNiKBTioIAhgIIQ86giqCUR0ZgRMBW?= =?us-ascii?q?COEIoZgAQEB?= Message-ID: <1513256850.18008.1.camel@tycho.nsa.gov> Subject: Re: [BUG]kernel softlockup due to sidtab_search_context run for long time because of too many sidtab context node From: Stephen Smalley To: yangjihong , "paul@paul-moore.com" , "eparis@parisplace.org" , "selinux@tycho.nsa.gov" , Daniel J Walsh , Lukas Vrabec , Petr Lautrbach Cc: "linux-kernel@vger.kernel.org" Date: Thu, 14 Dec 2017 08:07:30 -0500 In-Reply-To: <1BC3DBD98AD61A4A9B2569BC1C0B4437D5D2AF@DGGEMM506-MBS.china.huawei.com> References: <1BC3DBD98AD61A4A9B2569BC1C0B4437D5D1F3@DGGEMM506-MBS.china.huawei.com> <1513178296.19161.8.camel@tycho.nsa.gov> <1BC3DBD98AD61A4A9B2569BC1C0B4437D5D2AF@DGGEMM506-MBS.china.huawei.com> Organization: National Security Agency Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-12-14 at 03:19 +0000, yangjihong wrote: > Hello, > > >  So, does docker just keep allocating a unique category set for > > every new container, never reusing them even if the container is > > destroyed?  > >  That would be a bug in docker IMHO.  Or are you creating an > > unbounded number of containers and never destroying the older ones? > > I creat a containers, then destroy it,  and create second one, > destroy it....... > When docker created, it will mount overlay fs, because every > containers has different selinux context, so a new sidtab node is > generated and insert into the sidtab list   > When docker destroyed, it will umount overlay fs, but umount > operation does not seem relevant to "delete the node" hooks function, > resulting in longer and longer sidtab list > I think when umount, its selinux context will never reuse, so sidtab > node is useless, it is best to delete i The "selinux context will never reuse" is IMHO a bug in docker; if you truly destroy the container (i.e. don't just stop its execution, but delete it entirely), then the context should be reusable. > >  sidtab_search_context() could no doubt be optimized for the > > negative case; there was an earlier optimization for the positive > > case by adding a cache to sidtab_context_to_sid() prior to calling > > it.  It's a reverse lookup in the sidtab. > > I think add cache may be not very userful, because every containers > has different selinux context, so when one docker created, it will > search the whole sidtab list, until compare the last node, When a new > node arrives, it is always necessary to compare all the nodes first, > and then insert.  > All as long as the list does not delete the node, list will always > increase, and search time will longer and longer, eventually leading > to softlockup > > > Is there any solution to this problem? On the kernel side, we could certainly implement a reverse lookup hash table. And there could be a faster way to quickly check whether a given category set has ever been used if we wanted to specialize in that manner. But that won't fix the fact that docker is allocating unbounded security contexts.