Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

On 5/1/24 2:50 AM, Hillf Danton wrote: > On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin >> >> and then it failed testing. >> > So did my patch [1] but then the reason was spotted [2,3] > > [1] https://lore.kernel.org/lkml/20240430110209.4310-1-hdan...@sina.com/ > [2]

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

On 4/30/24 7:15 PM, Hillf Danton wrote: > On Tue, Apr 30, 2024 at 11:23:04AM -0500, Mike Christie wrote: >> On 4/30/24 8:05 AM, Edward Adam Davis wrote: >>> static int vhost_task_fn(void *data) >>> { >>> struct vhost_task *vtsk = data; >>> @@

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

On 4/30/24 8:05 AM, Edward Adam Davis wrote: > static int vhost_task_fn(void *data) > { > struct vhost_task *vtsk = data; > @@ -51,7 +51,7 @@ static int vhost_task_fn(void *data) > schedule(); > } > > - mutex_lock(>exit_mutex); > + mutex_lock(_mutex);

Re: [syzbot] [virtualization?] upstream boot error: WARNING: refcount bug in __free_pages_ok

c:673 >>> driver_register+0x23a/0x320 drivers/base/driver.c:246 >>> virtio_scsi_init+0x65/0xe0 drivers/scsi/virtio_scsi.c:1083 >>> do_one_initcall+0x248/0x880 init/main.c:1238 >>> do_initcall_level+0x157/0x210 init/main.c:1300 >>> do_initcalls+0x

Re: [RFC V1 07/13] vhost-vdpa: flush workers on suspend

On 1/10/24 9:09 PM, Jason Wang wrote: > On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare > wrote: >> >> To pass ownership of a live vdpa device to a new process, the user >> suspends the device, calls VHOST_NEW_OWNER to change the mm, and calls >> VHOST_IOTLB_REMAP to change the user virtual

Re: EEVDF/vhost regression (bisected to 86bfbb7ce4f6 sched/fair: Add lag based placement)

On 12/8/23 3:24 AM, Tobias Huschle wrote: > On Thu, Dec 07, 2023 at 01:48:40AM -0500, Michael S. Tsirkin wrote: >> On Thu, Dec 07, 2023 at 07:22:12AM +0100, Tobias Huschle wrote: >>> 3. vhost looping endlessly, waiting for kworker to be scheduled >>> >>> I dug a little deeper on what the vhost is

Re: [PATCH 2/2] scsi: iscsi_tcp: Fix use-after-free in iscsi_sw_tcp_host_get_param()

On 4/6/21 8:24 PM, Wenchao Hao wrote: > iscsi_sw_tcp_host_get_param() would access struct iscsi_session, while > struct iscsi_session might be freed by session destroy flow in > iscsi_free_session(). This commit fix this condition by freeing session > after host has already been removed. > >

Re: [PATCH AUTOSEL 5.10 07/22] scsi: iscsi: Fix race condition between login and sync thread

gt; https://urldefense.com/v3/__https://lore.kernel.org/r/20210325093248.284678-1-gulam.mohamed@oracle.com__;!!GqivPVa7Brio!Jiqrc6pu3EgrquzpG-KpNQkNebwKUgctkE0MN1MloQ2y5Y4OVOkKN0yCr2_W_CX2oRet$ > > Reviewed-by: Mike Christie There was a mistake in my review of this patch. It will also req

Re: [PATCH] target: Fix a double put in transport_free_session

On 3/26/21 7:31 AM, Maurizio Lombardi wrote: > > > Dne 23. 03. 21 v 3:58 Lv Yunlong napsal(a): >> In transport_free_session, se_nacl is got from se_sess >> with the initial reference. If se_nacl->acl_sess_list is >> empty, se_nacl->dynamic_stop is set to true. Then the first >>

Re: [PATCH] target: Fix a double put in transport_free_session

On 3/25/21 2:48 AM, lyl2...@mail.ustc.edu.cn wrote: > > > >> -原始邮件- >> 发件人: michael.chris...@oracle.com >> 发送时间: 2021-03-24 00:28:35 (星期三) >> 收件人: "Lv Yunlong" , martin.peter...@oracle.com >> 抄送: linux-s...@vger.kernel.org, target-de...@vger.kernel.org, >> linux-kernel@vger.kernel.org

Re: [PATCH] iscsi: Do Not set param when sock is NULL

On 1/7/21 9:48 AM, Gulam Mohamed wrote: > Hi Michael, > > As per your suggestions in below mail, I have completed the > suggested changes and tested them. Can you please review and let me know your > comments? Here is the patch: > > Description > === > 1. This Kernel panic

Re: [PATCH] scsi: target: tcmu: Fix wrong uio handling causing big memory leak

On 1/13/21 11:59 AM, Bodo Stroesser wrote: > On 12.01.21 19:36, Mike Christie wrote: >> On 12/18/20 8:15 AM, Bodo Stroesser wrote: >>> tcmu calls uio_unregister_device from tcmu_destroy_device. >>> After that uio will never call tcmu_release for this device. >>

Re: [PATCH] scsi: target: tcmu: Fix wrong uio handling causing big memory leak

On 12/18/20 8:15 AM, Bodo Stroesser wrote: > tcmu calls uio_unregister_device from tcmu_destroy_device. > After that uio will never call tcmu_release for this device. > If userspace still had the uio device open and / or mmap'ed > during uio_unregister_device, tcmu_release will not be called and >

Re: [PATCH] vhost scsi: fix error return code in vhost_scsi_set_endpoint()

destroy_vq_cmds; } Reviewed-by: Mike Christie

