Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp560412pxx; Wed, 28 Oct 2020 11:06:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyt+rbkfoyXDkSOTBXEYpZ0GekdxwtSzWEzwJR3zhT6PB2lKJvyU3TgD7RX9QsEQOsLbfdp X-Received: by 2002:a05:6402:6ca:: with SMTP id n10mr66669edy.273.1603908383148; Wed, 28 Oct 2020 11:06:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603908383; cv=none; d=google.com; s=arc-20160816; b=QyB3O1370oSZy/OqACnuYBexL3GJn4rCpJcr4cUdxNhfHQLv2hgPORGnGgR37PGtCP qmEez8l9J+Tb8aB9iA8BkuHmjzY7/zb8RSu5vb5CFu0jqLc6+OLzRg3xeWWruqR5BzXF wkNw+sNuBctMJTCjO8j4/5ew7QZbhygRCGRxjwrUyUMHoJmCqS7WSu/B/8s1tF0V1T4i YQv4jLsNDyaU9kXQ6i7w2yxEhkeeeuFWCPjxy20SSoy1cQIuW5p5UlKciMOTICsplout w+BJOte21iPtOEDU32L9WCDiPGfvkrxOjDPQZIVX9Hs/+Q49RtueIaA/5fsWBxKi++mK +HDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:content-disposition:mime-version :reply-to:message-id:subject:cc:to:from:date:dkim-signature; bh=SnFmkXwqD1pUyJHpB3RrIg6ChtyxxiBkgZFYSdgKpxs=; b=a5lLMoXXpmfoksnauviW65SiAovk7J88yzIcXAjgJBDLahqU8Y8AVfd9Ye70vz3qPt YSD5aBpQxwa1pO/b4WNKjauVGuX4cGXX463uJKci8xy0se5HU2cwm/8P3Qq2PvvrkXhg wlf6YoeYfPxFVU8GFCCUPAECAL3IE85AjBaHyxbLLBOq+LRR6rQKMe6fAZ+hJuVwRcFl vtaLspb9q94HeYtpcOvOHTYL/s3vmlX86pO4hL6KXs0Pjl9FKVR+DErTa5cvoRVPegJp xTGh8FBHmRlmtf26Za5Wz7B/96Op7g8ZkSNlYuUETp244GJZ2LzRMAPxYXVGdnYzpPGm M4MQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="c/C/5297"; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay1si32292edb.3.2020.10.28.11.05.59; Wed, 28 Oct 2020 11:06:23 -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=@kernel.org header.s=default header.b="c/C/5297"; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1823670AbgJ0R72 (ORCPT + 99 others); Tue, 27 Oct 2020 13:59:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:50094 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1823204AbgJ0R6L (ORCPT ); Tue, 27 Oct 2020 13:58:11 -0400 Received: from paulmck-ThinkPad-P72.home (50-39-104-11.bvtn.or.frontiernet.net [50.39.104.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B867721556; Tue, 27 Oct 2020 17:58:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603821490; bh=+WdREhYOpPlOy7/jYqsbnSwfvnjFHZx6hOjap1wi2fk=; h=Date:From:To:Cc:Subject:Reply-To:From; b=c/C/5297m3QN3xalQSz0+R0cgn41tFT6MisMrH8UDvXSKLoW6FnhzIktmWMA+C4Pv IjGo63beACo+3t+HM1u3MQfX9RQcPdp4yAPwJDTnQUOZXZ915WFrXCUM60Q/nkcYmB SOP1PGi0iRjD7SJlFqiMqKUcLO761B3yLUa6rUbs= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 5E90C35229CE; Tue, 27 Oct 2020 10:58:10 -0700 (PDT) Date: Tue, 27 Oct 2020 10:58:10 -0700 From: "Paul E. McKenney" To: elver@google.com, dvyukov@google.com Cc: linux-kernel@vger.kernel.org, andriin@fb.com Subject: Recording allocation location for blocks of memory? Message-ID: <20201027175810.GA26121@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! I have vague memories of some facility some time some where that recorded who allocated a given block of memory, but am not seeing anything that does this at present. The problem is rare enough and the situation sufficiently performance-sensitive that things like ftrace need not apply, and the BPF guys suggest that BPF might not be the best tool for this job. The problem I am trying to solve is that a generic function that detects reference count underflow that was passed to call_rcu(), and there are a lot of places where the underlying problem might lie, and pretty much no information. One thing that could help is something that identifies which use case the underflow corresponds to. So, is there something out there (including old patches) that, given a pointer to allocated memory, gives some information about who allocated it? Or should I risk further inflaming the MM guys by creating one? ;-) Thanx, Paul