Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3029349ybt; Mon, 29 Jun 2020 13:20:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjDc+u0wZi3lGUG107CFxorpqNTvIgF5LNwvQhaz84jlLHoc6cImsrLgIQlv8uzAlxwVxq X-Received: by 2002:a50:8143:: with SMTP id 61mr19749480edc.202.1593462013449; Mon, 29 Jun 2020 13:20:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593462013; cv=none; d=google.com; s=arc-20160816; b=xvermqu8rMyxe3qc2swXw2sM7F2cwL1HyHkn+kH4+JDRE+/PG2hmV1ci8H1XOCflgn HAGjBPlAvnM1EXuEpkVZDpPyxgwo5xwmQSaDA/AYFRqEL3RyDtFnwN/9A71rBcrrIHCa lzuQz4I5n4335FLUr8cP1CAowD6dphP8PqiBBCU+zo07NYb4Q4Un4SSYg6SQ/GHOuw3j c7gYyxMhzupQLQaxqzL5VRPxJjQtlxDUErooCX/PsO0hZVZPkqhztKAHldyzVvzU8y9S KlB0DncbgYcVGRE8XgNFzP1eAY8c8GkgUsvpH0khVTqmzG119HRJu2RfgT2f65GNtN3h gDOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=LgZ6Y/LAZdlanutBkLGPQSkOKvJYyE7hUG22lbkDZM8=; b=Z2PlnpmON7SpnrUbJQUGuW0qoz2t9NjHxSzogueweMmur5IOkC9COBpI7g0YvT3dzp nsFuMm7J0egqUCGJgh4BrYymCHy8y5KXG92xdZiDXm0it1fp9COkd9QWiAH1q5tFcIST KoB8oKxpbzJWm4wSVqhRT6fPznx1+nTAmcQklq8gQSIi9+SzvEgF8dc1DqdnyhMp+uYr JQgl+REteoXYMSB/d9Obd5OnZbC6CpsxQnFYHQy9nzTu+E/rxgMQ1ouyEv4aH8azKPG6 +T0nv9fOEA7bojSuoo7lAx+QjRCxwukIkuJ7tgkcr4X3VubFX0RfYKXjPhwFcxzQHZ/2 3FIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=f9oWsTBo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si383632eja.81.2020.06.29.13.19.50; Mon, 29 Jun 2020 13:20:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=f9oWsTBo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730933AbgF2USP (ORCPT + 99 others); Mon, 29 Jun 2020 16:18:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:37018 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732627AbgF2TZl (ORCPT ); Mon, 29 Jun 2020 15:25:41 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A05DE2558A; Mon, 29 Jun 2020 16:15:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593447352; bh=klIL3IOn+Sds26IUTL2F8EnYRJUx3am2hJ0RrpMsz0g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f9oWsTBo0LTbV90r28cXpkf0rG6Cx+kBwQhW0WyK5V7LJACKMYaXrNxLEsrfrbqfN rttFp9EJzONsmvLLNJPGF4asPeiYLbxGyVKv3fe0PPtvUJH+5AuMaTzimvfWrLwNTa tlcJPsSbq9Ck5M+B1LWGLoCgQEUCKcFTg/VPSd+c= Date: Mon, 29 Jun 2020 18:15:42 +0200 From: Greg KH To: SeongJae Park Cc: sashal@kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Upstream fixes not merged in 5.4.y Message-ID: <20200629161542.GA683634@kroah.com> References: <20200629142805.28013-1-sjpark@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200629142805.28013-1-sjpark@amazon.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 29, 2020 at 04:28:05PM +0200, SeongJae Park wrote: > Hello, > > > With my little script, I found below commits in the mainline tree are more than > 1 week old and fixing commits that back-ported in v5.4..v5.4.49, but not merged > in the stable/linux-5.4.y tree. Are those need to be merged in but missed or > dealyed? > > 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()") > 9fecd13202f5 ("btrfs: fix a block group ref counter leak after failure to remove block group") > 9d964e1b82d8 ("fix a braino in "sparc32: fix register window handling in genregs32_[gs]et()"") > 8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding") > 6e2f83884c09 ("bnxt_en: Fix AER reset logic on 57500 chips.") > efb94790852a ("drm/panel-simple: fix connector type for LogicPD Type28 Display") > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams") > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams") > 8dbe4c5d5e40 ("net: dsa: bcm_sf2: Fix node reference count") > ca8826095e4d ("selftests/net: report etf errors correctly") > 5a8d7f126c97 ("of: of_mdio: Correct loop scanning logic") > d35d3660e065 ("binder: fix null deref of proc->context") > > The script found several more commits but I exclude those here, because those > seems not applicable on 5.4.y or fixing trivial problems only. If I'm not > following a proper process for this kind of reports, please let me know. For commits that only have a "Fixes:" tag, and not a "cc: stable..." tag, wait a few weeks, or a month, for us to catch up with them. We usually get to them eventually, but it takes us a while as we have lots more to deal with by developers and maintainers that are properly tagging patches for this type of thing. Some of the above commits are queued up already, but not all of them. I'll take a look at the list after this next round of patches go out, and will let you know. And yes, we do want this type of list, it's greatly appreciated. thanks, greg k-h