On (09/13/18 21:12), Steven Rostedt wrote:
> >
> > +#define __SEQ_BUF_INITIALIZER(buf, length) {
> > \
> > + .buffer = (buf),\
> > + .size = (length), \
> > + .len
On (09/13/18 21:12), Steven Rostedt wrote:
> >
> > +#define __SEQ_BUF_INITIALIZER(buf, length) {
> > \
> > + .buffer = (buf),\
> > + .size = (length), \
> > + .len
On (09/13/18 14:26), Petr Mladek wrote:
> > +
> > +int vpr_line(struct pr_line *pl, const char *fmt, va_list args)
> > +{
> > + struct seq_buf *s = >sb;
> > + int ret, len;
> > +
> > + if (fmt[0] == '\n') {
> > + pr_line_flush(pl);
> > + return 0;
> > + }
>
> You would
On (09/13/18 14:26), Petr Mladek wrote:
> > +
> > +int vpr_line(struct pr_line *pl, const char *fmt, va_list args)
> > +{
> > + struct seq_buf *s = >sb;
> > + int ret, len;
> > +
> > + if (fmt[0] == '\n') {
> > + pr_line_flush(pl);
> > + return 0;
> > + }
>
> You would
quot;%s.\n", "Steven");
And, looking at potential users of pr_line, I'd say that we better
have DEFINE_PR_LINE_BUF, because some of them do print messages longer
than 80 chars.
===
From: Sergey Senozhatsky
Subject: [PATCH] lib/seq_buf: add pr_line buffering API
quot;%s.\n", "Steven");
And, looking at potential users of pr_line, I'd say that we better
have DEFINE_PR_LINE_BUF, because some of them do print messages longer
than 80 chars.
===
From: Sergey Senozhatsky
Subject: [PATCH] lib/seq_buf: add pr_line buffering API
to this point sooner.
> I would do this change only when people complains about
> the current behavior.
OK. Agreed.
> I think that more important is to do:
[..]
> IMHO, this is a clear win. It fixes a clear mistake.
>
> I would just rename the variable to exclusive_console_s
to this point sooner.
> I would do this change only when people complains about
> the current behavior.
OK. Agreed.
> I think that more important is to do:
[..]
> IMHO, this is a clear win. It fixes a clear mistake.
>
> I would just rename the variable to exclusive_console_s
On (09/11/18 10:47), Petr Mladek wrote:
> > Oh, that was intentional. I consider repeated messages to be less
> > problematic than the missing ones.
>
> It makes some sense. But it might be problematic with slow consoles.
Right. And this is why I brought up Jan's patch.
And I agree that we
On (09/11/18 10:47), Petr Mladek wrote:
> > Oh, that was intentional. I consider repeated messages to be less
> > problematic than the missing ones.
>
> It makes some sense. But it might be problematic with slow consoles.
Right. And this is why I brought up Jan's patch.
And I agree that we
ar buf[16];
DEFINE_PR_LINE_BUF(KERN_ERR, ps, buf, sizeof(buf));
pr_line(, "Test test test test test test test test test\n");
pr_line(, "\n");
dmesg | tail
[ 69.908547] Test test test ** truncated **
Opinions? Will this work for us?
==
ar buf[16];
DEFINE_PR_LINE_BUF(KERN_ERR, ps, buf, sizeof(buf));
pr_line(, "Test test test test test test test test test\n");
pr_line(, "\n");
dmesg | tail
[ 69.908547] Test test test ** truncated **
Opinions? Will this work for us?
==
On (09/11/18 14:04), Sergey Senozhatsky wrote:
> > for (;;) {
> > set_current_state(TASK_UNINTERRUPTIBLE);
>
> I think that set_current_state() also executes memory barrier. Just
> because it accesses task state.
>
> > - if (!waiter.task)
On (09/11/18 14:04), Sergey Senozhatsky wrote:
> > for (;;) {
> > set_current_state(TASK_UNINTERRUPTIBLE);
>
> I think that set_current_state() also executes memory barrier. Just
> because it accesses task state.
>
> > - if (!waiter.task)
On (09/11/18 02:48), Dmitry Safonov wrote:
> There is a couple of reports about lockup in ldsem_down_read() without
> anyone holding write end of ldisc semaphore:
> lkml.kernel.org/r/<20171121132855.ajdv4k6swzhvk...@wfg-t540p.sh.intel.com>
> lkml.kernel.org/r/<20180907045041.GF1110@shao2-debian>
>
On (09/11/18 02:48), Dmitry Safonov wrote:
> There is a couple of reports about lockup in ldsem_down_read() without
> anyone holding write end of ldisc semaphore:
> lkml.kernel.org/r/<20171121132855.ajdv4k6swzhvk...@wfg-t540p.sh.intel.com>
> lkml.kernel.org/r/<20180907045041.GF1110@shao2-debian>
>
re.kernel.org/lkml/1457964820-4642-3-git-send-email-sergey.senozhat...@gmail.com/T/#u
> This reverts commit 375899cddcbb26881b03cb3fbdcfd600e4e67f4a.
>
> Reported-by: Hans de Goede
> Signed-off-by: Petr Mladek
Acked-by: Sergey Senozhatsky
-ss
re.kernel.org/lkml/1457964820-4642-3-git-send-email-sergey.senozhat...@gmail.com/T/#u
> This reverts commit 375899cddcbb26881b03cb3fbdcfd600e4e67f4a.
>
> Reported-by: Hans de Goede
> Signed-off-by: Petr Mladek
Acked-by: Sergey Senozhatsky
-ss
On (09/07/18 08:39), Jiri Slaby wrote:
> > [ 244.944070]
> > [ 244.944070] Showing all locks held in the system:
> > [ 244.945558] 1 lock held by khungtaskd/18:
> > [ 244.946495] #0: (ptrval) (rcu_read_lock){}, at:
> > debug_show_all_locks+0x16/0x190
> > [ 244.948503] 2 locks
On (09/07/18 08:39), Jiri Slaby wrote:
> > [ 244.944070]
> > [ 244.944070] Showing all locks held in the system:
> > [ 244.945558] 1 lock held by khungtaskd/18:
> > [ 244.946495] #0: (ptrval) (rcu_read_lock){}, at:
> > debug_show_all_locks+0x16/0x190
> > [ 244.948503] 2 locks
On (09/07/18 16:03), Peter Zijlstra wrote:
> >
> > I would even argue that placing printk_nmi_enter() between
> > lockdep_off() and ftrace_nmi_enter() is wrong because if in the future
> > printk_nmi_enter() were to do any ftrace tracing, it wont be caught, as
> > it was by having it before
On (09/07/18 16:03), Peter Zijlstra wrote:
> >
> > I would even argue that placing printk_nmi_enter() between
> > lockdep_off() and ftrace_nmi_enter() is wrong because if in the future
> > printk_nmi_enter() were to do any ftrace tracing, it wont be caught, as
> > it was by having it before
On (09/07/18 10:28), Petr Mladek wrote:
> On Fri 2018-09-07 09:45:31, Peter Zijlstra wrote:
> > On Thu, Sep 06, 2018 at 11:31:51AM +0900, Sergey Senozhatsky wrote:
> > > An alternative option, thus, could be re-instating back the rule that
> > > lockdep_off/on shoul
On (09/07/18 10:28), Petr Mladek wrote:
> On Fri 2018-09-07 09:45:31, Peter Zijlstra wrote:
> > On Thu, Sep 06, 2018 at 11:31:51AM +0900, Sergey Senozhatsky wrote:
> > > An alternative option, thus, could be re-instating back the rule that
> > > lockdep_off/on shoul
On (09/06/18 16:28), Petr Mladek wrote:
> On Thu 2018-09-06 16:29:40, Sergey Senozhatsky wrote:
> > On (09/05/18 13:02), Petr Mladek wrote:
> > > Note that the first registered console prints all messages
> > > even without this flag.
> >
> > Hmm, OK
On (09/06/18 16:28), Petr Mladek wrote:
> On Thu 2018-09-06 16:29:40, Sergey Senozhatsky wrote:
> > On (09/05/18 13:02), Petr Mladek wrote:
> > > Note that the first registered console prints all messages
> > > even without this flag.
> >
> > Hmm, OK
On (09/05/18 13:02), Petr Mladek wrote:
> Note that the first registered console prints all messages
> even without this flag.
Hmm, OK, interesting point.
I assumed that the first console usually has CON_PRINTBUFFER bit set.
Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of
On (09/05/18 13:02), Petr Mladek wrote:
> Note that the first registered console prints all messages
> even without this flag.
Hmm, OK, interesting point.
I assumed that the first console usually has CON_PRINTBUFFER bit set.
Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of
last thing we do in
nmi_enter/nmi_exit. E.g.
nmi_enter()
lockdep_off();
printk_nmi_enter();
nmi_exit()
printk_nmi_exit();
lockdep_on();
I guess that we can keep printk_nmi_enter/printk_nmi_exit at the top
and at the bottom of nmi_enter/nmi_exit correspondingly just in case
if l
last thing we do in
nmi_enter/nmi_exit. E.g.
nmi_enter()
lockdep_off();
printk_nmi_enter();
nmi_exit()
printk_nmi_exit();
lockdep_on();
I guess that we can keep printk_nmi_enter/printk_nmi_exit at the top
and at the bottom of nmi_enter/nmi_exit correspondingly just in case
if l
On (09/05/18 14:36), Sergey Senozhatsky wrote:
>
> Just a demonstration of the idea. It does not look very good, tho.
> I'd rather have just one suppress_message_printing() in printk code.
>
> // This is not a proposed patch, hence the 80-cols violation.
>
> ---
>
>
On (09/05/18 14:36), Sergey Senozhatsky wrote:
>
> Just a demonstration of the idea. It does not look very good, tho.
> I'd rather have just one suppress_message_printing() in printk code.
>
> // This is not a proposed patch, hence the 80-cols violation.
>
> ---
>
>
On (09/05/18 14:36), Sergey Senozhatsky wrote:
>
> OK, thanks for the report!
> So I think that your case is CON_PRINTBUFFER related as well. We have
> a number of logbuf messages before we parse quiet and console_loglevel.
> Those messages pass the suppress_message() test. Then
On (09/05/18 14:36), Sergey Senozhatsky wrote:
>
> OK, thanks for the report!
> So I think that your case is CON_PRINTBUFFER related as well. We have
> a number of logbuf messages before we parse quiet and console_loglevel.
> Those messages pass the suppress_message() test. Then
On (09/05/18 06:53), Hans de Goede wrote:
> >
> > Do you use earlycon?
>
> No, I'm seeing this with the regular/normal console stuff.
OK, thanks for the report!
So I think that your case is CON_PRINTBUFFER related as well. We have
a number of logbuf messages before we parse quiet and
On (09/05/18 06:53), Hans de Goede wrote:
> >
> > Do you use earlycon?
>
> No, I'm seeing this with the regular/normal console stuff.
OK, thanks for the report!
So I think that your case is CON_PRINTBUFFER related as well. We have
a number of logbuf messages before we parse quiet and
Hi,
On (09/04/18 20:01), Hans de Goede wrote:
> Commit 375899cddcbb ("printk: make sure to print log on console."), moved
> the checking of the loglevel of messages from flush time to the actual
> log time.
>
> This introduces one problem, some early boot messages are printed before
>
Hi,
On (09/04/18 20:01), Hans de Goede wrote:
> Commit 375899cddcbb ("printk: make sure to print log on console."), moved
> the checking of the loglevel of messages from flush time to the actual
> log time.
>
> This introduces one problem, some early boot messages are printed before
>
On (09/04/18 08:30), Jiri Slaby wrote:
>
> >> Cc: sta...@vger.kernel.org # depends on commit b027e2298bd5 ("tty: fix
> >> data race between tty_init_dev and flush of buf")
> >
> > I believe there's a "Fixes" tag for that
> >
> > Fixes: b027e2298bd5 ("tty: fix data race between tty_init_dev and
On (09/04/18 08:30), Jiri Slaby wrote:
>
> >> Cc: sta...@vger.kernel.org # depends on commit b027e2298bd5 ("tty: fix
> >> data race between tty_init_dev and flush of buf")
> >
> > I believe there's a "Fixes" tag for that
> >
> > Fixes: b027e2298bd5 ("tty: fix data race between tty_init_dev and
On (09/03/18 17:52), Dmitry Safonov wrote:
>
> We've seen the following crash on v4.9.108 stable:
>
> BUG: unable to handle kernel paging request at 2260
> IP: [..] n_tty_receive_buf_common+0x5f/0x86d
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
> [..] n_tty_receive_buf2
On (09/03/18 17:52), Dmitry Safonov wrote:
>
> We've seen the following crash on v4.9.108 stable:
>
> BUG: unable to handle kernel paging request at 2260
> IP: [..] n_tty_receive_buf_common+0x5f/0x86d
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
> [..] n_tty_receive_buf2
Hi,
Cc-ing Benjamin on this.
On (08/29/18 03:23), Dmitry Safonov wrote:
> BUG: unable to handle kernel paging request at 2260
> IP: [..] n_tty_receive_buf_common+0x5f/0x86d
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
> [..] n_tty_receive_buf2
> [..]
Hi,
Cc-ing Benjamin on this.
On (08/29/18 03:23), Dmitry Safonov wrote:
> BUG: unable to handle kernel paging request at 2260
> IP: [..] n_tty_receive_buf_common+0x5f/0x86d
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
> [..] n_tty_receive_buf2
> [..]
Hi,
On (08/21/18 14:43), Rasmus Villemoes wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there.
>
> Maybe. But it shouldn't hurt to make it accept a src size (the caller
> can always pass -1 is he's sure the
Hi,
On (08/21/18 14:43), Rasmus Villemoes wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there.
>
> Maybe. But it shouldn't hurt to make it accept a src size (the caller
> can always pass -1 is he's sure the
Hello Greg,
On (08/21/18 15:57), Greg Kroah-Hartman wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there. Am I wrong?
>
> sysfs data is always null terminated.
>
> What exactly are you trying to do here? If a
Hello Greg,
On (08/21/18 15:57), Greg Kroah-Hartman wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there. Am I wrong?
>
> sysfs data is always null terminated.
>
> What exactly are you trying to do here? If a
On (08/21/18 15:00), Andy Shevchenko wrote:
> > Returning the length of dst/-EOVERFLOW is a bit inconvenient, because
> > "the length" forces us to have size_t return, which is unsigned.
>
> We have for ages ssize_t to workaround that.
OK.
[..]
> Wouldn't be better to split out something like
>
On (08/21/18 15:00), Andy Shevchenko wrote:
> > Returning the length of dst/-EOVERFLOW is a bit inconvenient, because
> > "the length" forces us to have size_t return, which is unsigned.
>
> We have for ages ssize_t to workaround that.
OK.
[..]
> Wouldn't be better to split out something like
>
On (08/21/18 18:50), Sergey Senozhatsky wrote:
>
> > int strcpy_trim(char *dst, size_t dstsize, const char *src, size_t
> > srcsize) - copy (potentially not '\0'-terminated) src to dst, trimming
> > leading and trailing whitespace. dstsize must be positive, and dst is
>
On (08/21/18 18:50), Sergey Senozhatsky wrote:
>
> > int strcpy_trim(char *dst, size_t dstsize, const char *src, size_t
> > srcsize) - copy (potentially not '\0'-terminated) src to dst, trimming
> > leading and trailing whitespace. dstsize must be positive, and dst is
>
On (08/21/18 18:50), Sergey Senozhatsky wrote:
>
> Going point, that's why the patch is in RFC stage: to figure out
> what do we actually want.
s/Going/Good/ don't know how did that happen.
-ss
On (08/21/18 18:50), Sergey Senozhatsky wrote:
>
> Going point, that's why the patch is in RFC stage: to figure out
> what do we actually want.
s/Going/Good/ don't know how did that happen.
-ss
Hi Rasmus,
On (08/21/18 09:59), Rasmus Villemoes wrote:
> > +char *sysfs_strncpy(char *dest, const char *src, size_t count)
> > +{
> > + char *c;
> > +
> > + strncpy(dest, skip_spaces(src), count);
>
> I'd like to see where and how you'd use this, but I'm very skeptical of
> count being used
Hi Rasmus,
On (08/21/18 09:59), Rasmus Villemoes wrote:
> > +char *sysfs_strncpy(char *dest, const char *src, size_t count)
> > +{
> > + char *c;
> > +
> > + strncpy(dest, skip_spaces(src), count);
>
> I'd like to see where and how you'd use this, but I'm very skeptical of
> count being used
railing white-spaces and
tailing new-line symbols. So a FOO_store() example which was posted
above may be rewritten to:
ssize_t FOO_store(struct device *dev, )
{
sysfs_strlcpy(value, buf, MAX_SZ);
...
}
Signed-of
railing white-spaces and
tailing new-line symbols. So a FOO_store() example which was posted
above may be rewritten to:
ssize_t FOO_store(struct device *dev, )
{
sysfs_strlcpy(value, buf, MAX_SZ);
...
}
Signed-of
05:38 AM, Sergey Senozhatsky wrote:
> > On (08/16/18 13:39), Prarit Bhargava wrote:
> >>
> >> + auto[X86] Enable ACPI SPCR console
> >
> > And arm64?
>
> Hi Sergey, on arm64 if an SPCR is present th
05:38 AM, Sergey Senozhatsky wrote:
> > On (08/16/18 13:39), Prarit Bhargava wrote:
> >>
> >> + auto[X86] Enable ACPI SPCR console
> >
> > And arm64?
>
> Hi Sergey, on arm64 if an SPCR is present th
On (08/16/18 13:39), Prarit Bhargava wrote:
>
> + auto[X86] Enable ACPI SPCR console
And arm64?
Any chance we can rename param to "spcr" or something more clear?
To explicitly state what exactly it's going to do. `auto' sounds
On (08/16/18 13:39), Prarit Bhargava wrote:
>
> + auto[X86] Enable ACPI SPCR console
And arm64?
Any chance we can rename param to "spcr" or something more clear?
To explicitly state what exactly it's going to do. `auto' sounds
A bunch of corrections
On (08/16/18 10:48), Sergey Senozhatsky wrote:
> The problem is that strlcpy() copies as many bytes as the source string
> has, not as many bytes as destination string can fit.
I mean - strlcpy() expects that the 3rd argument will be sizeof(dst), but
we passed the
A bunch of corrections
On (08/16/18 10:48), Sergey Senozhatsky wrote:
> The problem is that strlcpy() copies as many bytes as the source string
> has, not as many bytes as destination string can fit.
I mean - strlcpy() expects that the 3rd argument will be sizeof(dst), but
we passed the
On (08/14/18 16:45), Andrew Morton wrote:
> >
> > > > - strlcpy(file_name, buf, len);
> >
> > This is quite interesting. The reason it worked before was the fact that
> > strlcpy() copies 'len - 1' bytes, which is strlen(buf) - 1 in our case,
> > so it accidentally didn't copy the trailing
On (08/14/18 16:45), Andrew Morton wrote:
> >
> > > > - strlcpy(file_name, buf, len);
> >
> > This is quite interesting. The reason it worked before was the fact that
> > strlcpy() copies 'len - 1' bytes, which is strlen(buf) - 1 in our case,
> > so it accidentally didn't copy the trailing
Hi Minchan,
On (08/14/18 09:24), Minchan Kim wrote:
> > Any thoughts?
>
> If we want a refactoring, I'm not against but description said it tiggered
> BUG_ON on zs_map_object rarely. That means it should be stable material
> and need more description to understand. Please be more specific with
>
Hi Minchan,
On (08/14/18 09:24), Minchan Kim wrote:
> > Any thoughts?
>
> If we want a refactoring, I'm not against but description said it tiggered
> BUG_ON on zs_map_object rarely. That means it should be stable material
> and need more description to understand. Please be more specific with
>
On (08/13/18 15:05), Minchan Kim wrote:
> > From: zhouxianrong
> >
> > The last partial object in last subpage of zspage should not be linked
> > in allocation list. Otherwise it could trigger BUG_ON explicitly at
> > function zs_map_object. But it happened rarely.
>
> Could you be more
On (08/13/18 15:05), Minchan Kim wrote:
> > From: zhouxianrong
> >
> > The last partial object in last subpage of zspage should not be linked
> > in allocation list. Otherwise it could trigger BUG_ON explicitly at
> > function zs_map_object. But it happened rarely.
>
> Could you be more
the new file_name buffer. This makes it possible to set the backing_dev
> > as follows:
> >
> > echo /dev/sdX > /sys/block/zram0/backing_dev
> >
> > Signed-off-by: Peter Kalauskas
> Acked-by: Minchan Kim
>
> Cc: Andrew Morton
> Cc: Sergey Senozhatsky
the new file_name buffer. This makes it possible to set the backing_dev
> > as follows:
> >
> > echo /dev/sdX > /sys/block/zram0/backing_dev
> >
> > Signed-off-by: Peter Kalauskas
> Acked-by: Minchan Kim
>
> Cc: Andrew Morton
> Cc: Sergey Senozhatsky
Hello,
On (08/08/18 11:01), Vlastimil Babka wrote:
> On 08/08/2018 05:50 AM, Mikhail Gavrilov wrote:
> > Hi guys.
> > I am catched new bug.
> > Can anyone look?
>
> fbcon_startup() calls kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL) so
> it tells slab it can sleep. The problem must be higher in
Hello,
On (08/08/18 11:01), Vlastimil Babka wrote:
> On 08/08/2018 05:50 AM, Mikhail Gavrilov wrote:
> > Hi guys.
> > I am catched new bug.
> > Can anyone look?
>
> fbcon_startup() calls kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL) so
> it tells slab it can sleep. The problem must be higher in
On (08/03/18 14:23), Sergey Senozhatsky wrote:
>
> Hmm, any chance a WB device can be async on its own? We add a page
> to a new bio and submit it to another async device driver. Then we
> return back to the upper layer (swap), which can free a page before
> the device picks up
On (08/03/18 14:23), Sergey Senozhatsky wrote:
>
> Hmm, any chance a WB device can be async on its own? We add a page
> to a new bio and submit it to another async device driver. Then we
> return back to the upper layer (swap), which can free a page before
> the device picks up
On (08/03/18 13:51), Minchan Kim wrote:
>
> AFAIK, onging writeback page couldn't freed so it was not writeabck problem.
>
> What I'm tryig to fix is read part.
> If we use swapcache, it shouldn't be a problem either because swapcache
> has a reference count and we should wait PG_lock release
On (08/03/18 13:51), Minchan Kim wrote:
>
> AFAIK, onging writeback page couldn't freed so it was not writeabck problem.
>
> What I'm tryig to fix is read part.
> If we use swapcache, it shouldn't be a problem either because swapcache
> has a reference count and we should wait PG_lock release
Hi Minchan,
On (08/03/18 12:00), Minchan Kim wrote:
> > "Device is so fast that asynchronous IO would be inefficient."
> >
> > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM.
> > Probably, the comment needs to be updated as well.
>
> I couldn't catch your point. Could
Hi Minchan,
On (08/03/18 12:00), Minchan Kim wrote:
> > "Device is so fast that asynchronous IO would be inefficient."
> >
> > Which is not the reason why BDI_CAP_SYNCHRONOUS_IO is used by ZRAM.
> > Probably, the comment needs to be updated as well.
>
> I couldn't catch your point. Could
On (08/03/18 11:39), Sergey Senozhatsky wrote:
> [..]
>
> > A reader looking at this would wonder "why the heck are we doing that".
> > Adding a code comment would help them.
>
> The interesting thing here is that include/linux/backing-dev.h
>
On (08/03/18 11:39), Sergey Senozhatsky wrote:
> [..]
>
> > A reader looking at this would wonder "why the heck are we doing that".
> > Adding a code comment would help them.
>
> The interesting thing here is that include/linux/backing-dev.h
>
On (08/02/18 14:13), Andrew Morton wrote:
[..]
> That changelog is rather hard to follow. Please review my edits:
>
> : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO
^BDI_CAP_SYNCHRONOUS_IO
[..]
> A reader
On (08/02/18 14:13), Andrew Morton wrote:
[..]
> That changelog is rather hard to follow. Please review my edits:
>
> : If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO
^BDI_CAP_SYNCHRONOUS_IO
[..]
> A reader
On (07/24/18 19:51), Matthew Wilcox wrote:
>
> Also note that this is in the allocation path; this flag isn't checked
> at free. But it is cleared on free, so someone's stomping on page->flags
> after they're freed. I suggest enabling more debugging code.
Would be lovely if Tino could bisect
On (07/24/18 19:51), Matthew Wilcox wrote:
>
> Also note that this is in the allocation path; this flag isn't checked
> at free. But it is cleared on free, so someone's stomping on page->flags
> after they're freed. I suggest enabling more debugging code.
Would be lovely if Tino could bisect
On (07/24/18 10:03), Minchan Kim wrote:
> On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > Hello,
> >
> > after enabling the writeback feature in zram, I encountered the kernel bug
> > below with heavy swap utilization. There is one specific workload that
> > triggers the bug
On (07/24/18 10:03), Minchan Kim wrote:
> On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > Hello,
> >
> > after enabling the writeback feature in zram, I encountered the kernel bug
> > below with heavy swap utilization. There is one specific workload that
> > triggers the bug
e WARN definition to 80-chars's
> per line ;-)
Yeah, I noticed that too.
Acked-by: Sergey Senozhatsky
-ss
e WARN definition to 80-chars's
> per line ;-)
Yeah, I noticed that too.
Acked-by: Sergey Senozhatsky
-ss
On (07/11/18 23:09), Steven Rostedt wrote:
> > On (07/11/18 15:17), Steven Rostedt wrote:
> > > +bool ignore_console_lock_warning __read_mostly;
> > > +EXPORT_SYMBOL(ignore_console_lock_warning);
> >
> > OK. So, to recap,
> > We made is_console_locked() EXPORT_SYMBOL recently [it's still in
>
On (07/11/18 23:09), Steven Rostedt wrote:
> > On (07/11/18 15:17), Steven Rostedt wrote:
> > > +bool ignore_console_lock_warning __read_mostly;
> > > +EXPORT_SYMBOL(ignore_console_lock_warning);
> >
> > OK. So, to recap,
> > We made is_console_locked() EXPORT_SYMBOL recently [it's still in
>
On (07/11/18 15:17), Steven Rostedt wrote:
> +bool ignore_console_lock_warning __read_mostly;
> +EXPORT_SYMBOL(ignore_console_lock_warning);
OK. So, to recap,
We made is_console_locked() EXPORT_SYMBOL recently [it's still in linux-next],
so people could use WARN_CONSOLE_UNLOCKED in more places;
On (07/11/18 15:17), Steven Rostedt wrote:
> +bool ignore_console_lock_warning __read_mostly;
> +EXPORT_SYMBOL(ignore_console_lock_warning);
OK. So, to recap,
We made is_console_locked() EXPORT_SYMBOL recently [it's still in linux-next],
so people could use WARN_CONSOLE_UNLOCKED in more places;
Cc-ng Alan, Greg, Jiri
A lockdep report:
https://lore.kernel.org/lkml/20180703043021.GA547@jagdpanzerIV/T/#u
On (07/10/18 13:50), Petr Mladek wrote:
> >
> > Another option *possibly* could be...
> >
> > ... maybe we can brake another lock dependency. I don't quite understand,
> > and surely
Cc-ng Alan, Greg, Jiri
A lockdep report:
https://lore.kernel.org/lkml/20180703043021.GA547@jagdpanzerIV/T/#u
On (07/10/18 13:50), Petr Mladek wrote:
> >
> > Another option *possibly* could be...
> >
> > ... maybe we can brake another lock dependency. I don't quite understand,
> > and surely
On (07/10/18 17:22), Arnd Bergmann wrote:
> Moving the call to suppress_message_printing() into the '#ifdef CONFIG_PRINTK'
> section means that the alternative definition is now unused when PRINTK is
> disabled:
>
> kernel/printk/printk.c:2033:13: error: 'suppress_message_printing' defined
> but
On (07/10/18 17:22), Arnd Bergmann wrote:
> Moving the call to suppress_message_printing() into the '#ifdef CONFIG_PRINTK'
> section means that the alternative definition is now unused when PRINTK is
> disabled:
>
> kernel/printk/printk.c:2033:13: error: 'suppress_message_printing' defined
> but
_printing’ defined
> but not used [-Wunused-function]
> static bool suppress_message_printing(int level) { return false; }
>
> Reported-by: Stephen Rothwell
> Suggested-by: Maninder Singh
> Signed-off-by: Petr Mladek
Acked-by: Sergey Senozhatsky
Happens all the time to me as w
_printing’ defined
> but not used [-Wunused-function]
> static bool suppress_message_printing(int level) { return false; }
>
> Reported-by: Stephen Rothwell
> Suggested-by: Maninder Singh
> Signed-off-by: Petr Mladek
Acked-by: Sergey Senozhatsky
Happens all the time to me as w
1001 - 1100 of 6882 matches
Mail list logo
