From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755557AbcFQPLu (ORCPT ); Fri, 17 Jun 2016 11:11:50 -0400 Received: from mail-db3on0135.outbound.protection.outlook.com ([157.55.234.135]:44601 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753222AbcFQPLs (ORCPT ); Fri, 17 Jun 2016 11:11:48 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=aryabinin@virtuozzo.com; Subject: Re: [PATCH v3] mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB To: Alexander Potapenko References: <1466004364-57279-1-git-send-email-glider@google.com> <5761873A.2020104@virtuozzo.com> CC: Andrey Konovalov , Christoph Lameter , Dmitriy Vyukov , Andrew Morton , Steven Rostedt , Joonsoo Kim , Joonsoo Kim , Kostya Serebryany , Kuthonuzo Luruo , kasan-dev , Linux Memory Management List , LKML From: Andrey Ryabinin Message-ID: <57641364.5000001@virtuozzo.com> Date: Fri, 17 Jun 2016 18:12:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: AM3PR03CA029.eurprd03.prod.outlook.com (10.141.191.157) To VI1PR0801MB1310.eurprd08.prod.outlook.com (10.167.197.148) X-MS-Office365-Filtering-Correlation-Id: 2fd59d6d-f962-4d5b-d7dc-08d396c1b1b9 X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1310;2:Zyz9IztD7WvCCx5pqnVuGcIECv7GCXHznzC0yTohsgHTb6QJeRnAleD8GLiH1HRvfKv70Z49EbV4LMaBEUxQPAPdsgEpBMJNtZHygcDe/Xx3m8irMisQMy6JpamQ3LT1XUAunxNhnW0/OKRbVvqsMIwU8rg6vdNC3Esn8BYzUBl0uBvWkdKjTX62Ltz5tIPE;3:h7WSyVXc6Xke1HOaxEzXdIyKzBM6dhdMyzu4lniQVPG3+cFMXa8/CxWBwPQFlrftDJ2y/+mI1mHJ5f86I1CjKdIrAZL9xepI/bECS7QL6EQ/31e+1HncMUyz3xCtS6B8;25:U9YuvD836FNx74Zg5rnAlLZE/swmmhnC6StcjVNIl6W9S1sye1pisKhQWsfpDBbYdbpHHHZFzC63UwkFeJ1laKcgBuT0bYbjKpa7U4R4qGJQP0h/QDCD0r13jmhstwXKUBfRqZwxQPMv/KDCUKg23a9HbpMLON6YNZcY1+eDHoR56Zid3K2s3Oobqoox1GnMwkHjqlH8RKP8+HhT6aDJ+AXroMQd+W89zNHK+BOl+/gOkstpX97XgeWeSgNjuebrGh7xKwN1sIyEK5qpzrYUoQFGpC66LBxGn+co5GgwiSZi29hlLPDM1I2TCX567TVHNYbmnKzWiCrd4IDoldO8cJynbLs4CAJgWW5tB8Rdh9K32QdFn8RCFNXJF98Rl4B+whoxOeVKNsIhtHeoSnufY61mKx7nM4Svd53jbPvWjX8= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1310; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046);SRVR:VI1PR0801MB1310;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1310; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1310;4:NKHKZy7nQzml5gxq/0RsdojpGqLem1qeN1Aq1p2RCi6FnykR8B0Z2R4mYMXLXisiNvuTpr6BJux7LfG1yLSfDozqDQe8E60xx7+Ch+bXxkj5cDJUOSyt7curZZLo2yNE83sAsilUYDCfay7hWZGIPwZpiHGb9zj4Tl4350BkhLoEhwtEWglf+braGiP0i8QqlBDffkA3597/Nh8U5fOCfS4k18WSQEksqojxyDylALmKHwQ7cxdpbU8qSc4GGtjq1phjGcc+C5J7Wy0+6a6Dns/T6xkiUGEWwTigXHNkxHqtC5EF2oI+n25hFOqwu20hGDXXcEsth2GPTMhswFHvIPe5PdlrM+eti2cRQkTzuxfU8/c+FkYLTJrRTXoUXaOeUsyVvYPDXBwBFZDNos3UxnvOAbTqLKz64lOGWYXpxWA= X-Forefront-PRVS: 09760A0505 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(377454003)(24454002)(189002)(117636001)(122286003)(97736004)(4001350100001)(50466002)(4326007)(92566002)(50986999)(83506001)(68736007)(110136002)(2950100001)(5004730100002)(42186005)(19580405001)(19580395003)(99136001)(36756003)(5008740100001)(77096005)(586003)(81166006)(59896002)(105586002)(2906002)(64126003)(101416001)(189998001)(106356001)(47776003)(81156014)(23676002)(65956001)(3846002)(66066001)(65806001)(6116002)(65816999)(86362001)(8676002)(87266999)(54356999)(230700001)(76176999)(62816006);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0801MB1310;H:[10.30.19.223];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;CAT:NONE;LANG:en;CAT:NONE; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA4MDFNQjEzMTA7MjM6ZmEzQTNwY0hkUGxubVZlMnlYd2JuemJV?= =?utf-8?B?WllkNDF5eVJpRm5PazR1M1haTmJ5QWI1QzBURjFNQVpVMkJEbmlQWnQwUmll?= =?utf-8?B?SEFaRjNDSmx2T3MvdVhkU1VrT1lDZjYxWjgvQVprZDgwc3NqQzhZMVZ4ME9D?= =?utf-8?B?Y0o4UkRkcENLT0xLMzVKQ3FpSHNkbGJKNGFXQVMvZllnUWdseW1vTm9VUFg5?= =?utf-8?B?VlpIQjJ0V2M4SDRiZncxSTdiWlpwc0ZTQmwyWm5DVTdQM1NRQ1EzVkY4cjVa?= =?utf-8?B?R1Z3NzJITW13bFhBdjJ5VVZNQlhOOHBzeGk4ZWRKb3pESU9iS1NkaVVoVDlu?= =?utf-8?B?YW9xaFo4b1paWGdibXpNbDVhMDFtdTB6eWYrTjl5OHRNTy9wc0F0Z1Y4RVF6?= =?utf-8?B?UVhmdFZsS1YzK29YSVpwR3VaYWpWbW5Db1pLV2VvTFJ3Y3NiRkt2ZURNTVBT?= =?utf-8?B?eEVQRGYyRldIeW1ZUDB6Z0VlMlBFQThlKzBKd29KTXNpeEUyVjYzYzE2eXhh?= =?utf-8?B?MWY0NE1tdUVaOENqR3NiUmZuV1ZaRHhyc0RPVW5zQmZwMWhVdVVVSS9KYlhv?= =?utf-8?B?L1ErNXdLY3hQTWh0WlNOc3B6by96OHpBOTdhMVhKNTZUSzVIa2RoY0ROamc0?= =?utf-8?B?M3B4YVAxVU84aXhpdWcrZk84Y2FxNHI1ZGRKUnFLUy80L3dudVdZZkh0ZjVZ?= =?utf-8?B?MU5GR0t1MXlPUTlOSXVxUUJNQXdQMnIzZnErN0JRaWNvSFlVL29Tdy9BOFI5?= =?utf-8?B?MVRZbUJzK3BQVFF6TmFLR0VsQXFKOHQyMUZvZmFIOVpCVjM5ZEw5MG5EOVhx?= =?utf-8?B?blpVem1Rc2hHMzBYMmdhSHYvY0ZjbkxyQ2R4TGFDMjR3UkhrOFVaSUpwVVNy?= =?utf-8?B?NWpLWDNtb2hlNEZpTEpCcUp4bkZQWStaODdFRWxNZXhPdmthMldNZS9BcSs5?= =?utf-8?B?clVIN3RHbHdWQVpnRHk2cHR0UHd2MjFIaFVDYTRyZUZVVVUwbWJRZDJUTG9B?= =?utf-8?B?aENldGN4NmpqeWhRR2NiT3hXVEw0YXlaSXhXVndSSlFubUNxTnF6am5PR05j?= =?utf-8?B?OC9HbFRZUnVPQmM5WVF5cGRlWWM3N1ZJVTczbUZSd2NqUTFoQWZTMUNUUHR2?= =?utf-8?B?aUNPbkdLT3R5bG9vaWwydG91TU9OQXREc3UyZnZKenRxSmJpbVg1NXpHakJQ?= =?utf-8?B?VENTN05ndkJqMkpiNmNxM3c3N0RUeHlhRHJsNkxvWUlOTEFWVW5tTUY0MUV2?= =?utf-8?B?UENsVnpkcS9lbW9OUEdtdFNacExJeWkweU9mTVcxcGRXZXJod1pJL0Y0UkNk?= =?utf-8?B?WlIzTnRDZFp2V3U3U0lmdzFXSE5UUmVvWnR2ckQwODRYNWZYOW13aVBTS0dz?= =?utf-8?B?NUU4c2pTR1liTWFZQkkrYklZVlJ1bSszVlFVaWxnTWV2U0FlcVNyOVl3eCtm?= =?utf-8?B?eGN5ME5oL3FpZVRmWHFvTTIyUlkvaE9pWHl6TEdKZ2lFK2Q1SkxLellKbFRW?= =?utf-8?B?L1V3ekdMc2IxVHRJZ3liZERnRjZpeC9HQ1dZT2xQMFk4WnhDZVgzZzgveFd4?= =?utf-8?B?S3YwSlZtN1k1ZEZPRkNjakNrM1UxMVhDNnVPU09TS0dHeUtzbmg0MW9PbW40?= =?utf-8?B?ZXJPTWlPMjdOc3h0R3p2MC9lWHA5YXlUcS85Si85RmMrNFovMlVla2ozcGR5?= =?utf-8?B?Q0FRcFBHT0RuNXhybmNMbHd1R05KOVpEOWFHbVJLY01nU09BaDdlcWZtVVFa?= =?utf-8?B?TklicEJoNmNwQklwVWJmZ3V4TXEwUWFoenF5WGwrZm9Wem5VV3YvNnNnUi9G?= =?utf-8?Q?jHR+47MR3TqlZoZ?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1310;6:uZP4AU4koZBpPwBsTqfjgywOc3weEaORUmcGCEKAzayWO/Y3KHAGSbanwTqGKB2qGfnjZ1NvRzFx2OSCij/NT7tJvTAdTYP7Vhc1gJvb1MAurcEln2cHIJK5tImjFnEAMg9eqqhg5UQ+CekAA9z1cuTJm7G3wtkCdzC4JMfV23WpHquoPREr8c5Mrz2nVaHOKOAU5SBs18TeJndyymYWRCIaYtAEkCdhXgG3UyvPNbgVc5CH+R+mozF8r19U3ob2+CdgET0hks1yRMXZ2iaPfBoGB7kHtW1tZyh5lC0qpibHXM1XdbhhB6NWfkKqDF6g;5:KxQ/4l0y7raai4j/Bsz2UcO48PHA6WuqmEdOxiSASucgbaB1/rySfYX3ESkJF88UpeR1FgArBPocCLnX6jyZ9jPq4Xx4xoQ4qLExHVS0mdcjem+gGHGeZHPtPi+jkKysUo+nnLAW6uGR4yTkVgSFPw==;24:1ov7ulKRkNnwJnHrVESxxKLq+y4hpY6hs/lD6M7eAogC7CZ/UcGCrBjErp3zIXnMGopF3CoLep9CMoWiZi1/oarx+TO46gojkDN2fpSZcgk=;7:xct9Gm+qTgg8b4VGp+X8Ak+VJpToOZ+ZFeaEwUAMs2yg0ZiDidDjiChhCGW36sfhwcrTpR4UMM2enrc73fPo8YBEubSwM/f7DIosruaItBz5fS4pdnEoReKqcq9mXDZT+ChRtp4hkMvzdO3B3m3zHnItkHxuRlVEo7X3THQVr4+GKwTeeBccxyhssO2tx4OzhyJGpXQrqHc8pLPOrkCaJw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1310;20:1Yl6FhvS5/rljfYDrJ7PAWFV1gKQWBpzFYCLs+5vpSeJcQCfgqyyRVHpIWktyg67aQcVxrxnGDu7APit6otG4H2rvw/qbhFTwwFf+edE8ilJ4WwElpQXN6mqJnfTet51TnbEmpqWAeVOvIAWmCom/YGWnpjnLXIrYa/aOhTXvvI= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2016 15:11:43.1212 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1310 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/17/2016 05:27 PM, Alexander Potapenko wrote: > On Wed, Jun 15, 2016 at 6:50 PM, Andrey Ryabinin > wrote: >> >> >> On 06/15/2016 06:26 PM, Alexander Potapenko wrote: >>> For KASAN builds: >>> - switch SLUB allocator to using stackdepot instead of storing the >>> allocation/deallocation stacks in the objects; >>> - define SLAB_RED_ZONE, SLAB_POISON, SLAB_STORE_USER to zero, >>> effectively disabling these debug features, as they're redundant in >>> the presence of KASAN; >> >> So, why we forbid these? If user wants to set these, why not? If you don't want it, just don't turn them on, that's it. > SLAB_RED_ZONE simply doesn't work with KASAN. Why? This sounds like a bug. > With additional efforts it may work, but I don't think we really need > that. Extra red zones will just bloat the heap, and won't give any > interesting signal except "someone corrupted this object from > non-instrumented code". > SLAB_POISON doesn't crash on simple tests, but I am not sure there are > no corner cases which I haven't checked, so I thought it's safer to > disable it. > As I said before, we can make SLAB_STORE_USER use stackdepot in a > later CL, thus we disable it now. > This doesn't explain why we need this. What's the problem you are trying to solve by this? And why it is ok to silently ignore user requests? You think that these options are redundant, I get it. Well, then just don't turn them on. But, when a user requests for something, he expects that such request will be fulfilled, not just ignored. >> And sometimes POISON/REDZONE might be actually useful. KASAN doesn't catch everything, >> e.g. corruption may happen in assembly code, or DMA by some device. >> >>