Received: by 10.223.176.46 with SMTP id f43csp911840wra; Sat, 20 Jan 2018 07:08:55 -0800 (PST) X-Google-Smtp-Source: AH8x227ydq5zoJqyWkrvcHQ3q4LUgbNACLKgk7cm7eAKyQbGGOdngLGWvDwpk17dWynKQc26Xuuw X-Received: by 2002:a17:902:8691:: with SMTP id g17-v6mr1059173plo.446.1516460935540; Sat, 20 Jan 2018 07:08:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516460935; cv=none; d=google.com; s=arc-20160816; b=R3IvKKtJEMOd3B9hVDSw9mrO8sIi4s51NLoi3Mpu0XLknbyqJjplZWYhCHgJIqY1q+ sgH8o5Y3Mon+HQLVHCZbftU1lMql1G9z8hdQdLmBOsTAsVgU/a0Ygl0X1r7is+CA33GR OjEtceBE/aT/zCQCE8L4V9Gpfn7dKUOoy9PIod64E0t7FEsdBqedVLEmTXcyuGCdBNQJ nLd9z1xAlauQA7zzhtcYtJ/Dxl98SDGO5mELNnsoavhHdvwsZaiKrEfXxpWSrQrx3bfJ C549TVzqPt3GKFdkgWQS8IiJxrE8n7ccDK+Ad78X9uCJQmcFhhyBqG961E8ko/59nmEi KL6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=eFBHOOpZeKEdhEX4Va8Zui76zOp1CmZhTJwRedNJN40=; b=bJqqPRQ/iHEy4dPLbcV5T9ifZWOZ1BmxeiC4kLCOhrVm9x0/RXNR0boV1syAhtAngg DzQXzNRQ0VZhUTu6fXLpPQdj9ajsrvwokf4iSORtzNMb0vLUqhqnFy/8wg+VMM8z2lNT jtEEPfZjQrng+hurHooCk0cAtzJNKe9LXtYREoyYDWBowX+9kim7+XlXp3INjO6+kY4L dXlhW7/TICoM9Mtu6ug89k0GXJxiCtizK4hf8kx2IEBt2v3xi/FqB96trbaZtFlEmyNV WcWqpoHtf54K8FKFnV9n8BTIpIsd21jZFdUogxkpncBlsVvrq/2eoM/TVJBDF9wIyKY+ GNMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kzbqazmN; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 74si11468995pfl.59.2018.01.20.07.08.40; Sat, 20 Jan 2018 07:08:55 -0800 (PST) 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=@google.com header.s=20161025 header.b=kzbqazmN; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755507AbeATPHX (ORCPT + 99 others); Sat, 20 Jan 2018 10:07:23 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:42800 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751324AbeATPHT (ORCPT ); Sat, 20 Jan 2018 10:07:19 -0500 Received: by mail-pf0-f193.google.com with SMTP id b25so3638723pfd.9 for ; Sat, 20 Jan 2018 07:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eFBHOOpZeKEdhEX4Va8Zui76zOp1CmZhTJwRedNJN40=; b=kzbqazmNpuZJ8sCbhT7U+hdiYjI9jrPr1X8cAoEW7OCZMIWC/oBopXGaq9GPqqdn9W dAdUHdZaCO+VfsvgVDn8SarB4s0FHQ3jX3VQEOdvEkOYlJt3kkhz7h+T8NFNqsJlKQgb Tkv8oxcQNepvaCiB/pkwHEg2SxaWJxQ/5WrrVAdfM9rJqgui4FTrod6losjq5fn7C3Qx 92cJIiUSlH7PdQoTorB3E0zBx+HdaSiju45GG/0EMFTuoIzUc7mlbCI7vT66UgXSKeu7 w5ebqgh1dTIZmijxO1ZFmwhlpXAZ/EmQhNl7C2ZCL+2YJBoj/NtqQJEEaY0y339TiRth 1NWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eFBHOOpZeKEdhEX4Va8Zui76zOp1CmZhTJwRedNJN40=; b=CZ/WhdNqVBjsfDcc40wwYaI0uvKKR3fz+VLxfNRCvQ9uCyy5lUPZbFbXruwvMcgX/M s/lk/6rRb7i2R9ExnWfTC2Bfq1ppsnn93jaR22vqYQh5Bm4tFHOhrx/NoVc6Btg+TM2B UOdug3/AomDq1X0gnjhcFc3c4gvfXzny3OpBGoqNq/YvGXvaRWuqtqFvel8Gpgg0XYVC D13bFjcUa3xdofAWDckT9oVsHQuD7NgwkUmByrbG/V9G/bvIaBvhSS8kD7NJJuITF+9T mlVnZ6/Zs6LOd2RFhV8MjPaO1B4Ghbo+dklkyXMxMBAJRaTRpGs2GdJ7Kd09lTQEPfnc TVCw== X-Gm-Message-State: AKwxytdjz/1Q2RjhAnV1PnpQ4pkSagU98n36mrGQhCfbG86QY0Yn9UGl c6+wLT1HLOWu8750KxQOOaf2e/JzTLadl1xgZHkL5g== X-Received: by 10.99.159.9 with SMTP id g9mr2208346pge.174.1516460838414; Sat, 20 Jan 2018 07:07:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.140.151 with HTTP; Sat, 20 Jan 2018 07:06:57 -0800 (PST) In-Reply-To: References: From: Dmitry Vyukov Date: Sat, 20 Jan 2018 16:06:57 +0100 Message-ID: Subject: Re: Possible Memory Leak in KCOV Linux 4.15-rc1 To: Shankara Pailoor Cc: LKML , syzkaller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor wrote: > Hi Dmitry, > > I will try and get something to you tomorrow. Just wondering, but what > happens to the old struct kcov if a task opens /sys/kernel/debug/kcov > twice? I am looking here > https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 > and I don't see where the previous struct would get freed. Good question. Perhaps we need something like: diff --git a/kernel/kcov.c b/kernel/kcov.c index 7594c033d98a..c76498018500 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, */ if (kcov->mode != KCOV_MODE_INIT || !kcov->area) return -EINVAL; - if (kcov->t != NULL) + if (kcov->t != NULL || t->kcov != NULL) return -EBUSY; if (arg == KCOV_TRACE_PC) kcov->mode = KCOV_MODE_TRACE_PC; > On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: >> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor wrote: >>> Hi Dmitry, >>> >>> I added support for kcov in strace and I have been tracing a fairly >>> large program but after a little while, I notice that when I mmap a >>> new cover buffer, the call fails with ENOMEM. After killing the >>> program, I try and rerun and I notice that there is nearly no memory >>> on the system. When I do a kmemleak scan I get the following reports: >>> >>> I believe the problem occurs when I try and setup the kcov buffer >>> again after an exec. Instead of reusing the old file descriptor I open >>> kcov again within that process. In that case, I don't know what >>> happens to the old kcov struct. >>> >>> I don't see a maintainers list for kcov so I decided to email you >>> directly. Let me know what more information I can provide. >> >> >> Hi Shankara, >> >> Looks bad. Can you provide a reproducer? >> We extensively use kcov with syzkaller, but have not observed such >> leaks. Also I don't see anything obvious in the code. >> >> Thanks >