linux-kernel - Re: [PATCH resend] drop_caches: add some documentation and info message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130805072013.GA10146@dhcp22.suse.cz>
Date:	Mon, 5 Aug 2013 09:20:13 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>, dave.hansen@...el.com,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, bp@...e.de,
	Dave Hansen <dave@...ux.vnet.ibm.com>
Subject: Re: [PATCH resend] drop_caches: add some documentation and info
 message

On Sun 04-08-13 21:13:44, KOSAKI Motohiro wrote:
> On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko <mhocko@...e.cz> wrote:
> > On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
> >> >>> You missed the "!".  I'm proposing that setting the new bit 2 will
> >> >>> permit people to prevent the new printk if it is causing them problems.
> >> >>
> >> >> No I don't. I'm sure almost all abuse users think our usage is correct. Then,
> >> >> I can imagine all crazy applications start to use this flag eventually.
> >> >
> >> > I guess we do not care about those. If somebody wants to shoot his feet
> >> > then we cannot do much about it. The primary motivation was to find out
> >> > those that think this is right and they are willing to change the setup
> >> > once they know this is not the right way to do things.
> >> >
> >> > I think that giving a way to suppress the warning is a good step. Log
> >> > level might be to coarse and sysctl would be an overkill.
> >>
> >> When Dave Hansen reported this issue originally, he explained a lot of userland
> >> developer misuse /proc/drop_caches because they don't understand what
> >> drop_caches do.
> >> So, if they never understand the fact, why can we trust them? I have no
> >> idea.
> >
> > Well, most of that usage I have come across was legacy scripts which
> > happened to work at a certain point in time because we sucked.
> > Thinks have changed but such scripts happen to survive a long time.
> > We are primarily interested in those.
> 
> Well, if the main target is shell script, task_comm and pid don't help us
> a lot. I suggest to add ppid too.

I do not have any objections to add ppid.
 
> >> Or, if you have different motivation w/ Dave, please let me know it.
> >
> > We have seen reports where users complained about performance drop down
> > when in fact the real culprit turned out to be such a clever script
> > which dropped caches on the background thinking it will help to free
> > some memory. Such cases are tedious to reveal.
> 
> Imagine such script have bit-2 and no logging output. Because
> the script author think "we are doing the right thing".
> Why distro guys want such suppress messages?

I am not really pushing this suppressing functionality. I just
understand that there might be some legitimate use for supressing and if
that is a must for merging the printk, I can live with that.
 
[...]
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/