Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Tejun Heo <htejun@gmail.com>
Date:   Mon, 12 Dec 2022 12:55:16 -1000
From:   Tejun Heo <tj@kernel.org>
To:     John Moon <quic_johmoo@quicinc.com>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [PATCH] workqueue: Check for null pointer return from
 get_work_pwq()
Message-ID: <Y5exVKEXe2vddXhP@slm.duckdns.org>
References: <20221208005344.25195-1-quic_johmoo@quicinc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221208005344.25195-1-quic_johmoo@quicinc.com>
Precedence: bulk

On Wed, Dec 07, 2022 at 04:53:44PM -0800, John Moon wrote:
> We've encountered a kernel panic with the following stack trace:
> 
> -> ret_from_fork
>  -> kthread
>   -> worker_thread
>    -> process_one_work
>     -> pwq_dec_nr_in_flight
>      -> pwq_activate_inactive_work
> 
> The issue was narrowed down to a null pointer dereference within
> pwq_activate_inactive_work() stemming from the return value of
> get_work_pwq() which may return NULL, but was not checked for
> null return prior to use.
> 
> While fixing the issue, other dereferences of get_work_pwq()'s
> return value were found without a null check.
> 
> Add null pointer checks to the calling functions that need them.

At that point the work item must have pwq assigned - see insert_work(), so
this can't be the root cause. It's just papering over a bug somewhere else
(e.g. the work item got freed or written over somehow).

Thanks.

-- 
tejun