On Fri, Oct 16, 2020 at 03:51:25PM -0700, Kees Cook wrote:
> On Fri, Oct 16, 2020 at 12:53:13PM +0200, Peter Zijlstra wrote:
> > That's like saying: "I'm too lazy to track what I've looked at already".
> > You're basically proposing to graffiti "Kees was here -- 16/10/2020" all
> > over the kernel.
On Fri, Oct 16, 2020 at 12:53:13PM +0200, Peter Zijlstra wrote:
> That's like saying: "I'm too lazy to track what I've looked at already".
> You're basically proposing to graffiti "Kees was here -- 16/10/2020" all
> over the kernel. Just so you can see where you still need to go.
>
> It says the c
On 10/14/20 5:31 PM, Kees Cook wrote:
On Wed, Oct 14, 2020 at 11:17:20AM +0200, Peter Zijlstra wrote:
On Tue, Oct 13, 2020 at 08:12:20PM -0600, Shuah Khan wrote:
They don't add any new behavior, As Kees mentioned they do give us a
way to clearly differentiate atomic usages that can wrap.
No
On Wed, Oct 14, 2020 at 04:31:42PM -0700, Kees Cook wrote:
> On Wed, Oct 14, 2020 at 11:17:20AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 13, 2020 at 08:12:20PM -0600, Shuah Khan wrote:
> >
> > > They don't add any new behavior, As Kees mentioned they do give us a
> > > way to clearly different
On Wed, Oct 14, 2020 at 11:17:20AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2020 at 08:12:20PM -0600, Shuah Khan wrote:
>
> > They don't add any new behavior, As Kees mentioned they do give us a
> > way to clearly differentiate atomic usages that can wrap.
>
> No it doesn't! atomic_t can wr
On Tue, Oct 13, 2020 at 08:12:20PM -0600, Shuah Khan wrote:
> They don't add any new behavior, As Kees mentioned they do give us a
> way to clearly differentiate atomic usages that can wrap.
No it doesn't! atomic_t can wrap, this thing can wrap, no distinction.
All it does is fragment the API an
On 10/10/20 5:09 AM, Peter Zijlstra wrote:
On Fri, Oct 09, 2020 at 01:45:43PM -0700, Kees Cook wrote:
On Fri, Oct 09, 2020 at 09:37:46PM +0200, Peter Zijlstra wrote:
On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote:
Simple atomic counters api provides interfaces for simple atomic cou
On Fri, Oct 09, 2020 at 01:45:43PM -0700, Kees Cook wrote:
> On Fri, Oct 09, 2020 at 09:37:46PM +0200, Peter Zijlstra wrote:
> > On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote:
> > > Simple atomic counters api provides interfaces for simple atomic counters
> > > that just count, and don
On Fri, Oct 09, 2020 at 09:37:46PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote:
> > Simple atomic counters api provides interfaces for simple atomic counters
> > that just count, and don't guard resource lifetimes. The interfaces are
> > built on top of
On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote:
> This patch series is a result of discussion at the refcount_t BOF
> the Linux Plumbers Conference. In this discussion, we identified
> a need for looking closely and investigating atomic_t usages in
> the kernel when it is used strictly
On 10/9/20 12:03 PM, Kees Cook wrote:
On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote:
Note: Would like to get this into Linux 5.10-rc1 so we can continue
updating drivers that can be updated to use this API. If this all looks
good, Kees, would you like to take this through your tree
On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote:
> Note: Would like to get this into Linux 5.10-rc1 so we can continue
> updating drivers that can be updated to use this API. If this all looks
> good, Kees, would you like to take this through your tree or would you
> like to take this th
This patch series is a result of discussion at the refcount_t BOF
the Linux Plumbers Conference. In this discussion, we identified
a need for looking closely and investigating atomic_t usages in
the kernel when it is used strictly as a counter without it
controlling object lifetimes and state chang
13 matches
Mail list logo