lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Jun 2019 11:09:26 +0200 From: John Ogness <john.ogness@...utronix.de> To: Petr Mladek <pmladek@...e.com> Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Steven Rostedt <rostedt@...dmis.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Andrea Parri <andrea.parri@...rulasolutions.com>, Thomas Gleixner <tglx@...utronix.de>, Sergey Senozhatsky <sergey.senozhatsky@...il.com> Subject: Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation On 2019-06-26, Petr Mladek <pmladek@...e.com> wrote: >> To address your question: For the linked list implementation, if you >> are looking at it from the linked list perspective, the number of >> descriptors on the list is constantly fluctuating (increasing and >> decreasing) and the ordering of the descriptors is constantly >> changing. They are ordered according to the writer commit order (not >> the writer reserve order) and the only descriptors on the list are >> the ones that are not within a reserve/commit window. > > This and few other comments below are really valuable explanation. > I misunderstood how the list worked. I will add a documentation section about why a linked list was used. >>>>> If the above is true then we could achieve similar result >>>>> when using the array as a circular buffer. It would be >>>>> the same like when all members are linked from the beginning. >>>> >>>> So you are suggesting using a multi-reader multi-writer lockless >>>> ringbuffer to implement a multi-reader multi-writer lockless >>>> ringbuffer. ;-) >>>> >>>> The descriptor ringbuffer has fixed-size items, which simplifies >>>> the task. But I expect you will run into a chicken-egg scenario. >>> >>> AFAIK, the main obstacle with the fully lockless solution was >>> that the entries did not have a fixed size. >> >> No. The variable size of the records was the reason I used >> descriptors. That has nothing to do with how I chose to connect those >> descriptors. > > I think that we are talking about the same. If I remember correctly, > the main problem is that cmpxchg() is not reliable when the same > address might be used by the metadata and data. The cmpxchg() issue you mention is why I needed descriptors. But even if I were to implement a fixed-record-size ringbuffer where the cmpxchg() issue does not exist, I _still_ would have used a linked list to connect the records. It is misleading to think the linked list is because of variable size records. John Ogness
Powered by blists - more mailing lists