linux-kernel - Re: [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time

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: <20160822120937.GK13596@dhcp22.suse.cz>
Date:   Mon, 22 Aug 2016 14:09:37 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Joe Perches <joe@...ches.com>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jann Horn <jann@...jh.net>, linux-mm@...ck.org
Subject: Re: [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time

On Mon 22-08-16 01:30:14, Joe Perches wrote:
> On Mon, 2016-08-22 at 01:00 -0700, Joe Perches wrote:
> > On Mon, 2016-08-22 at 09:24 +0200, Michal Hocko wrote:
> > > On Sat 20-08-16 01:00:17, Joe Perches wrote:
> []
> > > > static int proc_maps_open(struct inode *inode, struct file *file,
> > > >  			const struct seq_operations *ops, int psize)
> > > >  {
> > > > -	struct proc_maps_private *priv = __seq_open_private(file, ops, psize);
> > > > +	struct proc_maps_private *priv;
> > > > +	struct mm_struct *mm;
> > > > +
> > > > +	mm = proc_mem_open(inode, PTRACE_MODE_READ);
> > > > +	if (IS_ERR(mm))
> > > > +		return PTR_ERR(mm);
> > > >  
> > > > +	priv = __seq_open_private_bufsize(file, ops, psize,
> > > > +					  mm && mm->map_count ?
> > > > +					  mm->map_count * 0x300 : PAGE_SIZE);
> > > NAK to this!
> > > 
> > > Seriously, this just gives any random user access to user
> > > defined amount of memory which not accounted, not reclaimable and a
> > > potential consumer of any higher order blocks.
> > I completely disagree here with your rationale here.
> 
> And with further review and your comment above, I withdraw this patch.

So you've made me look into that code. I can imagine how it is easy to
to get confused here. The important part is that m->count is reset after
each ->show(). So traverse() same as seq_read only grows the buffer if
a single show doesn't fit in.

That being said, should I repost my rebased patches or do you plan to
repost your patch? I do not want spam people with another version if
you do not like it.
-- 
Michal Hocko
SUSE Labs