Re: [PATCH] scsi: iscsi: fix inappropriate use of put_device

> return conn; > > release_conn_ref: > - put_device(>dev); > + device_unregister(>dev); > + put_device(>dev); > + return NULL; > release_parent_ref: > put_device(>dev); > free_conn: > Reviewed-by: Mike Christie

Re: [PATCH] scsi: qedi: fix missing destroy_workqueue() on error in __qedi_probe

ct pci_dev *pdev, int mode) > > return 0; > > +free_tmf_thread: > + destroy_workqueue(qedi->tmf_thread); > free_cid_que: > qedi_release_cid_que(qedi); > free_uio: > Reviewed-by: Mike Christie

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 11/30/20 11:52 AM, Paolo Bonzini wrote: > On 30/11/20 18:38, Sasha Levin wrote: >>> I am not aware of any public CI being done _at all_ done on vhost-scsi, by >>> CKI or everyone else.  So autoselection should be done only on subsystems >>> that have very high coverage in CI. >> >> Where can

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

On 10/8/20 12:11 PM, Mike Christie wrote: > On 9/25/20 1:41 PM, ldun...@suse.com wrote: >> From: Lee Duncan >> >> iSCSI NOPs are sometimes "lost", mistakenly sent to the >> user-land iscsid daemon instead of handled in the kernel, >> as they should be,

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

On 9/25/20 1:41 PM, ldun...@suse.com wrote: > From: Lee Duncan > > iSCSI NOPs are sometimes "lost", mistakenly sent to the > user-land iscsid daemon instead of handled in the kernel, > as they should be, resulting in a message from the daemon like: > >> iscsid: Got nop in, but kernel supports

Re: [PATCH ] scsi: page warning: 'page' may be used uninitialized

> To: linux-s...@vger.kernel.org > Cc: Mike Christie > Signed-off-by: John Donnelly > --- > drivers/target/target_core_user.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/target/target_core_user.c > b/drivers/target/target_core_use

Re: [PATCH] scsi: iscsi: Do not put host in iscsi_set_flashnode_param()

_set_fnode; > } > > idx = ev->u.set_flashnode.flashnode_idx; > Reviewed-by: Mike Christie

Re: [PATCH 2/2] scsi: register sysfs for scsi/iscsi workqueues

On 6/11/20 5:07 AM, Bob Liu wrote: This patch enable setting cpu affinity through "cpumask" for below scsi/iscsi workqueues, so as to get better isolation. - scsi_wq_* - scsi_tmf_* - iscsi_q_xx - iscsi_eh Signed-off-by: Bob Liu --- drivers/scsi/hosts.c| 4 ++--

Re: [PATCH v1 target] target: Add initiatorname to NON_EXISTENT_LUN error

> This version ensures the initiator name is also printed on the same > message in transport_lookup_tmr_lun for consistency. > Reviewed-by: Mike Christie

Re: [PATCH target] target: Add initiatorname to NON_EXISTENT_LUN error

STENT_LUN instace in transport_lookup_tmr_lun. I just thought we would want/need the same info there. > > > > > > > > > > On Sat, May 16, 2020 at 9:50 AM Mike Christie wrote: >> >> On 5/13/20 11:01 PM, Lance Digby wrote: >>> The NON_EXI

Re: [PATCH target] target: Add initiatorname to NON_EXISTENT_LUN error

