linux-kernel - RE: VM issue causing high CPU loads

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: <7A24DF798E223B4C9864E8F92E8C93EC03F0AFB3@SACMVEXC1-PRD.hq.netapp.com>
Date:	Thu, 3 Sep 2009 14:21:18 -0700
From:	"Muntz, Daniel" <Dan.Muntz@...app.com>
To:	"Simon Kirby" <sim@...tway.ca>,
	"Trond Myklebust" <trond.myklebust@....uio.no>
Cc:	"Yohan" <ytordjman@...p.free.fr>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <linux-nfs@...r.kernel.org>,
	"Neil Brown" <neilb@...e.de>,
	"J. Bruce Fields" <bfields@...ldses.org>, <mikevs@...all.net>
Subject: RE: VM issue causing high CPU loads

Amen.  I understand that v4 wants to extend across domains, etc., but it
goes out of its way to prevent the use of uids/gids, which in the vast
majority of installations would work just fine and wouldn't incur the
overhead of the mapping/unmapping operations.  There's no reason
uids/gids couldn't coexist with string names.  If the 4.0 spec had a
slightly different version of this paragraph:

   To provide a greater degree of compatibility with previous versions
   of NFS (i.e., v2 and v3), which identified users and groups by 32-bit
   unsigned uid's and gid's, owner and group strings that consist of
   decimal numeric values with no leading zeros can be given a special
   interpretation by clients and servers which choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by a v2/v3 uid or
   gid having the corresponding numeric value.  A server is not
   obligated to accept such a string, but may return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all of the owners and
   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that case, the client must use the
   appropriate name@...ain string and not the special form for
   compatibility.

i.e., take out the "subvert" portion, and just plain allow string
representations of uids/gids, then at least the conversion would just be
an atoi and itoa.  Even better, allow the uids/gids to be used directly
and avoid the atoi/itoa, perhaps with a flag.  Either case is better
than idmapd and getting EDELAY and an X-second pause in odd places
because NFS has to go to userspace for a translation.

  -Dan Quixote

> -----Original Message-----
> From: Simon Kirby [mailto:sim@...tway.ca] 
> Sent: Thursday, September 03, 2009 1:06 PM
> To: Trond Myklebust
> Cc: Yohan; Andrew Morton; linux-kernel@...r.kernel.org; 
> linux-nfs@...r.kernel.org; Neil Brown; J. Bruce Fields; 
> mikevs@...all.net
> Subject: Re: VM issue causing high CPU loads
> 
> On Thu, Sep 03, 2009 at 10:02:06AM -0400, Trond Myklebust wrote:
> 
> > OK, so 16 hash buckets are likely to be filled with ~10^6 
> entries each.
> > I can see that might be a performance issue...
> 
> We have a similar setup with millions of UIDs over NFS 
> (currently NFSv3).
> I _wish_ there were a way to use NFSv4 without having to use 
> name-mapped UIDs and GIDs, since our user and group names 
> come from MySQL anyway, and are guaranteed to be consistent 
> across machines.
> 
> Why on earth does NFSv4 force the use of names?
> 
> I was considering hacking the code to stick IDs in there 
> anyway, but I haven't looked at the feasibility of this.  I 
> suspect this would break or complicate other things, but the 
> current NFSv4 design just seems like an incredible waste for 
> this case.
> 
> Simon-
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-nfs" in the body of a message to 
> majordomo@...r.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 
--
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/