gt; Reported-by: syzbot+6cebc1af246fe020a...@syzkaller.appspotmail.com
> References:
> https://lore.kernel.org/dri-devel/26c1ff061cd0d...@google.com/
> Signed-off-by: Daniel Vetter
> Fixes: a8f354284304 ("bcachefs: bch2_print_string_as_lines()")
Reviewed-by: John Ogness
/bcache/bset.c:bch_dump_bucket()
from commit cafe56359144("bcache: A block layer cache")
These should also be removed. Although Kent should verify that the
console lock is not providing some sort of necessary side-effect
synchronization.
John Ogness
lines in between.
There is no way to guarantee a contiguous ringbuffer block using
multiple printk() calls.
The console_lock usage should be removed.
John Ogness
On 2019-03-14, John Ogness wrote:
> On 2019-03-14, Daniel Vetter wrote:
>> That's why we came up with the trylock + immediate bail out design if
>> that fails. Plus really only render the oops int whatever is the
>> current display buffer, so that we don't have to
example, you may have
functions without a return value taking spinlocks. But now those
functions could fail.
John Ogness
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ven if the trylock fails. It only
makes sense to do this if the driver has a chance of being
successful. Ignoring locks is a serious issue. I personally am quite
unhappy that the serial drivers do this, which was part of my motivation
for the new printk design I'm working on.
If the driver
