All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: David Howells <dhowells@redhat.com>
Cc: Jann Horn <jannh@google.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	raven@themaw.net, linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-block@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
Date: Fri, 31 May 2019 15:26:20 +0200	[thread overview]
Message-ID: <20190531132620.GC2606@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <21942.1559304135@warthog.procyon.org.uk>

On Fri, May 31, 2019 at 01:02:15PM +0100, David Howells wrote:
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > Can you re-iterate the exact problem? I konw we talked about this in the
> > past, but I seem to have misplaced those memories :/
> 
> Take this for example:
> 
> 	void afs_put_call(struct afs_call *call)
> 	{
> 		struct afs_net *net = call->net;
> 		int n = atomic_dec_return(&call->usage);
> 		int o = atomic_read(&net->nr_outstanding_calls);
> 
> 		trace_afs_call(call, afs_call_trace_put, n + 1, o,
> 			       __builtin_return_address(0));
> 
> 		ASSERTCMP(n, >=, 0);
> 		if (n == 0) {
> 			...
> 		}
> 	}
> 
> I am printing the usage count in the afs_call tracepoint so that I can use it
> to debug refcount bugs.  If I do it like this:
> 
> 	void afs_put_call(struct afs_call *call)
> 	{
> 		int n = refcount_read(&call->usage);
> 		int o = atomic_read(&net->nr_outstanding_calls);
> 
> 		trace_afs_call(call, afs_call_trace_put, n, o,
> 			       __builtin_return_address(0));
> 
> 		if (refcount_dec_and_test(&call->usage)) {
> 			...
> 		}
> 	}
> 
> then there's a temporal gap between the usage count being read and the actual
> atomic decrement in which another CPU can alter the count.  This can be
> exacerbated by an interrupt occurring, a softirq occurring or someone enabling
> the tracepoint.
> 
> I can't do the tracepoint after the decrement if refcount_dec_and_test()
> returns false unless I save all the values from the object that I might need
> as the object could be destroyed any time from that point on.

Is it not the responsibility of the task that affects the 1->0
transition to actually free the memory?

That is, I'm expecting the '...' in both cases above the include the
actual freeing of the object. If this is not the case, then @usage is
not a reference count.

(and it has already been established that refcount_t doesn't work for
usage count scenarios)

Aside from that, is the problem that refcount_dec_and_test() returns a
boolean (true - last put, false - not last) instead of the refcount
value? This does indeed make it hard to print the exact count value for
the event.

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: David Howells <dhowells@redhat.com>
Cc: Jann Horn <jannh@google.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	raven@themaw.net, linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-block@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
Date: Fri, 31 May 2019 13:26:20 +0000	[thread overview]
Message-ID: <20190531132620.GC2606@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <21942.1559304135@warthog.procyon.org.uk>

On Fri, May 31, 2019 at 01:02:15PM +0100, David Howells wrote:
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > Can you re-iterate the exact problem? I konw we talked about this in the
> > past, but I seem to have misplaced those memories :/
> 
> Take this for example:
> 
> 	void afs_put_call(struct afs_call *call)
> 	{
> 		struct afs_net *net = call->net;
> 		int n = atomic_dec_return(&call->usage);
> 		int o = atomic_read(&net->nr_outstanding_calls);
> 
> 		trace_afs_call(call, afs_call_trace_put, n + 1, o,
> 			       __builtin_return_address(0));
> 
> 		ASSERTCMP(n, >=, 0);
> 		if (n = 0) {
> 			...
> 		}
> 	}
> 
> I am printing the usage count in the afs_call tracepoint so that I can use it
> to debug refcount bugs.  If I do it like this:
> 
> 	void afs_put_call(struct afs_call *call)
> 	{
> 		int n = refcount_read(&call->usage);
> 		int o = atomic_read(&net->nr_outstanding_calls);
> 
> 		trace_afs_call(call, afs_call_trace_put, n, o,
> 			       __builtin_return_address(0));
> 
> 		if (refcount_dec_and_test(&call->usage)) {
> 			...
> 		}
> 	}
> 
> then there's a temporal gap between the usage count being read and the actual
> atomic decrement in which another CPU can alter the count.  This can be
> exacerbated by an interrupt occurring, a softirq occurring or someone enabling
> the tracepoint.
> 
> I can't do the tracepoint after the decrement if refcount_dec_and_test()
> returns false unless I save all the values from the object that I might need
> as the object could be destroyed any time from that point on.

Is it not the responsibility of the task that affects the 1->0
transition to actually free the memory?

That is, I'm expecting the '...' in both cases above the include the
actual freeing of the object. If this is not the case, then @usage is
not a reference count.

(and it has already been established that refcount_t doesn't work for
usage count scenarios)

Aside from that, is the problem that refcount_dec_and_test() returns a
boolean (true - last put, false - not last) instead of the refcount
value? This does indeed make it hard to print the exact count value for
the event.

  reply	other threads:[~2019-05-31 13:26 UTC|newest]

