On (12/03/18 14:50), Sergey Senozhatsky wrote:
> On (12/03/18 11:40), Minchan Kim wrote:
> [..]
> > + down_read(>init_lock);
> > + atomic64_set(>stats.bd_wb_limit, val);
> > + if (val == 0)
> > + zram->stop_writeb
On (12/03/18 14:50), Sergey Senozhatsky wrote:
> On (12/03/18 11:40), Minchan Kim wrote:
> [..]
> > + down_read(>init_lock);
> > + atomic64_set(>stats.bd_wb_limit, val);
> > + if (val == 0)
> > + zram->stop_writeb
On (12/03/18 11:40), Minchan Kim wrote:
[..]
> + down_read(>init_lock);
> + atomic64_set(>stats.bd_wb_limit, val);
> + if (val == 0)
> + zram->stop_writeback = false;
> + up_read(>init_lock);
[..]
> + if (zram->stop_writeback) {
> + ret
On (12/03/18 11:40), Minchan Kim wrote:
[..]
> + down_read(>init_lock);
> + atomic64_set(>stats.bd_wb_limit, val);
> + if (val == 0)
> + zram->stop_writeback = false;
> + up_read(>init_lock);
[..]
> + if (zram->stop_writeback) {
> + ret
On (12/03/18 11:41), Minchan Kim wrote:
> On Mon, Dec 03, 2018 at 11:30:40AM +0900, Sergey Senozhatsky wrote:
> > On (12/03/18 08:18), Minchan Kim wrote:
> > >
> > > Per andrew's comment:
> > > https://lkml.org/lkml/2018/11/27/156
> > >
> > >
On (12/03/18 11:41), Minchan Kim wrote:
> On Mon, Dec 03, 2018 at 11:30:40AM +0900, Sergey Senozhatsky wrote:
> > On (12/03/18 08:18), Minchan Kim wrote:
> > >
> > > Per andrew's comment:
> > > https://lkml.org/lkml/2018/11/27/156
> > >
> > >
On (12/03/18 08:18), Minchan Kim wrote:
>
> Per andrew's comment:
> https://lkml.org/lkml/2018/11/27/156
>
> I need to fix it to represent 4K always.
Aha.
Then we need to increase bd_writes PAGE_SIZE/4K times in writeback_store()?
wb_count = atomic64_inc_return(>stats.bd_writes);
...
On (12/03/18 08:18), Minchan Kim wrote:
>
> Per andrew's comment:
> https://lkml.org/lkml/2018/11/27/156
>
> I need to fix it to represent 4K always.
Aha.
Then we need to increase bd_writes PAGE_SIZE/4K times in writeback_store()?
wb_count = atomic64_inc_return(>stats.bd_writes);
...
On (11/30/18 12:59), Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 02:41:11PM -0500, Steven Rostedt wrote:
> > Since the code has been greatly modified since that comment was added,
> > I would say the comment is simply out of date.
> >
> > Just nuke the comment, and that will be an accurate
On (11/30/18 12:59), Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 02:41:11PM -0500, Steven Rostedt wrote:
> > Since the code has been greatly modified since that comment was added,
> > I would say the comment is simply out of date.
> >
> > Just nuke the comment, and that will be an accurate
t two patches are -stable material so it could go first
> separately with others in this series.
I had some time to look at the patches
Reviewed-by: Sergey Senozhatsky
Will give it some testing later; next week maybe.
-ss
t two patches are -stable material so it could go first
> separately with others in this series.
I had some time to look at the patches
Reviewed-by: Sergey Senozhatsky
Will give it some testing later; next week maybe.
-ss
On (11/29/18 15:19), Petr Mladek wrote:
> This fixes a real problem. It might even avoid a crash.
>
> See syslog_print_all() and kmsg_dump_get_buffer(). They
> start with calling msg_print_text() many times to calculate
> how many messages fit into the given buffer. Then they
> blindly copy the
On (11/29/18 15:19), Petr Mladek wrote:
> This fixes a real problem. It might even avoid a crash.
>
> See syslog_print_all() and kmsg_dump_get_buffer(). They
> start with calling msg_print_text() many times to calculate
> how many messages fit into the given buffer. Then they
> blindly copy the
On (11/29/18 10:21), Dave Rodgman wrote:
> > [..]
> >> +++ b/drivers/block/zram/zcomp.c
> >> @@ -20,6 +20,7 @@
> >>
> >> static const char * const backends[] = {
> >>"lzo",
> >> + "lzo-rle",
> >> #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
> >>"lz4",
> >> #endif
> >
> > [..]
> >
> >> +++
On (11/29/18 10:21), Dave Rodgman wrote:
> > [..]
> >> +++ b/drivers/block/zram/zcomp.c
> >> @@ -20,6 +20,7 @@
> >>
> >> static const char * const backends[] = {
> >>"lzo",
> >> + "lzo-rle",
> >> #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
> >>"lz4",
> >> #endif
> >
> > [..]
> >
> >> +++
On (11/27/18 16:19), Dave Rodgman wrote:
> > Right. The number is data dependent. Not all swapped out pages can be
> > compressed; compressed pages that end up being >= zs_huge_class_size() are
> > considered incompressible and stored as it.
> >
> > I'd say that on my setups around 50-60% of
On (11/27/18 16:19), Dave Rodgman wrote:
> > Right. The number is data dependent. Not all swapped out pages can be
> > compressed; compressed pages that end up being >= zs_huge_class_size() are
> > considered incompressible and stored as it.
> >
> > I'd say that on my setups around 50-60% of
On (11/27/18 16:19), Dave Rodgman wrote:
> Documentation/lzo.txt | 12 ++-
> crypto/Makefile | 2 +-
> crypto/lzo-rle.c | 175
> ++
> crypto/tcrypt.c | 4 +-
> drivers/block/zram/zcomp.c| 1 +
>
On (11/27/18 16:19), Dave Rodgman wrote:
> Documentation/lzo.txt | 12 ++-
> crypto/Makefile | 2 +-
> crypto/lzo-rle.c | 175
> ++
> crypto/tcrypt.c | 4 +-
> drivers/block/zram/zcomp.c| 1 +
>
On (11/29/18 12:08), Sergey Senozhatsky wrote:
> On (11/27/18 16:19), Dave Rodgman wrote:
> >
> > This modifies the bitstream in a way which is backwards compatible
> > (i.e., we can decompress old bitstreams, but old versions of lzo
> > cannot decompress new bitstre
On (11/29/18 12:08), Sergey Senozhatsky wrote:
> On (11/27/18 16:19), Dave Rodgman wrote:
> >
> > This modifies the bitstream in a way which is backwards compatible
> > (i.e., we can decompress old bitstreams, but old versions of lzo
> > cannot decompress new bitstre
On (11/27/18 16:19), Dave Rodgman wrote:
>
> This modifies the bitstream in a way which is backwards compatible
> (i.e., we can decompress old bitstreams, but old versions of lzo
> cannot decompress new bitstreams).
>
Hmmm... Whoa. Help me understand this:
So a btrfs filesystem, compressed with
On (11/27/18 16:19), Dave Rodgman wrote:
>
> This modifies the bitstream in a way which is backwards compatible
> (i.e., we can decompress old bitstreams, but old versions of lzo
> cannot decompress new bitstreams).
>
Hmmm... Whoa. Help me understand this:
So a btrfs filesystem, compressed with
On (11/27/18 18:33), Rafael David Tinoco wrote:
> On 11/20/18 10:18 PM, Rafael David Tinoco wrote:
> >
> > Russell,
> >
> > I have tried to place MAX_POSSIBLE_PHYSMEM_BITS in the best available
> > header for each architecture, considering different paging levels, PAE
> > existence, and existing
On (11/27/18 18:33), Rafael David Tinoco wrote:
> On 11/20/18 10:18 PM, Rafael David Tinoco wrote:
> >
> > Russell,
> >
> > I have tried to place MAX_POSSIBLE_PHYSMEM_BITS in the best available
> > header for each architecture, considering different paging levels, PAE
> > existence, and existing
> The other problem is zram_slot_lock in zram_slot_slot_free_notify.
> To make it safe is this patch introduces zram_slot_trylock where
> zram_slot_free_notify uses it. Although it's rare to be contented,
> this patch adds new debug stat "miss_free" to keep monitoring
> how often it happens.
>
> Signed-off-by: Minchan Kim
Reviewed-by: Sergey Senozhatsky
-ss
> The other problem is zram_slot_lock in zram_slot_slot_free_notify.
> To make it safe is this patch introduces zram_slot_trylock where
> zram_slot_free_notify uses it. Although it's rare to be contented,
> this patch adds new debug stat "miss_free" to keep monitoring
> how often it happens.
>
> Signed-off-by: Minchan Kim
Reviewed-by: Sergey Senozhatsky
-ss
__free_pages_ok+0x1e3/0x490
> [ 31.112437] hardirqs last disabled at (4466): []
> trace_hardirqs_off_thunk+0x1a/0x1c
> [ 31.113973] softirqs last enabled at (3420): []
> __do_softirq+0x333/0x446
> [ 31.115364] softirqs last disabled at (3407): []
> irq_exit+0xd1/0xe0
>
> Cc: sta...@vger.kernel.org # 4.14+
> Signed-off-by: Minchan Kim
Good catch.
Reviewed-by: Sergey Senozhatsky
-ss
__free_pages_ok+0x1e3/0x490
> [ 31.112437] hardirqs last disabled at (4466): []
> trace_hardirqs_off_thunk+0x1a/0x1c
> [ 31.113973] softirqs last enabled at (3420): []
> __do_softirq+0x333/0x446
> [ 31.115364] softirqs last disabled at (3407): []
> irq_exit+0xd1/0xe0
>
> Cc: sta...@vger.kernel.org # 4.14+
> Signed-off-by: Minchan Kim
Good catch.
Reviewed-by: Sergey Senozhatsky
-ss
On (11/27/18 14:54), Minchan Kim wrote:
> To support idle page writeback with upcoming patches, this patch
> introduces a new ZRAM_IDLE flag.
>
> Userspace can mark zram slots as "idle" via
> "echo all > /sys/block/zramX/idle"
> which marks every allocated zram slot as ZRAM_IDLE.
> User
On (11/27/18 14:54), Minchan Kim wrote:
> To support idle page writeback with upcoming patches, this patch
> introduces a new ZRAM_IDLE flag.
>
> Userspace can mark zram slots as "idle" via
> "echo all > /sys/block/zramX/idle"
> which marks every allocated zram slot as ZRAM_IDLE.
> User
On (11/27/18 14:54), Minchan Kim wrote:
> diff --git a/Documentation/ABI/testing/sysfs-block-zram
> b/Documentation/ABI/testing/sysfs-block-zram
> index 65fc33b2f53b..9d2339a485c8 100644
> --- a/Documentation/ABI/testing/sysfs-block-zram
> +++ b/Documentation/ABI/testing/sysfs-block-zram
> @@
On (11/27/18 14:54), Minchan Kim wrote:
> diff --git a/Documentation/ABI/testing/sysfs-block-zram
> b/Documentation/ABI/testing/sysfs-block-zram
> index 65fc33b2f53b..9d2339a485c8 100644
> --- a/Documentation/ABI/testing/sysfs-block-zram
> +++ b/Documentation/ABI/testing/sysfs-block-zram
> @@
On (11/26/18 21:23), Tamir Carmeli wrote:
> Thanks for the reply and sorry for my noob question:
> Wasn't I supposed to send this patch also to the FAT maintainer, OGAWA
> Hirofumi?
Yes.
> His name wasn't on the get_maintainer output, and I think
> that this specific file isn't listed anywhere
On (11/26/18 21:23), Tamir Carmeli wrote:
> Thanks for the reply and sorry for my noob question:
> Wasn't I supposed to send this patch also to the FAT maintainer, OGAWA
> Hirofumi?
Yes.
> His name wasn't on the get_maintainer output, and I think
> that this specific file isn't listed anywhere
On (11/24/18 23:28), Tetsuo Handa wrote:
> Since /sys/module/printk/parameters/time can change from N to Y between
> "msg_print_text() called print_prefix() with buf == NULL" and
> "msg_print_text() again calls print_prefix() with buf != NULL", it is not
> safe for print_time() to unconditionally
On (11/24/18 23:28), Tetsuo Handa wrote:
> Since /sys/module/printk/parameters/time can change from N to Y between
> "msg_print_text() called print_prefix() with buf == NULL" and
> "msg_print_text() again calls print_prefix() with buf != NULL", it is not
> safe for print_time() to unconditionally
And I forgot to actually Cc Petr and Steven...
Top-posting.
---
Hi,
Cc-ing Petr and Steven
On (11/25/18 01:13), Joe Perches wrote:
> commit 04b8eb7a4ccd ("symbol lookup: introduce
> dereference_symbol_descriptor()}"
>
> deprecated vsprintf extension %pf and %pF.
>
> There are
And I forgot to actually Cc Petr and Steven...
Top-posting.
---
Hi,
Cc-ing Petr and Steven
On (11/25/18 01:13), Joe Perches wrote:
> commit 04b8eb7a4ccd ("symbol lookup: introduce
> dereference_symbol_descriptor()}"
>
> deprecated vsprintf extension %pf and %pF.
>
> There are
Hi,
Cc-ing Petr and Steven
On (11/25/18 01:13), Joe Perches wrote:
> commit 04b8eb7a4ccd ("symbol lookup: introduce
> dereference_symbol_descriptor()}"
>
> deprecated vsprintf extension %pf and %pF.
>
> There are approximately these total uses of the symbolic
> lookup vsprintf extensions
Hi,
Cc-ing Petr and Steven
On (11/25/18 01:13), Joe Perches wrote:
> commit 04b8eb7a4ccd ("symbol lookup: introduce
> dereference_symbol_descriptor()}"
>
> deprecated vsprintf extension %pf and %pF.
>
> There are approximately these total uses of the symbolic
> lookup vsprintf extensions
-off-by: Carmeli Tamir
Looks good to me,
Reviewed-by: Sergey Senozhatsky
-ss
-off-by: Carmeli Tamir
Looks good to me,
Reviewed-by: Sergey Senozhatsky
-ss
d to me,
Reviewed-by: Sergey Senozhatsky
-ss
d to me,
Reviewed-by: Sergey Senozhatsky
-ss
On (11/24/18 09:24), Tetsuo Handa wrote:
> >> Steven told me on Plumbers conference that even few initial
> >> characters saved him a day few times.
> >
> > Yes, and that has happened more than once. I would reboot and retest
> > code that is crashing, and due to a triple fault, the machine would
On (11/24/18 09:24), Tetsuo Handa wrote:
> >> Steven told me on Plumbers conference that even few initial
> >> characters saved him a day few times.
> >
> > Yes, and that has happened more than once. I would reboot and retest
> > code that is crashing, and due to a triple fault, the machine would
On (11/22/18 15:15), Petr Mladek wrote:
> The commit cefc8be82403cf ("Consolidate bust_spinlocks()") kept
> the s390-specific implementation because of the absence of CONFIG_VT.
> In fact, the only difference was calling console_unblank() instead of
> unblank_screen().
>
> The common
On (11/22/18 15:15), Petr Mladek wrote:
> The commit cefc8be82403cf ("Consolidate bust_spinlocks()") kept
> the s390-specific implementation because of the absence of CONFIG_VT.
> In fact, the only difference was calling console_unblank() instead of
> unblank_screen().
>
> The common
On (11/21/18 12:06), Dave Rodgman wrote:
>
> Overall, performance is improved by around 1.1 - 4.8x (data-dependent: data
> with many zero runs shows higher improvement). Under real-world testing with
> zram, time spent in (de)compression during swapping is reduced by around 27%.
Impressive.
I
On (11/21/18 12:06), Dave Rodgman wrote:
>
> Overall, performance is improved by around 1.1 - 4.8x (data-dependent: data
> with many zero runs shows higher improvement). Under real-world testing with
> zram, time spent in (de)compression during swapping is reduced by around 27%.
Impressive.
I
On (11/22/18 15:31), Minchan Kim wrote:
> >
> > I got what you mean now. Let's call it as "incompressible page wrieback"
> > to prevent confusing.
> >
> > "incompressible page writeback" would be orthgonal feature. The goal is
> > "let's save memory at the cost of *latency*". If the page is
On (11/22/18 15:31), Minchan Kim wrote:
> >
> > I got what you mean now. Let's call it as "incompressible page wrieback"
> > to prevent confusing.
> >
> > "incompressible page writeback" would be orthgonal feature. The goal is
> > "let's save memory at the cost of *latency*". If the page is
On (11/22/18 14:11), Minchan Kim wrote:
>
> It was a option when I imagined this idea first but problem from product
> division was memory waste of ac_time for every zram table.
OK, I see.
-ss
On (11/22/18 14:11), Minchan Kim wrote:
>
> It was a option when I imagined this idea first but problem from product
> division was memory waste of ac_time for every zram table.
OK, I see.
-ss
On (11/22/18 14:04), Minchan Kim wrote:
>
> > additionally, it's too simple. It writes-back pages which can be
> > swapped in immediately; which basically means that we do pointless
> > PAGE_SIZE writes to a device which doesn't really like pointless
> > writes.
>
> This patchset aims for *IDLE
On (11/22/18 14:04), Minchan Kim wrote:
>
> > additionally, it's too simple. It writes-back pages which can be
> > swapped in immediately; which basically means that we do pointless
> > PAGE_SIZE writes to a device which doesn't really like pointless
> > writes.
>
> This patchset aims for *IDLE
On (11/21/18 05:34), Minchan Kim wrote:
> >
> > Just a thought,
> >
> > I wonder if it will make sense (and if it will be possible) to writeback
> > idle _compressed_ objects. Right now we decompress, say, a perfectly
> > fine 400-byte compressed object to a PAGE_SIZE-d object and then push
> >
On (11/21/18 05:34), Minchan Kim wrote:
> >
> > Just a thought,
> >
> > I wonder if it will make sense (and if it will be possible) to writeback
> > idle _compressed_ objects. Right now we decompress, say, a perfectly
> > fine 400-byte compressed object to a PAGE_SIZE-d object and then push
> >
On (11/16/18 16:20), Minchan Kim wrote:
> + zram_set_flag(zram, index, ZRAM_UNDER_WB);
> + zram_slot_unlock(zram, index);
> + if (zram_bvec_read(zram, , index, 0, NULL)) {
> + zram_slot_lock(zram, index);
> +
On (11/16/18 16:20), Minchan Kim wrote:
> + zram_set_flag(zram, index, ZRAM_UNDER_WB);
> + zram_slot_unlock(zram, index);
> + if (zram_bvec_read(zram, , index, 0, NULL)) {
> + zram_slot_lock(zram, index);
> +
Hello,
On (11/16/18 16:20), Minchan Kim wrote:
[..]
> +static ssize_t idle_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + struct zram *zram = dev_to_zram(dev);
> + unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
> +
Hello,
On (11/16/18 16:20), Minchan Kim wrote:
[..]
> +static ssize_t idle_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + struct zram *zram = dev_to_zram(dev);
> + unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
> +
On (11/09/18 15:10), Petr Mladek wrote:
> >
> > If I'm not mistaken, this is for the futute "printk injection" work.
>
> The above code only tries to push complete lines to the main log buffer
> and consoles ASAP. It sounds like a Good Idea(tm).
Probably it is. So *quite likely* I'm wrong here.
On (11/09/18 15:10), Petr Mladek wrote:
> >
> > If I'm not mistaken, this is for the futute "printk injection" work.
>
> The above code only tries to push complete lines to the main log buffer
> and consoles ASAP. It sounds like a Good Idea(tm).
Probably it is. So *quite likely* I'm wrong here.
On (11/01/18 09:05), Daniel Wang wrote:
> > Another deadlock scenario could be the following one:
> >
> > printk()
> > console_trylock()
> > down_trylock()
> >raw_spin_lock_irqsave(>lock, flags)
> >
> > panic()
> >
On (11/01/18 09:05), Daniel Wang wrote:
> > Another deadlock scenario could be the following one:
> >
> > printk()
> > console_trylock()
> > down_trylock()
> >raw_spin_lock_irqsave(>lock, flags)
> >
> > panic()
> >
On (11/08/18 20:37), Tetsuo Handa wrote:
> On 2018/11/08 13:45, Sergey Senozhatsky wrote:
> > So, can we just do the following? /* a sketch */
> >
> > lockdep.c
> > printk_safe_enter_irqsave(flags);
> > lockdep_report();
> > printk_safe_exit_irqr
On (11/08/18 20:37), Tetsuo Handa wrote:
> On 2018/11/08 13:45, Sergey Senozhatsky wrote:
> > So, can we just do the following? /* a sketch */
> >
> > lockdep.c
> > printk_safe_enter_irqsave(flags);
> > lockdep_report();
> > printk_safe_exit_irqr
On (11/08/18 21:44), Sergey Senozhatsky wrote:
>
> If lockdep and OOM people will ACK buffered printk transition in
> its current form, then we can go ahead.
That printk_safe approach in lockdep, BTW, does not change (convert)
any printk-s within lockdep, thus Peter's earlyc
On (11/08/18 21:44), Sergey Senozhatsky wrote:
>
> If lockdep and OOM people will ACK buffered printk transition in
> its current form, then we can go ahead.
That printk_safe approach in lockdep, BTW, does not change (convert)
any printk-s within lockdep, thus Peter's earlyc
On (11/08/18 12:53), Petr Mladek wrote:
> > lockdep.c
> > printk_safe_enter_irqsave(flags);
> > lockdep_report();
> > printk_safe_exit_irqrestore(flags);
>
> All this looks nice. Let's look it also from the other side.
> The following comes to my mind:
>
> a) lockdep is not the only
On (11/08/18 12:53), Petr Mladek wrote:
> > lockdep.c
> > printk_safe_enter_irqsave(flags);
> > lockdep_report();
> > printk_safe_exit_irqrestore(flags);
>
> All this looks nice. Let's look it also from the other side.
> The following comes to my mind:
>
> a) lockdep is not the only
On (11/08/18 12:24), Petr Mladek wrote:
> I believe that I mentioned this more times. 16 buffers is the first
> attempt. We could improve it later in several ways
Sure. Like I said - maybe it is a normal development pattern; I really
don't know.
> > Let's have one more look at what we will fix
On (11/08/18 12:24), Petr Mladek wrote:
> I believe that I mentioned this more times. 16 buffers is the first
> attempt. We could improve it later in several ways
Sure. Like I said - maybe it is a normal development pattern; I really
don't know.
> > Let's have one more look at what we will fix
On (11/07/18 16:19), Petr Mladek wrote:
> > syzbot is sometimes getting mixed output like below due to concurrent
> > printk(). Mitigate such output by using line-buffered printk() API.
> >
> > @@ -2421,18 +2458,20 @@ static void check_chain_key(struct task_struct
> > *curr)
> >
On (11/07/18 16:19), Petr Mladek wrote:
> > syzbot is sometimes getting mixed output like below due to concurrent
> > printk(). Mitigate such output by using line-buffered printk() API.
> >
> > @@ -2421,18 +2458,20 @@ static void check_chain_key(struct task_struct
> > *curr)
> >
On (11/07/18 19:52), Tetsuo Handa wrote:
> > A question.
> >
> > How bad would it actually be to:
> >
> > - Allocate seq_buf 512-bytes buffer (GFP_ATOMIC) just-in-time, when we
> > need it.
> > // How often systems cannot allocate a 512-byte buffer? //
>
> It is a very bad thing to do
On (11/07/18 19:52), Tetsuo Handa wrote:
> > A question.
> >
> > How bad would it actually be to:
> >
> > - Allocate seq_buf 512-bytes buffer (GFP_ATOMIC) just-in-time, when we
> > need it.
> > // How often systems cannot allocate a 512-byte buffer? //
>
> It is a very bad thing to do
to flush buffered printk
buffers on panic
- I don't exactly like the completely of the vprintk_buffered. If
buffered printk is for single line, then it must be for single
line only. And I'm not buying the "we will need this for printk
origin info injection" argument.
Linus was ver
to flush buffered printk
buffers on panic
- I don't exactly like the completely of the vprintk_buffered. If
buffered printk is for single line, then it must be for single
line only. And I'm not buying the "we will need this for printk
origin info injection" argument.
Linus was ver
On (11/02/18 22:31), Tetsuo Handa wrote:
> (1) Call get_printk_buffer() and acquire "struct printk_buffer *".
>
> (2) Rewrite printk() calls in the following way. The "ptr" is
> "struct printk_buffer *" obtained in step (1).
>
> printk(fmt, ...) => printk_buffered(ptr, fmt,
On (11/02/18 22:31), Tetsuo Handa wrote:
> (1) Call get_printk_buffer() and acquire "struct printk_buffer *".
>
> (2) Rewrite printk() calls in the following way. The "ptr" is
> "struct printk_buffer *" obtained in step (1).
>
> printk(fmt, ...) => printk_buffered(ptr, fmt,
On (11/06/18 09:38), Petr Mladek wrote:
>
> If you would want to avoid buffering, you could set the number
> of buffers to zero. Then it would always fallback to
> the direct printk().
This printk-fallback makes me wonder if 'cont' really can ever go away.
We would totally break cont printk-s
On (11/06/18 09:38), Petr Mladek wrote:
>
> If you would want to avoid buffering, you could set the number
> of buffers to zero. Then it would always fallback to
> the direct printk().
This printk-fallback makes me wonder if 'cont' really can ever go away.
We would totally break cont printk-s
On (10/31/18 13:27), Petr Mladek wrote:
> >
> > Signed-off-by: Sergey Senozhatsky
>
> The patch makes sense to me. The locks should stay busted also for
> console_flush_on_panic().
>
> With the added #include :
>
> Reviewed-by: Petr Mladek
Thanks!
Since th
On (10/31/18 13:27), Petr Mladek wrote:
> >
> > Signed-off-by: Sergey Senozhatsky
>
> The patch makes sense to me. The locks should stay busted also for
> console_flush_on_panic().
>
> With the added #include :
>
> Reviewed-by: Petr Mladek
Thanks!
Since th
lude
This should fix it.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: Sergey Senozhatsky
Subject: [PATCH] panic: avoid deadlocks in re-entrant console drivers
>From printk()/serial console point of view panic() is special, because
it may force CPU to re-enter printk() or/and serial console dr
lude
This should fix it.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: Sergey Senozhatsky
Subject: [PATCH] panic: avoid deadlocks in re-entrant console drivers
>From printk()/serial console point of view panic() is special, because
it may force CPU to re-enter printk() or/and serial console dr
ush_on_panic().
Signed-off-by: Sergey Senozhatsky
---
v2: do not do bust_spinlocks(1);bust_spinlocks(0);bust_spinlocks(1)
thing and just copy paste from lib/bust_spinlocks what
bust_spinlocks(0) does. (Petr)
kernel/panic.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
di
ush_on_panic().
Signed-off-by: Sergey Senozhatsky
---
v2: do not do bust_spinlocks(1);bust_spinlocks(0);bust_spinlocks(1)
thing and just copy paste from lib/bust_spinlocks what
bust_spinlocks(0) does. (Petr)
kernel/panic.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
di
On (10/25/18 11:06), Petr Mladek wrote:
>
> IMHO, the custom s390 implementation can get removed.
> The generic code should do the same job these days.
>
Yep.
> > And console_unblank() is not guaranteed to print anything (unlike
> > console_flush_on_panic(), but oops is not panic() yet, so we
On (10/25/18 11:06), Petr Mladek wrote:
>
> IMHO, the custom s390 implementation can get removed.
> The generic code should do the same job these days.
>
Yep.
> > And console_unblank() is not guaranteed to print anything (unlike
> > console_flush_on_panic(), but oops is not panic() yet, so we
On (10/25/18 10:29), Petr Mladek wrote:
>
> Yes, klogd is not a big deal. I just think that the bust_spinlocks()
> ping-pong would just confuse the code.
I agree; that's why I put some comments there.
> It might be better to keep the spinlocks busted and make sure that we do
> not cause
On (10/25/18 10:29), Petr Mladek wrote:
>
> Yes, klogd is not a big deal. I just think that the bust_spinlocks()
> ping-pong would just confuse the code.
I agree; that's why I put some comments there.
> It might be better to keep the spinlocks busted and make sure that we do
> not cause
eantime. So if we change this I'd prefer that we switch s390 to the
> > common code variant as well. Right now I can't see a reason for not
> > doing that
> >
> > This patch removes s390 bust_spinlocks() and drops the weak attribute
> > from the common bust_spinlocks() vers
eantime. So if we change this I'd prefer that we switch s390 to the
> > common code variant as well. Right now I can't see a reason for not
> > doing that
> >
> > This patch removes s390 bust_spinlocks() and drops the weak attribute
> > from the common bust_spinlocks() vers
ch just
> removes this variant and makes s390 use the generic one too.
>
> We'll see if there is any fallout...
Heiko, if this one works for you then I'll submit a format patch.
Let me know. Thanks.
From: Sergey Senozhatsky
Subject: [PATCH] arch/s390: use common bust_spinlocks()
s390 is
ch just
> removes this variant and makes s390 use the generic one too.
>
> We'll see if there is any fallout...
Heiko, if this one works for you then I'll submit a format patch.
Let me know. Thanks.
From: Sergey Senozhatsky
Subject: [PATCH] arch/s390: use common bust_spinlocks()
s390 is
701 - 800 of 6882 matches
Mail list logo