On 5/13/20 11:01 PM, Lance Digby wrote: > The NON_EXISTENT_LUN error can be written without an error condition > on the initiator responsible. Adding the initiatorname to this message > will reduce the effort required to fix this when many initiators are > supported by a target. > >

Re: INFO: task hung in do_read_cache_page (3)

On 5/11/20 8:19 AM, syzbot wrote: > syzbot has bisected this bug to: > > commit 2da22da573481cc4837e246d0eee4d518b3f715e > Author: Mike Christie > Date: Tue Aug 13 16:39:52 2019 + > > nbd: fix zero cmd timeout handling v2 > > bisection log: https://syzkall

Re: [PATCH] Add prctl support for controlling PF_MEMALLOC V2

On 10/22/2019 06:24 AM, Michal Hocko wrote: > On Mon 21-10-19 16:41:37, Mike Christie wrote: >> There are several storage drivers like dm-multipath, iscsi, tcmu-runner, >> amd nbd that have userspace components that can run in the IO path. For >> example, iscsi and nbd's users

Re: INFO: task hung in nbd_ioctl

abc2a360 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11712c0560 > > The bug was bisected to: > > commit e9e006f5fcf2bab59149cb38a48a4817c1b538b4 > Author: Mike Christie > Date: Sun Aug 4 19:10:06 2019 + > > nbd: fix max number of supported devs &g

Re: [RFC PATCH] Add proc interface to set PF_MEMALLOC flags

On 09/11/2019 03:40 AM, Martin Raiber wrote: > On 10.09.2019 10:35 Damien Le Moal wrote: >> Mike, >> >> On 2019/09/09 19:26, Mike Christie wrote: >>> Forgot to cc linux-mm. >>> >>> On 09/09/2019 11:28 AM, Mike Christie wrote: >>>> There a

Re: [RFC PATCH] Add proc interface to set PF_MEMALLOC flags

On 09/10/2019 05:00 AM, Kirill A. Shutemov wrote: > On Mon, Sep 09, 2019 at 11:28:04AM -0500, Mike Christie wrote: >> There are several storage drivers like dm-multipath, iscsi, and nbd that >> have userspace components that can run in the IO path. For example, >> iscsi and nb

Re: [PATCH] nbd: add a missed nbd_config_put() in nbd_xmit_timeout()

Josef had ackd my patch for the same thing here: https://www.spinics.net/lists/linux-block/msg43800.html so maybe Jens will pick that up with the rest of the set Josef had acked: https://www.spinics.net/lists/linux-block/msg43809.html to make it easier. On 08/14/2019 08:27 PM, sunke (E)

Re: [PATCH v2] target: fix a missing check of match_int

On 01/11/2019 11:31 PM, Kangjie Lu wrote: > When match_int fails, "arg" is left uninitialized and may contain random > value, thus should not be used. > The fix checks if match_int fails, and if so, returns its error code. > > Signed-off-by: Kangjie Lu > --- > drivers/target/target_core_rd.c |

Re: [PATCH] target: fix a missing check for match_int

On 12/26/2018 12:48 AM, Kangjie Lu wrote: > When match_int fails, "arg" is left uninitialized and may contain random > value, thus should not be used. > The fix checks if match_int fails, and if so, break. > > Signed-off-by: Kangjie Lu > --- > drivers/target/target_core_rd.c | 3 ++- > 1 file

Re: [PATCHv3] iscsi-target: Don't use stack buffer for scatterlist

sion, rejecting.\n", opcode); > iscsit_add_reject(conn, ISCSI_REASON_PROTOCOL_ERROR, > buffer); > - return; > + break; > } > > ret = iscsi_target_rx_opcode(conn, buffer); > if (ret < 0) > - return; > + break; > } > + > + kfree(buffer); > } > > int iscsi_target_rx_thread(void *arg) > Ok. Reviewed-by: Mike Christie

Re: [PATCHv3] iscsi-target: Don't use stack buffer for scatterlist

sion, rejecting.\n", opcode); > iscsit_add_reject(conn, ISCSI_REASON_PROTOCOL_ERROR, > buffer); > - return; > + break; > } > > ret = iscsi_target_rx_opcode(conn, buffer); > if (ret < 0) > - return; > + break; > } > + > + kfree(buffer); > } > > int iscsi_target_rx_thread(void *arg) > Ok. Reviewed-by: Mike Christie

Re: [PATCH] iscsi-target: Don't use stack buffer for scatterlist

