From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Date: Mon, 6 Jul 2020 20:40:41 +0530 Message-ID: <20200706151041.GL633187@vkoul-mobl> References: <8c50799e-d0ba-626a-5627-5ff4e5825f6a@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <8c50799e-d0ba-626a-5627-5ff4e5825f6a@intel.com> Sender: linux-serial-owner@vger.kernel.org To: Dave Jiang Cc: Arnd Bergmann , Naresh Kamboju , linux-serial@vger.kernel.org, open list , Jiri Slaby , linux-arm-msm , linux-tegra , jirislaby@kernel.org, Greg Kroah-Hartman , Andy Gross , Bjorn Andersson , ldewangan@nvidia.com, Thierry Reding , Jon Hunter , Qian Cai , lkft-triage@lists.linaro.org List-Id: linux-tegra@vger.kernel.org On 06-07-20, 07:33, Dave Jiang wrote: > > I don't see anything suspicious in dmaengine drivers, but there is a > > recent series > > from Dave Jiang that might explain it. Could you try reverting commit > > deb9541f5052 ("dmaengine: check device and channel list for empty")? > > > > I think the broken change is this one: > > > > @@ -819,6 +850,11 @@ struct dma_chan *dma_request_chan(struct device > > *dev, const char *name) > > > > /* Try to find the channel via the DMA filter map(s) */ > > mutex_lock(&dma_list_mutex); > > + if (list_empty(&dma_device_list)) { > > + mutex_unlock(&dma_list_mutex); > > + return NULL; > > + } > > + > > list_for_each_entry_safe(d, _d, &dma_device_list, global_node) { > > dma_cap_mask_t mask; > > const struct dma_slave_map *map = dma_filter_match(d, > > name, dev); > > > > which needs to return an error code like -ENODEV instead of NULL. There > > may be other changes in the same patch that introduce the same bug > > elsewhere. > > > > Arnd > > > > Vinod, > Do you want a diff fix or a revision of the patch for the fix? Diff fix please -- ~Vinod