Re: [RFC][PATCHv2 3/4] serial: introduce uart_port locking helpers

2018-12-07 Thread Sergey Senozhatsky
On (10/16/18 14:04), Sergey Senozhatsky wrote: [..] > - The first entry point is console ->write() callback, which we call > from printk(). A possible deadlock scenario there is: > > CPU0 > > spin_lock_irqsave(>lock, flags) << dea

Re: [PATCH] printk: Add caller information to printk() output.

2018-12-06 Thread Sergey Senozhatsky
On (12/07/18 13:58), Tetsuo Handa wrote: > > All you need is a way to reconstruct a message around > > some very specific place in the log - say in a range [-500, +500] lines, > > assuming that a backtrace you are trying to reconstruct is badly fragmented. > > I think, even 3

Re: [PATCH] printk: Add caller information to printk() output.

2018-12-05 Thread Sergey Senozhatsky
On (12/05/18 19:42), Tetsuo Handa wrote: > >> > >> PID_MAX_LIMIT is 4194304, which can take up to 10 bytes if [T%u] is used. > > > > 4194304 is the worst case. I would use the same approach as with the > > timestamp seconds. It uses 5 characters as the minimum. But it might > > eventully get

Re: [PATCH v4 0/7] lib/lzo: performance improvements

2018-12-05 Thread Sergey Senozhatsky
On (12/05/18 09:50), Dave Rodgman wrote: > > lib/lzo/lzo1x_compress.c: In function ‘lzo1x_1_do_compress’: > > lib/lzo/lzo1x_compress.c:239:14: warning: ‘m_pos’ may be used uninitialized > > in this function [-Wmaybe-uninitialized] > > 239 | m_off = ip - m_pos; > > > > Care to take a look?

Re: [PATCH v4 0/7] lib/lzo: performance improvements

2018-12-04 Thread Sergey Senozhatsky
On (11/30/18 14:26), Dave Rodgman wrote: > > This patch series introduces performance improvements for lzo. > > The previous version of this patchset is here: > https://lkml.org/lkml/2018/11/30/807 > > This version of the patchset fixes a maybe-used-uninitialized warning > (although the

Re: [PATCH] printk: don't unconditionally shortcut print_time()

2018-12-04 Thread Sergey Senozhatsky
On (12/04/18 19:06), Tetsuo Handa wrote: > On 2018/12/04 11:56, Sergey Senozhatsky wrote: > > Can we please have something better than 'f'? > > OK. To pass 80 column limit, one line increased. ;-) Ah, so that was the reason :) [..] > To close this race, get a snapshot va

Re: [PATCH] printk: Add caller information to printk() output.

2018-12-04 Thread Sergey Senozhatsky
On (12/04/18 19:16), Tetsuo Handa wrote: > On 2018/12/04 11:02, Sergey Senozhatsky wrote: > > On (12/02/18 20:23), Tetsuo Handa wrote: > >> > >> Some examples for console output: > >> > >> [0.919699]@T1 x86: Booting SMP configuration: > >>

Re: [PATCH] printk: don't unconditionally shortcut print_time()

2018-12-03 Thread Sergey Senozhatsky
On (12/02/18 14:02), Tetsuo Handa wrote: > > @@ -1541,11 +1545,13 @@ int do_syslog(int type, char __user *buf, int len, > int source) > } else { > u64 seq = syslog_seq; > u32 idx = syslog_idx; > + bool f =

Re: [PATCH v4 0/7] zram idle page writeback

2018-12-03 Thread Sergey Senozhatsky
iteback > zram: add bd_stat statistics > zram: writeback throttle Looks good to me. Reviewed-by: Sergey Senozhatsky -ss

Re: [PATCH] printk: Add caller information to printk() output.

2018-12-03 Thread Sergey Senozhatsky
On (12/02/18 20:23), Tetsuo Handa wrote: > > Some examples for console output: > > [0.919699]@T1 x86: Booting SMP configuration: > [4.152681]@T271 Fusion MPT base driver 3.04.20 > [5.070470]@C0 random: fast init done > [6.587900]@C3 random: crng init done This is hard to

Re: [PATCH v4 7/7] zram: writeback throttle

2018-12-02 Thread Sergey Senozhatsky
On (12/03/18 15:02), Sergey Senozhatsky wrote: > Seems like I misread writeback_limit_store() a bit. > > So, if I want to, say, let only 10M of writteback pages, I need to > do > > echo 0 > writeback_limit > echo 10M > writeback_limit_stor

Re: [PATCH v4 7/7] zram: writeback throttle

2018-12-02 Thread Sergey Senozhatsky
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

Re: [PATCH v4 7/7] zram: writeback throttle

2018-12-02 Thread Sergey Senozhatsky
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

Re: [PATCH v3 7/7] zram: writeback throttle

2018-12-02 Thread Sergey Senozhatsky
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 > > > > > >

Re: [PATCH v3 7/7] zram: writeback throttle

2018-12-02 Thread Sergey Senozhatsky
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); ...

