• Jens Axboe's avatar
    scsi: sd: use mempool for discard special page · 61cce6f6
    Jens Axboe authored
    When boxes are run near (or to) OOM, we have a problem with the discard
    page allocation in sd. If we fail allocating the special page, we return
    busy, and it'll get retried. But since ordering is honored for dispatch
    requests, we can keep retrying this same IO and failing. Behind that IO
    could be requests that want to free memory, but they never get the
    chance. This means you get repeated spews of traces like this:
    
    [1201401.625972] Call Trace:
    [1201401.631748]  dump_stack+0x4d/0x65
    [1201401.639445]  warn_alloc+0xec/0x190
    [1201401.647335]  __alloc_pages_slowpath+0xe84/0xf30
    [1201401.657722]  ? get_page_from_freelist+0x11b/0xb10
    [1201401.668475]  ? __alloc_pages_slowpath+0x2e/0xf30
    [1201401.679054]  __alloc_pages_nodemask+0x1f9/0x210
    [1201401.689424]  alloc_pages_current+0x8c/0x110
    [1201401.699025]  sd_setup_write_same16_cmnd+0x51/0x150
    [1201401.709987]  sd_init_command+0x49c/0xb70
    [1201401.719029]  scsi_setup_cmnd+0x9c/0x160
    [1201401.727877]  scsi_queue_rq+0x4d9/0x610
    [1201401.736535]  blk_mq_dispatch_rq_list+0x19a/0x360
    [1201401.747113]  blk_mq_sched_dispatch_requests+0xff/0x190
    [1201401.758844]  __blk_mq_run_hw_queue+0x95/0xa0
    [1201401.768653]  blk_mq_run_work_fn+0x2c/0x30
    [1201401.777886]  process_one_work+0x14b/0x400
    [1201401.787119]  worker_thread+0x4b/0x470
    [1201401.795586]  kthread+0x110/0x150
    [1201401.803089]  ? rescuer_thread+0x320/0x320
    [1201401.812322]  ? kthread_park+0x90/0x90
    [1201401.820787]  ? do_syscall_64+0x53/0x150
    [1201401.829635]  ret_from_fork+0x29/0x40
    
    Ensure that the discard page allocation has a mempool backing, so we
    know we can make progress.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
    61cce6f6
sd.c 98 KB