On (10/03/18 11:23), Petr Mladek wrote:
> On Fri 2018-09-28 18:53:04, Sergey Senozhatsky wrote:
> > CON_PRINTBUFFER console registration requires us to do several
> > preparation steps:
> > - Rollback console_seq to replay logbuf messages which were already
> > seen o
On (10/03/18 11:23), Petr Mladek wrote:
> On Fri 2018-09-28 18:53:04, Sergey Senozhatsky wrote:
> > CON_PRINTBUFFER console registration requires us to do several
> > preparation steps:
> > - Rollback console_seq to replay logbuf messages which were already
> > seen o
On (09/27/18 12:46), Daniel Wang wrote:
> Prior to this change, the combination of `softlockup_panic=1` and
> `softlockup_all_cpu_stacktrace=1` may result in a deadlock when the reboot
> path
> is trying to grab the console lock that is held by the stack trace printing
> path. What seems to be
On (09/27/18 12:46), Daniel Wang wrote:
> Prior to this change, the combination of `softlockup_panic=1` and
> `softlockup_all_cpu_stacktrace=1` may result in a deadlock when the reboot
> path
> is trying to grab the console lock that is held by the stack trace printing
> path. What seems to be
On (10/01/18 20:21), Tetsuo Handa wrote:
> >> Because there is no guarantee that memory information is dumped under the
> >> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
> >> cannot be held when reporting GFP_ATOMIC memory allocation failures.
> >
> > IOW, static
On (10/01/18 20:21), Tetsuo Handa wrote:
> >> Because there is no guarantee that memory information is dumped under the
> >> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
> >> cannot be held when reporting GFP_ATOMIC memory allocation failures.
> >
> > IOW, static
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Give explicit error for users who want to use larger log buffer.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Suggested-by: Serge
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Add KBUILD_MODNAME to make prints more clear.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Give explicit error for users who want to use larger log buffer.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Suggested-by: Serge
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Add KBUILD_MODNAME to make prints more clear.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
Signed-off-by: He Zhe
> Cc: sta...@vger.kernel.org
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
Signed-off-by: He Zhe
> Cc: sta...@vger.kernel.org
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
On (09/30/18 00:45), zhe...@windriver.com wrote:
>
> This patch adds a check to prevent the panic.
>
> Signed-off-by: He Zhe
> Cc: sta...@vger.kernel.org
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
On (09/30/18 00:45), zhe...@windriver.com wrote:
>
> This patch adds a check to prevent the panic.
>
> Signed-off-by: He Zhe
> Cc: sta...@vger.kernel.org
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
reviously, it worked
because msg_print_ext_header() had that "an optional external merge
of the records" functionality:
if (msg->flags & LOG_CONT)
cont = (prev_flags & LOG_CONT) ? '+' : 'c';
We don't do this as of now, so keep kernel cont always en
reviously, it worked
because msg_print_ext_header() had that "an optional external merge
of the records" functionality:
if (msg->flags & LOG_CONT)
cont = (prev_flags & LOG_CONT) ? '+' : 'c';
We don't do this as of now, so keep kernel cont always en
ush due to
possible buffer overflow or for preliminary flush due to cont race.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index aea37b7927dd..1856db8128c6 100644
--- a/kernel/pr
From: Sergey Senozhatsky
Prior to 5c2992ee7fd8a29 ("printk: remove console flushing special
cases for partial buffered lines") we would do console_cont_flush()
for each pr_cont() to print cont fragments, so console_unlock() would
actually print data:
pr_cont();
co
ush due to
possible buffer overflow or for preliminary flush due to cont race.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index aea37b7927dd..1856db8128c6 100644
--- a/kernel/pr
From: Sergey Senozhatsky
Prior to 5c2992ee7fd8a29 ("printk: remove console flushing special
cases for partial buffered lines") we would do console_cont_flush()
for each pr_cont() to print cont fragments, so console_unlock() would
actually print data:
pr_cont();
co
Hello,
RFC
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.
Sergey Senozhatsky (3):
printk: keep kernel cont supp
Hello,
RFC
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.
Sergey Senozhatsky (3):
printk: keep kernel cont supp
On (09/22/18 12:11), Minchan Kim wrote:
> On Wed, Sep 19, 2018 at 04:29:16PM +0900, Sergey Senozhatsky wrote:
> > On (09/19/18 14:18), Minchan Kim wrote:
> > > We need to count zero filled pages as well as other pages in zram.
> >
> > A nit,
> >
> >
On (09/22/18 12:11), Minchan Kim wrote:
> On Wed, Sep 19, 2018 at 04:29:16PM +0900, Sergey Senozhatsky wrote:
> > On (09/19/18 14:18), Minchan Kim wrote:
> > > We need to count zero filled pages as well as other pages in zram.
> >
> > A nit,
> >
> >
On (10/01/18 14:52), Sergey Senozhatsky wrote:
> On (09/29/18 20:13), Sergey Senozhatsky wrote:
> > We used to flush "incomplete" cont lines (fragments) from console_unlock().
> >
> > void console_unlock(void)
> > {
> > ...
> > /* flush
On (10/01/18 14:52), Sergey Senozhatsky wrote:
> On (09/29/18 20:13), Sergey Senozhatsky wrote:
> > We used to flush "incomplete" cont lines (fragments) from console_unlock().
> >
> > void console_unlock(void)
> > {
> > ...
> > /* flush
On (09/29/18 20:13), Sergey Senozhatsky wrote:
> We used to flush "incomplete" cont lines (fragments) from console_unlock().
>
> void console_unlock(void)
> {
> ...
> /* flush buffered message fragment immediately to console */
> console_cont_flu
On (09/29/18 20:13), Sergey Senozhatsky wrote:
> We used to flush "incomplete" cont lines (fragments) from console_unlock().
>
> void console_unlock(void)
> {
> ...
> /* flush buffered message fragment immediately to console */
> console_cont_flu
On (10/01/18 11:37), Sergey Senozhatsky wrote:
> If we are about to have a list of printk buffers then we probably can
> define a list of NR_CPUS cont buffers. And we probably can reuse the
> existing struct cont for buffered printk, having 2 different struct-s
> for the same thing -
On (10/01/18 11:37), Sergey Senozhatsky wrote:
> If we are about to have a list of printk buffers then we probably can
> define a list of NR_CPUS cont buffers. And we probably can reuse the
> existing struct cont for buffered printk, having 2 different struct-s
> for the same thing -
On (09/29/18 20:15), Tetsuo Handa wrote:
>
> Because there is no guarantee that memory information is dumped under the
> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
> cannot be held when reporting GFP_ATOMIC memory allocation failures.
IOW, static pr_line buffer
On (09/29/18 20:15), Tetsuo Handa wrote:
>
> Because there is no guarantee that memory information is dumped under the
> oom_lock mutex. The oom_lock is held when calling out_of_memory(), and it
> cannot be held when reporting GFP_ATOMIC memory allocation failures.
IOW, static pr_line buffer
On (09/29/18 22:48), zhe...@windriver.com wrote:
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
Plus this one
---
kernel/printk/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c9068074dd09..e32f93a2fa84
On (09/29/18 22:48), zhe...@windriver.com wrote:
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
Plus this one
---
kernel/printk/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c9068074dd09..e32f93a2fa84
On (09/28/18 20:21), Tetsuo Handa wrote:
> On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> > The good thing about cont buffer is that we flush it on panic. E.g.
> > core/arch early boot stage can do:
> >
> > pr_cont("going to call early_init_fo
On (09/28/18 20:21), Tetsuo Handa wrote:
> On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> > The good thing about cont buffer is that we flush it on panic. E.g.
> > core/arch early boot stage can do:
> >
> > pr_cont("going to call early_init_fo
On (09/28/18 20:01), Tetsuo Handa wrote:
> > Yes, this makes sense. At the same time we can keep pr_line buffer
> > in .bss
> >
> > static char buffer[1024];
> > static DEFINE_PR_LINE_BUF(..., buffer);
> >
> > just like you have already mentioned. But that's going to require a
> >
On (09/28/18 20:01), Tetsuo Handa wrote:
> > Yes, this makes sense. At the same time we can keep pr_line buffer
> > in .bss
> >
> > static char buffer[1024];
> > static DEFINE_PR_LINE_BUF(..., buffer);
> >
> > just like you have already mentioned. But that's going to require a
> >
On (09/28/18 22:46), zhe...@windriver.com wrote:
> This patch adds a check to prevent the panic and a check to report if someone
> is
> setting it over 4G.
OK, He Zhe, you are almost there.
Let's do the series the following way:
- four patches
- each change goes into a separate patch
- the
On (09/28/18 22:46), zhe...@windriver.com wrote:
> This patch adds a check to prevent the panic and a check to report if someone
> is
> setting it over 4G.
OK, He Zhe, you are almost there.
Let's do the series the following way:
- four patches
- each change goes into a separate patch
- the
ere we rollback console_seq.
Signed-off-by: Sergey Senozhatsky
---
v2: added comment (Petr)
kernel/printk/printk.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 308497194bd4..24a81ba9ec77 100644
--- a/kernel/printk/printk
ere we rollback console_seq.
Signed-off-by: Sergey Senozhatsky
---
v2: added comment (Petr)
kernel/printk/printk.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 308497194bd4..24a81ba9ec77 100644
--- a/kernel/printk/printk
On (09/24/18 17:11), Tetsuo Handa wrote:
> The reason of using statically preallocated global buffers is that I think
> that it is inconvenient for KERN_CONT users to calculate necessary bytes
> only for avoiding message truncation. The pr_line might be passed to deep
> into the callchain and
On (09/24/18 17:11), Tetsuo Handa wrote:
> The reason of using statically preallocated global buffers is that I think
> that it is inconvenient for KERN_CONT users to calculate necessary bytes
> only for avoiding message truncation. The pr_line might be passed to deep
> into the callchain and
On (09/28/18 01:10), Tetsuo Handa wrote:
>
> Therefore, I think that "Either we need to require synchronization - umm...
> and
> document it - or to provide some means of synchronization in pr_line()." is a
> pointless worry. It is only existing printk() API which needs
> synchronization. I
>
On (09/28/18 01:10), Tetsuo Handa wrote:
>
> Therefore, I think that "Either we need to require synchronization - umm...
> and
> document it - or to provide some means of synchronization in pr_line()." is a
> pointless worry. It is only existing printk() API which needs
> synchronization. I
>
On (09/19/18 20:02), Tetsuo Handa wrote:
> I'm inclined to propose a simple one shown below, similar to just having
> several "struct cont" for concurrent printk() users.
Tetsuo, thanks for the patch.
> What Linus has commented is that implicit context is bad, and below one
> uses explicit
On (09/19/18 20:02), Tetsuo Handa wrote:
> I'm inclined to propose a simple one shown below, similar to just having
> several "struct cont" for concurrent printk() users.
Tetsuo, thanks for the patch.
> What Linus has commented is that implicit context is bad, and below one
> uses explicit
On (09/26/18 13:37), Petr Mladek wrote:
> /*
> * Set exclusive_console still with disabled interrupts to
> * reduce race window with eventual console_flush_on_panic()
> * that ignores console_lock.
> */
Looks good to me.
> I am not against the change. It makes some sense and it does
> not
On (09/26/18 13:37), Petr Mladek wrote:
> /*
> * Set exclusive_console still with disabled interrupts to
> * reduce race window with eventual console_flush_on_panic()
> * that ignores console_lock.
> */
Looks good to me.
> I am not against the change. It makes some sense and it does
> not
On (09/26/18 13:05), Petr Mladek wrote:
> First, I would move the check into log_buf_len_update() so that
> we catch the overflow also in other situations.
OK.
> Second, please, keep only the first line.
OK.
> It is enough to describe the problem.
OK.
He Zhe, will you pick it up?
-ss
On (09/26/18 13:05), Petr Mladek wrote:
> First, I would move the check into log_buf_len_update() so that
> we catch the overflow also in other situations.
OK.
> Second, please, keep only the first line.
OK.
> It is enough to describe the problem.
OK.
He Zhe, will you pick it up?
-ss
On (09/25/18 14:23), Petr Mladek wrote:
> The 32GB was mentioned as an example one year ego. This is not enough
> for a new syscall from my point of view.
I agree. I didn't think of syslog(); was merely thinking about logbuf
and flushing it to the consoles. syslog() stuff is a bit complex. We
On (09/25/18 14:23), Petr Mladek wrote:
> The 32GB was mentioned as an example one year ego. This is not enough
> for a new syscall from my point of view.
I agree. I didn't think of syslog(); was merely thinking about logbuf
and flushing it to the consoles. syslog() stuff is a bit complex. We
On (09/14/18 20:19), Sergey Senozhatsky wrote:
> On (09/14/18 10:59), Petr Mladek wrote:
> >
> > Well, I am not sure if it is worth the code complexity.
> >
>
> Well, I don't think we need to bother that much here. Besides,
> exclusive_console is cleared und
On (09/14/18 20:19), Sergey Senozhatsky wrote:
> On (09/14/18 10:59), Petr Mladek wrote:
> >
> > Well, I am not sure if it is worth the code complexity.
> >
>
> Well, I don't think we need to bother that much here. Besides,
> exclusive_console is cleared und
On (09/25/18 14:23), Petr Mladek wrote:
>
> Thanks for pointing this out. Well, it seems that the change would
> require a new syscall to pass the buffer size as long. We need to
> be sure that people would use this in the real life.
Agreed.
> This thread suggested this change to avoid a
On (09/25/18 14:23), Petr Mladek wrote:
>
> Thanks for pointing this out. Well, it seems that the change would
> require a new syscall to pass the buffer size as long. We need to
> be sure that people would use this in the real life.
Agreed.
> This thread suggested this change to avoid a
On (09/22/18 23:36), He Zhe wrote:
> I'd like to fix the above issues. But can I have your opinions about how to
> handle the syscall?
Hmm. This part is complex, I need to look at it more.
A signed int is a good buffer size limit for 32-bit user space.
But this also means that syslog might
On (09/22/18 23:36), He Zhe wrote:
> I'd like to fix the above issues. But can I have your opinions about how to
> handle the syscall?
Hmm. This part is complex, I need to look at it more.
A signed int is a good buffer size limit for 32-bit user space.
But this also means that syslog might
On (09/21/18 09:37), Petr Mladek wrote:
>
> I would personally keep the size as unsigned int. IMHO, a support
> for a log buffer bigger than 4GB is not worth the complexity.
>
ftrace dumps are bothering me.
Steven Rostedt wrote [0]:
>
> Especially when I have a machine with 240 CPUs. But it
On (09/21/18 09:37), Petr Mladek wrote:
>
> I would personally keep the size as unsigned int. IMHO, a support
> for a log buffer bigger than 4GB is not worth the complexity.
>
ftrace dumps are bothering me.
Steven Rostedt wrote [0]:
>
> Especially when I have a machine with 240 CPUs. But it
On (09/22/18 23:40), zhe...@windriver.com wrote:
> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> /* save requested log_buf_len since it's too early to process it */
> static int __init log_buf_len_setup(char *str)
> {
> - unsigned size = memparse(str, );
> +
On (09/22/18 23:40), zhe...@windriver.com wrote:
> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> /* save requested log_buf_len since it's too early to process it */
> static int __init log_buf_len_setup(char *str)
> {
> - unsigned size = memparse(str, );
> +
On (09/19/18 14:18), Minchan Kim wrote:
> We need to count zero filled pages as well as other pages in zram.
A nit,
'ZRAM_FLAG_SHIFT + 1' covers all ZRAM_SAME pages, not only
zero filled pages.
-ss
On (09/19/18 14:18), Minchan Kim wrote:
> We need to count zero filled pages as well as other pages in zram.
A nit,
'ZRAM_FLAG_SHIFT + 1' covers all ZRAM_SAME pages, not only
zero filled pages.
-ss
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len sinc
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len sinc
On (09/18/18 22:43), Steven Rostedt wrote:
> > First - switch to u64 size.
> > Second - check for NULL str.
> >
> I think I would switch it around. Check for NULL first, and then switch
> to u64. It was always an int, do we need to backport converting it to
> u64 to stable? The NULL check is a
On (09/18/18 22:43), Steven Rostedt wrote:
> > First - switch to u64 size.
> > Second - check for NULL str.
> >
> I think I would switch it around. Check for NULL first, and then switch
> to u64. It was always an int, do we need to backport converting it to
> u64 to stable? The NULL check is a
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len sinc
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len sinc
On (09/19/18 01:17), zhe...@windriver.com wrote:
> Add KBUILD_MODNAME to make prints more clear.
No strong opinion. I'm OK with this change.
> And use 'unsigned int' intead of 'unsigned' according to
> checkpatch.pl's suggestion.
I don't think that "unsigned int" is the right thing to use
On (09/19/18 01:17), zhe...@windriver.com wrote:
> Add KBUILD_MODNAME to make prints more clear.
No strong opinion. I'm OK with this change.
> And use 'unsigned int' intead of 'unsigned' according to
> checkpatch.pl's suggestion.
I don't think that "unsigned int" is the right thing to use
uot;config string" is misleading and in
fact it's a "boot command line parameter". But, dunno, I guess I'd just
drop that print out.
Otherwise,
Acked-by: Sergey Senozhatsky
-ss
uot;config string" is misleading and in
fact it's a "boot command line parameter". But, dunno, I guess I'd just
drop that print out.
Otherwise,
Acked-by: Sergey Senozhatsky
-ss
On (09/19/18 10:12), Sergey Senozhatsky wrote:
> On (09/18/18 07:06), Guenter Roeck wrote:
> > > So the check either better be
> > >
> > > if (fc->ops && fc->ops->reconfigure)
> > >
> >
> > Since there are multiple i
On (09/19/18 10:12), Sergey Senozhatsky wrote:
> On (09/18/18 07:06), Guenter Roeck wrote:
> > > So the check either better be
> > >
> > > if (fc->ops && fc->ops->reconfigure)
> > >
> >
> > Since there are multiple i
On (09/18/18 17:39), David Howells wrote:
[..]
> -static int legacy_init_fs_context(struct fs_context *fc, struct dentry
> *dentry)
> +int legacy_init_fs_context(struct fs_context *fc, struct dentry *dentry)
> {
> + switch (fc->purpose) {
> + default:
> + fc->fs_private =
On (09/18/18 17:39), David Howells wrote:
[..]
> -static int legacy_init_fs_context(struct fs_context *fc, struct dentry
> *dentry)
> +int legacy_init_fs_context(struct fs_context *fc, struct dentry *dentry)
> {
> + switch (fc->purpose) {
> + default:
> + fc->fs_private =
On (09/18/18 07:06), Guenter Roeck wrote:
> > So the check either better be
> >
> > if (fc->ops && fc->ops->reconfigure)
> >
>
> Since there are multiple instances of fs_context where fc->ops isn't set,
> this check would be needed wherever fc->ops is dereferenced.
Right. If fc is always
On (09/18/18 07:06), Guenter Roeck wrote:
> > So the check either better be
> >
> > if (fc->ops && fc->ops->reconfigure)
> >
>
> Since there are multiple instances of fs_context where fc->ops isn't set,
> this check would be needed wherever fc->ops is dereferenced.
Right. If fc is always
On (08/01/18 16:25), David Howells wrote:
[..]
> @@ -2460,18 +2428,41 @@ static int do_remount(struct path *path, int
> ms_flags, int sb_flags,
> if (!can_change_locked_flags(mnt, mnt_flags))
> return -EPERM;
>
> - err = security_sb_remount(sb, data, data_size);
> -
On (08/01/18 16:25), David Howells wrote:
[..]
> @@ -2460,18 +2428,41 @@ static int do_remount(struct path *path, int
> ms_flags, int sb_flags,
> if (!can_change_locked_flags(mnt, mnt_flags))
> return -EPERM;
>
> - err = security_sb_remount(sb, data, data_size);
> -
On (09/18/18 18:07), Sergey Senozhatsky wrote:
> emergency_remount()
> do_emergency_remount()
> do_emergency_remount_callback()
>reconfigure_super()
>
> At fc->ops dereference:
>
> 981 if (fc->ops->reconfigure) {
> ^
>
On (09/18/18 18:07), Sergey Senozhatsky wrote:
> emergency_remount()
> do_emergency_remount()
> do_emergency_remount_callback()
>reconfigure_super()
>
> At fc->ops dereference:
>
> 981 if (fc->ops->reconfigure) {
> ^
>
Hi,
On (09/11/18 16:54), Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 12:17:35AM +0100, David Howells wrote:
> > Guenter Roeck wrote:
> >
> > > [8.507672] RIP: 0010:reconfigure_super+0x47/0x210
> >
> > Can you tell me the file and line this corresponds to?
> >
> I don't know, but some
Hi,
On (09/11/18 16:54), Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 12:17:35AM +0100, David Howells wrote:
> > Guenter Roeck wrote:
> >
> > > [8.507672] RIP: 0010:reconfigure_super+0x47/0x210
> >
> > Can you tell me the file and line this corresponds to?
> >
> I don't know, but some
On (09/14/18 21:03), Tetsuo Handa wrote:
> > 80 bytes is quite short for OOM, agreed.
> >
> >> static char oom_print_buf[1024];
> >> DEFINE_PR_LINE_BUF(level, oom_print_buf);
> >
> > Do I get it right that you suggest to drop the "size" param?
>
> No. I just forgot to add params. ;-)
>
> >
On (09/14/18 21:03), Tetsuo Handa wrote:
> > 80 bytes is quite short for OOM, agreed.
> >
> >> static char oom_print_buf[1024];
> >> DEFINE_PR_LINE_BUF(level, oom_print_buf);
> >
> > Do I get it right that you suggest to drop the "size" param?
>
> No. I just forgot to add params. ;-)
>
> >
On (09/14/18 19:37), Tetsuo Handa wrote:
> > @@ -20,6 +20,9 @@
> > * Annotation for a "continued" line of log printout (only done after a
> > * line that had no enclosing \n). Only to be used by core/arch code
> > * during early bootup (a continued line is not SMP-safe otherwise).
> > + *
>
On (09/14/18 19:37), Tetsuo Handa wrote:
> > @@ -20,6 +20,9 @@
> > * Annotation for a "continued" line of log printout (only done after a
> > * line that had no enclosing \n). Only to be used by core/arch code
> > * during early bootup (a continued line is not SMP-safe otherwise).
> > + *
>
On (09/14/18 10:59), Petr Mladek wrote:
>
> Well, I am not sure if it is worth the code complexity.
>
Well, I don't think we need to bother that much here. Besides,
exclusive_console is cleared under logbuf_lock with preemption
disabled now. So we set it under logbuf_lock and !irq and we
clear
On (09/14/18 10:59), Petr Mladek wrote:
>
> Well, I am not sure if it is worth the code complexity.
>
Well, I don't think we need to bother that much here. Besides,
exclusive_console is cleared under logbuf_lock with preemption
disabled now. So we set it under logbuf_lock and !irq and we
clear
On (09/13/18 23:28), Sergey Senozhatsky wrote:
> Not that I see any problems with pr_line_flush(). But can drop it, sure.
> pr_line() is a replacement for pr_cont() and as such it's not for multi-line
> buffering.
OK, attached.
Let me know if anything needs to improved (including broke
On (09/13/18 23:28), Sergey Senozhatsky wrote:
> Not that I see any problems with pr_line_flush(). But can drop it, sure.
> pr_line() is a replacement for pr_cont() and as such it's not for multi-line
> buffering.
OK, attached.
Let me know if anything needs to improved (including broke
ere we rollback console_seq.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 992bb6bb7ac2..c52a986a72b3 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/prin
ere we rollback console_seq.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 992bb6bb7ac2..c52a986a72b3 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/prin
On (09/13/18 21:22), Steven Rostedt wrote:
> > Good call. It was a fast path for pr_cont("\n").
> > But it made me wondering and I did some grepping
> >
>
> [..]
>
> > kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
>
> Note, looking at the history of that, I was just
On (09/13/18 21:22), Steven Rostedt wrote:
> > Good call. It was a fast path for pr_cont("\n").
> > But it made me wondering and I did some grepping
> >
>
> [..]
>
> > kernel/trace/ftrace.c: pr_cont("\n expected tramp: %lx\n", ip);
>
> Note, looking at the history of that, I was just
901 - 1000 of 6882 matches
Mail list logo