Re: [PATCH RFC 14/15] lib: replace **** with a hug

2018-12-01 Thread Sergey Senozhatsky
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

Re: [PATCH v3 0/7] zram idle page writeback

2018-11-29 Thread Sergey Senozhatsky
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

Re: [PATCH] printk: don't unconditionally shortcut print_time()

2018-11-29 Thread Sergey Senozhatsky
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

Re: [PATCH 7/7] lib/lzo: separate lzo-rle from lzo

2018-11-29 Thread Sergey Senozhatsky
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 > > > > [..] > > > >> +++

Re: [PATCH v2 0/7] lib/lzo: performance improvements

2018-11-28 Thread Sergey Senozhatsky
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

Re: [PATCH 7/7] lib/lzo: separate lzo-rle from lzo

2018-11-28 Thread Sergey Senozhatsky
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 + >

Re: [PATCH 6/7] lib/lzo: implement run-length encoding

2018-11-28 Thread Sergey Senozhatsky
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

Re: [PATCH 6/7] lib/lzo: implement run-length encoding

2018-11-28 Thread Sergey Senozhatsky
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

Re: [PATCH v2] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support

2018-11-28 Thread Sergey Senozhatsky
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

Re: [PATCH v3 1/7] zram: fix lockdep warning of free block handling

2018-11-28 Thread Sergey Senozhatsky
> 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

Re: [PATCH v3 2/7] zram: fix double free backing device

2018-11-28 Thread Sergey Senozhatsky
__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

Re: [PATCH v3 4/7] zram: introduce ZRAM_IDLE flag

2018-11-28 Thread Sergey Senozhatsky
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

Re: [PATCH v3 7/7] zram: writeback throttle

2018-11-28 Thread Sergey Senozhatsky
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 > @@

Re: [PATCH] fat: Replaced 11 magic to MSDOS_NAME for volume label

2018-11-26 Thread Sergey Senozhatsky
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

Re: [PATCH] printk: deduplicate print_prefix() calls

2018-11-25 Thread Sergey Senozhatsky
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

Re: RFC: script to convert vsprintf uses of %pf to %ps and %pF to %pS

2018-11-25 Thread Sergey Senozhatsky
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

Re: RFC: script to convert vsprintf uses of %pf to %ps and %pF to %pS

2018-11-25 Thread Sergey Senozhatsky
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

Re: [PATCH] fat: Replaced 11 magic to MSDOS_NAME for volume label

2018-11-25 Thread Sergey Senozhatsky
-off-by: Carmeli Tamir Looks good to me, Reviewed-by: Sergey Senozhatsky -ss

Re: [PATCH] printk: Make printk_emit() local function.

2018-11-25 Thread Sergey Senozhatsky
d to me, Reviewed-by: Sergey Senozhatsky -ss

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-25 Thread Sergey Senozhatsky
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

Re: [PATCH] s390: Remove obsolete bust_spinlock() implementation

2018-11-22 Thread Sergey Senozhatsky
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

Re: [PATCH 0/6] lib/lzo: performance improvements

2018-11-22 Thread Sergey Senozhatsky
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

Re: [PATCH 4/6] zram: support idle page writeback

2018-11-21 Thread Sergey Senozhatsky
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

Re: [PATCH 3/6] zram: introduce ZRAM_IDLE flag

2018-11-21 Thread Sergey Senozhatsky
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

Re: [PATCH 4/6] zram: support idle page writeback

2018-11-21 Thread Sergey Senozhatsky
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

Re: [PATCH 4/6] zram: support idle page writeback

2018-11-21 Thread Sergey Senozhatsky
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 > >

Re: [PATCH 4/6] zram: support idle page writeback

2018-11-20 Thread Sergey Senozhatsky
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); > +

