Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp983364ybl; Fri, 9 Aug 2019 17:46:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqwJQetSOzO663oiy4eyxOYd/oNa9Z/BipQ1Mtgxn/oZ/6lV21wGX3CjbXbVUxP+GdcOjeub X-Received: by 2002:a65:4044:: with SMTP id h4mr19918783pgp.164.1565397988451; Fri, 09 Aug 2019 17:46:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565397988; cv=none; d=google.com; s=arc-20160816; b=ohxwt4hb1rjPZOjzcjdicjU9PIX9eBgWXeaa0gjNKMLzdQdTVBZSfFM0Nx6ZYkoGkS 4kXheEz81CH2n/gnrUP2bJVC7KQqvQ2bRTQVSlVyxl/OwkIG5gaR0DKzQdKpjPscLoY3 t7C7QjxHYd7hpWVGXqX8vr62a78Bqi4eYTuD1xqISrTEmYVWzR0CU/AL12aTxf4dMA3I BAe4UUCfoec8uVDCi/8qGH0lDktTUkY8knPBy43WbzkiFmfR7i7N/+Lt4QtQqR4nYDIY t1BVk3oyY5RN/WwyoN6RQBOU8w9nrtFrh0WlBXPGmfJVR0PswTY/jz8QSq+hgcOy/4w6 JEkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=CBUazHhddmZsxB0Hoiw4zvE6oiR+uVF7ClLhkcMSvXE=; b=08ibO6iTvNESE8XM4fu+axLovxQiwELysXaGeyXKl+o7yl2naONLpFPaeQ2rRZUi11 QwW2xVoDlQ4gpczEq5lJ4nC9mDK6P1p8ctfs5RZphUH7UGkrx6Y0IehQuLw3WzYQTvCZ 49t1vtLvR2SGcZAOrc8DXS+EtGqNiHye9TCqE+R4TKYYkMMgStlmfN3l5jrCCWxxH2Vu qvcMHris0oLO9tW3vFyjir2WCLk5T/X2uWMAFTb0vLaSwlp+qQoJBHsVh9i0oB3/WcZ4 MTeqZ/v2J+ueFU3paS9Uc2ecZ1vPP5IvwOnTPLKC96vEoRRxlPOwGJ80wGrMO4sjvxm3 5Fzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o9+sM2gW; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q10si51097062pls.42.2019.08.09.17.45.57; Fri, 09 Aug 2019 17:46:28 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o9+sM2gW; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726865AbfHJApC (ORCPT + 99 others); Fri, 9 Aug 2019 20:45:02 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:43025 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726263AbfHJApC (ORCPT ); Fri, 9 Aug 2019 20:45:02 -0400 Received: by mail-ed1-f65.google.com with SMTP id e3so96874440edr.10 for ; Fri, 09 Aug 2019 17:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CBUazHhddmZsxB0Hoiw4zvE6oiR+uVF7ClLhkcMSvXE=; b=o9+sM2gWtH4nJNfa/ID1tZFd5YZrs+EQ2XTzzc8MRVuVVTA5BwAGFAlnpd5iZ8kUuY JFIOeVjTsxEDmWNk1ERHIkLM/axY1dpLapJEOzNmRgXTAGACf3SsCI80WvZc0gOd9L2y Qj+VO3ouupoO4iMEo2OJll/NQGly6ipuRh8ZC1kuBniID9Lx/WsK18+Vytqlskug7+xg teu1x5AG7k/kuPR1d6mzzEuc/jvvVxJvo4iCHfrP1yM++mAx6jFoQtW+Ychtq3IMvA6n Qk+TtA7XOZqiZE7xt3miSyeyC4Hi2Zob6bbWIjGp0PHxO4+Wx+GnO0VDeFxDUWxn89nm nhmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=CBUazHhddmZsxB0Hoiw4zvE6oiR+uVF7ClLhkcMSvXE=; b=aw1t9GN/JNjkcYm1pMq44jyyledtsUIzSvQp3NeHUz+F1tZzOWmjuCxLMy1LFi3YCM 1P7gYUk7G92ylweRAJbAZ8AgTnz0lbrSMxWjmMIO77saMsc7awsiUl72PF7gHPcGeeW9 8Dj4TOXH9o/psTNwGfkqdPMy20EtQ0fcR8ARsQoEPHhNkSG9ZewKAHi83F3ogVM4UyaX Mlc38/2qoSP4bgE8JG4ne+xtGuwRcoQxhf8jGBOtVnlwjNQVUppiGQaHTExtVHKUnalY w/AReRUr2vsGN+Zq+26zy7JQzbh5YKYkgy4cyU2t5LeNqYht8zxy+i+9mJ/P6eMmlEPV TFoA== X-Gm-Message-State: APjAAAXeN/rw3NYUJNOKinVP8kqmrJA8nCPCCjfaG8TWXXqXAxkY2wdC 9RFrwdtEn9BBbHSjfJSDQNA= X-Received: by 2002:a17:906:2401:: with SMTP id z1mr20929355eja.292.1565397900414; Fri, 09 Aug 2019 17:45:00 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id u9sm22940007edm.71.2019.08.09.17.44.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Aug 2019 17:44:59 -0700 (PDT) Date: Sat, 10 Aug 2019 00:44:58 +0000 From: Wei Yang To: Linus Torvalds Cc: Wei Yang , "Schmid, Carsten" , "bp@suse.de" , "dan.j.williams@intel.com" , "mingo@kernel.org" , "dave.hansen@linux.intel.com" , "linux-kernel@vger.kernel.org" , "bhelgaas@google.com" , "osalvador@suse.de" , "rdunlap@infradead.org" , "richardw.yang@linux.intel.com" , "gregkh@linuxfoundation.org" Subject: Re: Resend [PATCH] kernel/resource.c: invalidate parent when freed resource has childs Message-ID: <20190810004458.mio4vp3nk6jl2hyh@master> Reply-To: Wei Yang References: <1565278859475.1962@mentor.com> <1565358624103.3694@mentor.com> <20190809223831.fk4uyrzscr366syr@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 09, 2019 at 03:45:59PM -0700, Linus Torvalds wrote: >On Fri, Aug 9, 2019 at 3:38 PM Wei Yang wrote: >> >> In theory, child may have siblings. Would it be possible to have several >> devices under xhci-hcd? > >I'm less interested in the xhci-hcd case - which I certainly *hope* is >fixed already? - than in "if this happens somewhere else". > Agree, this is what I want to say. >So if we do want to remove the parent (which may be a good idea with a >warning), and want to make sure that the children are really removed >from the resource hierarchy, we should do somethiing like > > static bool detach_children(struct resource *res) > { > res = res->child; > if (!res) > return false; > do { > res->parent = NULL; > res = res->sibling; > } while (res); > return true; > } > >and then we could write the __release_region() warning as > > /* You should not release a resource that has children */ > WARN_ON_ONCE(detach_children(res)); > I am thinking about why this could happen. To guard the core kernel code, it looks reasonable. >or something? > >NOTE! The above is entirely untested, and written purely in my mail >reader. It might be seriously buggy, including not compiling, or doing >odd things. See it more as a "maybe something like this" code snippet >example than any kind of final form. > > Linus -- Wei Yang Help you, Help me