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: <20130423131558.GH8001@dhcp22.suse.cz>
Date:	Tue, 23 Apr 2013 15:15:58 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	linux-kernel@...r.kernel.org, rientjes@...gle.com
Subject: Re: OOM-killer and strange RSS value in 3.9-rc7

On Tue 23-04-13 12:22:34, Han Pingtian wrote:
> On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
> > >  CONFIG_PPC_BOOK3S_64=y
> > >  # CONFIG_PPC_BOOK3E_64 is not set
> > > -CONFIG_GENERIC_CPU=y
> > > +# CONFIG_GENERIC_CPU is not set
> > >  # CONFIG_CELL_CPU is not set
> > >  # CONFIG_POWER4_CPU is not set
> > >  # CONFIG_POWER5_CPU is not set
> > >  # CONFIG_POWER6_CPU is not set
> > > -# CONFIG_POWER7_CPU is not set
> > > +CONFIG_POWER7_CPU=y
> > 
> > Wow, so the two configs are for different architectures? Not very much
> > helpful. Could you stick with a single machine and do just small updates
> > to the config to the point where the problem is no longer present,
> > please?
> > 
> No, both configs are for power system. I changed it to
> 'CONFIG_POWER7_CPU' by myself in the good one. I think this difference
> doesn't matter here. 

Ohh, good, I thought it was a x86 thingy. Sorry about the confusion. No
other arch does that...

> > [...]
> > > -CONFIG_SLUB_DEBUG=y
> > > -# CONFIG_COMPAT_BRK is not set
> > > -# CONFIG_SLAB is not set
> > > -CONFIG_SLUB=y
> > > +CONFIG_COMPAT_BRK=y
> > > +CONFIG_SLAB=y
> > 
> > I would start with the bad config and SLUB changed to SLAB in the first
> > step, though.
> > 
> Yep, after I changed bad config to use SLAB, the problem disppears after
> using the new kernel. Looks like something wrong in SLUB?

It seems so or maybe there is a different issue which is just made
visible by SLUB or it is an arch specific problem.
What is the workload that triggers this behavior? Can you reduce it to a
minimum test case?

I guess that you are still testing with vanilla 3.9-rc? kernel without
any additional patches or 3rd party modules, right?

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