Re: [PATCH v2 1/2] scsi: replace GFP_ATOMIC with GFP_KERNEL for allocations in scsi_scan.c

2019-02-27 Thread Martin K. Petersen
Benjamin, > We had a test-report where, under memory pressure, adding LUNs to the > systems would fail (the tests add LUNs strictly in sequence): Applied to 5.1/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v2 1/2] scsi: replace GFP_ATOMIC with GFP_KERNEL for allocations in scsi_scan.c

2019-02-21 Thread Bart Van Assche
On Thu, 2019-02-21 at 10:18 +0100, Benjamin Block wrote: > Looking at the code of scsi_alloc_sdev(), and all the calling contexts, > there seems to be no reason to use GFP_ATMOIC here. All the different > call-contexts use a mutex at some point, and nothing in between that > requires no sleeping, a

[PATCH v2 1/2] scsi: replace GFP_ATOMIC with GFP_KERNEL for allocations in scsi_scan.c

2019-02-21 Thread Benjamin Block
We had a test-report where, under memory pressure, adding LUNs to the systems would fail (the tests add LUNs strictly in sequence): [ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5 [ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TP