Re: [PATCH 5.10 000/381] 5.10.180-rc1 review

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sat, May 20, 2023 at 02:39:10PM -0700, Greg Thelen wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > This is the start of the stable review cycle for the 5.10.180 release.
> > There are 381 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 17 May 2023 16:16:37 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.180-rc1.gz
> > or in the git tree and branch at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > -------------
> > Pseudo-Shortlog of commits:
> 
> [...]
> 
> > Baokun Li <libaokun1@huawei.com>
> >     writeback, cgroup: fix null-ptr-deref write in bdi_split_work_to_wbs
> 
> Sorry for not noticing this sooner, but I think there's a benign issue
> in this backport.
> 
> v5.10.180 commit 2b00b2a0e642 ("writeback, cgroup: fix null-ptr-deref
> write in bdi_split_work_to_wbs") contains:
> 
> +static void cgwb_free_rcu(struct rcu_head *rcu_head)
> +{
> +       struct bdi_writeback *wb = container_of(rcu_head,
> +                       struct bdi_writeback, rcu);
> +
> +       percpu_ref_exit(&wb->refcnt);
> +       kfree(wb);
> +}
> 
> [...]
> 
> @@ -397,7 +406,7 @@ static void cgwb_release_workfn(struct work_struct *work)
>         fprop_local_destroy_percpu(&wb->memcg_completions);
>         percpu_ref_exit(&wb->refcnt);
>         wb_exit(wb);
> -       kfree_rcu(wb, rcu);
> +       call_rcu(&wb->rcu, cgwb_free_rcu);
>  }
> 
> Notice there are now 2 percpu_ref_exit() calls. The upstream, and 5.15.y
> patches remove the cgwb_release_workfn() calls to percpu_ref_exit(). The
> 5.10.y fixup is below. It's not essential but might be worth applying to
> track upstream.

Thanks, I've queued this up now.

greg k-h