Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp6277005imm; Mon, 23 Jul 2018 14:57:16 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdfK/OtW5cV4nCOspBQfZ/4rdk8FUr/6v0zIJeeUCtQW53ZM03MPTLCynCdCKFneyqFLSNk X-Received: by 2002:a65:5a01:: with SMTP id y1-v6mr13721120pgs.125.1532383036577; Mon, 23 Jul 2018 14:57:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532383036; cv=none; d=google.com; s=arc-20160816; b=ZPo13AmlpM1C6+SieH2jOWYa+az23LBeYDDP4ZjB46Wc40epJlcAT8cuEOql2598jj Q+yn50ArE6vcLjrARdrw5swlCZKFISYGA+xbRVYd+Z6lHALdha0kxSr3UwDpQaCq15Nu +8N6WCDJqFZd3jtUmTaKnKRenvAj0j8mcH30LdA/R/hQqBYfF/KrKc/kieNRjJQs1y9P K8HbJZCjq39858mTEkFOzQrlqRKTQ5Ly+CuCc67gahyREEvcr0P/tP5m9UEAAedLtV9m iqrpLFOSaVV69Y+rLu0trTzIRFWEM5DUQoyp7dgnW+Tw/IqUGCbqI3+A/jNTWQcgzIhr bPUw== 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:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=rehKX3gUYUErgSLu2skKfIvxS4Oh77/P+afcLtkuw9w=; b=etIf3iBR/nI3rp0FvXhQRw8LL1zu3tTukIWhc/trJMSq6QYKLmTiMT1wF34hTULnZO 3DUXFWpzk/76gy3Lew9T5RiAc+kqTMJvIpd0LMsLRhKnw1XHVK6Cb8MMSGsMJDDo2PuA ZUKzB57AD6GNrGg18hku5ymNLkkG77y+WssimqJNL4H311UX4qB1+yUrnpruVSjZkeyv 6RqNVoYwFg5WNoJzK/unLxn/PHYYuKdCeN6Q67iklTOOoIlg6yjgA2nM0n25+H0MILK6 Qwjj4yJktlASEx2KXIJe4M/m4SOXsnXlRHpyHfO1JTwhPShudoZSbnQ9aU1Rc2fx0RhD PbHA== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s13-v6si8492094pgo.505.2018.07.23.14.57.01; Mon, 23 Jul 2018 14:57:16 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388278AbeGWW7K (ORCPT + 99 others); Mon, 23 Jul 2018 18:59:10 -0400 Received: from mga18.intel.com ([134.134.136.126]:55307 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388052AbeGWW7K (ORCPT ); Mon, 23 Jul 2018 18:59:10 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 14:55:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,394,1526367600"; d="scan'208";a="242673569" Received: from spandruv-desk.jf.intel.com ([10.54.75.31]) by orsmga005.jf.intel.com with ESMTP; 23 Jul 2018 14:55:41 -0700 Message-ID: Subject: Re: HID: intel_ish-hid: tx_buf memory leak on probe/remove From: Srinivas Pandruvada To: Anton Vasilyev Cc: Jiri Kosina , Benjamin Tissoires , Even Xu , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, ldv-project@linuxtesting.org Date: Mon, 23 Jul 2018 14:55:41 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-07-23 at 20:56 +0300, Anton Vasilyev wrote: > ish_dev_init() allocates 512*176 bytes memory for tx_buf and stores > it at > &dev->wr_free_list_head.link list on ish_probe(). > But there is no deallocation of this memory in ish_remove() and in > ish_probe() > error path. > So current intel-ish-ipc provides 88 KB memory leak for each > probe/release. > > I have two ideas 1) to replace kzalloc allocation by devm_kzalloc, Thanks for finding this. We can replace both alloc in this function with devm_ calls. Once you have a patch I can test. Thanks, Srinivas > or 2) release memory stored at &dev->wr_free_list_head.link list > (and > may be at > &dev->wr_processing_list_head.link) in all driver exits. > > But I do not know which way is preferable for this case. > > Found by Linux Driver Verification project (linuxtesting.org). > > -- > Anton Vasilyev > Linux Verification Center, ISPRAS > web: http://linuxtesting.org > e-mail: vasilyev@ispras.ru