Re: [PATCH 3/6] zram: introduce ZRAM_IDLE flag

2018-11-19 Thread Sergey Senozhatsky
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; > +

Re: [PATCH v6 1/3] printk: Add line-buffered printk() API.

2018-11-12 Thread Sergey Senozhatsky
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.

Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"

2018-11-08 Thread Sergey Senozhatsky
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() > >

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-08 Thread Sergey Senozhatsky
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

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-08 Thread Sergey Senozhatsky
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

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-08 Thread Sergey Senozhatsky
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

Re: [PATCH v6 1/3] printk: Add line-buffered printk() API.

2018-11-08 Thread Sergey Senozhatsky
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

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-07 Thread Sergey Senozhatsky
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) > >

Re: [PATCH v6 1/3] printk: Add line-buffered printk() API.

2018-11-07 Thread Sergey Senozhatsky
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

Re: [PATCH v6 1/3] printk: Add line-buffered printk() API.

2018-11-07 Thread Sergey Senozhatsky
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

Re: [PATCH v6 1/3] printk: Add line-buffered printk() API.

2018-11-06 Thread Sergey Senozhatsky
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,

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-06 Thread Sergey Senozhatsky
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

Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers

2018-10-31 Thread Sergey Senozhatsky
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

Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers

2018-10-25 Thread Sergey Senozhatsky
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

[PATCHv3] panic: avoid deadlocks in re-entrant console drivers

2018-10-25 Thread Sergey Senozhatsky
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

