On 9/11/22 00:10, Yanjun Zhu wrote:
I also implemented a workqueue for rxe. IMO, can we add a variable to
decide to use tasklet or workqueue?
If user prefer using tasklet, he can set the variable to use
tasklet. And the default is tasklet. Set the variable to another
value to use workqueue.
I'
On 4/18/21 10:49 PM, Changheun Lee wrote:
>>> @@ -167,6 +168,7 @@ void blk_queue_max_hw_sectors(struct request_queue *q,
>>> unsigned int max_hw_secto
>>> max_sectors = round_down(max_sectors,
>>> limits->logical_block_size >> SECTOR_SHIFT);
>>> limits->max_sec
On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote:
> The list in To: is the one given by get_maintainer.pl. Usualy, I only
> put the ML in Cc: I've run the script on the 2 patches of the serie
> and merged the 2 lists. Everyone is in the To: of the cover letter
> and of the 2 patches.
>
> If
On 4/18/21 2:26 PM, Christophe JAILLET wrote:
> Improve 'create_workqueue', 'create_freezable_workqueue' and
> 'create_singlethread_workqueue' so that they accept a format
> specifier and a variable number of arguments.
>
> This will put these macros more in line with 'alloc_ordered_workqueue' and
On 4/17/21 12:16 AM, Christophe JAILLET wrote:
> 'kasprintf()' can replace a kmalloc/strcpy/strcat sequence.
> It is less verbose and avoid the use of a magic number (64).
>
> Anyway, the underlying 'alloc_workqueue()' would only keep the 24 first
> chars (i.e. sizeof(struct workqueue_struct->name
On 4/15/21 10:50 PM, Changheun Lee wrote:
>> On 4/15/21 3:38 AM, Changheun Lee wrote:
>>> @@ -538,6 +540,8 @@ int blk_stack_limits(struct queue_limits *t, struct
>>> queue_limits *b,
>>> {
>>> unsigned int top, bottom, alignment, ret = 0;
>>>
>>> + t->bio_max_bytes = min_not_zero(t->bio_m
On 4/14/21 11:58 AM, Asutosh Das wrote:
> [ ... ]
Patches sent to the SCSI mailing list should not have a "scsi: " prefix
in the subject. That prefix is inserted before any SCSI patches go into
Martin's tree.
> diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
> index 1
On 4/15/21 3:38 AM, Changheun Lee wrote:
> @@ -167,6 +168,7 @@ void blk_queue_max_hw_sectors(struct request_queue *q,
> unsigned int max_hw_secto
> max_sectors = round_down(max_sectors,
>limits->logical_block_size >> SECTOR_SHIFT);
> limits->max_sectors
On 4/15/21 1:39 AM, Jiapeng Chong wrote:
> Fix the following clang warning:
>
> block/blk-zoned.c:55:24: warning: unused function 'blk_zone_start'
> [-Wunused-function].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> block/blk-zoned.c | 8
> 1 file changed, 8 dele
On 4/12/21 7:55 PM, Changheun Lee wrote:
> +unsigned int bio_max_size(struct bio *bio)
> +{
> + struct request_queue *q = bio->bi_bdev->bd_disk->queue;
> +
> + if (blk_queue_limit_bio_size(q))
> + return blk_queue_get_max_sectors(q, bio_op(bio))
> + << SECTOR
On 4/12/21 7:55 PM, Changheun Lee wrote:
> Set QUEUE_FLAG_LIMIT_BIO_SIZE queue flag to limit bio max size to
> queue max sectors size for UFS device.
>
> Signed-off-by: Changheun Lee
> ---
> drivers/scsi/scsi_lib.c | 2 ++
> drivers/scsi/ufs/ufshcd.c | 1 +
> include/scsi/scsi_host.h | 2 ++
>
_name(&sdev->device->dev), port_num);
> mutex_unlock(&sport->mutex);
> + ret = -EINVAL;
> goto reject;
> }
Reviewed-by: Bart Van Assche
On 4/12/21 11:09 AM, Jason Gunthorpe wrote:
> On Thu, Apr 08, 2021 at 09:50:30AM -0700, Bart Van Assche wrote:
>> On 4/8/21 4:31 AM, Wang Wensheng wrote:
>>> Fix to return a negative error code from the error handling
>>> case instead of 0, as done elsewhere in t
On 4/11/21 3:43 PM, Chaitanya Kulkarni wrote:
> Use the right name for the struct request variable that removes the
> following compilation error :-
>
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=sh
> CROSS_COMPILE=sh4-linux-gnu- 'CC=sccache sh4-linux-g
ret = qla2xxx_get_ini_stats(fc_bsg_to_shost(bsg_job),
> req_data->stat_type,
Since the above looks good to me:
Reviewed-by: Bart Van Assche
On 4/7/21 3:27 AM, Damien Le Moal wrote:
On 2021/04/07 18:46, Changheun Lee wrote:
I'll prepare new patch as you recommand. It will be added setting of
limit_bio_size automatically when queue max sectors is determined.
Please do that in the driver for the HW that benefits from it. Do not do th
On 4/8/21 4:31 AM, Wang Wensheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: db7683d7deb2 ("IB/srpt: Fix login-related race conditions")
> Reported-by: Hulk Robot
> Signed-off-by: Wang Wensheng
> ---
>
On 4/5/21 11:39 PM, luojiaxing wrote:
On 2021/4/3 0:01, Bart Van Assche wrote:
On 4/2/21 2:08 AM, Luo Jiaxing wrote:
#define AAP1_MEMMAP(r, c) \
- (*(u32 *)((u8*)pm8001_ha->memoryMap.region[AAP1].virt_ptr + (r)
* 32 \
+ (*(u32 *)((u8 *)pm8001_ha->memoryMap.region[AAP1].virt_pt
On 3/16/21 12:44 AM, Changheun Lee wrote:
> Add limit_bio_size block sysfs node to limit bio size.
> Queue flag QUEUE_FLAG_LIMIT_BIO_SIZE will be set if limit_bio_size is set.
> And bio max size will be limited by queue max sectors via
> QUEUE_FLAG_LIMIT_BIO_SIZE set.
>
> Signed-off-by: Changheun
On 3/12/21 2:55 AM, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/block/mtip32xx/mtip32xx.c: In function ‘mtip_standby_immediate’:
> drivers/block/mtip32xx/mtip32xx.c:1216:16: warning: variable ‘start’ set but
> not used [-Wunused-but-set-variable]
Has it been
On 3/12/21 2:55 AM, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> [ ... ]
Reviewed-by: Bart Van Assche
Card Event Handler ---*/
> -static const char * const rsxx_card_state_to_str(unsigned int state)
> +static const char *rsxx_card_state_to_str(unsigned int state)
> {
> static const char * const state_strings[] = {
> "Unknown", "Shutdown", "Starting", "Formatting",
Reviewed-by: Bart Van Assche
On 4/4/21 10:23 PM, Leon Romanovsky wrote:
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index bed4cfe50554..59138174affa 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -2444,10 +2444,10 @@ struct ib_device_ops {
>
On 4/2/21 2:08 AM, Luo Jiaxing wrote:
> -static struct flash_command flash_command_table[] =
> -{
> +static struct flash_command flash_command_table[] = {
> {"set_nvmd",FLASH_CMD_SET_NVMD},
> {"update", FLASH_CMD_UPDATE},
> {"",FLASH_CMD_NONE} /* Last entry sh
On 4/2/21 2:08 AM, Luo Jiaxing wrote:
> #define AAP1_MEMMAP(r, c) \
> - (*(u32 *)((u8*)pm8001_ha->memoryMap.region[AAP1].virt_ptr + (r) * 32 \
> + (*(u32 *)((u8 *)pm8001_ha->memoryMap.region[AAP1].virt_ptr + (r) * 32 \
> + (c)))
Since this macro is being modified, please convert it
, TMR always ends up with completion timeout. Fix it by
> calling blk_mq_start_request() in __ufshcd_issue_tm_cmd().
Reviewed-by: Bart Van Assche
On 3/24/21 7:09 AM, YueHaibing wrote:
Fix smatch warning:
drivers/infiniband/ulp/srpt/ib_srpt.c:2341 srpt_cm_req_recv() warn: passing
zero to 'PTR_ERR'
Use PTR_ERR_OR_ZERO instead of PTR_ERR
Fixes: 847462de3a0a ("IB/srpt: Fix srpt_cm_req_recv() error path (1/2)")
Signed-off-by: YueHaibing
--
On 3/31/21 9:45 AM, Avri Altman wrote:
>> ufshcd_tmc_handler() calls blk_mq_tagset_busy_iter(fn =
>> ufshcd_compl_tm()),
>> but since blk_mq_tagset_busy_iter() only iterates over all reserved tags
>> and requests which are not in IDLE state, ufshcd_compl_tm() never gets a
>> chance to run. Thus, TM
On 3/28/21 3:25 AM, Martin Kepplinger wrote:
> +/* Ignore the next media change event */
> +#define BLIST_MEDIA_CHANGE ((__force blist_flags_t)(1ULL << 11))
That comment is not descriptive enough. Consider to change it into
something like the following: "ignore one MEDIA CHANGE unit attention
af
On 3/28/21 3:25 AM, Martin Kepplinger wrote:
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 08c06c56331c..c62915d34ba4 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -585,6 +585,18 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>
On 3/28/21 3:25 AM, Martin Kepplinger wrote:
> Since these devices don't distinguish between resume and medium changed
> there's no better solution.
Is there any information in the SCSI VPD pages that could be used to
determine whether or not the medium has been changed, e.g. in VPD page 0x83?
Th
On 3/27/21 3:48 AM, Martin Kepplinger wrote:
> since this is absolutely needed for runtime pm with the SD device we
> use I assume there are others that would benefit from this too. Do you
> have any concerns or thoughts about this (logic and interface)?
Hi Martin,
Since the issue addressed by th
On 3/25/21 2:26 PM, Satya Tangirala wrote:
> @@ -1458,6 +1458,7 @@ struct bio *bio_split(struct bio *bio, int sectors,
>
> BUG_ON(sectors <= 0);
> BUG_ON(sectors >= bio_sectors(bio));
> + WARN_ON(!IS_ALIGNED(sectors, bio_required_sector_alignment(bio)));
Please change this WARN_O
On 3/25/21 6:39 PM, Satya Tangirala wrote:
> On Thu, Mar 25, 2021 at 02:51:31PM -0700, Bart Van Assche wrote:
>> Are you sure that the block layer core splits bios at logical block
>> boundaries? Commit 9cc5169cd478 ("block: Improve physical block
>> alignment of split
On 3/25/21 7:55 PM, Daejun Park wrote:
>> Please address it in next version. After that, I will give my
>> reviewed-by tag.
>
> OK, I will do.
Hi,
Please trim emails when replying. Otherwise it is very hard to follow a
conversation. It took me plenty of scrolling to find the above reply.
Thanks
On 3/25/21 2:26 PM, Satya Tangirala wrote:
> When a bio has an encryption context, its size must be aligned to its
> crypto data unit size. A bio must not be split in the middle of a data
> unit. Currently, bios are split at logical block boundaries [...]
Hi Satya,
Are you sure that the block lay
On 3/23/21 12:24 AM, Du Dengke wrote:
> When I read scsi kernel code, I found a spell error in
> __scsi_remove_device function comments. Patch was made in attach file.
Please include patches in the email body instead of sending these as an
attachment. Please also make yourself familiar with gi
On 3/22/21 12:18 AM, Christoph Hellwig wrote:
I've been running the reproducer on a KASAN enable VM for about
15 minutes now, but haven't been able to reproduce it.
Is there a way to inject this proposed fix into the syzbot queue?
diff --git a/block/partitions/core.c b/block/partitions/core.c
i
On 3/21/21 7:35 PM, Ming Lei wrote:
> On Mon, Mar 22, 2021 at 7:03 AM Bart Van Assche wrote:
>>
>> On 3/14/21 4:08 AM, syzbot wrote:
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:280d542f Merge tag 'drm-fixes-2021-03-05&#
On 3/14/21 4:08 AM, syzbot wrote:
> syzbot found the following issue on:
>
> HEAD commit:280d542f Merge tag 'drm-fixes-2021-03-05' of git://anongit..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15ade5aed0
> kernel config: https://syzkaller.appspo
On 3/19/21 10:47 AM, Adrian Hunter wrote:
It would also be good if you could re-base on linux-next.
Hmm ... my understanding is that patches should be prepared on top of
the for-next branch of the maintainer a patch is sent to, in this case
the for-next branch of
git://git.kernel.org/pub/scm
On 3/19/21 11:19 AM, John Garry wrote:
OK, but TBH, I am not so familiar with srcu - where you going to try this?
Hi John,
Have you received the following patch: "[PATCH] blk-mq: Fix races
between iterating over requests and freeing requests"
(https://lore.kernel.org/linux-block/202103190100
On 3/18/21 5:35 PM, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU to wlun during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> sus
On 2/15/21 9:40 AM, Arthur Simchaev wrote:
> -#define UFS_STRING_DESCRIPTOR(_name, _pname) \
> +#define UFS_STRING_DESCRIPTOR(_name, _pname, _is_ascii) \
> static ssize_t _name##_show(struct device *dev,
> \
> struct device_a
On 3/16/21 10:43 AM, John Garry wrote:
> On 16/03/2021 17:00, Bart Van Assche wrote:
>> I agree that Jens asked at the end of 2018 not to touch the fast path
>> to fix this use-after-free (maybe that request has been repeated more
>> recently). If Jens or anyone else fee
On 3/16/21 9:15 AM, John Garry wrote:
I'll have a look at this ASAP - a bit busy.
But a quick scan and I notice this:
> @@ -226,6 +226,7 @@ static inline void __blk_mq_put_driver_tag(struct
blk_mq_hw_ctx *hctx,
> struct request *rq)
> {
> blk_mq_put_tag(h
are added to the block layer code.
- No early return is inserted in blk_mq_tagset_busy_iter().
Thanks,
Bart.
>From a0e534012a766bd6e53cdd466eec0a811164c12a Mon Sep 17 00:00:00 2001
From: Bart Van Assche
Date: Wed, 10 Mar 2021 19:11:47 -0800
Subject: [PATCH] blk-mq: Fix races between iteratin
On 3/10/21 12:52 AM, John Garry wrote:
On 09/03/2021 19:21, Bart Van Assche wrote:
Regarding this patch series, I have shared the feedback I wanted to
share so I would appreciate it if someone else could also take a look.
So I can incorporate any changes and suggestions so far and send a
non
{
+ if (tmp == q)
+ continue;
+ blk_mq_unquiesce_queue(tmp);
+ blk_mq_unfreeze_queue(tmp);
+ }
+ mutex_unlock(&set->tag_list_lock);
}
Reviewed-by: Bart Van Assche
On 3/9/21 9:47 AM, John Garry wrote:
> This does fall over if some tags are allocated without associated
> request queue, which I do not know exists.
The only tag allocation mechanism I know of is blk_mq_get_tag(). The
only blk_mq_get_tag() callers I know of are __blk_mq_alloc_request() and
blk_mq
On 3/8/21 3:17 AM, John Garry wrote:
On 06/03/2021 04:43, Bart Van Assche wrote:
On 3/5/21 7:14 AM, John Garry wrote:
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 7ff1b20d58e7..5950fee490e8 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -358,11 +358,16 @@ void
On 3/8/21 2:50 AM, John Garry wrote:
Please let me know further thoughts.
Hi John,
My guess is that it is safe to nest these two locks. I was asking
because I had not found any information about the nesting in the patch
description.
Bart.
On 3/5/21 7:14 AM, John Garry wrote:
> @@ -2296,10 +2296,14 @@ void blk_mq_free_rqs(struct blk_mq_tag_set *set,
> struct blk_mq_tags *tags,
>
> for (i = 0; i < tags->nr_tags; i++) {
> struct request *rq = tags->static_rqs[i];
> + int j;
>
On 3/5/21 7:14 AM, John Garry wrote:
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index 7ff1b20d58e7..5950fee490e8 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -358,11 +358,16 @@ void blk_mq_tagset_busy_iter(struct blk_mq_tag_set
> *tagset,
> {
> int i;
>
On 3/5/21 7:14 AM, John Garry wrote:
> diff --git a/block/blk.h b/block/blk.h
> index 3b53e44b967e..1a948bfd91e4 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -201,10 +201,29 @@ void elv_unregister_queue(struct request_queue *q);
> static inline void elevator_exit(struct request_queue *q,
>
On 2/28/21 9:01 AM, Alexey Dobriyan wrote:
> This file has broken include guard which is not obvious just by looking
> at the code. Convert it manually. I think I got #endif right.
Why do you think that the include guard is broken? Please mention this
in the patch description.
> -
> -#ifndef __QL
dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
> +
> + trace_ufshcd_wl_suspend(dev_name(dev), ret,
> + ktime_to_us(ktime_sub(ktime_get(), start)),
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> +
> + return ret;
> +
> +}
Please remove the blank line after the return statement.
Otherwise this patch looks good to me. Hence:
Reviewed-by: Bart Van Assche
On 2/10/21 2:53 AM, Arthur Simchaev wrote:
> +static bool is_ascii_output = true;
[ ... ]
> static const char *ufschd_uic_link_state_to_string(
> enum uic_link_state state)
> {
> @@ -693,7 +695,15 @@ static ssize_t _name##_show(struct device *dev,
>
anagement Input Parameters
> Field Description
> Input Parameter 2 LSB: Task Tag of the task/command operated by the task
> management function.
Thanks for the clarification. Feel free to add the following to this patch:
Reviewed-by: Bart Van Assche
On 1/26/21 8:00 PM, Asutosh Das wrote:
> Resumes the scsi device before accessing it.
>
> Change-Id: I2929af60f2a92c89704a582fcdb285d35b429fde
> Signed-off-by: Asutosh Das
> Signed-off-by: Can Guo
> Signed-off-by: Bao D. Nguyen
No Change-Id tags in upstream patches please.
Thanks,
Bart.
On 1/28/21 9:57 PM, Can Guo wrote:
> On 2021-01-29 11:15, Bart Van Assche wrote:
>> On 1/27/21 8:16 PM, Can Guo wrote:
>>> In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs +
>>> req->tag as
>>> the Task Tag in one TMR UPIU. Directly use
On 1/28/21 10:29 PM, Can Guo wrote:
> On second thought, actually the 1st fix alone is enough to eliminate the
> race condition. Because blk_mq_tagset_busy_iter() only iterates over all
> requests which are not in IDLE state, if blk_mq_start_request() is called
> within the protection of host spin
On 1/27/21 8:16 PM, Can Guo wrote:
> ufshcd_tmc_handler() calls blk_mq_tagset_busy_iter(fn = ufshcd_compl_tm()),
> but since blk_mq_tagset_busy_iter() only iterates over all reserved tags
> and requests which are not in IDLE state, ufshcd_compl_tm() never gets a
> chance to run. Thus, TMR always en
On 1/27/21 8:16 PM, Can Guo wrote:
> ufshcd_compl_tm() looks for all 0 bits in the REG_UTP_TASK_REQ_DOOR_BELL
> and call complete() for each req who has the req->end_io_data set. There
> can be a race condition btw tmc send/compl, because the req->end_io_data is
> set, in __ufshcd_issue_tm_cmd(), w
On 1/27/21 8:16 PM, Can Guo wrote:
> In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs + req->tag as
> the Task Tag in one TMR UPIU. Directly use req->tag as the Task Tag.
Why is the current code wrong and why is this patch the proper fix?
Please explain this in the patch description.
On 1/26/21 11:59 AM, Maxim Mikityanskiy wrote:
> The cited commit introduced a serious regression with SATA write speed,
> as found by bisecting. This patch reverts this commit, which restores
> write speed back to the values observed before this commit.
>
> The performance tests were done on a He
On 1/20/21 7:23 PM, Can Guo wrote:
> Current task management request send/compl implementation is broken, the
> problems and fixes are listed as below:
>
> Problem: TMR completion timeout. ufshcd_tmc_handler() calls
> blk_mq_tagset_busy_iter(fn == ufshcd_compl_tm()), but since
>
On 1/20/21 7:57 PM, Jiapeng Zhong wrote:
> - return snprintf(buf, PAGE_SIZE, "%d.%02d.%02d (%x)\n",
> + return sysfs_emit_at(buf, PAGE_SIZE, "%d.%02d.%02d (%x)\n",
> ha->fw_info.fw_major, ha->fw_info.fw_minor,
> ha-
On 1/13/21 3:47 AM, Pavel Machek wrote:
>> From: Bart Van Assche
>>
>> [ Upstream commit cfefd9f8240a7b9fdd96fcd54cb029870b6d8d88 ]
>>
>> Disable runtime power management during domain validation. Since a later
>> patch removes RQF_PREEMPT, set RQF_PM for dom
On 1/9/21 7:53 AM, Pavel Begunkov wrote:
> iov_iter_bvec() initialises iterators well, no need to pre-zero it
> beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it
> out and generate extra code for that (confirmed with assembly).
Reviewed-by: Bart Van Assche
On 1/4/21 2:50 PM, Finn Thain wrote:
> On Mon, 4 Jan 2021, Bart Van Assche wrote:
>> Additionally, there is a good alternative available for the sbp driver.
>> Every system I know of that is equipped with a Firewire port also has an
>> Ethernet port. So users who want t
On 6/16/20 7:07 PM, Finn Thain wrote:
> On Tue, 16 Jun 2020, Bart Van Assche wrote:
>> As far as I know the sbp driver only has had one user ever and that user
>> is no longer user the sbp driver.
>
> So, you estimate the userbase at zero. Can you give a confidence level?
On 1/4/21 7:33 AM, John Garry wrote:
> On 23/12/2020 15:47, Bart Van Assche wrote:
>> I propose to change the order in which blk_mq_sched_free_requests(q) and
>> blk_mq_debugfs_unregister(q) are called. Today blk_mq_sched_free_requests(q)
>> is called by blk_cleanup_queue()
On 12/31/20 9:44 PM, Can Guo wrote:
> During system resume/suspend, hba could be NULL. In this case, do not touch
> eh_sem.
>
> Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM events and
> async scan")
>
> Signed-off-by: Can Guo
> ---
> drivers/scsi/ufs/ufshcd.c | 9 +
On 12/22/20 11:48 PM, Christoph Hellwig wrote:
> FYI, a few years ago I spent some time helping a customer to prepare
> their block device in userspace using fuse code for upstreaming, but
> at some point they abandoned the project. But if for some reason we
> don't want to use nbd I think a drive
On 12/23/20 3:40 AM, John Garry wrote:
> Sorry, I got the 2x iter functions mixed up.
>
> So if we use mutex to solve blk_mq_queue_tag_busy_iter() problem, then we
> still have this issue in blk_mq_tagset_busy_iter() which I report previously
> [0]:
>
> [ 319.771745] BUG: KASAN: use-after-free i
On 12/22/20 3:15 AM, John Garry wrote:
So then we could have something like this:
---8<---
-435,9 +444,13 @@ void blk_mq_queue_tag_busy_iter(struct request_queue
*q, busy_iter_fn *fn,
if (!blk_mq_hw_queue_mapped(hctx))
continue;
+ while (!atomic_inc_not_zero(&tags->ite
On 12/21/20 10:47 AM, John Garry wrote:
> Yes, I agree, and I'm not sure what I wrote to give that impression.
>
> About "root partition", above, I'm just saying that / is mounted on a
> sda partition:
>
> root@ubuntu:/home/john# mount | grep sda
> /dev/sda2 on / type ext4 (rw,relatime,errors=rem
On 12/21/20 4:06 AM, John Garry wrote:
> On 18/12/2020 22:43, Bart Van Assche wrote:
>> Does this mean that we do not yet have
>> a full explanation about why the above call stack can be triggered?
>
> We understand it, and I'll describe my experiment in detail:
>
On 12/17/20 3:07 AM, John Garry wrote:
> References to old IO sched requests are currently cleared from the
> tagset when freeing those requests; switching elevator or changing
> request queue depth is such a scenario in which this occurs.
>
> However, this does not stop the potentially racy behav
On 12/17/20 5:05 PM, Daejun Park wrote:
> Here is my iozone script:
> iozone -r 4k -+n -i2 -ecI -t 16 -l 16 -u 16
> -s $IO_RANGE/16 -F mnt/tmp_1 mnt/tmp_2 mnt/tmp_3 mnt/tmp_4
> mnt/tmp_5 mnt/tmp_6 mnt/tmp_7 mnt/tmp_8 mnt/tmp_9 mnt/tmp_10 mnt/tmp_11
> mnt/tmp_12 mnt/tmp_13 mnt/tmp_14 mnt/tmp_15 m
On 12/17/20 3:07 AM, John Garry wrote:
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index a6df2d5df88a..853ed5b889aa 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -358,10 +358,19 @@ void blk_mq_tagset_busy_iter(struct blk_mq_tag_set
> *tagset,
> {
> int i;
>
On 12/7/20 10:55 AM, Palmer Dabbelt wrote:
> All in all, I've found it a bit hard to figure out what sort of interest
> people
> have in dm-user: when I bring this up I seem to run into people who've done
> similar things before and are vaguely interested, but certainly nobody is
> chomping at the
On 12/8/20 9:55 AM, Alan Stern wrote:
Yes, that certainly is the proper fix. It's all to easy to miss these
issues that depend on your kernel configuration.
Bart, can you fold it into a new version of the patch?
Sure, I will do that.
Thanks,
Bart.
On 12/6/20 8:42 AM, Bean Huo wrote:
> From: Bean Huo
>
> Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
> for the TM response, let TM UPIU trace print its TM response UPIU.
>
> Signed-off-by: Bean Huo
> ---
> drivers/scsi/ufs/ufshcd.c | 8 ++--
> 1 file changed, 6
On 12/6/20 8:42 AM, Bean Huo wrote:
> From: Bean Huo
>
> Currently, in the query completion trace print, since we use
> hba->lrb[tag].ucd_req_ptr and didn't differentiate UPIU between
> request and response, thus header and transaction-specific field
> in UPIU printed by query trace are identica
On 11/29/20 11:04 PM, Hannes Reinecke wrote:
> On 11/26/20 5:49 PM, John Garry wrote:
>> On 26/11/2020 16:27, Bart Van Assche wrote:
>>> On 11/26/20 7:02 AM, Pradeep P V K wrote:
>>>> Observes below crash while accessing (use-after-free) request queue
On 11/26/20 7:02 AM, Pradeep P V K wrote:
> Observes below crash while accessing (use-after-free) request queue
> member of struct request.
>
> 191.784789: <2> Unable to handle kernel paging request at virtual
> address ff81429a4440
> ...
> 191.786174: <2> CPU: 3 PID: 213 Comm: kworker/3:1
On 11/20/20 8:35 AM, Alan Stern wrote:
> On Fri, Nov 20, 2020 at 12:37:22AM -0800, Can Guo wrote:
>> Runtime resume is handled by runtime PM framework, no need to forcibly
>> set runtime PM status to RPM_ACTIVE during system resume/thaw/restore.
>
> Sorry, I don't understand this explanation at al
On 11/15/20 5:42 PM, Can Guo wrote:
> Actually, I am thinking about removing all the pm_runtime_set_active()
> codes in both scsi_bus_resume_common() and scsi_dev_type_resume() - we
> don't need to forcibly set the runtime PM status to RPM_ACTIVE for either
> SCSI host/target or SCSI devices.
>
>
On 11/17/20 8:00 AM, kernel test robot wrote:
on test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz with 32G
memory
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
On 11/12/20 10:30 PM, Can Guo wrote:
> If block layer runtime PM is enabled for one SCSI device, then there is
> no need to forcibly change the SCSI device and its request queue's runtime
> PM status to active in scsi_dev_type_resume(), since block layer PM shall
> resume the SCSI device on the dem
On 11/12/20 9:20 AM, Jason Gunthorpe wrote:
I think it should be like this, Bart?
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 6017d525084a0c..80f9673956ced2 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/
On 10/27/20 2:51 AM, Mauro Carvalho Chehab wrote:
> Add a description for it.
It seems like my Reviewed-by tag is missing? See also
https://lore.kernel.org/linux-rdma/cb5944e2-bdea-e320-d4d1-2f9bc9539...@acm.org/
Bart.
On 10/21/20 9:59 PM, Chanho Park wrote:
Please use udev or systemd instead of adding code in the UFS driver that
is
not necessary when udev or systemd is used.
What I mentioned was how it can be handled when we mount rootfs directly from
kernel.
1) kernel -> initramfs (mount root) -> systemd
On 10/20/20 9:23 PM, chanho61.park wrote:
> Did you mean /dev/disk/by-[part]label/ symlink? It's quite reasonable to
> use them by udev in userspace such as initramfs but some cases does not use
> initramfs or initrd. In that case, we need to load the root
> device(/dev/sda[N]) directly from kernel
Number of CQEs in @cq.
> * @zw_cqe: Zero-length write CQE.
> * @rcu: RCU head.
> * @kref: kref for this channel.
Reviewed-by: Bart Van Assche
On 10/20/20 12:05 AM, Chanho Park wrote:
> By doing scan as asynchronous way, scsi device scannning can be out of
> order execution. It is no problem if there is a ufs host but the scsi
> device name of each host can be changed according to the scan sequences.
>
> Ideal Case) host0 scan first
> ho
On 10/13/20 4:54 AM, Mauro Carvalho Chehab wrote:
> Changeset c804af2c1d31 ("IB/srpt: use new shared CQ mechanism")
> added a new member for struct srpt_rdma_ch, but didn't add the
> corresponding kernel-doc markup, as repoted when doing
> "make htmldocs":
> ./drivers/infiniband/ulp/srpt/ib_s
/repro.syz?x=10ce0a8b90
>
> The issue was bisected to:
>
> commit 2004bfdef945fe55196db6b9cdf321fbc75bb0de
> Author: Bart Van Assche
> Date: Tue Mar 10 04:26:21 2020 +
>
> null_blk: Fix the null_add_dev() error path
#syz wrong-bisect
1 - 100 of 1024 matches
Mail list logo
