Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1567794 > unrolled thread

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCH 7/7] kref: Implement using refcount_t Kees Cook <keescook@chromium.org> - 2017-01-27 00:20 +0100
    Re: [RFC][PATCH 7/7] kref: Implement using refcount_t Peter Zijlstra <peterz@infradead.org> - 2017-01-27 11:10 +0100
      Re: [RFC][PATCH 7/7] kref: Implement using refcount_t Kees Cook <keescook@chromium.org> - 2017-01-27 22:20 +0100
        Re: [RFC][PATCH 7/7] kref: Implement using refcount_t Peter Zijlstra <peterz@infradead.org> - 2017-01-30 14:50 +0100

#1567794 — Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On Mon, Nov 14, 2016 at 9:39 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> Provide refcount_t, an atomic_t like primitive built just for
> refcounting.
>
> It provides overflow and underflow checks as well as saturation
> semantics such that when it overflows, we'll never attempt to free it
> again, ever.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Hi!

I see the other 6 patches from this series are in -next, but the
refcount_t implementation is still missing. What's needed to land this
in -next? It's blocking sending the atomic_t -> refcount_t patches,
which will likely all go through various maintainers, so we need to
have refcount_t first. :)

Thanks!

-Kees

-- 
Kees Cook
Nexus Security

[toc] | [next] | [standalone]

#1568010

On Thu, Jan 26, 2017 at 03:14:41PM -0800, Kees Cook wrote:
> On Mon, Nov 14, 2016 at 9:39 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > Provide refcount_t, an atomic_t like primitive built just for
> > refcounting.
> >
> > It provides overflow and underflow checks as well as saturation
> > semantics such that when it overflows, we'll never attempt to free it
> > again, ever.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> 
> Hi!
> 
> I see the other 6 patches from this series are in -next, but the
> refcount_t implementation is still missing. What's needed to land this
> in -next? It's blocking sending the atomic_t -> refcount_t patches,
> which will likely all go through various maintainers, so we need to
> have refcount_t first. :)

Nothing much, except lack of time. I spend the last several days hunting
bugs, that trumps new features on my todo list.

[toc] | [prev] | [next] | [standalone]

#1568686

On Fri, Jan 27, 2017 at 1:58 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, Jan 26, 2017 at 03:14:41PM -0800, Kees Cook wrote:
>> On Mon, Nov 14, 2016 at 9:39 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > Provide refcount_t, an atomic_t like primitive built just for
>> > refcounting.
>> >
>> > It provides overflow and underflow checks as well as saturation
>> > semantics such that when it overflows, we'll never attempt to free it
>> > again, ever.
>> >
>> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>>
>> Hi!
>>
>> I see the other 6 patches from this series are in -next, but the
>> refcount_t implementation is still missing. What's needed to land this
>> in -next? It's blocking sending the atomic_t -> refcount_t patches,
>> which will likely all go through various maintainers, so we need to
>> have refcount_t first. :)
>
> Nothing much, except lack of time. I spend the last several days hunting
> bugs, that trumps new features on my todo list.

Totally understood. I was just trying to see if there was anything I
could help with for it. Are you expecting it to change much from your
original posted version?

-Kees

-- 
Kees Cook
Nexus Security

[toc] | [prev] | [next] | [standalone]

#1569746

On Fri, Jan 27, 2017 at 01:07:35PM -0800, Kees Cook wrote:
> On Fri, Jan 27, 2017 at 1:58 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > Nothing much, except lack of time. I spend the last several days hunting
> > bugs, that trumps new features on my todo list.
> 
> Totally understood. I was just trying to see if there was anything I
> could help with for it. Are you expecting it to change much from your
> original posted version?

There's a few things I wanted to play with, but I suppose we can merge
as is and fix up later. I should hopefully get time to do so this week.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web