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;
MIME-Version: 1.0
References: <20200221080510.197337-1-saravanak@google.com> <20200221080510.197337-4-saravanak@google.com>
 <f22b7cd6fb6256f56e908e021f4fe389f3a6ee07.camel@redhat.com>
In-Reply-To: <f22b7cd6fb6256f56e908e021f4fe389f3a6ee07.camel@redhat.com>
From:   Saravana Kannan <saravanak@google.com>
Date:   Tue, 24 Mar 2020 13:14:57 -0700
Message-ID: <CAGETcx9Ab8ygQhsrQPhYjymvmNdQYxYzczrXJdLeTPiSYh5VEw@mail.gmail.com>
Subject: Re: [PATCH v2 3/3] driver core: Skip unnecessary work when device
 doesn't have sync_state()
To:     Davide Caratti <dcaratti@redhat.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Vladimir Benes <vbenes@redhat.com>,
        Android Kernel Team <kernel-team@android.com>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Mar 24, 2020 at 1:03 PM Davide Caratti <dcaratti@redhat.com> wrote:
>
> On Fri, 2020-02-21 at 00:05 -0800, Saravana Kannan wrote:
> > A bunch of busy work is done for devices that don't have sync_state()
> > support. Stop doing the busy work.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > ---
> >  drivers/base/core.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
>
> hello Greg,
>
> this patch and patch 2/3 of the same series proved to fix systematic
> crashes (NULL pointer dereference in device_links_flush_sync_list() while
> loading mac80211_hwsim.ko, see [1]) on Fedora 31, that are triggered by
> NetworkManager-ci [2]. May I ask to queue these two patches for the next
> 5.5 stable?
>
> thank you in advance (and thanks to Vladimir for reporting)!

This was reported internally on some backports I did of 1/3. But I
forgot 1/3 was cherry-picked onto stable releases too. Otherwise, I'd
have reported this upstream too.

Thanks for reporting this and sorry about the breakage. 2/3 and 3/3
weren't meant to be fixes for 1/3, but they just happened to fix 1/3.
Problems of testing a series I suppose.

Thanks,
Saravana