Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3279675ybl; Sun, 11 Aug 2019 20:00:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqzKGA0iNmCqvBIsuW5J67aXLmxdFIdYoSL5sU0GwsGIURGx9y4PdKSxn4E2uUhe3wg2Tant X-Received: by 2002:aa7:8106:: with SMTP id b6mr33721458pfi.5.1565578838055; Sun, 11 Aug 2019 20:00:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565578838; cv=none; d=google.com; s=arc-20160816; b=pUSMhGzONr0RaQSDsOxY8Koa+hehej5aLT06GnLzGfMibPA5DEpw/4dL++9x+kj7J2 qOS9AUVvL0DduCNQLBx8pILLIwWXNm689+MhqbM19pA+lIeFLtYnUXMFquWnTMQYfoA9 /Mlc4RjouJnsHal9ZA9We/Z3xBe3wwQPdmS5lDLKTygPqadt0af8hdQy2Bszj4RuWMyV W5MsdhnlWpx3lefkot4iasdCNdODI4+2J4U3dHCf8ZGfr1vPS2hjSOcLG+uKvq36UwBj lf0WHaVRELP1pDC1RbT//BGPcMqtTzvdtqbeENZB2WCpE1By6n8gijc5rOFusUTrqyZm yQrg== 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:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=OkmPNLv9HCOKJrfuoMs47C8uR2B9++8NNO8koO26e3Y=; b=0rVZIZQhckSnkuAwVSsXnx0I32WYBHNeUudrqmSkbyCUdFl53114qnTLdDwyKDzTO1 BMGYBXapzwHiKDLntZgLTPKSOV/UdpdrihxTSfz1y8sE+BK5f1GIRKxEmf2BmhEsqSuf dWqjWWwsw8jZVmGqTncmSBEcjKfXx8vwu4Hv/fwajz7O8bUjSrgn0iGR3yRNJonKuZ9T wGLHPkZKN/rt/c4ZCSXHhREHe5jeAG9FsZXvpgDoKzEAkEXlqaxRnvtox502sVuqB/GK rscNOilJrYCwudgUf7bJReUUPteCgV8VI67m3SYEL5bxjBYpi3hAji0fnDbM9ZQAlJmo LJlg== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16si65276224pfd.126.2019.08.11.20.00.22; Sun, 11 Aug 2019 20:00:38 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726527AbfHLC7v (ORCPT + 99 others); Sun, 11 Aug 2019 22:59:51 -0400 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:47610 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726200AbfHLC7v (ORCPT ); Sun, 11 Aug 2019 22:59:51 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04420;MF=luoben@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0TZD5MR7_1565578788; Received: from bn0418deMacBook-Pro.local(mailfrom:luoben@linux.alibaba.com fp:SMTPD_---0TZD5MR7_1565578788) by smtp.aliyun-inc.com(127.0.0.1); Mon, 12 Aug 2019 10:59:48 +0800 Subject: Re: [PATCH 1/2] genirq: introduce update_irq_devid() To: Thomas Gleixner Cc: alex.williamson@redhat.com, linux-kernel@vger.kernel.org, tao.ma@linux.alibaba.com, gerry@linux.alibaba.com References: <39a5009c77d07c3ce42ef784465c05e36d5f684d.1565263723.git.luoben@linux.alibaba.com> From: luoben Message-ID: <46a5b5ea-8832-470b-2577-d7412e6a9cbd@linux.alibaba.com> Date: Mon, 12 Aug 2019 10:59:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2019/8/9 上午3:56, Thomas Gleixner 写道: > On Thu, 8 Aug 2019, Ben Luo wrote: >> +int update_irq_devid(unsigned int irq, void *dev_id, void *new_dev_id) >> +{ >> + struct irq_desc *desc = irq_to_desc(irq); >> + struct irqaction *action, **action_ptr; >> + unsigned long flags; >> + >> + WARN(in_interrupt(), >> + "Trying to update IRQ %d from IRQ context!\n", irq); > This is broken. The function needs to return on that condition. Actually it > cannot even be called from non-preemptible code. > > What's worse is that if the interrupt in question is handled concurrently, > then it will either see the old or the new dev_id and because the interrupt > handler loop runs with desc->lock dropped even more crap can happen because > dev_id can be subject to load and store tearing. > > Staring at that, I see that there is the same issue in setup_irq() and > free_irq(). It's actually worse there. I'll have a look. ok,  will return with an error code in v2 in this case > >> + /* >> + * There can be multiple actions per IRQ descriptor, find the right >> + * one based on the dev_id: >> + */ >> + action_ptr = &desc->action; >> + for (;;) { >> + action = *action_ptr; >> + >> + if (!action) { >> + WARN(1, "Trying to update already-free IRQ %d\n", irq); > That's wrong in two aspects: > > 1) The warn should be outside of the locked region. > > 2) Just having the irq number is not useful for debugging either > when the interrupt is shared. will take care in v2 >> + raw_spin_unlock_irqrestore(&desc->lock, flags); >> + chip_bus_sync_unlock(desc); >> + return -ENXIO; >> + } >> + >> + if (action->dev_id == dev_id) { >> + action->dev_id = new_dev_id; >> + break; >> + } >> + action_ptr = &action->next; >> + } >> + >> + raw_spin_unlock_irqrestore(&desc->lock, flags); >> + chip_bus_sync_unlock(desc); >> + >> + /* >> + * Make sure it's not being used on another CPU: >> + * There is a risk of UAF for old *dev_id, if it is >> + * freed in a short time after this func returns >> + */ >> + synchronize_irq(irq); >> + >> + return 0; >> +} >> +EXPORT_SYMBOL(update_irq_devid); > EXPORT_SYMBOL_GPL() please. thanks, will use EXPORT_SYMBOL_GPL in v2 > > Thanks, > > tglx Thanks,      Ben