Joe Perches writes:
On Fri, 2021-04-16 at 14:56 +0100, Chris Down wrote:
Any better suggestions? :-)
A gcc plugin that looks for functions marked __printf(fmt, pos)
so any const fmt is stored.
I fail to see any way in which that can solve the problem described, which is
mobility
Hey Petr, Rasmus,
Apologies for the delay, I've been out ill for a while so I'm just coming back
to look at this.
Petr Mladek writes:
Anyway, on to the other thing I mentioned on dev_err and friends: I
think it would improve readability and make it a lot easier to (probably
in a later patch)
-forward correction inside the spinlock section. I
didn't carry it forward into the lockless page counters for
simplicity, but it turns out this is quite useful in practice. ]
Signed-off-by: Johannes Weiner
Acked-by: Chris Down
---
mm/page_counter.c | 8 ++--
1 file changed, 6 insertions(+), 2
Hey Chuck,
Thanks for the (very) fast reply! :-)
Chuck Lever III writes:
This can be confusing for downstream users, who don't know what messages
like "fragment too large: 1195725856" actually mean, or that they
indicate some misconfigured infrastructure elsewhere.
One wonders whether that
Hey folks,
Let me know if you'd like more evidence that this is a persisting problem. Also
more than happy to change the generation of the whole debug string to go into
svc_sock_reclen_ascii or use LOG_CONT if you'd prefer to avoid the multiple
ternaries (but the latter probably needs some
ble to put this here since this particular code path is the
one that has repeatedly come up in production.
Signed-off-by: Chris Down
Cc: Chuck Lever
Cc: J. Bruce Fields
Cc: Trond Myklebust
Cc: David S. Miller
---
net/sunrpc/svcsock.c | 39 +--
1 file ch
Rasmus Villemoes writes:
I think it's pointless renaming the symbol to _printk, with all the
churn and reduced readability that involves (especially when reading
assembly "why are we calling _printk and not printk here?"). There's
nothing wrong with providing a macro wrapper by the same name
Petr Mladek writes:
In my mind, pi_start is really just a special case of pi_next, so the code
flow makes sense to me. I'm happy to change it to whatever you like, but
it's not immediately obvious to me what that is :-)
Good question! I have missed that pi_start() can be called also with
Petr Mladek writes:
I don't feel strongly that this is more clear though, so maybe you
mean something else?
I was pretty tired when reviewing the patch. It was not easy for me
to create the mental model of the code. I felt that some other names
would have made it easier.
Also the tricky
Ack to all unmentioned suggestions. :-)
Petr Mladek writes:
+ changed or no longer present.
+
+ There is no additional runtime cost to printk with this enabled.
+
#
# Architectures with an unreliable sched_clock() should select this:
#
diff --git a/kernel/module.c
Hey Petr,
Chris Down writes:
$ head -1 vmlinux; shuf -n 5 vmlinux
# filename:line function "format"
<5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is
misaligned\n"
<4> kernel/trace/trace.c:8296 trace_create_file "C
Greg Kroah-Hartman writes:
On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote:
+ ps->file = debugfs_create_file(pi_get_module_name(mod), 0444, dfs_index,
+ ps, _index_fops);
+
+ if (IS_ERR(ps->file)) {
+ pi_sec_remo
it becomes problematic.
There is no additional runtime cost for printk callers or printk itself,
and the assembly generated is exactly the same.
Signed-off-by: Chris Down
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: John Ogness
Cc: Steven Rostedt
Cc: Greg Kroah-Hartman
Cc: Johannes Wei
is missed for cgroup v1.
Signed-off-by: Yang Shi
Thanks.
Acked-by: Chris Down
---
Documentation/admin-guide/cgroup-v1/memory.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst
b/Documentation/admin-guide/cgroup-v1/memory.rst
index 0936412e044e
Chris Down writes:
I must confess I have no idea of the history of why it was `extern
int` in the first place -- my fear was somehow we use cmpxchg.h from a
different context. Do you have any idea? :-)
Ok, found where it's introduced in the pre-git archives: "New file
asm-ia64/intrins
Matthew Wilcox writes:
Why not just fix it?
diff --git a/arch/ia64/include/uapi/asm/cmpxchg.h
b/arch/ia64/include/uapi/asm/cmpxchg.h
index 5d90307fd6e0..d955a8e3ebde 100644
--- a/arch/ia64/include/uapi/asm/cmpxchg.h
+++ b/arch/ia64/include/uapi/asm/cmpxchg.h
@@ -139,7 +139,7 @@ extern long
+ akpm, linux-mm
Hey folks,
Chris Down writes:
With !CONFIG_PRINTK, printk() is static in the header, but ia64's
cmpxchg.h with CONFIG_IA64_DEBUG_CMPXCHG doesn't take this into account
before trying to use it as extern, resulting in a compiler error:
./include/linux/printk.h:219:5: error
Petr Mladek writes:
On Thu 2021-02-18 12:41:39, Chris Down wrote:
Petr Mladek writes:
> > - See if it's safe to pass a printk_fmt_sec to seq_file instead of a module
>
> Also it might be needed to store the pointer to struct module.
You mean, have a `struct module` entry for this
Thanks for all your feedback, Petr and Steven. :-)
Petr, I believe this is a comprehensive checklist of everything we discussed
for v5 -- any chance you could double check I'm not missing anything you folks
wanted? Thanks!
- Use seq_file iterator again instead of simple_open + size
- Remove
Eiichi Tsukata writes:
But that comes with a challenge: despite listening on cgroup for
pressure notifications (which happen from those runtime events we do
not control),
We do also have global pressure (PSI) counters. Have you tried to look
into those and try to back off even when the
Petr Mladek writes:
- Move to another file, kernel/printk/debug_formats.c or similar
Just to be sure. The filename should be ideally based on the configure
option and API names, e.g. formats_index.c or so.
The printk_ prefix is not strictly necessary. The file is in printk/
directory. IMHO,
Steven Rostedt writes:
OK, now do the same in C. "%q" "and I guess that "f" in the print statement
in python (but I don't know for sure) does some magic with converting the
"\n" and such.
I agree with Petr on this. Print the format itself, and not what is
converted. It's much easier to convert
Chris Down writes:
open(f);
debugfs_file_get(f);
fops->open();
inode->private = ps;
debugfs_file_put(f);
remove_printk_fmt_sec(); /* kfree ps */
read(f);
debugfs_file_get(f);
fops->read();
ps = inode->private; /* invalid */
debugfs_file_put(f);
Er, sorry, in
Petr Mladek writes:
What about storing the pointer to struct pf_object into
struct printk_fmt_sec *ps into the s->file->f_inode->i_private?
Then we would not need any global list/table at all.
Unless I'm misreading the debugfs code, I think the following is possible:
open(f);
Petr Mladek writes:
> How about config PRINTK_INDEX?
Ah yes, I also like that. PRINTK_INDEX is fine from my perspective and is
more straightforward than "enumeration", thanks.
It is better than enumeration. But there is still the same
problem. The word "index" is used neither in the code
nor
Petr Mladek writes:
> > + debugfs_remove(ps->file);
>
> IMHO, we should remove the file before we remove the way how
> to read it. This should be done in the opposite order
> than in store_printk_fmt_sec().
There is a subtle issue with doing this as-is: debugfs_remove(ps->file)
cannot be
Petr Mladek writes:
I guess that you already use it internally and have its own tooling
around it.
Hmm, we're actually not using it yet widely because I don't want to backport it
to our prod kernel until we're reasonably agreed on the format :-)
My main concern is making sure that parsing
Johannes Weiner writes:
On Tue, Feb 16, 2021 at 05:27:08PM +, Chris Down wrote:
Petr Mladek writes:
> I wonder if we could find a better name for the configure switch.
> I have troubles to imagine what printk enumeration might mean.
> Well, it might be because I am not a nativ
Petr Mladek writes:
I wonder if we could find a better name for the configure switch.
I have troubles to imagine what printk enumeration might mean.
Well, it might be because I am not a native speaker.
Anyway, the word "enumeration" is used only in the configure option.
Everything else is
Petr Mladek writes:
+static size_t printk_fmt_size(const char *fmt)
+{
+ size_t sz = strlen(fmt) + 1;
+
+ /*
+* Some printk formats don't start with KERN_SOH + level. We will add
+* it later when rendering the output.
+*/
+ if (unlikely(fmt[0] !=
Hey Petr,
Petr Mladek writes:
This produces something like:
3Warning: unable to open an initial console.
3Failed to execute %s (error %d)
6Kernel memory protection disabled.
3Starting init: %s exists but couldn't execute it (error %d)
6Run %s as init process
7initcall %pS returned %d after
Hi Eiichi,
I agree with Michal's points, and I think there are also some other design
questions which don't quite make sense to me. Perhaps you can clear them up?
:-)
Eiichi Tsukata writes:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4bdb58ab14cb..e2d57200fd00 100644
--- a/mm/hugetlb.c
Chris Down writes:
kernel test robot writes:
Hi Chris,
Thank you for the patch! Yet something to improve:
I'm pretty sure !CONFIG_PRINTK && CONFIG_IA64_DEBUG_CMPXCHG has been
broken like this long before this change.
I sent "ia64: Depend on non-static printk for cmpxchg debu
dependent on CONFIG_PRINTK to avoid this.
Signed-off-by: Chris Down
Reported-by: kernel test robot
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/Kconfig.debug b/arch/ia64
kernel test robot writes:
Hi Chris,
Thank you for the patch! Yet something to improve:
I'm pretty sure !CONFIG_PRINTK && CONFIG_IA64_DEBUG_CMPXCHG has been broken
like this long before this change.
With !CONFIG_PRINTK, printk() is static in the header, but ia64's cmpxchg.h
with
callers or printk itself,
and the assembly generated is exactly the same.
Signed-off-by: Chris Down
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: John Ogness
Cc: Steven Rostedt
Cc: Greg Kroah-Hartman
Cc: Johannes Weiner
Cc: Kees Cook
Cc: Andrew Morton
---
v2:
- Use seq_printf instead of ste
callers or printk itself,
and the assembly generated is exactly the same.
Signed-off-by: Chris Down
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: John Ogness
Cc: Steven Rostedt
Cc: Greg Kroah-Hartman
Cc: Johannes Weiner
Cc: Kees Cook
Cc: Andrew Morton
---
v2:
- Use seq_printf instead of ste
Greg Kroah-Hartman writes:
How can file ever be NULL?
And if it is an error, what is the problem here? You can always feed
the output of a debugfs_* call back into debugfs, and you never need to
check the return values.
Oh, thanks -- that's helpful to know. Looks like I misread
callers or printk itself,
and the assembly generated is exactly the same.
Signed-off-by: Chris Down
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: John Ogness
Cc: Steven Rostedt
Cc: Greg Kroah-Hartman
Cc: Johannes Weiner
Cc: Kees Cook
Cc: Andrew Morton
---
v2:
- Use seq_printf instead of ste
kernel test robot writes:
All errors (new ones prefixed by >>):
/usr/bin/ld: arch/um/drivers/xterm.o: in function `xterm_open':
xterm.c:(.text+0x16b): undefined reference to `printk'
/usr/bin/ld: xterm.c:(.text+0x1a8): undefined reference to `printk'
/usr/bin/ld: xterm.c:(.text+0x1f4):
Chris Down writes:
3. `KERN_SOH + level' can appear in other places than just printk strings
KERN_SOH is just ASCII '\001' -- it's not distinctive or unique, even when
paired with a check for something that looks like a level after it. For this
reason, your proposed patch results in a non
dynamic level.
I could find literally pages and pages of these just from the last few years.
Your belief that these printks are only in "unchanging" code does not match
reality.
On Thu, 2021-02-04 at 15:37 +, Chris Down wrote:
This patch provides a solution to the issue of
Joe Perches writes:
There are certainly printks which can't be trivially monitored using the printk
format alone, but the vast majority of the ones that are monitored _do_ have
meaningful formats and can be monitored over time. No solution to this is going
to catch every single case, especially
Joe Perches writes:
On Fri, 2021-02-05 at 22:25 +, Chris Down wrote:
Petr Mladek writes:
> + is already optinaly added by pr_fmt() to the printed strings
> as: pr_fmt(): ...
pr_fmts are not consistently used across the kernel, and sometimes differ from
the module itself
:
+ .printk_fmts : AT(ADDR(.printk_fmts) - LOAD_OFFSET) {
0: https://lore.kernel.org/patchwork/patch/1375749/
Signed-off-by: Chris Down
Cc: Andy Whitcroft
Cc: Joe Perches
Cc: Andrew Morton
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts
Oh, apologies -- I was somehow operating under the mistaken memory that this
was under Andrew's purview and neglected to run get_maintainer.
I'll resend. :-)
Greg Kroah-Hartman writes:
> I'm not against the idea. I don't think it belongs in /proc. Perhaps
> debugfs is a better place to put it.
Any location is fine with me, as long as it gets to userspace. How does
/printk/formats or /printk/formats/ sound to you?
That's fine with me, but I'd like
thus passes it in the
options for the remount.
So prevent CONFIG_TMPFS_INODE64 from being selected on s390.
Link:
https://lkml.kernel.org/r/20210205230620.518245-1-seth.fors...@canonical.com
Fixes: ea3271f7196c ("tmpfs: support 64-bit inums per-sb")
Signed-off-by: Seth Forshee
Cc: Chris Down
Hi Petr,
Thanks for looking over the patch. :-)
Petr Mladek writes:
Most production issues come from unexpected phenomena, and as such
usually the code in question doesn't have easily usable tracepoints or
other counters available for the specific problem being mitigated. We
have a number of
Hi Steven,
Steven Rostedt writes:
Interesting, because when I was looking at the original patch (looked at
the lore link before reading your reply), I thought to myself "this looks
exactly like what I did for trace_printk formats", which the above file is
where it is shown. I'm curious if this
Oh, and one more I just spotted and will fix in v2 after other feedback is in:
Chris Down writes:
+static void store_printk_fmt_sec(const struct module *mod, const char **start,
+const char **end)
+{
+ struct printk_fmt_sec *ps = NULL;
+ const char
Some improvements I noticed that I'll include when sending v2.
Chris Down writes:
+static void remove_printk_fmt_sec(const struct module *mod)
+{
+ struct printk_fmt_sec *tmp = NULL, *ps = NULL;
+ const char **fptr = NULL;
fptr can be scoped to list_for_each_entry_safe, I'll move
:
+ .printk_fmts : AT(ADDR(.printk_fmts) - LOAD_OFFSET) {
0: https://lore.kernel.org/patchwork/patch/1375749/
Signed-off-by: Chris Down
Cc: Andrew Morton
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
-by: Chris Down
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: John Ogness
Cc: Johannes Weiner
Cc: Andrew Morton
---
arch/arm/kernel/entry-v7m.S | 2 +-
arch/arm/lib/backtrace-clang.S | 2 +-
arch/arm/lib/backtrace.S | 2 +-
arch/arm/mach-rpc/io-acorn.S | 2
d by
other means already, revert it again.
Fixes: 536d3bf261a2 ("mm: memcontrol: avoid workload stalls when lowering
memory.high")
Cc: # 5.8+
Reported-by: Tejun Heo
Signed-off-by: Johannes Weiner
Acked-by: Chris Down
th keeping: but skip if mem_cgroup_disabled().
Fixes: 9a1ac2288cf1 ("mm/memcontrol:rewrite mem_cgroup_page_lruvec()")
Signed-off-by: Hugh Dickins
Thanks.
Acked-by: Chris Down
Chris Down writes:
solution to the problem -- inclusion should at least be contingent on
either having "correct-ish" stats exported to userspace. Displaying
s/either//
Feng Tang writes:
One further thought is, there are quite some "BATCH" number in
kernel for perf-cpu/global data updating, maybe we can add a
global flag 'sysctl_need_accurate_stats' for
if (sysctl_need_accurate_stats)
batch = SMALLER_BATCH
else
Jacob Wen writes:
set_task_reclaim_state() is a function with 3 lines of code of which 2
lines contain WARN_ON_ONCE.
I am not comfortable with the current repetition.
Ok, but could you please go into _why_ others should feel that way too? There
are equally also reasons to err on the side of
Hi folks,
Andrew Morton writes:
@@ -188,6 +190,10 @@ void quarantine_put(struct kasan_free_me
local_irq_save(flags);
q = this_cpu_ptr(_quarantine);
+ if (q->offline) {
+ local_irq_restore(flags);
+ return;
+ }
qlist_put(q,
` instead, which is more likely to be available (and
mandated by standards).
Signed-off-by: Chris Down
Cc: Masahiro Yamada
Cc: Michal Marek
Cc: linux-kbu...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
scripts/mkcompile_h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Andrea Righi writes:
senpai is focused at estimating the ideal memory requirements without
affecting performance. And this covers the use case about reducing
memory footprint.
In my specific use-case (hibernation) I would let the system use as much
memory as possible if it's doing any activity
Andrea Righi writes:
This feature has been successfully used to improve hibernation time of
cloud computing instances.
Certain cloud providers allow to run "spot instances": low-priority
instances that run when there are spare resources available and can be
stopped at any time to prioritize
Chunxin Zang writes:
Please forgive me for not being able to understand why setting
memory.low for Type_A can solve the problem.
In my scene, Type_A is the most important, so I will set 100G to memory.low.
But 'memory.low' only takes effect passively when the kernel is
reclaiming memory. It
Chunxin Zang writes:
On Tue, Sep 22, 2020 at 5:51 PM Chris Down wrote:
Chunxin Zang writes:
>My usecase is that there are two types of services in one server. They
>have difference
>priorities. Type_A has the highest priority, we need to ensure it's
>schedule latency、I/O
>
Chunxin Zang writes:
My usecase is that there are two types of services in one server. They
have difference
priorities. Type_A has the highest priority, we need to ensure it's
schedule latency、I/O
latency、memory enough. Type_B has the lowest priority, we expect it
will not affect
Type_A when
Michal Hocko writes:
On Mon 21-09-20 16:02:55, zangchun...@bytedance.com wrote:
From: Chunxin Zang
In the cgroup v1, we have 'force_mepty' interface. This is very
useful for userspace to actively release memory. But the cgroup
v2 does not.
This patch reuse cgroup v1's function, but have a
oot 1771385 ... RAug16 21146421:17 echo 3 > /proc/sys/vm/drop_caches
Add a bail out on the fatal signals in the main loop so that the
operation can be terminated by userspace.
Signed-off-by: Chunxin Zang
Signed-off-by: Muchun Song
Acked-by: Chris Down
zangchun...@bytedance.com writes:
+ if (signal_pending(current))
+ return;
This doesn't match your patch title, please update it. :-)
After that, you can add:
Acked-by: Chris Down
Michal Hocko writes:
On Tue 15-09-20 15:47:37, Chris Down wrote:
zangchun...@bytedance.com writes:
> + if (signal_pending(current))
> + return;
This doesn't match your patch title, please update it. :-)
I have to admit I have completely missed this and I
Michal Hocko writes:
> > Yeah, I think we should cc:stable.
>
> Is this a real problem? The buffer should contain 36 lines which makes
> it more than 100B per line. I strongly suspect we are not able to use
> that storage up.
Before memory_stat_format() return, we should call seq_buf_putc(,
Muchun Song writes:
In the cgroup v1, we have a numa_stat interface. This is useful for
providing visibility into the numa locality information within an
memcg since the pages are allowed to be allocated from any physical
node. One of the use cases is evaluating application performance by
Matthew Wilcox writes:
On Wed, Sep 09, 2020 at 10:47:24PM +0100, Chris Down wrote:
Vlastimil Babka writes:
> - Exit also on other signals such as SIGABRT, SIGTERM? If I write to
drop_caches
> and think it's too long, I would prefer to kill it by ctrl-c and not just kill
O
Vlastimil Babka writes:
- Exit also on other signals such as SIGABRT, SIGTERM? If I write to drop_caches
and think it's too long, I would prefer to kill it by ctrl-c and not just kill
Oh dear, fatal_signal_pending() doesn't consider cases with no more userspace
instructions due to SIG_DFL on
Thanks! This looks reasonable to me, and avoids hard-to-reason-about changes in
the existing semantics.
zangchun...@bytedance.com writes:
Signed-off-by: Chunxin Zang
Signed-off-by: Muchun Song
Acked-by: Chris Down
Muchun Song writes:
1. Double the threshold currently hard coded as "10" with each iteration
suggested by Vlastimil. It is also a good idea.
I think this sounds reasonable, although I'd like to see what the difference in
reclaim looks like in practice.
2. In the while loop, we can check
drop_caches by its very nature can be extremely performance intensive -- if
someone wants to abort after trying too long, they can just send a
TASK_KILLABLE signal, no? If exiting the loop and returning to usermode doesn't
reliably work when doing that, then _that's_ something to improve, but
Vlastimil Babka writes:
On 9/8/20 5:09 PM, Chris Down wrote:
drop_caches by its very nature can be extremely performance intensive -- if
someone wants to abort after trying too long, they can just send a
TASK_KILLABLE signal, no? If exiting the loop and returning to usermode doesn't
reliably
...@kvack.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Chris Down
Johannes Weiner writes:
That all being said, the semantics of the new 'high' limit in cgroup2
have allowed us to move reclaim/limit enforcement out of the
allocation context and into the userspace return path.
See the call to mem_cgroup_handle_over_high() from
tracehook_notify_resume(), and the
-onr_inodes=0 none /ext0
mount: /ext0: mount(2) system call failed: Cannot allocate memory.
This patch restores the nr_inodes=0 functionality.
Fixes: e809d5f0b5c9 ("tmpfs: per-superblock i_ino support")
Cc: Chris Down
Signed-off-by: Byron Stanoszek
Acked-by: Chris Down
Thanks, good catch.
Chris Down writes:
Xunlei Pang writes:
Add cond_resched() at the upper shrink_node_memcgs() to solve this
issue, and any other possible issue like meomry.min protection.
I understand the general intent of the patch, but could you clarify
your concern around memory protection?
Oh, I see
Hi Xunlei,
Xunlei Pang writes:
Add cond_resched() at the upper shrink_node_memcgs() to solve this
issue, and any other possible issue like meomry.min protection.
I understand the general intent of the patch, but could you clarify your
concern around memory protection?
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 1f35c9c0ce3888405fc813afedaff79de433cf27
Gitweb:
https://git.kernel.org/tip/1f35c9c0ce3888405fc813afedaff79de433cf27
Author:Chris Down
AuthorDate:Fri, 21 Aug 2020 13:10:24 +01:00
Committer
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: c31feed8461fb8648075ba9b53d9e527d530972f
Gitweb:
https://git.kernel.org/tip/c31feed8461fb8648075ba9b53d9e527d530972f
Author:Chris Down
AuthorDate:Fri, 21 Aug 2020 13:10:35 +01:00
Committer
In many cases the comm enough isn't enough to distinguish the offender,
since for interpreted languages it's likely just going to be "python3"
or whatever. Add the pid to make it unambiguous.
Signed-off-by: Chris Down
Cc: Borislav Petkov
Cc: Jakub Kicinski
---
arch/x86/kernel
of the original patch, while mitigating its
sometimes heavy effects on kmsg composition.
Signed-off-by: Chris Down
Cc: Borislav Petkov
Cc: Jakub Kicinski
---
arch/x86/kernel/msr.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86
ngelog).
Also added pid information to the message, since it makes identification
of the source (more or less) unambiguous.
Changes in v2:
- Fixed mostly aesthetic suggestions from Boris. Thanks! :-)
Chris Down (2):
x86: Prevent userspace MSR access from dominating the console
x86: Make
pet...@infradead.org writes:
On Tue, Aug 18, 2020 at 11:17:56AM +0100, Chris Down wrote:
I'd ask that you understand a bit more about the tradeoffs and intentions of
the patch before rushing in to declare its failure, considering it works
just fine :-)
Clamping the maximal time allows
pet...@infradead.org writes:
But then how can it run-away like Waiman suggested?
Probably because he's not running with that commit at all. We and others use
this to prevent runaway allocation on a huge range of production and desktop
use cases and it works just fine.
/me goes look... and
pet...@infradead.org writes:
On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
Memory controller can be used to control and limit the amount of
physical memory used by a task. When a limit is set in "memory.high" in
a v2 non-root memory cgroup, the memory controller will try to
ngelog).
Also added pid information to the message, since it makes identification
of the source (more or less) unambiguous.
Chris Down (2):
x86: Prevent userspace MSR access from dominating the console
x86: Make source of unrecognised MSR writes unambiguous
arch/x86/kernel/msr.
keeps the intent of the original patch, while
mitigating its sometimes heavy effects on kmsg composition.
Signed-off-by: Chris Down
Cc: Borislav Petkov
Cc: Jakub Kicinski
---
arch/x86/kernel/msr.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/x86
In many cases the comm enough isn't enough to distinguish the offender,
since for interpreted languages it's likely just going to be "python3"
or whatever. Add the pid to make it unambiguous.
Signed-off-by: Chris Down
Cc: Borislav Petkov
Cc: Jakub Kicinski
---
arch/x86/kernel
Waiman Long writes:
On 8/17/20 10:30 AM, Chris Down wrote:
Astractly, I think this really overcomplicates the API a lot. If
these are truly generally useful (and I think that remains to be
demonstrated), they should be additions to the existing API, rather
than a sidestep with prctl
Shakeel Butt writes:
Sometimes, memory reclaim may not be able to recover memory in a rate
that can catch up to the physical memory allocation rate especially
when rotating disks are used for swapping or writing dirty pages. In
this case, the physical memory consumption will keep on increasing.
Astractly, I think this really overcomplicates the API a lot. If these are
truly generally useful (and I think that remains to be demonstrated), they
should be additions to the existing API, rather than a sidestep with prctl.
I also worry about some other more concrete things:
1. Doesn't this
looks fine too.
Signed-off-by: Johannes Weiner
Acked-by: Chris Down
er to set a new memory.high")
Signed-off-by: Johannes Weiner
Acked-by: Chris Down
Gaurav Singh writes:
Passing NULL in strcmp will cause a segmentation fault.
Fix this by returning -1 if expected is NULL pointer.
Did you actually encounter this while running the tests?
1 - 100 of 206 matches
Mail list logo