Thread overview: 131+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 16:01 [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications David Howells
2019-05-28 16:01 ` David Howells
2019-05-28 16:01 ` [PATCH 1/7] General notification queue with user mmap()'able ring buffer David Howells
2019-05-28 16:01   ` David Howells
2019-05-28 16:26   ` Greg KH
2019-05-28 16:26     ` Greg KH
2019-05-28 17:30   ` David Howells
2019-05-28 17:30     ` David Howells
2019-05-28 23:12     ` Greg KH
2019-05-28 23:12       ` Greg KH
2019-05-29 16:06     ` David Howells
2019-05-29 16:06       ` David Howells
2019-05-29 17:46       ` Jann Horn
2019-05-29 17:46         ` Jann Horn
2019-05-29 21:02       ` David Howells
2019-05-29 21:02         ` David Howells
2019-05-31 11:14         ` Peter Zijlstra
2019-05-31 11:14           ` Peter Zijlstra
2019-05-31 12:02         ` David Howells
2019-05-31 12:02           ` David Howells
2019-05-31 13:26           ` Peter Zijlstra [this message]
2019-05-31 13:26             ` Peter Zijlstra
2019-05-31 14:20           ` David Howells
2019-05-31 14:20             ` David Howells
2019-05-31 16:44             ` Peter Zijlstra
2019-05-31 16:44               ` Peter Zijlstra
2019-05-31 17:12             ` David Howells
2019-05-31 17:12               ` David Howells
2019-06-17 16:24               ` Peter Zijlstra
2019-06-17 16:24                 ` Peter Zijlstra
2019-05-29 23:09       ` Greg KH
2019-05-29 23:09         ` Greg KH
2019-05-29 23:11       ` Greg KH
2019-05-29 23:11         ` Greg KH
2019-05-30  9:50         ` Andrea Parri
2019-05-30  9:50           ` Andrea Parri
2019-05-31  8:35           ` Peter Zijlstra
2019-05-31  8:35             ` Peter Zijlstra
2019-05-31  8:47       ` Peter Zijlstra
2019-05-31  8:47         ` Peter Zijlstra
2019-05-31 12:42       ` David Howells
2019-05-31 12:42         ` David Howells
2019-05-31 14:55       ` David Howells
2019-05-31 14:55         ` David Howells
2019-05-28 19:14   ` Jann Horn
2019-05-28 19:14     ` Jann Horn
2019-05-28 22:28   ` David Howells
2019-05-28 22:28     ` David Howells
2019-05-28 23:16     ` Jann Horn
2019-05-28 23:16       ` Jann Horn
2019-05-28 16:02 ` [PATCH 2/7] keys: Add a notification facility David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 16:02 ` [PATCH 3/7] vfs: Add a mount-notification facility David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 20:06   ` Jann Horn
2019-05-28 20:06     ` Jann Horn
2019-05-28 23:04   ` David Howells
2019-05-28 23:04     ` David Howells
2019-05-28 23:23     ` Jann Horn
2019-05-28 23:23       ` Jann Horn
2019-05-29 11:16     ` David Howells
2019-05-29 11:16       ` David Howells
2019-05-28 23:08   ` David Howells
2019-05-28 23:08     ` David Howells
2019-05-29 10:55   ` David Howells
2019-05-29 10:55     ` David Howells
2019-05-29 11:00   ` David Howells
2019-05-29 11:00     ` David Howells
2019-05-29 15:53     ` Casey Schaufler
2019-05-29 15:53       ` Casey Schaufler
2019-05-29 16:12       ` Jann Horn
2019-05-29 16:12         ` Jann Horn
2019-05-29 17:04         ` Casey Schaufler
2019-05-29 17:04           ` Casey Schaufler
2019-06-03 16:30         ` David Howells
2019-06-03 16:30           ` David Howells
2019-05-29 17:13       ` Andy Lutomirski
2019-05-29 17:13         ` Andy Lutomirski
2019-05-29 17:46         ` Casey Schaufler
2019-05-29 17:46           ` Casey Schaufler
2019-05-29 18:11           ` Jann Horn
2019-05-29 18:11             ` Jann Horn
2019-05-29 19:28             ` Casey Schaufler
2019-05-29 19:28               ` Casey Schaufler
2019-05-29 19:47               ` Jann Horn
2019-05-29 19:47                 ` Jann Horn
2019-05-29 20:50                 ` Casey Schaufler
2019-05-29 20:50                   ` Casey Schaufler
2019-05-29 23:12           ` Andy Lutomirski
2019-05-29 23:12             ` Andy Lutomirski
2019-05-29 23:56             ` Casey Schaufler
2019-05-29 23:56               ` Casey Schaufler
2019-05-28 16:02 ` [PATCH 4/7] vfs: Add superblock notifications David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 20:27   ` Jann Horn
2019-05-28 20:27     ` Jann Horn
2019-05-29 12:58   ` David Howells
2019-05-29 12:58     ` David Howells
2019-05-29 14:16     ` Jann Horn
2019-05-29 14:16       ` Jann Horn
2019-05-28 16:02 ` [PATCH 5/7] fsinfo: Export superblock notification counter David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 16:02 ` [PATCH 6/7] block: Add block layer notifications David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 20:37   ` Jann Horn
2019-05-28 20:37     ` Jann Horn
2019-05-28 16:02 ` [PATCH 7/7] Add sample notification program David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 23:58 ` [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications Greg KH
2019-05-28 23:58   ` Greg KH
2019-05-29  6:33 ` Amir Goldstein
2019-05-29  6:33   ` Amir Goldstein
2019-05-29  6:33   ` Amir Goldstein
2019-05-29 14:25   ` Jan Kara
2019-05-29 14:25     ` Jan Kara
2019-05-29 15:10     ` Greg KH
2019-05-29 15:10       ` Greg KH
2019-05-29 15:53     ` Amir Goldstein
2019-05-29 15:53       ` Amir Goldstein
2019-05-30 11:00       ` Jan Kara
2019-05-30 11:00         ` Jan Kara
2019-06-04 12:33     ` David Howells
2019-06-04 12:33       ` David Howells
2019-05-29  6:45 ` David Howells
2019-05-29  6:45   ` David Howells
2019-05-29  7:40   ` Amir Goldstein
2019-05-29  7:40     ` Amir Goldstein
2019-05-29  9:09 ` David Howells
2019-05-29  9:09   ` David Howells
2019-05-29 15:41   ` Casey Schaufler
2019-05-29 15:41     ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190531132620.GC2606@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=dhowells@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.