ccing Maurizio because he was working on the same issue. On 08/22/2018 12:37 PM, Laura Abbott wrote: > Fedora got a bug report of a crash with iSCSI: > > kernel BUG at include/linux/scatterlist.h:143! > ... > RIP: 0010:iscsit_do_crypto_hash_buf+0x154/0x180 [iscsi_target_mod] > ... > Call Trace:

Re: [PATCH] iscsi-target: Don't use stack buffer for scatterlist

ccing Maurizio because he was working on the same issue. On 08/22/2018 12:37 PM, Laura Abbott wrote: > Fedora got a bug report of a crash with iSCSI: > > kernel BUG at include/linux/scatterlist.h:143! > ... > RIP: 0010:iscsit_do_crypto_hash_buf+0x154/0x180 [iscsi_target_mod] > ... > Call Trace:

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/06/2018 08:28 PM, Xiubo Li wrote: > On 2018/7/7 2:23, Mike Christie wrote: >> On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: >>> static irqreturn_t uio_interrupt(int irq, void *dev_id) >>> { >>> struct uio_device *idev = (struct uio_devic

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/06/2018 08:28 PM, Xiubo Li wrote: > On 2018/7/7 2:23, Mike Christie wrote: >> On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: >>> static irqreturn_t uio_interrupt(int irq, void *dev_id) >>> { >>> struct uio_device *idev = (struct uio_devic

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/06/2018 08:47 PM, Xiubo Li wrote: > On 2018/7/7 2:58, Mike Christie wrote: >> On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: >>> void uio_event_notify(struct uio_info *info) >>> { >>> -struct uio_device *idev = info->ui

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/06/2018 08:47 PM, Xiubo Li wrote: > On 2018/7/7 2:58, Mike Christie wrote: >> On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: >>> void uio_event_notify(struct uio_info *info) >>> { >>> -struct uio_device *idev = info->ui

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: > void uio_event_notify(struct uio_info *info) > { > - struct uio_device *idev = info->uio_dev; > + struct uio_device *idev; > + > + if (!info) > + return; > + > + idev = info->uio_dev; > For this one too, I am not

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: > void uio_event_notify(struct uio_info *info) > { > - struct uio_device *idev = info->uio_dev; > + struct uio_device *idev; > + > + if (!info) > + return; > + > + idev = info->uio_dev; > For this one too, I am not

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: > static irqreturn_t uio_interrupt(int irq, void *dev_id) > { > struct uio_device *idev = (struct uio_device *)dev_id; > - irqreturn_t ret = idev->info->handler(irq, idev->info); > + irqreturn_t ret; > + > +

Re: [PATCH v3 3/3] uio: fix crash after the device is unregistered

On 07/05/2018 09:57 PM, xiu...@redhat.com wrote: > static irqreturn_t uio_interrupt(int irq, void *dev_id) > { > struct uio_device *idev = (struct uio_device *)dev_id; > - irqreturn_t ret = idev->info->handler(irq, idev->info); > + irqreturn_t ret; > + > +

uio regression in 4.18-rc1 due to "uio: Prevent device destruction while fds are open"

Hi Hamish, I am hitting a regression with your patch: commit a93e7b331568227500186a465fee3c2cb5dffd1f Author: Hamish Martin Date: Mon May 14 13:32:23 2018 +1200 uio: Prevent device destruction while fds are open The problem is the addition of spin_lock_irqsave in uio_write. This leads

uio regression in 4.18-rc1 due to "uio: Prevent device destruction while fds are open"

Hi Hamish, I am hitting a regression with your patch: commit a93e7b331568227500186a465fee3c2cb5dffd1f Author: Hamish Martin Date: Mon May 14 13:32:23 2018 +1200 uio: Prevent device destruction while fds are open The problem is the addition of spin_lock_irqsave in uio_write. This leads

Re: [PATCH] target: make device_mutex and device_list static

t; > #include "target_core_ua.h" > > -DEFINE_MUTEX(device_mutex); > -LIST_HEAD(device_list); > +static DEFINE_MUTEX(device_mutex); > +static LIST_HEAD(device_list); > static DEFINE_IDR(devices_idr); > > static struct se_hba *lun0_hba; > My fault. Thanks. Reviewed-by: Mike Christie <mchri...@redhat.com>

Re: [PATCH] target: make device_mutex and device_list static

DEFINE_MUTEX(device_mutex); > -LIST_HEAD(device_list); > +static DEFINE_MUTEX(device_mutex); > +static LIST_HEAD(device_list); > static DEFINE_IDR(devices_idr); > > static struct se_hba *lun0_hba; > My fault. Thanks. Reviewed-by: Mike Christie

Re: [PATCH 1/1] uio: Fix uio_device memory leak

On 06/13/2017 07:16 PM, Mike Christie wrote: > On 06/13/2017 09:01 AM, Greg KH wrote: >> > On Wed, Jun 07, 2017 at 03:06:44PM -0500, Mike Christie wrote: >>> >> It looks like there might be 2 issues with the uio_device allocation, or >>> >> it &

Re: [PATCH 1/1] uio: Fix uio_device memory leak

On 06/13/2017 07:16 PM, Mike Christie wrote: > On 06/13/2017 09:01 AM, Greg KH wrote: >> > On Wed, Jun 07, 2017 at 03:06:44PM -0500, Mike Christie wrote: >>> >> It looks like there might be 2 issues with the uio_device allocation, or >>> >> it &

Re: [PATCH 1/1] uio: Fix uio_device memory leak

On 06/13/2017 09:01 AM, Greg KH wrote: > On Wed, Jun 07, 2017 at 03:06:44PM -0500, Mike Christie wrote: >> It looks like there might be 2 issues with the uio_device allocation, or it >> looks like we are leaking the device for possibly a specific type of device >> case

Re: [PATCH 1/1] uio: Fix uio_device memory leak

On 06/13/2017 09:01 AM, Greg KH wrote: > On Wed, Jun 07, 2017 at 03:06:44PM -0500, Mike Christie wrote: >> It looks like there might be 2 issues with the uio_device allocation, or it >> looks like we are leaking the device for possibly a specific type of device >> case

[PATCH 1/1] uio: Fix uio_device memory leak

, but did not see any type of device like this though. If this is a bug, this patch, made over Linus's tree, fixes the problems by just allocating the uio_device with the uio_info struct since they need to be allocated/freed/accessed at the same times. Signed-off-by: Mike Christie <mchri...@redhat.

[PATCH 1/1] uio: Fix uio_device memory leak

, but did not see any type of device like this though. If this is a bug, this patch, made over Linus's tree, fixes the problems by just allocating the uio_device with the uio_info struct since they need to be allocated/freed/accessed at the same times. Signed-off-by: Mike Christie --- drivers/target

Re: [PATCH] tcmu: Add fifo type waiter list support to avoid starvation

On 05/04/2017 09:51 PM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > The fifo type waiter list will hold the udevs who are waiting for the > blocks from the data global pool. The unmap thread will try to feed the > first udevs in waiter list, if the

Re: [PATCH] tcmu: Add fifo type waiter list support to avoid starvation

On 05/04/2017 09:51 PM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > The fifo type waiter list will hold the udevs who are waiting for the > blocks from the data global pool. The unmap thread will try to feed the > first udevs in waiter list, if the global free blocks available are >

Re: [PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

On 05/30/2017 11:58 PM, Nicholas A. Bellinger wrote: > Hey MNC, > > On Fri, 2017-05-26 at 22:14 -0500, Mike Christie wrote: >> Thanks for the patch. >> > > Btw, after running DATERA's internal longevity and scale tests across > ~20 racks on v4.1.y with th

Re: [PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

On 05/30/2017 11:58 PM, Nicholas A. Bellinger wrote: > Hey MNC, > > On Fri, 2017-05-26 at 22:14 -0500, Mike Christie wrote: >> Thanks for the patch. >> > > Btw, after running DATERA's internal longevity and scale tests across > ~20 racks on v4.1.y with th

Re: [PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

Thanks for the patch. On 05/26/2017 12:32 AM, Nicholas A. Bellinger wrote: > > - state = iscsi_target_sk_state_check(sk); > - write_unlock_bh(>sk_callback_lock); > - > - pr_debug("iscsi_target_sk_state_change: state: %d\n", state); > + orig_state_change(sk); > > -

Re: [PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

Thanks for the patch. On 05/26/2017 12:32 AM, Nicholas A. Bellinger wrote: > > - state = iscsi_target_sk_state_check(sk); > - write_unlock_bh(>sk_callback_lock); > - > - pr_debug("iscsi_target_sk_state_change: state: %d\n", state); > + orig_state_change(sk); > > -

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

culate them again when it make sure > how many iovs is needed before insert it to cmd area. > > Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com> Looks ok to me. Thanks. Acked-by: Mike Christie <mchri...@redhat.com>

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

t; how many iovs is needed before insert it to cmd area. > > Signed-off-by: Xiubo Li Looks ok to me. Thanks. Acked-by: Mike Christie

Re: [PATCH v6 2/2] tcmu: Add global data block pool support

On 04/30/2017 06:29 AM, Xiubo Li wrote: > [...] >>> +static struct page *tcmu_try_get_block_page(struct tcmu_dev *udev, >>> uint32_t dbi) >>> +{ >>> +struct page *page; >>> +int ret; >>> + >>> +mutex_lock(>cmdr_lock); >>> +page = tcmu_get_block_page(udev, dbi); >>> +if

Re: [PATCH v6 2/2] tcmu: Add global data block pool support

On 04/30/2017 06:29 AM, Xiubo Li wrote: > [...] >>> +static struct page *tcmu_try_get_block_page(struct tcmu_dev *udev, >>> uint32_t dbi) >>> +{ >>> +struct page *page; >>> +int ret; >>> + >>> +mutex_lock(>cmdr_lock); >>> +page = tcmu_get_block_page(udev, dbi); >>> +if

Re: [PATCH v6 1/2] tcmu: Add dynamic growing data area featuresupport

On 04/30/2017 05:22 AM, Xiubo Li wrote: > On 2017年04月30日 13:48, Mike Christie wrote: >> On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: >>> for_each_sg(data_sg, sg, data_nents, i) { >>> @@ -275,22 +371,26 @@ static void alloc_and_scatter_data_are

Re: [PATCH v6 1/2] tcmu: Add dynamic growing data area featuresupport

On 04/30/2017 05:22 AM, Xiubo Li wrote: > On 2017年04月30日 13:48, Mike Christie wrote: >> On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: >>> for_each_sg(data_sg, sg, data_nents, i) { >>> @@ -275,22 +371,26 @@ static void alloc_and_scatter_data_are

Re: [PATCH v6 2/2] tcmu: Add global data block pool support

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > For each target there will be one ring, when the target number > grows larger and larger, it could eventually runs out of the > system memories. > > In this patch for each target ring,

Re: [PATCH v6 2/2] tcmu: Add global data block pool support

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > For each target there will be one ring, when the target number > grows larger and larger, it could eventually runs out of the > system memories. > > In this patch for each target ring, currently for the cmd area >

Re: [PATCH v6 1/2] tcmu: Add dynamic growing data area feature support

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: > for_each_sg(data_sg, sg, data_nents, i) { > @@ -275,22 +371,26 @@ static void alloc_and_scatter_data_area(struct tcmu_dev > *udev, > from = kmap_atomic(sg_page(sg)) + sg->offset; > while (sg_remaining

Re: [PATCH v6 1/2] tcmu: Add dynamic growing data area feature support

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: > for_each_sg(data_sg, sg, data_nents, i) { > @@ -275,22 +371,26 @@ static void alloc_and_scatter_data_area(struct tcmu_dev > *udev, > from = kmap_atomic(sg_page(sg)) + sg->offset; > while (sg_remaining

Re: [PATCH] target/user: Add daynmic growing data area featuresupport

On 02/27/2017 07:22 PM, Xiubo Li wrote: > Hi Mike > > Thanks verrry much for your work and test cases. > > > From: Xiubo Li > > Currently for the TCMU, the ring buffer size is fixed to 64K cmd > area + 1M data area, and this will be bottlenecks for

Re: [PATCH] target/user: Add daynmic growing data area featuresupport

On 02/27/2017 07:22 PM, Xiubo Li wrote: > Hi Mike > > Thanks verrry much for your work and test cases. > > > From: Xiubo Li > > Currently for the TCMU, the ring buffer size is fixed to 64K cmd > area + 1M data area, and this will be bottlenecks for high iops. >>> Hi Xiubo,

Re: [PATCH] target/user: Add daynmic growing data area feature support

On 02/22/2017 02:32 PM, Andy Grover wrote: > On 02/17/2017 01:24 AM, lixi...@cmss.chinamobile.com wrote: >> > From: Xiubo Li >> > >> > Currently for the TCMU, the ring buffer size is fixed to 64K cmd >> > area + 1M data area, and this will be bottlenecks for high

Re: [PATCH] target/user: Add daynmic growing data area feature support

On 02/22/2017 02:32 PM, Andy Grover wrote: > On 02/17/2017 01:24 AM, lixi...@cmss.chinamobile.com wrote: >> > From: Xiubo Li >> > >> > Currently for the TCMU, the ring buffer size is fixed to 64K cmd >> > area + 1M data area, and this will be bottlenecks for high iops. > Hi Xiubo, thanks for

Re: [PATCH] target/user: Fix use-after-free cmd->se_cmd if the cmd is expired

On 01/03/2017 02:46 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > This is another use-after-free bug, the crash Call Trace is like: > [ 368.909498] RIP: 0010:[] [] > memcpy+0x16/0x110 > .. > [ 368.909547] Call Trace: > [ 368.909550] []

Re: [PATCH] target/user: Fix use-after-free cmd->se_cmd if the cmd is expired

On 01/03/2017 02:46 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > This is another use-after-free bug, the crash Call Trace is like: > [ 368.909498] RIP: 0010:[] [] > memcpy+0x16/0x110 > .. > [ 368.909547] Call Trace: > [ 368.909550] [] ?gather_data_area+0x109/0x180 > [

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

sertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01bff8ea28d8..81384a2562e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6448,10 +6448,10 @@ S:Maintained > F: drivers/firmware/iscsi_ibft* > > ISCSI > -M: Mike Christie <m

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

sertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01bff8ea28d8..81384a2562e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6448,10 +6448,10 @@ S:Maintained > F: drivers/firmware/iscsi_ibft* > > ISCSI > -M: Mike Christie

Re: ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!

Adding Steven and adi-buildroot-devel list. On 09/04/2016 12:12 PM, kbuild test robot wrote: > Hi Mike, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 9ca581b50dab6103183396852cc08e440fcda18e > commit:

Re: ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!

Adding Steven and adi-buildroot-devel list. On 09/04/2016 12:12 PM, kbuild test robot wrote: > Hi Mike, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 9ca581b50dab6103183396852cc08e440fcda18e > commit:

Re: [PATCH 37/45] drivers: use req op accessor

On 08/03/2016 07:30 PM, Shaun Tancheff wrote: > On Wed, Aug 3, 2016 at 6:47 PM, Mike Christie <mchri...@redhat.com> wrote: >> On 08/03/2016 05:33 PM, Ross Zwisler wrote: >>> On Sun, Jun 5, 2016 at 1:32 PM, <mchri...@redhat.com> wrote: >>>>

Re: [PATCH 37/45] drivers: use req op accessor

On 08/03/2016 07:30 PM, Shaun Tancheff wrote: > On Wed, Aug 3, 2016 at 6:47 PM, Mike Christie wrote: >> On 08/03/2016 05:33 PM, Ross Zwisler wrote: >>> On Sun, Jun 5, 2016 at 1:32 PM, wrote: >>>> From: Mike Christie >>>> >>>> The r

Re: [PATCH 37/45] drivers: use req op accessor

On 08/03/2016 05:33 PM, Ross Zwisler wrote: > On Sun, Jun 5, 2016 at 1:32 PM, <mchri...@redhat.com> wrote: >> From: Mike Christie <mchri...@redhat.com> >> >> The req operation REQ_OP is separated from the rq_flag_bits >> definition. This converts the bloc

Re: [PATCH 37/45] drivers: use req op accessor

On 08/03/2016 05:33 PM, Ross Zwisler wrote: > On Sun, Jun 5, 2016 at 1:32 PM, wrote: >> From: Mike Christie >> >> The req operation REQ_OP is separated from the rq_flag_bits >> definition. This converts the block layer drivers to >> use req_op to get the op from

Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code

On 08/03/2016 11:25 AM, Ross Zwisler wrote: > run fstests generic/008 at 2016-08-03 09:54:56 > page:ea0017af04c0 count:3 mapcount:0 mapping:8805eb059200 index:0x0 > flags: 0x3fff802828(uptodate|lru|private|writeback) > page dumped because: VM_BUG_ON_PAGE(!PageLocked(page)) >

Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code

On 08/03/2016 11:25 AM, Ross Zwisler wrote: > run fstests generic/008 at 2016-08-03 09:54:56 > page:ea0017af04c0 count:3 mapcount:0 mapping:8805eb059200 index:0x0 > flags: 0x3fff802828(uptodate|lru|private|writeback) > page dumped because: VM_BUG_ON_PAGE(!PageLocked(page)) >

Re: [PATCH 28/45] target: use bio op accessors

On 06/06/2016 01:46 AM, Hannes Reinecke wrote: > On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: >> From: Mike Christie <mchri...@redhat.com> >> >> Separate the op from the rq_flag_bits and have the target layer >> set/get the bio using bio_set_op_attrs/

Re: [PATCH 28/45] target: use bio op accessors

On 06/06/2016 01:46 AM, Hannes Reinecke wrote: > On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: >> From: Mike Christie >> >> Separate the op from the rq_flag_bits and have the target layer >> set/get the bio using bio_set_op_attrs/bio_op. >> >> Signed-of

Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs

On 05/04/2016 12:58 PM, Jeff Moyer wrote: > Mike Christie <mchri...@redhat.com> writes: > >> On 05/03/2016 03:44 PM, Jeff Moyer wrote: >>> Hi, Mike, >>> >>> That git tree doesn't seem to exist. I did manage to apply your patch >>> set on to

Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs

On 05/04/2016 12:58 PM, Jeff Moyer wrote: > Mike Christie writes: > >> On 05/03/2016 03:44 PM, Jeff Moyer wrote: >>> Hi, Mike, >>> >>> That git tree doesn't seem to exist. I did manage to apply your patch >>> set on top of next-20160415, though.

Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs

On 05/03/2016 03:44 PM, Jeff Moyer wrote: > mchri...@redhat.com writes: > >> The following patches begin to cleanup the request->cmd_flags and >> bio->bi_rw mess. We currently use cmd_flags to specify the operation, >> attributes and state of the request. For bi_rw we use it for similar >> info

Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs

On 05/03/2016 03:44 PM, Jeff Moyer wrote: > mchri...@redhat.com writes: > >> The following patches begin to cleanup the request->cmd_flags and >> bio->bi_rw mess. We currently use cmd_flags to specify the operation, >> attributes and state of the request. For bi_rw we use it for similar >> info

Re: [PATCH 41/42] block: do not use REQ_FLUSH for tracking flush support

On 04/15/2016 05:50 AM, Juergen Gross wrote: > On 15/04/16 12:40, mchri...@redhat.com wrote: >> From: Mike Christie <mchri...@redhat.com> >> >> The last patch added a REQ_OP_FLUSH for request_fn drivers >> and the next patch renames REQ_FLUSH to REQ_PREFLUSH whic

Re: [PATCH 41/42] block: do not use REQ_FLUSH for tracking flush support

On 04/15/2016 05:50 AM, Juergen Gross wrote: > On 15/04/16 12:40, mchri...@redhat.com wrote: >> From: Mike Christie >> >> The last patch added a REQ_OP_FLUSH for request_fn drivers >> and the next patch renames REQ_FLUSH to REQ_PREFLUSH which >> will be used by

Re: [PATCH 1/6] block: ensure we don't truncate top bits of the request command flags

On 03/22/2016 02:01 PM, Jens Axboe wrote: > On 03/22/2016 12:59 PM, Christoph Hellwig wrote: >> On Tue, Mar 22, 2016 at 11:55:15AM -0600, Jens Axboe wrote: >>> Some of the flags that we want to use from the make_request_fn path >>> are now larger than 32-bit, so change the functions involved to

Re: [PATCH 1/6] block: ensure we don't truncate top bits of the request command flags

On 03/22/2016 02:01 PM, Jens Axboe wrote: > On 03/22/2016 12:59 PM, Christoph Hellwig wrote: >> On Tue, Mar 22, 2016 at 11:55:15AM -0600, Jens Axboe wrote: >>> Some of the flags that we want to use from the make_request_fn path >>> are now larger than 32-bit, so change the functions involved to

Re: [PATCH 00/35 v4] separate operations from flags in the bio/request structs

On 02/29/2016 11:13 AM, Christoph Hellwig wrote: > Any reason you've dropped my ACK for the previous version? Sorry. I think I accidentally dropped it when I rebased back over to linux-next. It looks like it only got stuck on the first patch. I will fix that up on the resend for those kbuild

Re: [PATCH 00/35 v4] separate operations from flags in the bio/request structs

On 02/29/2016 11:13 AM, Christoph Hellwig wrote: > Any reason you've dropped my ACK for the previous version? Sorry. I think I accidentally dropped it when I rebased back over to linux-next. It looks like it only got stuck on the first patch. I will fix that up on the resend for those kbuild

Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id

On 02/15/2016 12:26 PM, Chris Leech wrote: > On Fri, Feb 12, 2016 at 09:54:51AM -0800, James Bottomley wrote: >> On Fri, 2016-02-12 at 09:38 -0800, Lee Duncan wrote: >>> The scsi_transport_iscsi module already uses the ida_simple >>> routines for managing the target ID, if requested to do >>> so.

  1   2   3   >