From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09F82C433E0 for ; Thu, 23 Jul 2020 00:21:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C375220825 for ; Thu, 23 Jul 2020 00:21:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="l4Ka94rD"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="l+Wzb521" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C375220825 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TvEb5mHRWu2hU+g2pcKHK6KMs9cKVvueWf6Vrq8YdVU=; b=l4Ka94rDAR1XeCiEFMyQoJizK v0VhZXOe9EOI+kticVNCxpEuGJ+BNeX5fD2sMk9lJSzY1PYunfwUwF8Xte7A0N4aEdd12vFvFNdyr U/0lGMt2rWCX1sD0sxXrg4PoF0bXVoK9uqbaUpKahqP+GP3k/fc3vu5ip219Qamx10H1Ydy8RLuL3 hFRhv3IApmPSKWExoGH9/I6Xy9qW+6PHMsAaCr/NAkGLdTHNyhYcrbgUoEF0ws1LpSRevSfViCt/5 mcF9poioCMbL5Jmh8+97A7ToOLEOjm4ZDmHij3K9cuUd30xtjEWyYYTeEMWFnEvdv0HX1GK1P0xed Wnj4RYHOg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyOxP-0002WY-Av; Thu, 23 Jul 2020 00:19:31 +0000 Received: from m43-7.mailgun.net ([69.72.43.7]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyOxI-0002Vf-VR for linux-arm-kernel@lists.infradead.org; Thu, 23 Jul 2020 00:19:30 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1595463568; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=j7FKh4klG6yF43WhghOlIgT/+Gi+DhyWDySvLTTH7VI=; b=l+Wzb521YURGVvNZaZyonunOGdjhwXNe9gkoUash6pewuotB4xEN47KmZB0N//t176hPrDhY +SpeboQhJHeoeWjJOp6jY1jQrPQJFskA15b3V41tCD7cOki7PjMgTPwjrf1Kwb3n/cm6puM4 pO0RwvcT7HKnvg+7OSBh1qvPNIg= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyJiYzAxZiIsICJsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n01.prod.us-east-1.postgun.com with SMTP id 5f18d765f9ca681bd0563524 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 23 Jul 2020 00:18:45 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 3328BC4339C; Thu, 23 Jul 2020 00:18:45 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tingwei) by smtp.codeaurora.org (Postfix) with ESMTPSA id 58BFEC433C6; Thu, 23 Jul 2020 00:18:44 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 23 Jul 2020 08:18:44 +0800 From: tingwei@codeaurora.org To: Suzuki K Poulose Subject: Re: [PATCH v3 19/20] coresight: add try_get_module() in coresight_grab_device() In-Reply-To: References: <20200717054536.7052-1-tingwei@codeaurora.org> <20200717054536.7052-20-tingwei@codeaurora.org> <7ef8d427-23c9-10cd-b337-03ae75476a8c@arm.com> <20200722104859.GA2827860@kroah.com> Message-ID: <97a0a247c2c0833ec08c18e01a7d3c01@codeaurora.org> X-Sender: tingwei@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200722_201929_527499_71BB0C3E X-CRM114-Status: GOOD ( 21.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tsoni@codeaurora.org, saiprakash.ranjan@codeaurora.org, kim.phillips@arm.com, mathieu.poirier@linaro.org, alexander.shishkin@linux.intel.com, gregkh@linuxfoundation.org, coresight@lists.linaro.org, rdunlap@infradead.org, ykaukab@suse.de, linux@armlinux.org.uk, jinlmao@codeaurora.org, leo.yan@linaro.org, linux-arm-kernel , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-07-22 19:26, Suzuki K Poulose wrote: > On 07/22/2020 11:48 AM, Greg KH wrote: >> On Wed, Jul 22, 2020 at 11:49:48AM +0100, Suzuki K Poulose wrote: >>> Hi Tingwei, >>> >>> On 07/17/2020 06:45 AM, Tingwei Zhang wrote: >>>> When coresight device is in an active session, driver module of >>>> that device should not be removed. Use try_get_module() in >>>> coresight_grab_device() to prevent module to be unloaded. >>>> >>> >>> Is this really sufficient ? AFAIU, a device could be removed, but the >>> module may still be alive due to the refcount on the module. This >>> could imply that we have stale pointers in the _path_, which could >>> lead to corruption elsewhere. Should we do a get/put_device() instead >>> ? >> >> Remember there are two separate things here, code and data. There are >> two different reference counts for them, do not confuse the two. >> >> get/put is needed when you have a reference to the data, module stuff >> is >> when you are calling into code. > > Exactly. In this case, we have reference to the data specific to the > device in a data structure specific to one session, which doesn't have > any link back from the device to release it. Thus we need get/put here > to make sure that data doesn't get released under our feet. > Agree with you, Suzuki and Greg. Device refcount should be used to protect the device data and module refcount should be used to protect module code. This series is trying to add support to load/unload coresight module. When there's active session ongoing, coresight framework could call operation of client driver like sink->enable(). If module is removed at that time, it will be an issue. Add refcount to module here protect this kind of situation. For device count, coresight framework currently doesn't hold device refcount. I think that's because coresight client drivers doesn't support dynamic remove the device. As a consequence of module unload, devices which are using that module will be removed. However, module framework will first check the module refcount before calls module exit which leads to device remove. It will return without doing anything if refcount of module is hold by coresight framework. If we want to support dynamic remove device from unbind interface in coresight driver, we should definitely add device refcount there. This is out of this series' scope. Thanks, Tingwei >> >> But note that you do not always need to grab a reference count to the >> module, as long as the module can properly tear the data down when it >> is >> asked to be removed. Look at networking drivers as a great example of >> that. > > Thanks > > Suzuki > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel