On Tue, 2019-02-26 at 18:24 +0100, Peter Zijlstra wrote:
> On Thu, Feb 14, 2019 at 03:00:56PM -0800, Bart Van Assche wrote:
> > @@ -472,7 +473,8 @@ struct blk_flush_queue *blk_alloc_flush_queue(struct
> > request_queue *q,
> > if (!fq)
> > goto fail;
&
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,
>
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/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:
> 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/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/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 2020-05-30 02:32, Simon Arlott wrote:
> If the device minor cannot be allocated or the cdrom fails to be
> registered then the mutex should be destroyed.
Please add Fixes: and Cc: stable tags.
Thanks,
Bart.
On 2020-05-30 02:33, Simon Arlott wrote:
> If the cdrom fails to be registered then the device minor should be
> deallocated.
Also for this patch, please add Fixes: and Cc: stable tags.
Thanks,
Bart.
On 2020-05-30 09:41, James Bottomley wrote:
> On Sat, 2020-05-30 at 09:24 -0700, Bart Van Assche wrote:
>> On 2020-05-30 02:32, Simon Arlott wrote:
>>> If the device minor cannot be allocated or the cdrom fails to be
>>> registered then the mutex should be destroyed.
>
On 2020-05-15 20:19, Luis Chamberlain wrote:
> [ ... ]
Once Christoph's comments are addressed, feel free to add:
Reviewed-by: Bart Van Assche
On 2020-05-19 09:13, Gustavo A. R. Silva wrote:
> The function should return 0 on success, instead of err.
>
> Addresses-Coverity-ID: 1493753 ("Identical code for different branches")
> Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
> Signed-off-by: Gustavo A. R. Silva
> ---
> dri
On 2020-05-19 09:36, Gustavo A. R. Silva wrote:
> Remove the if-statement and return the value contained in _err_,
> unconditionally.
Thanks Gustavo!
Reviewed-by: Bart Van Assche
On 2020-07-30 18:30, Stanley Chu wrote:
> On Mon, 2020-07-27 at 11:18 +, Avri Altman wrote:
>> Looks good to me.
>> But better wait and see if Bart have any further reservations.
>
> Would you have any further suggestions?
Today is the first time that I took a look at ufshcd_abort(). The
appr
On 2020-05-20 10:55, Christoph Hellwig wrote:
> HPB is a completely fucked up concept and we shoud not merge it at all.
> Especially not with a crazy bullshit vendor extension layer that makes
> it even easier for vendors to implement even worse things than the
> already horrible spec says. Just s
On 2020-05-18 21:55, John Hubbard wrote:
> This code was using get_user_pages*(), in a "Case 2" scenario
> (DMA/RDMA), using the categorization from [1]. That means that it's
> time to convert the get_user_pages*() + put_page() calls to
> pin_user_pages*() + unpin_user_pages() calls.
>
> There is
On 2020-05-21 12:57, John Hubbard wrote:
> Also, I doubt if it's worth it, but do you want a patch to change
> SetPageDirty()
> to set_page_dirty_lock(), meanwhile? It seems like if that's never come
> up, then
> it's mostly a theoretical bug.
Hi John,
Since I do not use the st driver myself I wi
On 2020-08-12 20:00, Daejun Park wrote:
> On 2020-08-06 02:11, Daejun Park wrote:
>>> +static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb)
>>> +{
>>> +int ret;
>>> +
>>> +ufshpb_stat_init(hpb);
>>> +
>>> +kobject_init(&hpb->kobj, &ufshpb_ktype);
>>> +mutex_ini
On 2020-07-31 01:00, Can Guo wrote:
> AFAIK, sychronization of scsi_done is not a problem here, because scsi
> layer
> use the atomic state, namely SCMD_STATE_COMPLETE, of a scsi cmd to prevent
> the concurrency of abort and real completion of it.
>
> Check func scsi_times_out(), hope it helps.
>
On 2020-08-01 23:09, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: c804af2c1d3152c0cf877eeb50d60c2d49ac0cf0 ("IB/srpt: use new shared CQ
> mechanism")
> https://git.kernel.org/cgit/linux/kernel/git/rdma/rdma.git for-next
>
>
> in
On 2020-07-31 16:17, Can Guo wrote:
> For scsi_dma_unmap() part, that is true - we should make it serialized with
> any other completion paths. I've found it during my fault injection test, so
> I've made a patch to fix it, but it only comes in my next error recovery
> enhancement patch series. Ple
On 2020-08-03 03:04, Stanley Chu wrote:
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 307622284239..7cb220b3fde0 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -8640,6 +8640,7 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
> int ufshcd_shutdo
On 2020-08-06 09:36, Alim Akhtar wrote:
> V8 has removed the "UFS feature layer" which was the main topic of
> discussion. What else we thing is blocking this to be in mainline?
> Bart / Martin, any thought?
Thank you for having posted a version with the UFS feature layer removed. I
will try to
On 2020-08-06 02:11, Daejun Park wrote:
> +static void ufshpb_issue_hpb_reset_query(struct ufs_hba *hba)
> +{
> + int err;
> + int retries;
> +
> + for (retries = 0; retries < HPB_RESET_REQ_RETRIES; retries++) {
> + err = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_SET_FLAG,
>
On 2020-08-06 02:02, Daejun Park wrote:
> @@ -537,6 +548,7 @@ struct ufs_dev_info {
> u8 *model;
> u16 wspecversion;
> u32 clk_gating_wait_us;
> + u8 b_ufs_feature_sup;
> u32 d_ext_ufs_feature_sup;
> u8 b_wb_buffer_type;
> u32 d_wb_alloc_units;
>
Hmm ... sh
On 2020-08-06 02:11, Daejun Park wrote:
> This is a patch for the HPB feature.
> This patch adds HPB function calls to UFS core driver.
>
> The mininum size of the memory pool used in the HPB is implemented as a
^^^
minimum?
> Kconfig parameter (SCSI_UFS_HPB_HOST_MEM), so that it c
On 2020-08-06 02:15, Daejun Park wrote:
> + req->end_io_data = (void *)map_req;
Please leave the (void *) cast out since explicit casts from a non-void
to a void pointer are not necessary in C.
> +static inline struct
> +ufshpb_rsp_field *ufshpb_get_hpb_rsp(struct ufshcd_lrb *lrbp)
> +{
> +
On 2020-08-06 02:18, Daejun Park wrote:
> +static inline u32 ufshpb_get_lpn(struct scsi_cmnd *cmnd)
> +{
> + return blk_rq_pos(cmnd->request) >>
> + (ilog2(cmnd->device->sector_size) - 9);
> +}
Please use sectors_to_logical() from drivers/scsi/sd.h instead of open-coding
that funct
On 2020-08-17 22:20, Can Guo wrote:
> Commit 5586dd8ea250a ("scsi: ufs: Fix a race condition between error
> handler and runtime PM ops") moves the ufshcd_scsi_block_requests() inside
> err_handler(), but forgets to remove the ufshcd_scsi_unblock_requests() in
> the early return path. Correct the c
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 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/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/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/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/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 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 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 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/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 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/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/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/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/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/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/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
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/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 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 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/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/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/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:
> +/* 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 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/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/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 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/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
_name(&sdev->device->dev), port_num);
> mutex_unlock(&sport->mutex);
> + ret = -EINVAL;
> goto reject;
> }
Reviewed-by: Bart Van Assche
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 ++
>
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
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 3/12/21 2:55 AM, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> [ ... ]
Reviewed-by: Bart Van Assche
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/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/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/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
--
, 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 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
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/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/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/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 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 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 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
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/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
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 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/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 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 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 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 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/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/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:
> 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 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
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 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-
{
+ 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/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
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 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:
> @@ -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/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/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
501 - 600 of 1594 matches
Mail list logo
