Revert needed: udev spewing warnons on common systems in 3.0
Hi Linus,
Can you please revert
commit be8f684d73d8d916847e996bf69cef14352872c6
Author: David Rientjes <[email protected]> Date: Mon Jul 25 17:12:18 2011 -0700
oom: make deprecated use of oom_adj more verbose
/proc/pid/oom_adj is deprecated and scheduled for removal in August 2012 according to Documentation/feature-removal-schedule.txt.
This makes most of my test systems (suse 11.1, 11.2) spew scary WARN_ONs on every boot. GNOME then also complains. While it doesn't cause actual misfunction it scares me every time I boot and other people who can't read git logs like me will be unnecessary scared.
Also the warning is completely useless: noone will be "fixing" udev on old distributions.
IMHO that's not acceptable to break common user land like this. Linux is supposed to be binary compatible and this patch is not in this spirit.
Actually removing the file later should be still fine, but not printing out these scary messages.
I propose to revert this misguided patch for stable and 3.1
Thanks,
-Andi
Signature · 1 line
[email protected] -- Speaking for myself only
Quoted 9 lines · On Mon, 1 Aug 2011 17:52:06 -0700 Andi Kleen <[email protected]> wrote:
Hi Linus,
Can you please revert
commit
be8f684d73d8d916847e996bf69cef14352872c6Author: David Rientjes <[email protected]> Date: Mon Jul 25 17:12:18 2011 -0700
Quoted 8 lines
oom: make deprecated use of
oom_adjmore verbose
/proc/pid/oom_adjis deprecated and scheduled for removal in August 2012 according toDocumentation/feature-removal-schedule.txt.This makes most of my test systems (suse 11.1, 11.2) spew scary
WARN_ONson every boot. GNOME then also complains.
aw, what crap.
"/proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead."
Once per boot. That's not "scary".
Quoted 3 lines
While it doesn't cause actual
misfunction it scares me every time I boot and other people who can't read git logs like me will be unnecessary scared.
What? Look at the damn text - the only reason anyone would need to read a git log after looking at that is terminal cretinism.
Quoted 2 lines
Also the warning is completely useless: noone will be "fixing" udev on old distributions.
I bet there were still old copies of /sbin/update lying around, but we still managed to remove sys_bdflush() this way.
Quoted 9 lines
IMHO that's not acceptable to break common user land like this. Linux is supposed to be binary compatible and this patch is not in this spirit.
Actually removing the file later should be still fine, but not printing out these scary messages.
I propose to revert this misguided patch for stable and 3.1
I see lots of fake reasoning. What's really going on here??
Quoted 6 lines · Andrew Morton
aw, what crap.
"/proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead."
Once per boot. That's not "scary".
It is when there is that totally pointless stack trace, and the kernel bug reporting tool picks it up and tells the user that there was a kernel oops.
Which it really does.
So if it was a "printk_once()" it would be fine. The WARN_ONCE() is just annoying.
Linus
Quoted 6 lines · Linus Torvalds
Quoted 5 lines
aw, what crap.
"/proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead."
Once per boot. That's not "scary".
Quoted 9 lines
It is when there is that totally pointless stack trace, and the kernel bug reporting tool picks it up and tells the user that there was a kernel oops.
Which it really does.
So if it was a "
printk_once()" it would be fine. TheWARN_ONCE()is just annoying.
It was a printk_once() when the tunable was scheduled to be removed two years later. Now that one year has passed since the oom killer rewrite has been merged, it was changed to a WARN_ONCE() simply to attract more attention to the issue. The plan was to remove the tunable completely a year from now as specified in Documentation/feature-removal-schedule.txt.
The intent here was to be more helpful than annoying or causing a problem with a log parser that doesn't understand the different between a warning and a panic or oops.
We could change it to a more obvious multi-line notification that an application is using a deprecated interface that wouldn't parse like the WARN_ONCE() output if you'd like. The single printk_once() obviously wasn't sufficient over the course of a year to get enough applications to change although things like udev, kde, and opensshd did. chromium actually noticed the new WARN_ON() behavior and is in the process of fixing it because of that.
Quoted 4 lines
It was a
printk_once()when the tunable was scheduled to be removed two years later. Now that one year has passed since the oom killer rewrite has been merged, it was changed to aWARN_ONCE()simply to attract more attention to the issue.
For the most part the only people whose attention you need are the distributions not the end users so the WARN isn't helpful.
Alan
Quoted 8 lines · Alan Cox
Quoted 4 lines
It was a
printk_once()when the tunable was scheduled to be removed two years later. Now that one year has passed since the oom killer rewrite has been merged, it was changed to aWARN_ONCE()simply to attract more attention to the issue.For the most part the only people whose attention you need are the distributions not the end users so the WARN isn't helpful.
That's obviously wrong since all of the applications that I've cited that have been fixed to date have been the result of users actually noticing the printk_once() and emailing me directly to pass it along to the appropriate parties. I've also found other cases where bugzilla entries were created based on that single line warning by users, who in turn get distros and maintainers to convert to the new interface.
It's quite effective, but there are still some applications that have yet to be reported, hence the reason for anybody actually hitting this new WARN_ONCE().
Quoted 6 lines
That's obviously wrong since all of the applications that I've cited that have been fixed to date have been the result of users actually noticing the
printk_once()and emailing me directly to pass it along to the appropriate parties. I've also found other cases where bugzilla entries were created based on that single line warning by users, who in turn get distros and maintainers to convert to the new interface.
And what did the users do - they complained to the distribution.
Quoted 3 lines
It's quite effective, but there are still some applications that have yet to be reported, hence the reason for anybody actually hitting this new
WARN_ONCE().
Perhaps the right way to do it would be to file the bugzillas in the key distros instead
Actually this raises a more interesting question - would it make sense to have a moderated notification list for poking all the distributions about things like old API expiry >
From: Alan Cox <[email protected]>
Date: Tue, 2 Aug 2011 11:11:17 +0100
Quoted 2 lines
Perhaps the right way to do it would be to file the bugzillas in the key distros instead
I completely disagree, there are lots of distributions and filing a bug with all of them is unreasonable. Some don't even have bug databases and are just a bunch of people maintaining a distribution for fun :-)
So even the most obscure distribution might want to notice this and fix it if it's users care about it enough to report it.
Quoted 8 lines
Quoted 6 lines
That's obviously wrong since all of the applications that I've cited that have been fixed to date have been the result of users actually noticing the
printk_once()and emailing me directly to pass it along to the appropriate parties. I've also found other cases where bugzilla entries were created based on that single line warning by users, who in turn get distros and maintainers to convert to the new interface.And what did the users do - they complained to the distribution.
I don't think that's how distributions work. Usually they won't fix an old udev, but just eventually update to a new udev version when they release a new version of themselves.
But the old release with the old udev will just stay around and people will continue to use it for many years.
And that's fine because nothing is fundamentally broken here that needs urgent fixing (except for that bogus backtrace of course)
The kernel has always done a great job in supporting old userland, this is just one of the rare exceptions.
Quoted 2 lines
Perhaps the right way to do it would be to file the bugzillas in the key distros instead
The right way is to add a one linker printk_once and then just wait for a few years.
Quoted 3 lines
Actually this raises a more interesting question - would it make sense to have a moderated notification list for poking all the distributions about things like old API expiry
And? Even if the distributions scramble to follow you -- which is unlikely for old versions -- their users won't do it.
-Andi
Quoted 3 lines · Andi Kleen
And that's fine because nothing is fundamentally broken here that needs urgent fixing (except for that bogus backtrace of course)
Maybe not urgent, but needs to be fixed within the next 12 months because all of the users of /proc/pid/oom_adj thus far have been to disable oom killing for the thread and that protection isn't guaranteed when the tunable is removed. Doing echo -17 > /proc/pid/oom_adj is a pretty good indicator that the process is important.
Quoted 3 lines
The right way is to add a one linker
printk_onceand then just wait for a few years.
This is what I did, except I waited one year instead of a few and now I wanted to add a more verbose warning for those that still haven't been fixed because we're one year away from the tunable's scheduled removal. If you're going to reply with a concern about the stack trace again, please see my patch I posted for Linus if the kernel log parsers are really that delicate.
Quoted 9 lines · Alan Cox
Quoted 6 lines
That's obviously wrong since all of the applications that I've cited that have been fixed to date have been the result of users actually noticing the
printk_once()and emailing me directly to pass it along to the appropriate parties. I've also found other cases where bugzilla entries were created based on that single line warning by users, who in turn get distros and maintainers to convert to the new interface.And what did the users do - they complained to the distribution.
All of the examples that I've cited that were fixed as a result of the printk_once() were through bugzilla for the developers of those applications, I didn't talk to any distro when I publically said I would handle all reports of this warning that people didn't know how to triage.
Quoted 4 lines
Actually this raises a more interesting question - would it make sense to have a moderated notification list for poking all the distributions about things like old API expiry >
I think that's the goal of [email protected] although it only has 113 subscribers, so it could probably play the role of a notification list as well as a place to report warnings for things such as deprecated interfaces. More communication other than just sometimes stale entries in Documentation/ABI and Documentation/feature-removal-schedule.txt would certainly be helpful.
Quoted 4 lines
All of the examples that I've cited that were fixed as a result of the
printk_once()were through bugzilla for the developers of those applications, I didn't talk to any distro when I publically said I would handle all reports of this warning that people didn't know how to triage.
The distros would have updated udev at some point anyways. But they won't do it for old releases.
But the users who don't want to update will just be annoyed (in Linus words) the backtrace forever.
The big problem I have with your "use kernel WARN_ONs to social engineer" approach is that the devalues a good mechanism to report kernel problems.
Traditionally at least I looked at all backtraces
and tried to get at the bottom of the problem to improve the kernel. I know from email that users reported those too.
Now that all my test systems spew them on every boot I cannot do that anymore. When I see a backtrace scrolling by I now just think "Ah it's probably David Rientjes trying to social engineer someone again".
And then some point noone will look at backtraces anymore because they have become normal. Really serious problems will get missed.
And this is a bad thing.
IMHO still the only sensible thing that can be done with this patch is to revert it.
-Andi
From: David Rientjes <[email protected]>
Date: Tue, 2 Aug 2011 02:53:34 -0700 (PDT)
Quoted 10 lines
That's obviously wrong since all of the applications that I've cited that have been fixed to date have been the result of users actually noticing the
printk_once()and emailing me directly to pass it along to the appropriate parties. I've also found other cases where bugzilla entries were created based on that single line warning by users, who in turn get distros and maintainers to convert to the new interface.It's quite effective, but there are still some applications that have yet to be reported, hence the reason for anybody actually hitting this new
WARN_ONCE().
I completely agree with you. Printing out some kind of warning does get the problems fixed.
Quoted 11 lines · Andi Kleen
Hi Linus,
Can you please revert
commit
be8f684d73d8d916847e996bf69cef14352872c6Author: David Rientjes <[email protected]> Date: Mon Jul 25 17:12:18 2011 -0700oom: make deprecated use of
oom_adjmore verbose
Quoted 9 lines
/proc/pid/oom_adjis deprecated and scheduled for removal in August 2012 according toDocumentation/feature-removal-schedule.txt.This makes most of my test systems (suse 11.1, 11.2) spew scary
WARN_ONson every boot. GNOME then also complains. While it doesn't cause actual misfunction it scares me every time I boot and other people who can't read git logs like me will be unnecessary scared.
If you look at the warning, you should be able to infer that an application is writing to /proc/pid/oom_adj when it should be using the new /proc/pid/oom_score_adj interface instead.
Quoted 3 lines
Also the warning is completely useless: noone will be "fixing" udev on old distributions.
udev was fixed for v162, but admittedly that won't help on old distributions. The WARN_ONCE() was intended to be in place for a year just like its previous form, printk_once(), and then the tunable will disappear and result in no error message.
Quoted 4 lines
IMHO that's not acceptable to break common user land like this. Linux is supposed to be binary compatible and this patch is not in this spirit.
Can you show additional breakage that still need to be fixed in userspace applications (we can't do anything about old distributions, it'll be a silent failure in a year's time)? udev was fixed for v162, kde was fixed for 4.6.1, chromium is in the process of being fixed as a result of this WARN_ON() (see http://code.google.com/p/chromium/issues/detail?id=65009),
and opensshd was fixed in 5.7p1. oom_adj isn't that common of an interface, so if there are others that are largely popular than please let me know and we'll get it fixed up.
So I'm certainly not changing an interface and leaving people to fix it up, I've been actively involved in doing so for the known userspace that does touch the tunable. I think it's better for users to be notified whether by "scary" warnings in the log (come on, we should be able to warn about deprecated interfaces in a log without mass failures) as some due diligence before removing the tunable. Most applications use it only to disable oom killing entirely, so a silent failure and allowing a vital task to be killed is the alternative to getting them fixed up.
Quoted 6 lines · David Rientjes
Quoted 4 lines
Also the warning is completely useless: noone will be "fixing" udev on old distributions.
udev was fixed for v162, but admittedly that won't help on old
Nobody wants to update udev if they can avoid it, especially not for such an extremly obscure reason.
Repeat after me: Linux is not supposed to break old user land.
And not breaking in this case includes not randomly spewing useless backtraces.
If you feel the need to social engineer the Chromium people, please do it by email, not by keeping other people's kernel logs hostage.
Quoted 3 lines
distributions. The
WARN_ONCE()was intended to be in place for a year just like its previous form,printk_once(), and then the tunable will disappear and result in no error message.
printk_once() is fine, but oopsy looking backtraces are not.
Quoted 8 lines
Quoted 4 lines
IMHO that's not acceptable to break common user land like this. Linux is supposed to be binary compatible and this patch is not in this spirit.
Can you show additional breakage that still need to be fixed in userspace applications (we can't do anything about old distributions, it'll be a silent failure in a year's time)?
Simply backtraces are not supposed to happen unless something is really broken. That's not the case here. The old distribution works perfectly fine and will continue to do so.
Quoted 2 lines
udev was fixed for v162, kde was fixed
for 4.6.1
... and users will continue to run old versions.
Quoted 5 lines
So I'm certainly not changing an interface and leaving people to fix it up, I've been actively involved in doing so for the known userspace that does touch the tunable. I think it's better for users to be notified whether by "scary" warnings in the log (come on, we should be able to warn about deprecated interfaces in a log without mass failures) as some
You can warn, but not using oopsy looking backtraces. That trigger all the bug reporting machinery. That is just annoying.
Quoted 1 line
diligence before removing the tunable.
It's not due diligence, it's total overkill for this.
I still think reverting this patch is the right thing to do.
Otherwise I have to do it in my local trees :-/ (it's certainly preferable than messing with udev)
-Andi
Signature · 1 line
[email protected] -- Speaking for myself only
PATCH 1/1 oom: change warning for deprecated oom_adj to avoid WARN_ONCE()
Quoted 4 lines · Andi Kleen
Simply backtraces are not supposed to happen unless something is really broken. That's not the case here. The old distribution works perfectly fine and will continue to do so.
It won't work perfectly fine in a year when the tunable is removed completely and the code that was writing OOM_DISABLE to /proc/pid/oom_adj just fails and the task that was supposed to be prevented from being killed at all costs may now be killed. The printk_once() over the past year didn't get that fixed up like the other applications I mentioned did, so we need to attract more attention.
Quoted 2 lines
I still think reverting this patch is the right thing to do.
Reverting the patch is ludicrous, otherwise there is little possibility that the remaining users of the deprecated interface will change if they haven't done so already. I'm perfectly happy with changing it to a different style of warning other than using WARN_ONCE() like I've already said. That doesn't require a revert.
I'm fine with this patch if Linus would like to apply it.
oom: change warning for deprecated oom_adj to avoid WARN_ONCE()
WARN_ONCE() emits a stack trace to the kernel log which leads userspace parsers to interpret it as being a serious error or malfunction within the kernel. Change the warning to appear more like a lockdep warning while still trying to preserve the intention of be8f684d73d8 (oom: make deprecated use of oom_adj more verbose) to attract more attention to the use of a deprecated interface.
--- fs/proc/base.c | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-)
fs/proc/base.c +10 -3
@@ -1066,6 +1066,7 @@ static ssize_t oom_adjust_write(struct file *file, const char __user *buf,char buffer[PROC_NUMBUF ];int oom_adjust;unsigned long flags; +static bool warning_printed;int err;memset (buffer,0 ,sizeof (buffer));
@@ -1118,9 +1119,15 @@ static ssize_t oom_adjust_write(struct file *file, const char __user *buf,* Warn that /proc/pid/oom_adj is deprecated, see * Documentation/feature-removal-schedule.txt. */ -WARN_ONCE (1 ,"%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , - current->comm,task_pid_nr (current),task_pid_nr (task), -task_pid_nr (task)); +if (!warning_printed) { + warning_printed = true; +printk ("\n===============================================================================\n" ); +printk ("%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , + current->comm,task_pid_nr (current),task_pid_nr (task), +task_pid_nr (task)); +printk ("===============================================================================\n\n" ); + } + task->signal->oom_adj = oom_adjust;/* * Scale /proc/pid/oom_score_adj appropriately ensuring that a maximum
Re: [patch] oom: change warning for deprecated oom_adj to avoid WARN_ONCE()
Quoted 56 lines · David Rientjes
Quoted 4 lines · Andi Kleen
Simply backtraces are not supposed to happen unless something is really broken. That's not the case here. The old distribution works perfectly fine and will continue to do so.
It won't work perfectly fine in a year when the tunable is removed completely and the code that was writing
OOM_DISABLEto/proc/pid/oom_adjjust fails and the task that was supposed to be prevented from being killed at all costs may now be killed. Theprintk_once()over the past year didn't get that fixed up like the other applications I mentioned did, so we need to attract more attention.Quoted 2 lines
I still think reverting this patch is the right thing to do.
Reverting the patch is ludicrous, otherwise there is little possibility that the remaining users of the deprecated interface will change if they haven't done so already. I'm perfectly happy with changing it to a different style of warning other than using
WARN_ONCE()like I've already said. That doesn't require a revert.I'm fine with this patch if Linus would like to apply it.
oom: change warning for deprecated
oom_adjto avoidWARN_ONCE()
WARN_ONCE()emits a stack trace to the kernel log which leads userspace parsers to interpret it as being a serious error or malfunction within the kernel. Change the warning to appear more like a lockdep warning while still trying to preserve the intention ofbe8f684d73d8(oom: make deprecated use ofoom_adjmore verbose) to attract more attention to the use of a deprecated interface.Reported-by Andi Kleen <[email protected]>Signed-off-by David Rientjes <[email protected]>--- fs/proc/base.c | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-)fs/proc/base.c +1
-0@@ -1066,6 +1066,7 @@ static ssize_t oom_adjust_write(struct file *file, const char __user *buf,char buffer[PROC_NUMBUF ];int oom_adjust;unsigned long flags; +static bool warning_printed;int err;memset (buffer,0 ,sizeof (buffer));@@ -1118,9 +1119,15 @@ static ssize_t oom_adjust_write(struct file *file, const char __user *buf,* Warn that /proc/pid/oom_adj is deprecated, see * Documentation/feature-removal-schedule.txt. */
fs/proc/base.c static ssize_t oom_adjust_write(struct file *file, const char __user *buf, · line 1128
Quoted 10 lines
fs/proc/base.c +7
-3-WARN_ONCE (1 ,"%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , - current->comm,task_pid_nr (current),task_pid_nr (task), -task_pid_nr (task)); +if (!warning_printed) { + warning_printed = true; +printk ("\n===============================================================================\n" ); +printk ("%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , + current->comm,task_pid_nr (current),task_pid_nr (task), +task_pid_nr (task)); +printk ("===============================================================================\n\n" );
You're missing the KERN_WARNING level. Why don't you use pr_warn_once + pr_cont_once? No need for the warning_printed too, it gets defined in another scope by the pr_warn_once macro automatically.
Signature · 2 lines
Regards/Gruss,
Boris.Re: [patch] oom: change warning for deprecated oom_adj to avoid WARN_ONCE()
Quoted 34 lines · Borislav Petkov
Quoted 34 lines
oom: change warning for deprecated
oom_adjto avoidWARN_ONCE()
WARN_ONCE()emits a stack trace to the kernel log which leads userspace parsers to interpret it as being a serious error or malfunction within the kernel. Change the warning to appear more like a lockdep warning while still trying to preserve the intention ofbe8f684d73d8(oom: make deprecated use ofoom_adjmore verbose) to attract more attention to the use of a deprecated interface.Reported-by Andi Kleen <[email protected]>Signed-off-by David Rientjes <[email protected]>--- fs/proc/base.c | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-)fs/proc/base.c +2
-3@@ -1066,6 +1066,7 @@ static ssize_t oom_adjust_write(struct file *file, const char __user *buf,char buffer[PROC_NUMBUF ];int oom_adjust;unsigned long flags; +static bool warning_printed;int err;memset (buffer,0 ,sizeof (buffer));@@ -1118,9 +1119,15 @@ static ssize_t oom_adjust_write(struct file *file, const char __user *buf,* Warn that /proc/pid/oom_adj is deprecated, see * Documentation/feature-removal-schedule.txt. */ -WARN_ONCE (1 ,"%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , - current->comm,task_pid_nr (current),task_pid_nr (task), -task_pid_nr (task)); +if (!warning_printed) {
Quoted 8 lines
fs/proc/base.c static ssize_t oom_adjust_write(struct file *file, const char __user *buf, · line 1128
Quoted 6 lines
fs/proc/base.c +6
-0+ warning_printed = true; +printk ("\n===============================================================================\n" ); +printk ("%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , + current->comm,task_pid_nr (current),task_pid_nr (task), +task_pid_nr (task)); +printk ("===============================================================================\n\n" );You're missing the
KERN_WARNINGlevel.
It's intentional because (i) I'm using a multi-line notification with newlines and (ii) I don't want to be considered as a kernel warning. It's just for consumption by userspace and doesn't indicate a kernel issue.
Quoted 4 lines
Why don't you use
pr_warn_once+pr_cont_once? No need for thewarning_printedtoo, it gets defined in another scope by thepr_warn_oncemacro automatically.
Because using pr_warn_once + pr_cont_once for a multi-line notification is racy and I don't want three separated static variables? pr_cont_once() shouldn't be used unless synchronized.
Re: [patch] oom: change warning for deprecated oom_adj to avoid WARN_ONCE()
Quoted 13 lines · David Rientjes
Quoted 4 lines
Quoted 4 lines
fs/proc/base.c +1
-3-WARN_ONCE (1 ,"%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , - current->comm,task_pid_nr (current),task_pid_nr (task), -task_pid_nr (task)); +if (!warning_printed) {Quoted 8 lines
fs/proc/base.c static ssize_t oom_adjust_write(struct file *file, const char __user *buf, · line 1128
Quoted 6 lines
fs/proc/base.c +6
-0+ warning_printed = true; +printk ("\n===============================================================================\n" ); +printk ("%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n" , + current->comm,task_pid_nr (current),task_pid_nr (task), +task_pid_nr (task)); +printk ("===============================================================================\n\n" );You're missing the
KERN_WARNINGlevel.
Quoted 3 lines
It's intentional because (i) I'm using a multi-line notification with newlines and (ii) I don't want to be considered as a kernel warning. It's just for consumption by userspace and doesn't indicate a kernel issue.
I see.
Quoted 8 lines
Quoted 4 lines
Why don't you use
pr_warn_once+pr_cont_once? No need for thewarning_printedtoo, it gets defined in another scope by thepr_warn_oncemacro automatically.Because using
pr_warn_once+pr_cont_oncefor a multi-line notification is racy and I don't want three separated static variables?pr_cont_once()shouldn't be used unless synchronized.
Or maybe do:
pr_info_once("\n===============================================================================\n"
"%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.\n"
"===============================================================================\n\n",
current->comm, task_pid_nr(current), task_pid_nr(task), task_pid_nr(task));so as to not be a warning and still hide the warning_printed thing. You could even save yourself the last repeated argument by enumerating the format specifiers:
pr_info_once("\n===============================================================================\n"
"%1$s (%2$d): /proc/%3$d/oom_adj is deprecated, please use /proc/%3$d/oom_score_adj instead.\n"
"===============================================================================\n\n",
current->comm, task_pid_nr(current), task_pid_nr(task));It seems to build fine here.
Oh well. :-)
Signature · 2 lines
Regards/Gruss,
Boris.