With the patch in __blk_rq_map_sg, I was able to boot successfully. (just to note that the code that I tested included the other patch that updated blk_map_iter_next with guards as well). I can do a test that just has the update to __blk_rq_map_sg if needed. Thanks On Wed, Feb 12, 2025 at 11:38 PM Christoph Hellwig <hch@xxxxxx> wrote: > > On Thu, Feb 13, 2025 at 07:32:14AM +0100, Christoph Hellwig wrote: > > On Thu, Feb 13, 2025 at 09:29:53AM +0800, Ming Lei wrote: > > > Yeah, turns out oops is triggered in initializing req_iterator for > > > discard req, and the following patch should be enough: > > > > How do we end up in blk_rq_map_sg for a discard request here? > > dma-mapping doesn't make sense for a non-special pyaload discard > > as used by xxen-blkfront, and xen-blkfront also only calls > > blk_rq_map_sg from blkif_queue_rw_req and not blkif_queue_discard_req. > > I think we're probably dealing with a flush command, as that's the > only request that doesn't have a bio except for empty passthrough > commands. xen-blkfront is a bit weird in calling into these data > transfer helpers despite not having data to transfer, but I guess > something like your patch to safeguard against it should be fine. > But add a comment as well please.
