Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp936709ybp; Thu, 17 Oct 2019 05:52:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqzP2mASdQx0QOFSVw0zLvxYlZb4rtoAzJ34OkXO8NLUURDCctEwZhXEh8BhobDtGCxFZfVn X-Received: by 2002:a17:906:90c2:: with SMTP id v2mr3259120ejw.98.1571316765326; Thu, 17 Oct 2019 05:52:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571316765; cv=none; d=google.com; s=arc-20160816; b=k2DCjNCOVKkIwSYqyTV7hqd3SSolwNk3Jm4uTp8trlX8+gMMJTT92v3Vw9fErBTamx PVuyxu+JsvcdOgwxT93y1O4bjuHAVVZHR9S9e7bSU37aCO3X6gGtUdeW6GZgJbdGW6Cj SSLIOZutHaKolHfeV7bEp/KEtmz3hskxhknydjzG+gg2fItV/bZXCmggA3FCdDWKbWco yrkyjWubD7KLiIN64esDulp3m0yeXnLCMmYZy2PdUfQZoAOCgYtsfKtgPLtOfawiOzOq hmfam9Ok0JfldEyMhvVCCt79ucgcDaPqH8U5MJU2AZHs3o7xidmL64RTO/SFqj5Wp7kk XG1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=cgVJjPJNYamw8C05i/NoGR/EfXejQ0fsqwOBU0L1tVc=; b=WCZI8eBWR0K9PhCRdrrrvQDSI+21ujBPZecPte4CJ8zb45DBLt5+hQlhKtXjf+Hw8I Oa1eB3hkIbFuX5U9A8L2qffUO6Av51kjxKvxtuVwmA/DcIcqybHmuS5u7W94rPp9ovRV 265XSLRXiPblVRWRnFkXC338+gJf5dxAiZ6QTbuxoYXL+I9p3Pi4iw+ionZsRfBrB8aV GLfkNhXzfSj8eFO4Wob7rJ1pBffAkfpZjQwdWS4DeFh/e3KNaPv/IXJQd+WgTfm6eSOf EsOwMSqyuW3L4kaRVE51WokXWQi7FXDfNjOWuIiM/9J9b2OsGDJgUxfjaygfvCvvWe/u P/Zw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=mVmNBw1z; 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 26si1485810ejl.292.2019.10.17.05.52.22; Thu, 17 Oct 2019 05:52:45 -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=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=mVmNBw1z; 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 S2403916AbfJPTKB (ORCPT + 99 others); Wed, 16 Oct 2019 15:10:01 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:40899 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732084AbfJPTKA (ORCPT ); Wed, 16 Oct 2019 15:10:00 -0400 Received: by mail-pg1-f194.google.com with SMTP id e13so6636618pga.7 for ; Wed, 16 Oct 2019 12:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cgVJjPJNYamw8C05i/NoGR/EfXejQ0fsqwOBU0L1tVc=; b=mVmNBw1zzsT8UnD7F+zm4ue1nPrPLdoukhl9nz8Gx0oTIcLUPh7jc9mteqQBvLPcb5 O/kkzoQwEddeZ4PfA9y2coE4Wx6g7D0mCU9J+qMYphaJgKOmCoV0+cZP4Juu0IuJDJGg Uuke6SwlVHgxjG6jOZMj59wL/GKXG6rwUYvdAiAibtkgyMtkev7TCVeCc7jy3HMfDhf2 thMt5tCDvp44R9BkONqdLApHQmpYZnpjo6VKiHYg+/9/vivgaPlYS5PE46rik62YYJPg g9KhwqqBqo0z4FyLdWSqv4RpXHi6idpHE6AaeLN18OvB/PK6PGiZrrlAD9Uvc+jZLEIo Kgwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cgVJjPJNYamw8C05i/NoGR/EfXejQ0fsqwOBU0L1tVc=; b=Xobs6Qx2ARhf7r5fXYrJrM73rf81MbKxZpOOdRjPfgEcE50yhSUVHYLglbpxoNhvux 8esIPIVrz+6kH/86/Oj6+cd/hfd5Vo+myPLwP0d/vsjAmhoI8gYmVw8i9B3dqORAVjLl 5Nu2CdOYuu7NXCsBKGdtTIznzBpkPpeClNm9iDa4nQI74IS8RxjhwmuDT4CB9doE1SY4 fA1ILNc+5uB7IOitoVR7Wh6zfc5x9AM1EyKykV5+0AT54S+1DM8OjE/rMkXJw+Now7SC qoTSlpF+jGm5FNhLQAkXIr6RNFdUzFFfJ73pPF8YmTzc+d9P8of4oMG9/cIlQ71+8Y5F /gTQ== X-Gm-Message-State: APjAAAWDQS2EbXxEP6UDjId3Tmf9sjpIX/SwOB4yditUv/A2KonWXeXa 974U+UjLBUO4ETeUEAKLJyYFgA1/69WJ2g== X-Received: by 2002:a17:90a:8c86:: with SMTP id b6mr7079207pjo.129.1571252997537; Wed, 16 Oct 2019 12:09:57 -0700 (PDT) Received: from ?IPv6:2620:10d:c081:1132::116d? ([2620:10d:c090:180::88e5]) by smtp.gmail.com with ESMTPSA id s3sm3466094pjq.32.2019.10.16.12.09.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Oct 2019 12:09:55 -0700 (PDT) Subject: Re: [PATCH] libata: Ensure ata_port probe has completed before detach To: John Garry Cc: linux-ide@vger.kernel.org, linuxarm@huawei.com, linux-kernel@vger.kernel.org References: <1571221192-216909-1-git-send-email-john.garry@huawei.com> From: Jens Axboe Message-ID: Date: Wed, 16 Oct 2019 13:09:54 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1571221192-216909-1-git-send-email-john.garry@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/16/19 4:19 AM, John Garry wrote: > With CONFIG_DEBUG_TEST_DRIVER_REMOVE set, we may find the following WARN: > > [ 23.452574] ------------[ cut here ]------------ > [ 23.457190] WARNING: CPU: 59 PID: 1 at drivers/ata/libata-core.c:6676 ata_host_detach+0x15c/0x168 > [ 23.466047] Modules linked in: > [ 23.469092] CPU: 59 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00010-g5b83fd27752b-dirty #296 > [ 23.477776] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019 > [ 23.486286] pstate: a0c00009 (NzCv daif +PAN +UAO) > [ 23.491065] pc : ata_host_detach+0x15c/0x168 > [ 23.495322] lr : ata_host_detach+0x88/0x168 > [ 23.499491] sp : ffff800011cabb50 > [ 23.502792] x29: ffff800011cabb50 x28: 0000000000000007 > [ 23.508091] x27: ffff80001137f068 x26: ffff8000112c0c28 > [ 23.513390] x25: 0000000000003848 x24: ffff0023ea185300 > [ 23.518689] x23: 0000000000000001 x22: 00000000000014c0 > [ 23.523987] x21: 0000000000013740 x20: ffff0023bdc20000 > [ 23.529286] x19: 0000000000000000 x18: 0000000000000004 > [ 23.534584] x17: 0000000000000001 x16: 00000000000000f0 > [ 23.539883] x15: ffff0023eac13790 x14: ffff0023eb76c408 > [ 23.545181] x13: 0000000000000000 x12: ffff0023eac13790 > [ 23.550480] x11: ffff0023eb76c228 x10: 0000000000000000 > [ 23.555779] x9 : ffff0023eac13798 x8 : 0000000040000000 > [ 23.561077] x7 : 0000000000000002 x6 : 0000000000000001 > [ 23.566376] x5 : 0000000000000002 x4 : 0000000000000000 > [ 23.571674] x3 : ffff0023bf08a0bc x2 : 0000000000000000 > [ 23.576972] x1 : 3099674201f72700 x0 : 0000000000400284 > [ 23.582272] Call trace: > [ 23.584706] ata_host_detach+0x15c/0x168 > [ 23.588616] ata_pci_remove_one+0x10/0x18 > [ 23.592615] ahci_remove_one+0x20/0x40 > [ 23.596356] pci_device_remove+0x3c/0xe0 > [ 23.600267] really_probe+0xdc/0x3e0 > [ 23.603830] driver_probe_device+0x58/0x100 > [ 23.608000] device_driver_attach+0x6c/0x90 > [ 23.612169] __driver_attach+0x84/0xc8 > [ 23.615908] bus_for_each_dev+0x74/0xc8 > [ 23.619730] driver_attach+0x20/0x28 > [ 23.623292] bus_add_driver+0x148/0x1f0 > [ 23.627115] driver_register+0x60/0x110 > [ 23.630938] __pci_register_driver+0x40/0x48 > [ 23.635199] ahci_pci_driver_init+0x20/0x28 > [ 23.639372] do_one_initcall+0x5c/0x1b0 > [ 23.643199] kernel_init_freeable+0x1a4/0x24c > [ 23.647546] kernel_init+0x10/0x108 > [ 23.651023] ret_from_fork+0x10/0x18 > [ 23.654590] ---[ end trace 634a14b675b71c13 ]--- > > With KASAN also enabled, we may also get many use-after-free reports. > > The issue is that when CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, we may > attempt to detach the ata_port before it has been probed. > > This is because the ata_ports are async probed, meaning that there is no > guarantee that the ata_port has probed prior to detach. When the ata_port > does probe in this scenario, we get all sorts of issues as the detach may > have already happened. > > Fix by ensuring synchronisation with async_synchronize_full(). We could > alternatively use the cookie returned from the ata_port probe > async_schedule() call, but that means managing the cookie, so more > complicated. > > Signed-off-by: John Garry > --- > Note: This has only been boot tested and manual driver remove/add. > My system has no disk attached to the ahci host. > > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c > index 28c492be0a57..74c9b3032d46 100644 > --- a/drivers/ata/libata-core.c > +++ b/drivers/ata/libata-core.c > @@ -6708,6 +6708,9 @@ void ata_host_detach(struct ata_host *host) > { > int i; > > + /* Ensure ata_port probe has completed */ > + async_synchronize_full(); > + > for (i = 0; i < host->n_ports; i++) > ata_port_detach(host->ports[i]); > > Nice debugging, and the fix looks appropriate to me. I don't think there's any point in trying to individually synchronize cookies. I'll let this simmer on the list for a day or two to let other folks take a look at it, before queuing it up. -- Jens Axboe