linux-kernel - Re: [PATCH 3/3] 9p: Add mempools for RPCs

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]

Date:   Mon, 04 Jul 2022 13:12:51 +0200
From:   Christian Schoenebeck <linux_oss@...debyte.com>
To:     Kent Overstreet <kent.overstreet@...il.com>,
        Dominique Martinet <asmadeus@...ewreck.org>
Cc:     linux-kernel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net,
        Eric Van Hensbergen <ericvh@...il.com>,
        Latchesar Ionkov <lucho@...kov.net>
Subject: Re: [PATCH 3/3] 9p: Add mempools for RPCs

On Montag, 4. Juli 2022 05:38:46 CEST Dominique Martinet wrote:
> +Christian, sorry I just noticed you weren't in Ccs again --
> the patches are currently there if you want a look:
> https://evilpiepirate.org/git/bcachefs.git/log/?h=9p_mempool

I wonder whether it would make sense to update 9p section in MAINTAINERS to 
better reflect current reality, at least in a way such that contributors would 
CC me right away?

Eric, Latchesar, what do you think?

> > @@ -270,10 +276,8 @@ p9_tag_alloc(struct p9_client *c, int8_t type,
> > unsigned int max_size)> 
> >  	if (!req)
> >  	
> >  		return ERR_PTR(-ENOMEM);
> > 
> > -	if (p9_fcall_init(c, &req->tc, alloc_msize))
> > -		goto free_req;
> > -	if (p9_fcall_init(c, &req->rc, alloc_msize))
> > -		goto free;
> > +	p9_fcall_init(c, &req->tc, 0, alloc_msize);
> > +	p9_fcall_init(c, &req->rc, 1, alloc_msize);
> 
> mempool allocation never fails, correct?
> 
> (don't think this needs a comment, just making sure here)
> 
> This all looks good to me, will queue it up in my -next branch after
> running some tests next weekend and hopefully submit when 5.20 opens
> with the code making smaller allocs more common.

Hoo, Dominique, please hold your horses. I currently can't keep up with 
reviewing and testing all pending 9p patches right now.

Personally I would hold these patches back for now. They would make sense on 
current situation on master, because ATM basically all 9p requests simply 
allocate exactly 'msize' for any 9p request.

However that's exactly what I was going to address with my already posted 
patches (relevant patches regarding this issue here being 9..12):
https://lore.kernel.org/all/cover.1640870037.git.linux_oss@crudebyte.com/
And in the cover letter (section "STILL TODO" ... "3.") I was suggesting to 
subsequently subdivide kmem_cache_alloc() into e.g. 4 allocation size 
categories? Because that's what my already posted patches do anyway.

How about I address the already discussed issues and post a v5 of those 
patches this week and then we can continue from there?

Best regards,
Christian Schoenebeck