| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Peter Schneider reported that a system would no longer boot after
updating to 6.8.4. Peter bisected the issue and identified commit
b5fc07a5fb56 ("scsi: core: Consult supported VPD page list prior to
fetching page") as being the culprit.
Turns out the enclosure device in Peter's system reports a byteswapped
page length for VPD page 0. It reports "02 00" as page length instead
of "00 02". This causes us to attempt to access 516 bytes (page length
+ header) of information despite only 2 pages being present.
Limit the page search scope to the size of our VPD buffer to guard
against devices returning a larger page count than requested.
Link: https://lore.kernel.org/r/[email protected]
Fixes: b5fc07a5fb56 ("scsi: core: Consult supported VPD page list prior to fetching page")
Cc: [email protected]
Reported-by: Peter Schneider <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Tested-by: Peter Schneider <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add missing kerneldoc parameter descriptions to _scsih_set_debug_level().
Signed-off-by: Deming Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Zero qed_slowpath_params before use.
Signed-off-by: Saurav Kashyap <[email protected]>
Signed-off-by: Nilesh Javali <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
If stag work is already scheduled and unload is called, it can lead to
issues as unload cleans up the work element. Wait for stag work to get
completed before cleanup during unload.
Signed-off-by: Saurav Kashyap <[email protected]>
Signed-off-by: Nilesh Javali <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Stag work can cause issues during unload and recovery, hence don't process
it.
Signed-off-by: Saurav Kashyap <[email protected]>
Signed-off-by: Nilesh Javali <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Running syzkaller with the newly reintroduced signed integer overflow
sanitizer produces this report:
[ 65.194362] ------------[ cut here ]------------
[ 65.197752] UBSAN: signed-integer-overflow in ../drivers/scsi/sr_ioctl.c:436:9
[ 65.203607] -2147483648 * 177 cannot be represented in type 'int'
[ 65.207911] CPU: 2 PID: 10416 Comm: syz-executor.1 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[ 65.213585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 65.219923] Call Trace:
[ 65.221556] <TASK>
[ 65.223029] dump_stack_lvl+0x93/0xd0
[ 65.225573] handle_overflow+0x171/0x1b0
[ 65.228219] sr_select_speed+0xeb/0xf0
[ 65.230786] ? __pm_runtime_resume+0xe6/0x130
[ 65.233606] sr_block_ioctl+0x15d/0x1d0
...
Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang. It was re-enabled in the kernel
with Commit 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer").
Firstly, let's change the type of "speed" to unsigned long as
sr_select_speed()'s only caller passes in an unsigned long anyways.
$ git grep '\.select_speed'
| drivers/scsi/sr.c: .select_speed = sr_select_speed,
...
| static int cdrom_ioctl_select_speed(struct cdrom_device_info *cdi,
| unsigned long arg)
| {
| ...
| return cdi->ops->select_speed(cdi, arg);
| }
Next, let's add an extra check to make sure we don't exceed 0xffff/177
(350) since 0xffff is the max speed. This has two benefits: 1) we deal
with integer overflow before it happens and 2) we properly respect the
max speed of 0xffff. There are some "magic" numbers here but I did not
want to change more than what was necessary.
Link: https://github.com/llvm/llvm-project/pull/82432 [1]
Closes: https://github.com/KSPP/linux/issues/357
Cc: [email protected]
Signed-off-by: Justin Stitt <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When a host is configured with a few LUNs and I/O is running, injecting FC
faults repeatedly leads to path recovery problems. The LUNs have 4 paths
each and 3 of them come back active after say an FC fault which makes 2 of
the paths go down, instead of all 4. This happens after several iterations
of continuous FC faults.
Reason here is that we're returning an I/O error whenever we're
encountering sense code 06/04/0a (LOGICAL UNIT NOT ACCESSIBLE, ASYMMETRIC
ACCESS STATE TRANSITION) instead of retrying.
[mwilck: The original patch was developed by Rajashekhar M A and Hannes
Reinecke. I moved the code to alua_check_sense() as suggested by Mike
Christie [1]. Evan Milne had raised the question whether pg->state should
be set to transitioning in the UA case [2]. I believe that doing this is
correct. SCSI_ACCESS_STATE_TRANSITIONING by itself doesn't cause I/O
errors. Our handler schedules an RTPG, which will only result in an I/O
error condition if the transitioning timeout expires.]
[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/CAGtn9r=kicnTDE2o7Gt5Y=yoidHYD7tG8XdMHEBJTBraVEoOCw@mail.gmail.com/
Co-developed-by: Rajashekhar M A <[email protected]>
Co-developed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Hannes Reinecke <[email protected]>
Signed-off-by: Martin Wilck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When building for a 32-bit platform such as ARM or i386, for which size_t
is unsigned int, there is a warning due to using an unsigned long format
specifier:
drivers/scsi/mpi3mr/mpi3mr_transport.c:1370:11: error: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Werror,-Wformat]
1369 | ioc_warn(mrioc, "skipping port %u, max allowed value is %lu\n",
| ~~~
| %u
1370 | i, sizeof(mr_sas_port->phy_mask) * 8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the proper format specifier for size_t, %zu, to resolve the warning for
all platforms.
Fixes: 3668651def2c ("scsi: mpi3mr: Sanitise num_phys")
Signed-off-by: Nathan Chancellor <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Information is stored in mr_sas_port->phy_mask, values larger then size of
this field shouldn't be allowed.
Signed-off-by: Tomas Henzl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Sathya Prakash Veerichetty <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Justin Tee <[email protected]> says:
Update lpfc to revision 14.4.0.2
This patch set contains updates to log messaging, a bug fix related to
unloading of the driver, clean up patches regarding the abuse of a
global spinlock, and support for 32 byte CDBs.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Update copyrights to 2024 for files modified in the 14.4.0.2 patch set.
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Update lpfc version to 14.4.0.2
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver's I/O path is updated to support 32 byte CDBs.
Changes to accommodate 32 byte CDBs include:
- Updating various size fields to allow for the larger 32 byte CDB.
- Starting the FCP command payload at an earlier offset in WQE submission
to fit the 32 byte CDB.
- Redefining relevant structs to __le32/__be32 data types for proper cpu
endianness macro usage.
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In attempt to reduce the amount of unnecessary phba->hbalock acquisitions
in the lpfc driver, change hba_flag into an unsigned long bitmask and use
clear_bit/test_bit bitwise atomic APIs instead of reliance on phba->hbalock
for synchronization.
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Instead of using the generic object wide phba->hbalock, an explicit lock
should be used to synchronize mutations to the phba->active_rrq_list.
Update all accesses to the phba->active_rrq_list with a new
phba->rrq_list_lock.
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Device recovery logic is skipped when the RSCN processing flag is set.
However during rmmod, the flag is not cleared leading to unnecessary delays
in waiting for completions on a link that is being offlined.
Move clearing of the RSCN deferred flag to a refactored routine when called
from device recovery, and set the IA flag when issuing an abort during
unload.
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
A struct scsi_cmnd already contains T10 DIF protection type information in
prot_type. So, instead of manually checking a CDBs' RD/WRPROTECT fields
with (byte[1] >> 5) utilize scsi_get_prot_type().
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
For diagnostic purposes, it is convenient to automatically log unexpected
CT MIB events without the need to set lpfc_log_verbose flags. So, change
lpfc_ct_handle_mibreq's logging level from KERN_INFO to KERN_WARNING.
Signed-off-by: Justin Tee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Pull in bug fix update from 6.9/scsi-fixes to accommodate 14.4.0.2
series.
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Commit be50f538e9a5 ("target: remove g_device_list") made 'g_device_list'
local as 'device_list' but also removed the last use of it, the code that
added the device to it.
Build tested only.
Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
I think the last use of this list was removed by
commit 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure
handling").
Build tested only.
Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Peter Griffin <[email protected]> says:
Hi Martin, James & Alim,
This series adds support to the ufs-exynos driver for Tensor gs101
found in Pixel 6. It was send previously in [1] and [2] but included
the other clock, phy and DTS parts. This series has been split into
just the ufs-exynos part to hopefully make things easier.
With this series, plus the phy, clock and dts changes UFS is
functional upstream for Pixel 6. The SKhynix HN8T05BZGKX015 can be
enumerated, partitions mounted etc.
The series is split into some prepatory patches for ufs-exynos and a
final patch that adds the gs101 support.
Note the sysreg clock has been moved to ufs node as fine grained clock
control around the syscon sysreg register accesses doesn't result in
functional UFS.
regards,
Peter
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add a dedicated compatible and drv_data with associated hooks for gs101 SoC
found on Pixel 6.
Note we make use of the previously added EXYNOS_UFS_OPT_UFSPR_SECURE
option, to skip initialisation of UFSPR registers as these are only
accessible via SMC call.
EXYNOS_UFS_OPT_TIMER_TICK_SELECT option is also set to select tick
source. This has been done so as not to effect any existing platforms.
DBG_OPTION_SUITE on gs101 has different address offsets to other SoCs so
these register offsets now come from uic_attr struct.
Signed-off-by: Peter Griffin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Krzysztof Kozlowski <[email protected]>
Tested-by: Will McVicker <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This allows these registers to be at different offsets or not exist at all
on some SoCs variants.
Signed-off-by: Peter Griffin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Krzysztof Kozlowski <[email protected]>
Tested-by: Will McVicker <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Platforms such as Tensor gs101 the pclk frequency is 267Mhz. Increase
PCLK_AVAIL_MAX so we don't fail the frequency check.
Signed-off-by: Peter Griffin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Krzysztof Kozlowski <[email protected]>
Tested-by: Will McVicker <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This option is intended to be set for SoCs that have HCI_V2P1_CTRL register
and can select their tick source via IA_TICK_SEL bit.
Source clock selection for timer tick
0x0 = Bus clock (aclk)
0x1 = Function clock (mclk)
Signed-off-by: Peter Griffin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Krzysztof Kozlowski <[email protected]>
Tested-by: Will McVicker <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This option is intended to be set on platforms whose ufspr registers are
only accessible via smc call (such as gs101).
Signed-off-by: Peter Griffin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Krzysztof Kozlowski <[email protected]>
Tested-by: Will McVicker <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add dedicated google,gs101-ufs compatible for Google Tensor gs101 SoC.
Signed-off-by: Peter Griffin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
DebugFS output for fw_resource_count shows:
estimate exchange used[0] high water limit [1945] n estimate iocb2 used [0] high water limit [5141]
estimate exchange2 used[0] high water limit [1945]
Which shows incorrect display due to missing newline in seq_print().
[mkp: fix checkpatch warning about space before newline]
Fixes: 5f63a163ed2f ("scsi: qla2xxx: Fix exchange oversubscription for management commands")
Signed-off-by: Himanshu Madhani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Currently, we allocate a count-sized kernel buffer and copy count from
userspace to that buffer. Later, we use kstrtouint on this buffer but we
don't ensure that the string is terminated inside the buffer, this can
lead to OOB read when using kstrtouint. Fix this issue by using
memdup_user_nul instead of memdup_user.
Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
Signed-off-by: Bui Quang Minh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
of memdup_user.
Fixes: 9f30b674759b ("bfa: replace 2 kzalloc/copy_from_user by memdup_user")
Signed-off-by: Bui Quang Minh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Correct the name of a struct in kernel-doc to match the actual function
name.
Add kernel-doc comments for 2 reserved fields to match comments for other
reserved fields.
Correct the kernel-doc comments for a nested struct to eliminate kernel-doc
warnings for them.
Warnings fixed here are:
scsi_bsg_mpi3mr.h:419: warning: expecting prototype for struct mpi3mr_bsg_buf_entry_list. Prototype was for struct mpi3mr_buf_entry_list instead
scsi_bsg_mpi3mr.h:435: warning: Function parameter or struct member 'rsvd2' not described in 'mpi3mr_bsg_mptcmd'
scsi_bsg_mpi3mr.h:456: warning: Function parameter or struct member 'rsvd3' not described in 'mpi3mr_bsg_packet'
scsi_bsg_mpi3mr.h:456: warning: Excess struct member 'drvrcmd' description in 'mpi3mr_bsg_packet'
scsi_bsg_mpi3mr.h:456: warning: Excess struct member 'mptcmd' description in 'mpi3mr_bsg_packet'
Signed-off-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: James E.J. Bottomley <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: Sathya Prakash Veerichetty <[email protected]>
Cc: Kashyap Desai <[email protected]>
Cc: Sumit Saxena <[email protected]>
Cc: Sreekanth Reddy <[email protected]>
Cc: [email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In struct utp_upiu_query_v4_0, add description for @osf3 and mark the
@reserved field as private so that no description is needed for it.
In struct utp_upiu_cmd, use the correct struct member name to eliminate a
kernel-doc warning.
Signed-off-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: James E.J. Bottomley <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: Alim Akhtar <[email protected]>
Cc: Avri Altman <[email protected]>
Cc: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Complete the kernel-doc notation for enum fc_lport_state. This fixes 7
kernel-doc warnings.
- In struct fc_rport_priv, change 'event_callback' to 'lld_event_callback'
to match the struct member name.
- In struct fc_fcp_pkt, add a description for 'timer_delay' to eliminate
one kernel-doc warning.
- Add return value notation for 3 functions. This fixes 3 kernel-doc
warnings.
There are still 12 warnings for struct members not described in struct
fc_rport_priv and struct fc_lport, e.g:
libfc.h:218: warning: Function parameter or struct member 'event' not described in 'fc_rport_priv'
libfc.h:760: warning: Function parameter or struct member 'vlan' not described in 'fc_lport'
Warnings that are fixed in this patch:
libfc.h:75: warning: Enum value 'LPORT_ST_RNN_ID' not described in enum 'fc_lport_state'
libfc.h:75: warning: Enum value 'LPORT_ST_RSNN_NN' not described in enum 'fc_lport_state'
libfc.h:75: warning: Enum value 'LPORT_ST_RSPN_ID' not described in enum 'fc_lport_state'
libfc.h:75: warning: Enum value 'LPORT_ST_RPA' not described in enum 'fc_lport_state'
libfc.h:75: warning: Enum value 'LPORT_ST_DHBA' not described in enum 'fc_lport_state'
libfc.h:75: warning: Enum value 'LPORT_ST_DPRT' not described in enum 'fc_lport_state'
libfc.h:75: warning: Excess enum value 'LPORT_ST_RPN_ID' description in 'fc_lport_state'
libfc.h:218: warning: Excess struct member 'event_callback' description in 'fc_rport_priv'
libfc.h:793: warning: No description found for return value of 'fc_lport_test_ready'
libfc.h:835: warning: No description found for return value of 'fc_lport_init_stats'
libfc.h:856: warning: No description found for return value of 'lport_priv'
Signed-off-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Hannes Reinecke <[email protected]>
Cc: James E.J. Bottomley <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Update header inclusions to follow IWYU (Include What You Use) principle.
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The variable 'i' is being assigned a value that is never read, the
following code path via the label ofld_err never refers to the
variable. The assignment is redundant and can be removed.
Cleans up clang scan warning:
drivers/scsi/bnx2fc/bnx2fc_tgt.c:132:5: warning: Value stored to 'i'
is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
on a __user pointer, which results into the crash.
To fix this issue, use a small local stack buffer for sprintf() and then
call simple_read_from_buffer(), which in turns make the copy_to_user()
call.
BUG: unable to handle page fault for address: 00007f4801111000
PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
Oops: 0002 [#1] PREEMPT SMP PTI
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
RIP: 0010:memcpy_orig+0xcd/0x130
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? __die_body+0x1a/0x60
? page_fault_oops+0x183/0x510
? exc_page_fault+0x69/0x150
? asm_exc_page_fault+0x22/0x30
? memcpy_orig+0xcd/0x130
vsnprintf+0x102/0x4c0
sprintf+0x51/0x80
qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
full_proxy_read+0x50/0x80
vfs_read+0xa5/0x2e0
? folio_add_new_anon_rmap+0x44/0xa0
? set_pte_at+0x15/0x30
? do_pte_missing+0x426/0x7f0
ksys_read+0xa5/0xe0
do_syscall_64+0x58/0x80
? __count_memcg_events+0x46/0x90
? count_memcg_event_mm+0x3d/0x60
? handle_mm_fault+0x196/0x2f0
? do_user_addr_fault+0x267/0x890
? exc_page_fault+0x69/0x150
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f4800f20b4d
Tested-by: Martin Hoyer <[email protected]>
Reviewed-by: John Meneghini <[email protected]>
Signed-off-by: Manish Rangankar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the calculation of the utrd pointer. This patch addresses the following
Coverity complaint:
CID 1538170: (#1 of 1): Extra sizeof expression (SIZEOF_MISMATCH)
suspicious_pointer_arithmetic: Adding sq_head_slot * 32UL /* sizeof (struct
utp_transfer_req_desc) */ to pointer hwq->sqe_base_addr of type struct
utp_transfer_req_desc * is suspicious because adding an integral value to
this pointer automatically scales that value by the size, 32 bytes, of the
pointed-to type, struct utp_transfer_req_desc. Most likely, the
multiplication by sizeof (struct utp_transfer_req_desc) in this expression
is extraneous and should be eliminated.
Cc: Bao D. Nguyen <[email protected]>
Cc: Stanley Chu <[email protected]>
Cc: Can Guo <[email protected]>
Fixes: 8d7290348992 ("scsi: ufs: mcq: Add supporting functions for MCQ abort")
Signed-off-by: Bart Van Assche <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Stop calling smp_processor_id() from preemptible code in
qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.
[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646
[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]
Tested-by: Guangwu Zhang <[email protected]>
Cc: Saurav Kashyap <[email protected]>
Cc: Nilesh Javali <[email protected]>
Signed-off-by: John Meneghini <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Saurav Kashyap <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct Scsi_Host private data contains pointer to struct ctlr_info.
Restore allocation of only 8 bytes to store pointer in struct Scsi_Host
private data area.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: bbbd25499100 ("scsi: hpsa: Fix allocation size for scsi_host_alloc()")
Signed-off-by: Yuri Karpov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
zero-address to new port"
Xingui Yang <[email protected]> says:
This series is to solve the problem of a BUG() when adding phy with
zero address to a new port.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
As of commit 7d1d86518118 ("[SCSI] libsas: fix false positive 'device
attached' conditions"), reset the phy->entacted_sas_addr address to a
zero-address when the link rate is less than 1.5G.
Currently we find that when a new device is attached, and the link rate is
less than 1.5G, but the device type is not NO_DEVICE, for example: the link
rate is SAS_PHY_RESET_IN_PROGRESS and the device type is stp. After setting
the phy->entacted_sas_addr address to the zero address, the port will
continue to be created for the phy with the zero-address, and other phys
with the zero-address will be tried to be added to the new port:
[562240.051197] sas: ex 500e004aaaaaaa1f phy19:U:0 attached: 0000000000000000 (no device)
// phy19 is deleted but still on the parent port's phy_list
[562240.062536] sas: ex 500e004aaaaaaa1f phy0 new device attached
[562240.062616] sas: ex 500e004aaaaaaa1f phy00:U:5 attached: 0000000000000000 (stp)
[562240.062680] port-7:7:0: trying to add phy phy-7:7:19 fails: it's already part of another port
Therefore, it should be the same as sas_get_phy_attached_dev(). Only when
device_type is SAS_PHY_UNUSED, sas_address is set to the 0 address.
Fixes: 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions")
Signed-off-by: Xingui Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We found that when ex_phy was attached and added to the parent wide port,
ex_phy->port was not set, resulting in sas_unregister_devs_sas_addr() not
calling sas_port_delete_phy() when deleting the phy, and the deleted phy
was still on the parent wide port's phy_list.
When we use sas_port_add_ex_phy() to set ex_phy->port to solve the above
problem, we find that after all the phys of the parent_port are removed and
the number of phy becomes 0, the parent_port will not be set to NULL. This
causes the freed parent port to be used when attaching a new ex_phy in
sas_ex_add_parent_port().
Use sas_port_add_ex_phy() instead of sas_port_add_phy() to set ex_phy->port
when ex_phy is added to the parent port, and set ex_dev->parent_port to
NULL when the number of phy on the port becomes 0.
Signed-off-by: Xingui Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Move sas_add_parent_port() to sas_expander.c and rename it to
sas_ex_add_parent_port() as it is only used in this file.
Signed-off-by: Xingui Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: John Garry <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This moves the process of adding ex_phy to a port into a new helper.
Signed-off-by: Xingui Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: John Garry <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Christoph Hellwig <[email protected]> says:
Hi all,
this series converts the SCSI midlayer and LLDDs to use atomic queue
limits API. It is pretty straight forward, except for the mpt3mr
driver which does really weird and probably already broken things by
setting limits from unlocked device iteration callbacks.
I will probably defer the (more complicated) ULD changes to the next
merge window as they would heavily conflict with Damien's zone write
plugging series. With that the series could go in through the SCSI
tree if Jens' ACKs the core block layer bits.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Switch to the ->device_configure method instead of ->slave_alloc and update
the block limits on the passed in queue_limits instead of using the
per-limit accessors.
Note that uas was the only driver setting these size limits from
->slave_alloc and not ->slave_configure and this makes it match everyone
else.
Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The cxlflash driver is no longer actively maintained and we intend to
remove it in a future kernel release. Change its status to obsolete.
While we're here, Matthew Ochs no longer works at IBM and is no longer in a
position to access cxlflash hardware, so remove him from the maintainers
list.
Signed-off-by: Andrew Donnellan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add MODULE_DEVICE_TABLE() so the module can be properly autoloaded based on
the alias from of_device_id table.
Cc: Will McVicker <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Will McVicker <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: Peter Wang <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|