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

Groups > linux.kernel > #1519399

Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

Show all headers | View raw

On Thu, Nov 10, 2016 at 10:13:10PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 08:48:38PM +0000, Will Deacon wrote:
> > > That said, I still don't much like this.
> > > 
> > > I would much rather you make kref useful and use that. It still means
> > > you get to audit all refcounts in the kernel, but hey, you had to do
> > > that anyway.
> > 
> > What needs to happen to kref to make it useful? Like many others, I've
> > been guilty of using atomic_t for refcounts in the past.
> 
> As it stands kref is a pointless wrapper. If it were to provide
> something actually useful, like wrap protection, then it might actually
> make sense to use it.

It provides the correct cleanup ability for a reference count and the
object it is in, so it's not all that pointless :)

But I'm always willing to change it to make it work better for people,
if kref did the wrapping protection (i.e. used a non-wrapping atomic
type), then you would have that.  I thought that was what this patchset
provided...

And yes, this is a horridly large patchset.  I've looked at these
changes, and in almost all of them, people are using atomic_t as merely
a "counter" for something (sequences, rx/tx stats, etc), to get away
without having to lock it with an external lock.

So, does it make more sense to just provide a "pointless" api for this
type of "counter" pattern:
	counter_inc()
	counter_dec()
	counter_read()
	counter_set()
	counter_add()
	counter_subtract()
Those would use the wrapping atomic type, as they can wrap all they want
and no one really is in trouble.  Once those changes are done, just make
atomic_t not wrap and all should be fine, no other code should need to
be changed.

We can bikeshed on the function names for a while, to let everyone feel
they contributed (counter, kcount, ksequence, sequence_t, cnt_t, etc.)...

And yes, out-of-tree code will work differently, but really, the worse
that could happen is their "sequence number" stops wrapping :)

Would that be a better way to implement this?

thanks,

greg k-h

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra <peterz@infradead.org> - 2016-11-10 21:40 +0100
  Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Will Deacon <will.deacon@arm.com> - 2016-11-10 21:50 +0100
    Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Kees Cook <keescook@chromium.org> - 2016-11-10 22:10 +0100
      Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Kees Cook <keescook@chromium.org> - 2016-11-10 22:30 +0100
        Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC David Windsor <dave@progbits.org> - 2016-11-10 22:50 +0100
      Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC David Windsor <dave@progbits.org> - 2016-11-10 22:30 +0100
        Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra <peterz@infradead.org> - 2016-11-10 22:50 +0100
    Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra <peterz@infradead.org> - 2016-11-10 22:20 +0100
      Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Kees Cook <keescook@chromium.org> - 2016-11-10 22:30 +0100
        Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Rik van Riel <riel@redhat.com> - 2016-11-11 05:40 +0100
      Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Greg KH <gregkh@linuxfoundation.org> - 2016-11-10 23:30 +0100
        Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Kees Cook <keescook@chromium.org> - 2016-11-11 00:20 +0100
          Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Greg KH <gregkh@linuxfoundation.org> - 2016-11-11 00:40 +0100
          Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra <peterz@infradead.org> - 2016-11-11 01:00 +0100
            Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Colin Vidal <colin@cvidal.org> - 2016-11-11 01:30 +0100
              Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Mark Rutland <mark.rutland@arm.com> - 2016-11-11 13:50 +0100
                Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra <peterz@infradead.org> - 2016-11-11 13:50 +0100
                Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra <peterz@infradead.org> - 2016-11-11 14:10 +0100
                Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Peter Zijlstra <peterz@infradead.org> - 2016-11-11 15:50 +0100
                Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Thomas Gleixner <tglx@linutronix.de> - 2016-11-11 15:50 +0100
  Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Kees Cook <keescook@chromium.org> - 2016-11-10 22:00 +0100
    Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC David Windsor <dave@progbits.org> - 2016-11-11 04:30 +0100

csiph-web