From patchwork Tue Oct 24 00:29:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 10023385 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D623960245 for ; Tue, 24 Oct 2017 00:29:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C739D2891E for ; Tue, 24 Oct 2017 00:29:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BC07728931; Tue, 24 Oct 2017 00:29:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_TVD_MIME_EPI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1E9F32891E for ; Tue, 24 Oct 2017 00:29:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751123AbdJXA36 (ORCPT ); Mon, 23 Oct 2017 20:29:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:48217 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbdJXA35 (ORCPT ); Mon, 23 Oct 2017 20:29:57 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 684C5AEB0; Tue, 24 Oct 2017 00:29:56 +0000 (UTC) From: NeilBrown To: Trond Myklebust , Anna Schumaker Date: Tue, 24 Oct 2017 11:29:46 +1100 Cc: Linux NFS Mailing List Subject: [PATCH] sunrpc: use supplimental groups in auth hash. Message-ID: <87h8upe6bp.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some sites vary some supplimental groups a lot. To avoid unduely long hash chains, include all of these in the hash calculation. Signed-off-by: NeilBrown --- Hi, I have a customer who had thousands of auth entries with the same uid and gid, so the hashtable was unbalanced and some lookups were noticeably slow. This fix helped. Relatedly, I wonder if we should set a default auth_max_cred_cachesize, and nfs_access_max_cachesize - smaller than ULONG_MAX. For auth_max_cred_cachesize, a default of e.g. 256*(1<gid) | - ((u64)from_kuid(&init_user_ns, acred->uid) << - (sizeof(gid_t) * 8)), hashbits); + int ret = hash_32(from_kuid(&init_user_ns, acred->uid), 32); + + if (acred->group_info) { + int g; + + for (g = 0; g < acred->group_info->ngroups; g++) + ret = hash_32(ret ^ + from_kgid(&init_user_ns, + acred->group_info->gid[g]), + 32); + } + return hash_32(ret ^ from_kgid(&init_user_ns, acred->gid), hashbits); } /* diff --git a/net/sunrpc/auth_unix.c b/net/sunrpc/auth_unix.c index 82337e1ec9cd..20cd4ab3b339 100644 --- a/net/sunrpc/auth_unix.c +++ b/net/sunrpc/auth_unix.c @@ -47,9 +47,15 @@ unx_destroy(struct rpc_auth *auth) static int unx_hash_cred(struct auth_cred *acred, unsigned int hashbits) { - return hash_64(from_kgid(&init_user_ns, acred->gid) | - ((u64)from_kuid(&init_user_ns, acred->uid) << - (sizeof(gid_t) * 8)), hashbits); + int ret = hash_32(from_kuid(&init_user_ns, acred->uid), 32); + if (acred->group_info) { + int g; + + for (g = 0; g < acred->group_info->ngroups && g < UNX_NGROUPS; g++) + ret = hash_32(ret ^ from_kgid(&init_user_ns, + acred->group_info->gid[g]), 32); + } + return hash_32(ret ^ from_kgid(&init_user_ns, acred->gid), hashbits); } /*