Received: by 10.192.165.156 with SMTP id m28csp1491254imm; Mon, 16 Apr 2018 23:32:09 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+WteqMgKlfu0fgV6GDPA9igwO6b3H6AFibRGkB0hz0XQDydmL0xUuGEzG8mN9osdPuF3f4 X-Received: by 10.101.89.5 with SMTP id f5mr770547pgu.428.1523946729838; Mon, 16 Apr 2018 23:32:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523946729; cv=none; d=google.com; s=arc-20160816; b=FCRiUV9J6+12w9vYX6Wa+ALmFEEHy23KFhFk+h7NPvPgaaVqh5lF1QlDhAtqxo8vK0 lbAfEpjODHfgXDPddvoua+0gIlWiV9AV8Qm1HtSdOqtdpmJF0G9J23SiUY2C9sJbwYJO MHZ+ltxDhixliSIDDbzayYxdg3eUaMS/GFT9GUDMpWM5ZHRusBKnLFJOib49m8o3N49S 0quKTdvgxe51q9RZIQrqfeoDAIm1ata6CwkErbGigINvLMX/ttj/Wt0pOOfdkaE0eZjF v6C4kPF9QJhOeE93zjgvcUWgAw21kX+rZvRHs+Vnk5qxCSz5EpoYDlEHiQ12AF+njON3 NWZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=ybvGS2NkaFo74f0xK5C14mjhcHrgQAQjHB270eky5Ms=; b=nrGm8Oq0fMx2YEzgcavdTB4qQhM3DUfYV8xBxTee2Ps27kQbWhARjCmAAEjbLo8Z85 kZmgmJR4hWLm/GiHVgTLVGVGNlfll77DRw2BTbPvou2L/rHd8fmp97jScYo6Fx47981B 5LygWs3FoBQ2RLQkt9g/0YJBYOxwO2VJPrbzs3i3tXvtDhJDgTqg09DBR8XduayzoIiz 4MmvawCVD6Q0ExpWGmai8tljiCz1HsxOODp6TK1JpXfbhwpP166v1jNI6oZCLVuEc1gH euQup7fEZOFy6HZQoyHGZJgXTnfL1MRKnQznSkLz1FjCgFkl6SWa8J+4fAo1FE+oDLd3 opSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=DOBf8M30; dkim=pass header.i=@codeaurora.org header.s=default header.b=DOBf8M30; 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 q10si9420004pff.124.2018.04.16.23.31.55; Mon, 16 Apr 2018 23:32:09 -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=@codeaurora.org header.s=default header.b=DOBf8M30; dkim=pass header.i=@codeaurora.org header.s=default header.b=DOBf8M30; 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 S1752048AbeDQG3w (ORCPT + 99 others); Tue, 17 Apr 2018 02:29:52 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:42382 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751158AbeDQG3u (ORCPT ); Tue, 17 Apr 2018 02:29:50 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id EB79560807; Tue, 17 Apr 2018 06:29:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523946589; bh=SZhqve8g6BeMsPikjyq/GmNDwx08n7KRNuoeNN6cydQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=DOBf8M30Tc4Wm/Wo3RfVHxeI8BunuYNzrjqLxUOXa7oGtEJD7On0AfAzHyshgR27g /4a6NilqqmWIJNBcaJnIqvU5ZnnUzT4eoJRnRn79Lg+P8h/GFeWypEbxWv2r5K2aIl S4YptcAI2JP9P5gqOtePQCLN8VYQZ1oipweJYZJU= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.204.78.254] (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gkohli@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 521B6603AF; Tue, 17 Apr 2018 06:29:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523946589; bh=SZhqve8g6BeMsPikjyq/GmNDwx08n7KRNuoeNN6cydQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=DOBf8M30Tc4Wm/Wo3RfVHxeI8BunuYNzrjqLxUOXa7oGtEJD7On0AfAzHyshgR27g /4a6NilqqmWIJNBcaJnIqvU5ZnnUzT4eoJRnRn79Lg+P8h/GFeWypEbxWv2r5K2aIl S4YptcAI2JP9P5gqOtePQCLN8VYQZ1oipweJYZJU= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 521B6603AF Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=gkohli@codeaurora.org Subject: Re: [PATCH] percpu_counter: Remove debug_object_free call twice To: Tejun Heo Cc: gregkh@linuxfoundation.org, nborisov@suse.com, akpm@linux-foundation.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org References: <1523612103-15071-1-git-send-email-gkohli@codeaurora.org> <20180416214810.GF1911913@devbig577.frc2.facebook.com> From: "Kohli, Gaurav" Message-ID: Date: Tue, 17 Apr 2018 11:59:44 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180416214810.GF1911913@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/17/2018 3:18 AM, Tejun Heo wrote: > On Fri, Apr 13, 2018 at 03:05:03PM +0530, Gaurav Kohli wrote: >> During percpu_counter destroy, debug_object_free is calling >> twice which may create race. So removing once instance of call >> from debug_percpu_counter_deactivate. > I don't quite follow. Can you please elaborate how it can be called > twice? Hi Tejun, In percpu_counter_fixup_free function, first call is percpu_counter_destroy -> debug_percpu_counter_deactivate (this will set inactive and free the debug object as well for percpu counter) -> free_percpu (finally freeing the counters). Below is the code snippet:         case DEBUG_STATE_ACTIVE:                 percpu_counter_destroy(fbc); -> first call                 debug_object_free(fbc, &percpu_counter_debug_descr); -> this will again call the same debug object free, if somehow counters will reinitialize between these two calls. We are seeing one race condition issue where one object of db list is corrupted and just before object of that corrupted node is percpu_counter, Still i am not sure the reason of race as it is very difficult to reproduce. But i have found this during code review. Please correct me, if i misunderstood this. > > Thanks. > > -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.