Re: [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers

2018-10-25 Thread Sergey Senozhatsky
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

Re: [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers

2018-10-25 Thread Sergey Senozhatsky
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

Re: [PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks()

2018-10-25 Thread Sergey Senozhatsky
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

Re: [PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks()

2018-10-25 Thread Sergey Senozhatsky
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

Re: [PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks()

2018-10-25 Thread Sergey Senozhatsky
On (10/25/18 08:28), Heiko Carstens wrote: [..] > > int loglevel_save = console_loglevel; > > - console_unblank(); > > - oops_in_progress = 0; > > - /* > > -* OK, the message is on the console. Now we call printk() > > -* without

Re: [PATCH 1/2] mm/zsmalloc.c: check encoded object value overflow for PAE

2018-10-24 Thread Sergey Senozhatsky
On (10/24/18 22:27), Rafael David Tinoco wrote: > static unsigned long location_to_obj(struct page *page, unsigned int obj_idx) > { > - unsigned long obj; > + unsigned long obj, pfn; > + > + pfn = page_to_pfn(page); > + > + if (unlikely(OBJ_OVERFLOW(pfn))) > + BUG();

Re: [PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks()

2018-10-23 Thread Sergey Senozhatsky
On (10/24/18 13:30), Sergey Senozhatsky wrote: > - * OK, the message is on the console. Now we call printk() > - * without oops_in_progress set so that printk will give klogd > - * a poke. Hold onto

[PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks()

2018-10-23 Thread Sergey Senozhatsky
eplace that printk(" "). Signed-off-by: Sergey Senozhatsky --- arch/s390/mm/fault.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c index 2b8f32f56e0c..244993dc3c70 100644 --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/faul

Re: [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers

2018-10-23 Thread Sergey Senozhatsky
On (10/23/18 21:04), Sergey Senozhatsky wrote: > > Seems that s390 is the only arch which defines its own bust_spinlocks(). > Not sure why... Just to play games with console_loglevel? > > --- > > void bust_spinlocks(int yes) > { > if (yes) { >

Re: [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers

2018-10-23 Thread Sergey Senozhatsky
On (10/23/18 20:54), Sergey Senozhatsky wrote: > So I did look at what lib/bust_spinlocks.c does; and I agree that waking > up klogd makes little sense, on the other hand it just sets per-cpu > pending bit, so not a big deal. console_unlock() should do there the >

Re: [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers

2018-10-23 Thread Sergey Senozhatsky
On (10/23/18 13:07), Petr Mladek wrote: > Though this looks a bit weird. > > I have just realized that console_unblank() is called by > bust_spinlocks(0) and does basically the same as > console_flush_on_panic(). Also it does not make much > sense wake_up_klogd() there. Finally, it seems to be >

Re: NMI watchdog dump does not print on hard lockup

2018-10-23 Thread Sergey Senozhatsky
On (10/16/17 10:15), Steven Rostedt wrote: > On Mon, 16 Oct 2017 22:13:05 +0900 > Sergey Senozhatsky wrote: > > > just "brainstorming" it... with some silly ideas. > > > > pushing the data from NMI panic might look like we are replacing one > > deadl

Re: [RFC][PATCHv2 2/4] printk: move printk_safe macros to printk header

2018-10-23 Thread Sergey Senozhatsky
On (10/16/18 14:54), Peter Zijlstra wrote: > > No, no wakups. irq_work to wake the printk-thread, at most. > There are cases when we probably prefer to be in "direct printk" mode. E.g. sysrq or late PM stages (probably). Doing irq_work->wake_up_process->printk_kthread from sysrq probably might

Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.

2018-10-22 Thread Sergey Senozhatsky
On (10/19/18 19:35), Tetsuo Handa wrote: > > > > OK, that's a fair point. There was a patch from FB, which would allow us > > to set a log_level on per-console basis. So the noise goes to heav^W net > > console; only critical stuff goes to the serial console (if I recall it > > correctly). I'm

Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"

2018-10-22 Thread Sergey Senozhatsky
On (10/21/18 11:09), Daniel Wang wrote: > > Just got back from vacation. Thanks for the continued discussion. Just so > I understand the current state. Looks like we've got a pretty good explanation > of what's going on (though not completely sure), and backporting Steven's > patches is still the

Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.

2018-10-18 Thread Sergey Senozhatsky
On (10/18/18 20:58), Tetsuo Handa wrote: > > > > A knob might do. > > As well as /proc/sys/kernel/printk tweaks, probably. One can even add > > echo "a b c d" > /proc/sys/kernel/printk to .bashrc and adjust printk > > console levels on login and rollback to old values in .bash_logout > > May be.

Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.

2018-10-18 Thread Sergey Senozhatsky
On (10/18/18 09:56), Michal Hocko wrote: > On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote: > [...] > > and let's hear from MM people what they can suggest. > > > > Michal, Andrew, Johannes, any thoughts? > > I have already stated my position. Let's

Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.

2018-10-18 Thread Sergey Senozhatsky
On (10/18/18 14:26), Tetsuo Handa wrote: > Sergey Senozhatsky wrote: > > To my personal taste, "baud rate of registered and enabled consoles" > > approach is drastically more relevant than hard coded 10 * HZ or > > 60 * HZ magic numbers... But not in the form of that

Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.

2018-10-17 Thread Sergey Senozhatsky
On (10/18/18 11:46), Tetsuo Handa wrote: > Sergey Senozhatsky wrote: > > > > int printk_ratelimit_interval(void) > > { > >int ret = DEFAULT_RATELIMIT_INTERVAL; > >struct tty_driver *driver = NULL; > >speed_t min_baud

Re: [RFC PATCH for 4.21 04/16] mm: Introduce vm_map_user_ram, vm_unmap_user_ram

2018-10-17 Thread Sergey Senozhatsky
On (10/17/18 11:04), Mathieu Desnoyers wrote: > >> > >>> if (WARN_ON(x)) > >>> return; > >> > >> Given that this somewhat MM-related, I'd may be say VM_WARN_ON(). > > I notice that VM_WARN_ON() casts the result of WARN_ON() to (void), so it > cannot be used in a if () statement. >

Re: [RFC][PATCHv2 2/4] printk: move printk_safe macros to printk header

2018-10-17 Thread Sergey Senozhatsky
On (10/17/18 09:57), Peter Zijlstra wrote: > On Wed, Oct 17, 2018 at 01:32:51PM +0900, Sergey Senozhatsky wrote: > > This probably will be a bit more hairy. logbuf is written to by many > > sources and is read from by many sides, including user-space [both read() > > and writ

Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.

2018-10-17 Thread Sergey Senozhatsky
On (10/17/18 12:28), Michal Hocko wrote: > > Michal proposed ratelimiting dump_header() [2]. But I don't think that > > that patch is appropriate because that patch does not ratelimit > > > > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d, > > oom_score_adj=%hd\n" > >

Re: [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers

2018-10-16 Thread Sergey Senozhatsky
On (10/16/18 14:04), Sergey Senozhatsky wrote: > > Fix this by setting oops_in_progress before console_flush_on_panic(), > so re-entrant console drivers will trylock the port->lock instead of > spinning on it forever. > Just a small note: Regardless of what's going to ha

Re: [RFC][PATCHv2 2/4] printk: move printk_safe macros to printk header

2018-10-16 Thread Sergey Senozhatsky
On (10/16/18 14:54), Peter Zijlstra wrote: > On Tue, Oct 16, 2018 at 09:27:34PM +0900, Sergey Senozhatsky wrote: > > per-CPU printk_safe _semi-magic_ makes some things simple to handle. > > We can't just remove per-CPU buffers and add a wake_up_process() at > > the b

Re: [RFC PATCH for 4.21 06/16] cpu_opv: Provide cpu_opv system call (v8)

2018-10-16 Thread Sergey Senozhatsky
Hi Mathieu, On (10/16/18 15:17), Mathieu Desnoyers wrote: > > Therefore, only an internal kernel bug between vm_map_user_ram() and > vm_unmap_user_ram() should trigger the BUG_ON(). No user input is passed > to vm_unmap_user_ram(). > > Now, let's look at vm_map_user_ram(). It calls

Re: [RFC PATCH for 4.21 04/16] mm: Introduce vm_map_user_ram, vm_unmap_user_ram

2018-10-16 Thread Sergey Senozhatsky
On (10/16/18 14:30), Steven Rostedt wrote: > > +void vm_unmap_user_ram(const void *mem, unsigned int count) > > +{ > > + unsigned long size = (unsigned long)count << PAGE_SHIFT; > > + unsigned long addr = (unsigned long)mem; > > + struct vmap_area *va; > > + > > + might_sleep(); > > +

Re: [RFC][PATCHv2 2/4] printk: move printk_safe macros to printk header

2018-10-16 Thread Sergey Senozhatsky
On (10/16/18 09:27), Peter Zijlstra wrote: > > So I really _really_ hate all this. Utterly detest it. I learned a new word today - detest. I can haz re-entrant consoles now please? > That whole magic 'safe' printk buffer crap is just that crap. No, I don't see it this way; printk_safe is

Re: [RFC][PATCHv2 0/4] less deadlock prone serial consoles

2018-10-16 Thread Sergey Senozhatsky
On (10/16/18 09:23), Peter Zijlstra wrote: > On Tue, Oct 16, 2018 at 02:04:24PM +0900, Sergey Senozhatsky wrote: > > Hello, > > > > > > RFC > > > > > > The patch set reduces the number of ways serial consoles > > can deadlock t

Re: [RFC PATCH for 4.21 06/16] cpu_opv: Provide cpu_opv system call (v8)

2018-10-16 Thread Sergey Senozhatsky
Hi Mathieu, On (10/10/18 15:19), Mathieu Desnoyers wrote: [..] > +SYSCALL_DEFINE4(cpu_opv, struct cpu_op __user *, ucpuopv, int, cpuopcnt, > + int, cpu, int, flags) > +{ [..] > +again: > + ret = cpu_opv_pin_pages(cpuopv, cpuopcnt, _ptrs); > + if (ret) > + goto end;

[RFC][PATCHv2 4/4] tty: 8250: switch to uart_port locking helpers

2018-10-15 Thread Sergey Senozhatsky
Switch to uart_port_lock macros: - use uart_port_lock_for_printk()/uart_port_unlock_after_printk() in serial8250_console_write(). - use uart_port_lock_*()/uart_port_unlock_*() elsewhere. Signed-off-by: Sergey Senozhatsky --- drivers/tty/serial/8250/8250_core.c | 8 +-- drivers/tty/serial

[RFC][PATCHv2 3/4] serial: introduce uart_port locking helpers

2018-10-15 Thread Sergey Senozhatsky
ler. This macro should address the issue. Signed-off-by: Sergey Senozhatsky --- include/linux/serial_core.h | 48 + 1 file changed, 48 insertions(+) diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 047fa67d039b..acc6966fea8e 100644

[RFC][PATCHv2 2/4] printk: move printk_safe macros to printk header

2018-10-15 Thread Sergey Senozhatsky
Make printk_safe_enter_irqsave()/etc macros available to the rest of the kernel. Signed-off-by: Sergey Senozhatsky --- include/linux/printk.h | 40 + kernel/printk/internal.h| 37 -- kernel/printk/printk_safe.c | 6

[RFC][PATCHv2 0/4] less deadlock prone serial consoles

2018-10-15 Thread Sergey Senozhatsky
RFC I modify only 8250 serial driver. Sergey Senozhatsky (4): panic: avoid deadlocks in re-entrant console drivers printk: move printk_safe macros to printk header seial: introduce uart_port locking helpers tty: 8250: switch to uart_port locking helpers drivers/tty/serial/8250/8250_cor

[RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers

2018-10-15 Thread Sergey Senozhatsky
NMI panic() on printing CPU) the system deadlocks and does not reboot. Fix this by setting oops_in_progress before console_flush_on_panic(), so re-entrant console drivers will trylock the port->lock instead of spinning on it forever. Signed-off-by: Sergey Senozhatsky --- kernel/panic.c |

Re: [PATCH] printk: fix integer overflow in setup_log_buf()

2018-10-12 Thread Sergey Senozhatsky
On (10/12/18 11:01), Petr Mladek wrote: > > Make "free" unsigned integer and use appropriate printk() specifier. > > > > Signed-off-by: Sergey Senozhatsky > > I have pushed this fix into printk.git, for-4.20 branch. Thanks. > Please note that this 2n

Re: [RFC][PATCH 0/3] printk: some pr_cont tweaks and cleanups

2018-10-12 Thread Sergey Senozhatsky
On (10/12/18 10:27), Petr Mladek wrote: > > Forked from "printk feature for syzbot". Let's have a separate > > discussion thread. > > A buch of pr_cont tweaks and cleanups, please see commits and > > commits' messages for more details. > > > &

Re: INFO: rcu detected stall in shmem_fault

2018-10-10 Thread Sergey Senozhatsky
On (10/10/18 22:10), Tetsuo Handa wrote: > >> I've found at least 1 place that uses DEFAULT_RATELIMIT_INTERVAL*10: > >> https://elixir.bootlin.com/linux/latest/source/fs/btrfs/extent-tree.c#L8365 > >> Probably we need something similar here. > > Since printk() is a significantly CPU consuming

Re: INFO: rcu detected stall in shmem_fault

2018-10-10 Thread Sergey Senozhatsky
On (10/10/18 14:29), Dmitry Vyukov wrote: > >> A bit unrelated, but while we are at it: > >> > >> I like it when we rate-limit printk-s that lookup the system. > >> But it seems that default rate-limit values are not always good enough, > >> DEFAULT_RATELIMIT_INTERVAL / DEFAULT_RATELIMIT_BURST

Re: INFO: rcu detected stall in shmem_fault

2018-10-10 Thread Sergey Senozhatsky
On (10/10/18 13:35), Michal Hocko wrote: > > Just flooding out of memory messages can trigger RCU stall problems. > > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing > > [...] > > Quite some of them, indeed! I guess we want to rate limit the output. > What about the

[PATCH] printk: fix integer overflow in setup_log_buf()

2018-10-10 Thread Sergey Senozhatsky
nd log_buf_len=2G boot param: [0.075317] log_buf_len: -2147483648 bytes [0.075319] early log buf free: 33549896(-28%) Make "free" unsigned integer and use appropriate printk() specifier. Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 6 +++--- 1 file changed, 3 ins

Re: [PATCH] printk: fix integer overflow in setup_log_buf()

2018-10-10 Thread Sergey Senozhatsky
On (10/10/18 19:38), Sergey Senozhatsky wrote: > The way we calculate free logbuf free space percentage > overflows signed integer: > > int free; > > free = __LOG_BUF_LEN - log_next_idx; > pr_info("early log buf free: %u(%u%%)\n", &g

[PATCH] printk: fix integer overflow in setup_log_buf()

2018-10-10 Thread Sergey Senozhatsky
0.075319] early log buf free: 33549896(-28%) Make "free" unsigned integer. Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index c3f0e3927e77.

Re: [PATCH v5 4/4] printk: Give error on attempt to set log buffer length to over 4G

2018-10-10 Thread Sergey Senozhatsky
On (10/10/18 10:09), Petr Mladek wrote: > > > +#define LOG_BUF_LEN_MAX (u32)(1 << 31) > > [..] > > > + if (size > (u64)LOG_BUF_LEN_MAX) { > > > + size = (u64)LOG_BUF_LEN_MAX; > > > + pr_err("log_buf over 2G is not supported.\n"); > > > + } > > > > Why not INT_MAX? > > INT_MAX is

  1   2   3   4   5   6   7   8   9   10   >