Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp1547131imm; Fri, 6 Jul 2018 02:02:11 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcHsLVdti99AArNpHnQP0kR2iXPYub4GjSFuLhz5Z4EbHzVP0vkp0pTcp3iMtqLzkpmftvt X-Received: by 2002:a63:1e08:: with SMTP id e8-v6mr2764916pge.281.1530867731106; Fri, 06 Jul 2018 02:02:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530867731; cv=none; d=google.com; s=arc-20160816; b=TPsrLKezEE9jMHZ9cUxCGc0KJmq8At5J3dLUobhnSrXfVkoaQ4k3WktJDLIb/4A6Iw yrTtNCR+G9fBo5bAihxZqP9x8BeNK4Fz9JLu1XB33A3zNJvU1CcxE+HwF0sFkQt9uxWy 6h2hsnv57GXOWp6GT8j+uDtMQdvgaN1U3Fq1izLsXxMJXLipIyBT+ca02fm0546iOIhw n3PGpNt7MQgkadoeBZvIWkNe2VkOKaNTmfRZvwIaA35c1L+R30bav3Bq0RWgut6xekvz J4W4mZk/bHyq1BfjOWHnFJP0J58YuR2ELp0KUSpVrylVlOeAHuXUiM9+hR2cUKp10HS1 rTZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=lyQMxfnrcbPqSJ+m0XEfESTgNHTZgFJtkZ3CxVu+J90=; b=T3kXumv0v2CoEHZT7xvK8u4NgZ7B/bxOz2j9WtlSU4XJuC+9iuSn85mCpDVLgf8W1m UvltTrG1XoSEnF4/aYfvGrmLRMZw7oASHwkq2pUC3ySWeJABRYUvPTynSg8iSPQbA3Jm N/LG1ygEt0CuliVSfaW10IpQITrVA5r/1RPX26KlX6iZ7F0tF6RiEBYVOk8pxQ5wGFvf SaxcljCaFeFFjiiC/ebHtn1AUDg90leHeII/GCrnAClSfy9/01DiMFIBbzS88lKdFV2X 2tDImVis08jMNnam9NB21Gddsr7CzH1eKVStP7y88Su19W4Xy3+LTEkx9RsNKmExDgqE yK5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h1-v6si7797433pfn.285.2018.07.06.02.01.55; Fri, 06 Jul 2018 02:02:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753915AbeGFI7n (ORCPT + 99 others); Fri, 6 Jul 2018 04:59:43 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48248 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753535AbeGFI7f (ORCPT ); Fri, 6 Jul 2018 04:59:35 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F256D81A4EA9; Fri, 6 Jul 2018 08:59:34 +0000 (UTC) Received: from localhost.localdomain (unknown [10.32.181.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id A4A067C44; Fri, 6 Jul 2018 08:59:33 +0000 (UTC) Message-ID: <0a44916eacea6c3899152a07321ff69d96ed8c52.camel@redhat.com> Subject: Re: [PATCH 1/3] rhashtable: further improve stability of rhashtable_walk From: Paolo Abeni To: NeilBrown , Thomas Graf , Herbert Xu , Tom Herbert Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 06 Jul 2018 10:59:32 +0200 In-Reply-To: <153086109256.2825.15329014177598382684.stgit@noble> References: <153086101070.2825.6850140624411927465.stgit@noble> <153086109256.2825.15329014177598382684.stgit@noble> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 06 Jul 2018 08:59:35 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 06 Jul 2018 08:59:35 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pabeni@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-07-06 at 17:11 +1000, NeilBrown wrote: > If the sequence: > obj = rhashtable_walk_next(iter); > rhashtable_walk_stop(iter); > rhashtable_remove_fast(ht, &obj->head, params); > rhashtable_walk_start(iter); > > races with another thread inserting or removing > an object on the same hash chain, a subsequent > rhashtable_walk_next() is not guaranteed to get the "next" > object. It is possible that an object could be > repeated, or missed. The above scenario is very similar to the one I'm running: rhashtable_walk_next(iter); rhashtable_walk_stop(iter); // rhashtable change not yet identified, could be either // remove, insert or even rehash rhashtable_walk_start(iter); rhashtable_walk_next(iter); but I'm seeing use-after-free there. I'll try this patch to see if solves my issue. Note: the code under test is a pending new patch I'm holding due to the above issue, I can send it as RFC to share the code if you think it may help. > @@ -867,15 +866,39 @@ void *rhashtable_walk_next(struct rhashtable_iter *iter) > bool rhlist = ht->rhlist; > > if (p) { > - if (!rhlist || !(list = rcu_dereference(list->next))) { > - p = rcu_dereference(p->next); > - list = container_of(p, struct rhlist_head, rhead); > - } > - if (!rht_is_a_nulls(p)) { > - iter->skip++; > - iter->p = p; > - iter->list = list; > - return rht_obj(ht, rhlist ? &list->rhead : p); > + if (!rhlist && iter->p_is_unsafe) { > + /* > + * First time next() was called after start(). > + * Need to find location of 'p' in the list. > + */ > + struct rhash_head *p; > + > + iter->skip = 0; > + rht_for_each_rcu(p, iter->walker.tbl, iter->slot) { > + iter->skip++; > + if (p <= iter->p) > + continue; Out of sheer ignorance, I really don't understand the goal of the above conditional ?!? Should it possibly be something like: if (p != iter->p->next) instead? But I think we can't safely dereference 'p' yet ?!? I'm sorry for the possibly dumb comments, rhashtable internals are somewhat obscure to me, but I'm really interested in this topic. Cheers, Paolo