Received: by 2002:a17:90b:8d0:0:0:0:0 with SMTP id ds16csp5065986pjb; Mon, 27 Jul 2020 12:02:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4tsPvDxiUuTEU+qlaTyFF84KzijBY1K0+rNrero9cDJmivF0aWpBwknOdkmNmEmBOIabi X-Received: by 2002:a17:906:5657:: with SMTP id v23mr22981739ejr.196.1595876568965; Mon, 27 Jul 2020 12:02:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595876568; cv=none; d=google.com; s=arc-20160816; b=FecDOxWll+pjZiM4SVKe0J7ubQjLupspHjyUicKTY08B6K65yPUeu8edrUyx+EFygz /nj4xLwRCskdBh+KjyJUjA70Ihs4upRU+nqXbXIPuAUAktHQ2HJsUgQ0Do5bqs+YTgmD vKZqHgqlXRiax+EfoHPa+TKZFBrmtofrvhY7a7bIVrZd7vJBUipBE9+MH18LEwiZ6QA0 4SnRYrHU6bOp6s2rRTwMZbmN9wwF+6z1L+nmgw9Z8cU4iy7O93PCrhqdPtAoA5UDE4wz Qn939XoaHS+8wn2w1Xi4bQjCqQt+aewuInTyWoXPDXKrvjJFfeJ0tXTu14mmAd+vbR4y GaGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:dkim-filter; bh=hzbEnRYbp7CjaiVlwpRNX2SqfyUAUkPwouFn2zKxziQ=; b=MAqbx+Eo3bWvLXXxFdXp31yIBDo4IqdOhGdN8L3n6CzI5Zpdve9EpFKpP3zXSaJ4Am i1WE3UkI8zsQf+w5FpPBW9SE8p2h3pvmoDmdO1wHLLGSjwebTcsDNTlgODjVfEayftI1 MFrGH0DttC1am7BSMCljMGNBhGDMDs5LOmtyejSsz8peklU3zIS8CUzgQcwvGvPefxOf bOYBlPNPhWDQ98YZSCwSl+/os1P0ilOx37S+fIUIAkmDyptgurG2D8B7aTjGDOHxZbDC 2aT3aR1E9PWy3WTLVYdjBbqUMt0yV1dz7g1mdO/mL8CtHHnLgH91/0FQw+NC/f85fwyK m8Fw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=qmtAl08t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i5si6292640edd.112.2020.07.27.12.02.27; Mon, 27 Jul 2020 12:02:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=qmtAl08t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731422AbgG0Ri3 (ORCPT + 99 others); Mon, 27 Jul 2020 13:38:29 -0400 Received: from linux.microsoft.com ([13.77.154.182]:57700 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728925AbgG0Ri2 (ORCPT ); Mon, 27 Jul 2020 13:38:28 -0400 Received: by linux.microsoft.com (Postfix, from userid 1046) id 367BA20B4908; Mon, 27 Jul 2020 10:38:28 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 367BA20B4908 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1595871508; bh=hzbEnRYbp7CjaiVlwpRNX2SqfyUAUkPwouFn2zKxziQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qmtAl08tkOJUFq5qhM1G95ug1vjde7ZvCV47hZjBx2X0cEvxRw+gTnYZwve1MV6kL jQebm3l7+VP6UGuUb7CUHP4wUbFmOXkyQKD4D3pU56z0bjBc4SGlffw1wsdbWhyiVR oB4+OdZOETbwsP2nq7uZE2pPPv83JDXTgLa/O1g4= From: Dhananjay Phadke To: ray.jui@broadcom.com Cc: bcm-kernel-feedback-list@broadcom.com, dphadke@linux.microsoft.com, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, rayagonda.kokatanur@broadcom.com, rjui@broadcom.com, wsa@kernel.org Subject: Re: [PATCH] i2c: iproc: fix race between client unreg and isr Date: Mon, 27 Jul 2020 10:38:28 -0700 Message-Id: <1595871508-28566-1-git-send-email-dphadke@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <4cf12c92-889d-ffbf-f8de-c1e08cfb8ce9@broadcom.com> References: <4cf12c92-889d-ffbf-f8de-c1e08cfb8ce9@broadcom.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ray Jui wrote: >>> I think the following sequence needs to be implemented to make this >>> safe, i.e., after 'synchronize_irq', no further slave interrupt will be >>> fired. >>> >>> In 'bcm_iproc_i2c_unreg_slave': >>> >>> 1. Set an atomic variable 'unreg_slave' (I'm bad in names so please come >>> up with a better name than this) >>> >>> 2. Disable all slave interrupts >>> >>> 3. synchronize_irq >>> >>> 4. Set slave to NULL >>> >>> 5. Erase slave addresses >> >> What about this in unreg_slave? >> >> 1. disable_irq() >> This includes synchronize_irq() and avoids the race. Because irq >> will be masked at interrupt controller level, interrupts coming >> in at the I2C IP core level should still be pending once we >> reenable the irq. >> > > Can you confirm that even if we have irq pending at the i2c IP core > level, as long as we execute Step 2. below (to disable/mask all slave > interrupts), after 'enable_irq' is called, we still will not receive any > further i2c slave interrupt? > > Basically I'm asking if interrupts will be "cached" at the GIC > controller level after 'disable_irq' is called. As long as that is not > the case, then I think we are good. > > The goal of course is to ensure there's no further slave interrupts > after 'enable_irq' in Step 3 below. That was my question as well, the best would be if the i2c controller itself has a bit for masking all interrupts overriding individual event enables set by the ISR. Also with regards to the original sequence, I think slave address should be erased before enable_irq(), besides draining rx and tx FIFOs. I'll send reworked patch. @Rayagonda will validate new sequence with the test that hit the race condition. - Dhananjay