| Age | Commit message (Collapse) | Author |
|---|
|
queue
Tony Nguyen says:
====================
This series contains updates to iavf and i40e drivers.
Radoslaw prevents admin queue operations being added when the driver is
being removed for iavf.
Petr Oros immediately starts reconfiguration on changes to VLANs on
iavf.
Ivan Vecera moves reset of VF to occur after port VLAN values are set
on i40e.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Nothing prevents iscsi_sw_tcp_conn_bind() to receive file descriptor
pointing to non TCP socket (af_unix for example).
Return -EINVAL if this is attempted, instead of crashing the kernel.
Fixes: 7ba247138907 ("[SCSI] open-iscsi/linux-iscsi-5 Initiator: Initiator code")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Lee Duncan <lduncan@suse.com>
Cc: Chris Leech <cleech@redhat.com>
Cc: Mike Christie <michael.christie@oracle.com>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: open-iscsi@googlegroups.com
Cc: linux-scsi@vger.kernel.org
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"16 small(ish) fixes all in drivers.
The major fixes are in pm8001 (fixes MSI-X issue going back to its
origin), the qla2xxx endianness fix, which fixes a bug on big endian
and the lpfc ones which can cause an oops on module removal without
them"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: lpfc: Prevent use-after-free during rmmod with mapped NVMe rports
scsi: lpfc: Early return after marking final NLP_DROPPED flag in dev_loss_tmo
scsi: lpfc: Fix the NULL vs IS_ERR() bug for debugfs_create_file()
scsi: target: core: Fix target_cmd_counter leak
scsi: pm8001: Setup IRQs on resume
scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
scsi: pm80xx: Use phy-specific SAS address when sending PHY_START command
scsi: ufs: core: Poll HCS.UCRDY before issuing a UIC command
scsi: ufs: core: Move __ufshcd_send_uic_cmd() outside host_lock
scsi: qedf: Add synchronization between I/O completions and abort
scsi: target: Replace strlcpy() with strscpy()
scsi: qla2xxx: Fix NULL vs IS_ERR() bug for debugfs_create_dir()
scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()
scsi: qla2xxx: Correct endianness for rqstlen and rsplen
scsi: ppa: Fix accidentally reversed conditions for 16-bit and 32-bit EPP
scsi: megaraid_sas: Fix deadlock on firmware crashdump
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
Pull ata fixes from Damien Le Moal:
- Fix link power management transitions to disallow unsupported states
(Niklas)
- A small string handling fix for the sata_mv driver (Christophe)
- Clear port pending interrupts before reset, as per AHCI
specifications (Szuying).
Followup fixes for this one are to not clear ATA_PFLAG_EH_PENDING in
ata_eh_reset() to allow EH to continue on with other actions recorded
with error interrupts triggered before EH completes. And an
additional fix to avoid thawing a port twice in EH (Niklas)
- Small code style fixes in the pata_parport driver to silence the
build bot as it keeps complaining about bad indentation (me)
- A fix for the recent CDL code to avoid fetching sense data for
successful commands when not necessary for correct operation (Niklas)
* tag 'ata-6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata:
ata: libata-core: fetch sense data for successful commands iff CDL enabled
ata: libata-eh: do not thaw the port twice in ata_eh_reset()
ata: libata-eh: do not clear ATA_PFLAG_EH_PENDING in ata_eh_reset()
ata: pata_parport: Fix code style issues
ata: libahci: clear pending interrupt status
ata: sata_mv: Fix incorrect string length computation in mv_dump_mem()
ata: libata: disallow dev-initiated LPM transitions to unsupported states
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fix from Greg KH:
"Here is a single USB fix for a much-reported regression for 6.6-rc1.
It resolves a crash in the typec debugfs code for many systems. It's
been in linux-next with no reported issues, and many people have
reported it resolving their problem with 6.6-rc1"
* tag 'usb-6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: typec: ucsi: Fix NULL pointer dereference
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fixes from Greg KH:
"Here is a single driver core fix for a much-reported-by-sysbot issue
that showed up in 6.6-rc1. It's been submitted by many people, all in
the same way, so it obviously fixes things for them all.
Also in here is a single documentation update adding riscv to the
embargoed hardware document in case there are any future issues with
that processor family.
Both of these have been in linux-next with no reported problems"
* tag 'driver-core-6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
Documentation: embargoed-hardware-issues.rst: Add myself for RISC-V
driver core: return an error when dev_set_name() hasn't happened
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc fix from Greg KH:
"Here is a single patch for 6.6-rc2 that reverts a 6.5 change for the
comedi subsystem that has ended up being incorrect and caused drivers
that were working for people to be unable to be able to be selected to
build at all.
To fix this, the Kconfig change needs to be reverted and a future set
of fixes for the ioport dependancies will show up in 6.7-rc1 (there's
no rush for them.)
This has been in linux-next with no reported issues"
* tag 'char-misc-6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
Revert "comedi: add HAS_IOPORT dependencies"
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"The main thing is the removal of 'probe_new' because all i2c client
drivers are converted now. Thanks Uwe, this marks the end of a long
conversion process.
Other than that, we have a few Kconfig updates and driver bugfixes"
* tag 'i2c-for-6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: cadence: Fix the kernel-doc warnings
i2c: aspeed: Reset the i2c controller when timeout occurs
i2c: I2C_MLXCPLD on ARM64 should depend on ACPI
i2c: Make I2C_ATR invisible
i2c: Drop legacy callback .probe_new()
w1: ds2482: Switch back to use struct i2c_driver's .probe()
|
|
When an XDP redirect happens before the link is ready, that
transmission will not finish and will timeout, causing an adapter
reset. If the redirects do not stop, the adapter will not stop
resetting.
Wait for the driver to signal that there's a carrier before allowing
transmissions to proceed.
Previous code was relying that when __IGC_DOWN is cleared, the NIC is
ready to transmit as all the queues are ready, what happens is that
the carrier presence will only be signaled later, after the watchdog
workqueue has a chance to run. And during this interval (between
clearing __IGC_DOWN and the watchdog running) if any transmission
happens the timeout is emitted (detected by igc_tx_timeout()) which
causes the reset, with the potential for the infinite loop.
Fixes: 4ff320361092 ("igc: Add support for XDP_REDIRECT action")
Reported-by: Ferenc Fejes <ferenc.fejes@ericsson.com>
Closes: https://lore.kernel.org/netdev/0caf33cf6adb3a5bf137eeaa20e89b167c9986d5.camel@ericsson.com/
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Ferenc Fejes <ferenc.fejes@ericsson.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently, we fetch sense data for a _successful_ command if either:
1) Command was NCQ and ATA_DFLAG_CDL_ENABLED flag set (flag
ATA_DFLAG_CDL_ENABLED will only be set if the Successful NCQ command
sense data supported bit is set); or
2) Command was non-NCQ and regular sense data reporting is enabled.
This means that case 2) will trigger for a non-NCQ command which has
ATA_SENSE bit set, regardless if CDL is enabled or not.
This decision was by design. If the device reports that it has sense data
available, it makes sense to fetch that sense data, since the sk/asc/ascq
could be important information regardless if CDL is enabled or not.
However, the fetching of sense data for a successful command is done via
ATA EH. Considering how intricate the ATA EH is, we really do not want to
invoke ATA EH unless absolutely needed.
Before commit 18bd7718b5c4 ("scsi: ata: libata: Handle completion of CDL
commands using policy 0xD") we never fetched sense data for successful
commands.
In order to not invoke the ATA EH unless absolutely necessary, even if the
device claims support for sense data reporting, only fetch sense data for
successful (NCQ and non-NCQ commands) commands that are using CDL.
[Damien] Modified the check to test the qc flag ATA_QCFLAG_HAS_CDL
instead of the device support for CDL, which is implied for commands
using CDL.
Fixes: 3ac873c76d79 ("ata: libata-core: fix when to fetch sense data for successful commands")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
commit 1e641060c4b5 ("libata: clear eh_info on reset completion") added
a workaround that broke the retry mechanism in ATA EH.
Tejun himself suggested to remove this workaround when it was identified
to cause additional problems:
https://lore.kernel.org/linux-ide/20110426135027.GI878@htj.dyndns.org/
He even said:
"Hmm... it seems I wasn't thinking straight when I added that work around."
https://lore.kernel.org/linux-ide/20110426155229.GM878@htj.dyndns.org/
While removing the workaround solved the issue, however, the workaround was
kept to avoid "spurious hotplug events during reset", and instead another
workaround was added on top of the existing workaround in commit
8c56cacc724c ("libata: fix unexpectedly frozen port after ata_eh_reset()").
Because these IRQs happened when the port was frozen, we know that they
were actually a side effect of PxIS and IS.IPS(x) not being cleared before
the COMRESET. This is now done in commit 94152042eaa9 ("ata: libahci: clear
pending interrupt status"), so these workarounds can now be removed.
Since commit 1e641060c4b5 ("libata: clear eh_info on reset completion") has
now been reverted, the ATA EH retry mechanism is functional again, so there
is once again no need to thaw the port more than once in ata_eh_reset().
This reverts "the workaround on top of the workaround" introduced in commit
8c56cacc724c ("libata: fix unexpectedly frozen port after ata_eh_reset()").
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
ata_scsi_port_error_handler() starts off by clearing ATA_PFLAG_EH_PENDING,
before calling ap->ops->error_handler() (without holding the ap->lock).
If an error IRQ is received while ap->ops->error_handler() is running,
the irq handler will set ATA_PFLAG_EH_PENDING.
Once ap->ops->error_handler() returns, ata_scsi_port_error_handler()
checks if ATA_PFLAG_EH_PENDING is set, and if it is, another iteration
of ATA EH is performed.
The problem is that ATA_PFLAG_EH_PENDING is not only cleared by
ata_scsi_port_error_handler(), it is also cleared by ata_eh_reset().
ata_eh_reset() is called by ap->ops->error_handler(). This additional
clearing done by ata_eh_reset() breaks the whole retry logic in
ata_scsi_port_error_handler(). Thus, if an error IRQ is received while
ap->ops->error_handler() is running, the port will currently remain
frozen and will never get re-enabled.
The additional clearing in ata_eh_reset() was introduced in commit
1e641060c4b5 ("libata: clear eh_info on reset completion").
Looking at the original error report:
https://marc.info/?l=linux-ide&m=124765325828495&w=2
We can see the following happening:
[ 1.074659] ata3: XXX port freeze
[ 1.074700] ata3: XXX hardresetting link, stopping engine
[ 1.074746] ata3: XXX flipping SControl
[ 1.411471] ata3: XXX irq_stat=400040 CONN|PHY
[ 1.411475] ata3: XXX port freeze
[ 1.420049] ata3: XXX starting engine
[ 1.420096] ata3: XXX rc=0, class=1
[ 1.420142] ata3: XXX clearing IRQs for thawing
[ 1.420188] ata3: XXX port thawed
[ 1.420234] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
We are not supposed to be able to receive an error IRQ while the port is
frozen (PxIE is set to 0, i.e. all IRQs for the port are disabled).
AHCI 1.3.1 section 10.7.1.1 First Tier (IS Register) states:
"Each bit location can be thought of as reporting a '1' if the virtual
"interrupt line" for that port is indicating it wishes to generate an
interrupt. That is, if a port has one or more interrupt status bit set,
and the enables for those status bits are set, then this bit shall be set."
Additionally, AHCI state P:ComInit clearly shows that the state machine
will only jump to P:ComInitSetIS (which sets IS.IPS(x) to '1'), if PxIE.PCE
is set to '1'. In our case, PxIE is set to 0, so IS.IPS(x) won't get set.
So IS.IPS(x) only gets set if PxIS and PxIE is set.
AHCI 1.3.1 section 10.7.1.1 First Tier (IS Register) also states:
"The bits in this register are read/write clear. It is set by the level of
the virtual interrupt line being a set, and cleared by a write of '1' from
the software."
So if IS.IPS(x) is set, you need to explicitly clear it by writing a 1 to
IS.IPS(x) for that port.
Since PxIE is cleared, the only way to get an interrupt while the port is
frozen, is if IS.IPS(x) is set, and the only way IS.IPS(x) can be set when
the port is frozen, is if it was set before the port was frozen.
However, since commit 737dd811a3db ("ata: libahci: clear pending interrupt
status"), we clear both PxIS and IS.IPS(x) after freezing the port, but
before the COMRESET, so the problem that commit 1e641060c4b5 ("libata:
clear eh_info on reset completion") fixed can no longer happen.
Thus, revert commit 1e641060c4b5 ("libata: clear eh_info on reset
completion"), so that the retry logic in ata_scsi_port_error_handler()
works once again. (The retry logic is still needed, since we can still
get an error IRQ _after_ the port has been thawed, but before
ata_scsi_port_error_handler() takes the ap->lock in order to check
if ATA_PFLAG_EH_PENDING is set.)
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
The ionic device supports a maximum buffer length of 16 bits (see
ionic_rxq_desc or ionic_rxq_sg_elem). When adding new buffers to
the receive rings, the function ionic_rx_fill() uses 16bit math when
calculating the number of pages to allocate for an RX descriptor,
given the interface's MTU setting. If the system PAGE_SIZE >= 64KB,
and the buf_info->page_offset is 0, the remain_len value will never
decrement from the original MTU value and the frag_len value will
always be 0, causing additional pages to be allocated as scatter-
gather elements unnecessarily.
A similar math issue exists in ionic_rx_frags(), but no failures
have been observed here since a 64KB page should not normally
require any scatter-gather elements at any legal Ethernet MTU size.
Fixes: 4b0a7539a372 ("ionic: implement Rx page reuse")
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fixes from Rafael Wysocki:
"These fix a thermal core breakage introduced by one of the recent
changes, amend those changes by adding 'const' to a new callback
argument and fix two memory leaks.
Specifics:
- Unbreak disabled trip point check in handle_thermal_trip() that may
cause it to skip enabled trip points (Rafael Wysocki)
- Add missing of_node_put() to of_find_trip_id() and
thermal_of_for_each_cooling_maps() that each break out of a
for_each_child_of_node() loop without dropping the reference to the
child object (Julia Lawall)
- Constify the recently added trip argument of the .get_trend()
thermal zone callback (Rafael Wysocki)"
* tag 'thermal-6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: core: Fix disabled trip point check in handle_thermal_trip()
thermal: Constify the trip argument of the .get_trend() zone callback
thermal/of: add missing of_node_put()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
- Fix DM core retrieve_deps() UAF race due to missing locking of a DM
table's list of devices that is managed using dm_{get,put}_device.
- Revert DM core's half-baked RCU optimization if IO submitter has set
REQ_NOWAIT. Can be revisited, and properly justified, after
comprehensively auditing all of DM to also pass GFP_NOWAIT for any
allocations if REQ_NOWAIT used.
* tag 'for-6.6/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm: don't attempt to queue IO under RCU protection
dm: fix a race condition in retrieve_deps
|
|
Pull block fixes from Jens Axboe:
- NVMe pull via Keith:
- nvme-tcp iov len fix (Varun)
- nvme-hwmon const qualifier for safety (Krzysztof)
- nvme-fc null pointer checks (Nigel)
- nvme-pci no numa node fix (Pratyush)
- nvme timeout fix for non-compliant controllers (Keith)
- MD pull via Song fixing regressions with both 6.5 and 6.6
- Fix a use-after-free regression in resizing blk-mq tags (Chengming)
* tag 'block-6.6-2023-09-15' of git://git.kernel.dk/linux:
nvme: avoid bogus CRTO values
md: Put the right device in md_seq_next
nvme-pci: do not set the NUMA node of device if it has none
blk-mq: fix tags UAF when shrinking q->nr_hw_queues
md/raid1: fix error: ISO C90 forbids mixed declarations
md: fix warning for holder mismatch from export_rdev()
md: don't dereference mddev after export_rdev()
nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()
nvme: host: hwmon: constify pointers to hwmon_channel_info
nvmet-tcp: pass iov_len instead of sg->length to bvec_set_page()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire fix from Takashi Sakamoto:
"A change applied to v6.5 kernel brings an issue that usual GFP
allocation is done in atomic context under acquired spin-lock. Let us
revert it"
* tag 'firewire-fixes-6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
Revert "firewire: core: obsolete usage of GFP_ATOMIC at building node tree"
|
|
Pull drm fixes from Dave Airlie:
"Regular rc2 fixes pull, mostly made up of amdgpu stuff, one i915, and
a bunch of others, one vkms locking violation is reverted.
connector:
- doc fix
exec:
- workaround lockdep issue
tests:
- fix a UAF
vkms:
- revert hrtimer fix
fbdev:
- g364fb: fix build failure with mips
i915:
- Only check eDP HPD when AUX CH is shared.
amdgpu:
- GC 9.4.3 fixes
- Fix white screen issues with S/G display on system with >= 64G of ram
- Replay fixes
- SMU 13.0.6 fixes
- AUX backlight fix
- NBIO 4.3 SR-IOV fixes for HDP
- RAS fixes
- DP MST resume fix
- Fix segfault on systems with no vbios
- DPIA fixes
amdkfd:
- CWSR grace period fix
- Unaligned doorbell fix
- CRIU fix for GFX11
- Add missing TLB flush on gfx10 and newer
radeon:
- make fence wait in suballocator uninterrruptable
gm12u320:
- Fix the timeout usage for usb_bulk_msg()"
* tag 'drm-fixes-2023-09-15' of git://anongit.freedesktop.org/drm/drm: (29 commits)
drm/tests: helpers: Avoid a driver uaf
Revert "drm/vkms: Fix race-condition between the hrtimer and the atomic commit"
drm/amdkfd: Insert missing TLB flush on GFX10 and later
drm/i915: Only check eDP HPD when AUX CH is shared
drm/amd/display: Fix 2nd DPIA encoder Assignment
drm/amd/display: Add DPIA Link Encoder Assignment Fix
drm/amd/display: fix replay_mode kernel-doc warning
drm/amdgpu: Handle null atom context in VBIOS info ioctl
drm/amdkfd: Checkpoint and restore queues on GFX11
drm/amd/display: Adjust the MST resume flow
drm/amdgpu: fallback to old RAS error message for aqua_vanjaram
drm/amdgpu/nbio4.3: set proper rmmio_remap.reg_offset for SR-IOV
drm/amdgpu/soc21: don't remap HDP registers for SR-IOV
drm/amd/display: Don't check registers, if using AUX BL control
drm/amdgpu: fix retry loop test
drm/amd/display: Add dirty rect support for Replay
Revert "drm/amd: Disable S/G for APUs when 64GB or more host memory"
drm/amd/display: fix the white screen issue when >= 64GB DRAM
drm/amdkfd: Update CU masking for GFX 9.4.3
drm/amdkfd: Update cache info reporting for GFX v9.4.3
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI fixes from Ard Biesheuvel:
- Missing x86 patch for the runtime cleanup that was merged in -rc1
- Kconfig tweak for kexec on x86 so EFI support does not get disabled
inadvertently
- Use the right EFI memory type for the unaccepted memory table so
kexec/kdump exposes it to the crash kernel as well
- Work around EFI implementations which do not implement
QueryVariableInfo, which is now called by statfs() on efivarfs
* tag 'efi-fixes-for-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efivarfs: fix statfs() on efivarfs
efi/unaccepted: Use ACPI reclaim memory for unaccepted memory table
efi/x86: Ensure that EFI_RUNTIME_MAP is enabled for kexec
efi/x86: Move EFI runtime call setup/teardown helpers out of line
|
|
dm looks up the table for IO based on the request type, with an
assumption that if the request is marked REQ_NOWAIT, it's fine to
attempt to submit that IO while under RCU read lock protection. This
is not OK, as REQ_NOWAIT just means that we should not be sleeping
waiting on other IO, it does not mean that we can't potentially
schedule.
A simple test case demonstrates this quite nicely:
int main(int argc, char *argv[])
{
struct iovec iov;
int fd;
fd = open("/dev/dm-0", O_RDONLY | O_DIRECT);
posix_memalign(&iov.iov_base, 4096, 4096);
iov.iov_len = 4096;
preadv2(fd, &iov, 1, 0, RWF_NOWAIT);
return 0;
}
which will instantly spew:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-nowait
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
INFO: lockdep is turned off.
CPU: 7 PID: 5580 Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x11d/0x1b0
__might_resched+0x3c3/0x5e0
? preempt_count_sub+0x150/0x150
mempool_alloc+0x1e2/0x390
? mempool_resize+0x7d0/0x7d0
? lock_sync+0x190/0x190
? lock_release+0x4b7/0x670
? internal_get_user_pages_fast+0x868/0x2d40
bio_alloc_bioset+0x417/0x8c0
? bvec_alloc+0x200/0x200
? internal_get_user_pages_fast+0xb8c/0x2d40
bio_alloc_clone+0x53/0x100
dm_submit_bio+0x27f/0x1a20
? lock_release+0x4b7/0x670
? blk_try_enter_queue+0x1a0/0x4d0
? dm_dax_direct_access+0x260/0x260
? rcu_is_watching+0x12/0xb0
? blk_try_enter_queue+0x1cc/0x4d0
__submit_bio+0x239/0x310
? __bio_queue_enter+0x700/0x700
? kvm_clock_get_cycles+0x40/0x60
? ktime_get+0x285/0x470
submit_bio_noacct_nocheck+0x4d9/0xb80
? should_fail_request+0x80/0x80
? preempt_count_sub+0x150/0x150
? lock_release+0x4b7/0x670
? __bio_add_page+0x143/0x2d0
? iov_iter_revert+0x27/0x360
submit_bio_noacct+0x53e/0x1b30
submit_bio_wait+0x10a/0x230
? submit_bio_wait_endio+0x40/0x40
__blkdev_direct_IO_simple+0x4f8/0x780
? blkdev_bio_end_io+0x4c0/0x4c0
? stack_trace_save+0x90/0xc0
? __bio_clone+0x3c0/0x3c0
? lock_release+0x4b7/0x670
? lock_sync+0x190/0x190
? atime_needs_update+0x3bf/0x7e0
? timestamp_truncate+0x21b/0x2d0
? inode_owner_or_capable+0x240/0x240
blkdev_direct_IO.part.0+0x84a/0x1810
? rcu_is_watching+0x12/0xb0
? lock_release+0x4b7/0x670
? blkdev_read_iter+0x40d/0x530
? reacquire_held_locks+0x4e0/0x4e0
? __blkdev_direct_IO_simple+0x780/0x780
? rcu_is_watching+0x12/0xb0
? __mark_inode_dirty+0x297/0xd50
? preempt_count_add+0x72/0x140
blkdev_read_iter+0x2a4/0x530
do_iter_readv_writev+0x2f2/0x3c0
? generic_copy_file_range+0x1d0/0x1d0
? fsnotify_perm.part.0+0x25d/0x630
? security_file_permission+0xd8/0x100
do_iter_read+0x31b/0x880
? import_iovec+0x10b/0x140
vfs_readv+0x12d/0x1a0
? vfs_iter_read+0xb0/0xb0
? rcu_is_watching+0x12/0xb0
? rcu_is_watching+0x12/0xb0
? lock_release+0x4b7/0x670
do_preadv+0x1b3/0x260
? do_readv+0x370/0x370
__x64_sys_preadv2+0xef/0x150
do_syscall_64+0x39/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f5af41ad806
Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45 89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d da 55
RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5af41ad806
RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003
RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001
</TASK>
where in fact it is dm itself that attempts to allocate a bio clone with
GFP_NOIO under the rcu read lock, regardless of the request type.
Fix this by getting rid of the special casing for REQ_NOWAIT, and just
use the normal SRCU protected table lookup. Get rid of the bio based
table locking helpers at the same time, as they are now unused.
Cc: stable@vger.kernel.org
Fixes: 563a225c9fd2 ("dm: introduce dm_{get,put}_live_table_bio called from dm_submit_bio")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
|
|
If port VLAN is configured on a VF then any other VLANs on top of this VF
are broken.
During i40e_ndo_set_vf_port_vlan() call the i40e driver reset the VF and
iavf driver asks PF (using VIRTCHNL_OP_GET_VF_RESOURCES) for VF capabilities
but this reset occurs too early, prior setting of vf->info.pvid field
and because this field can be zero during i40e_vc_get_vf_resources_msg()
then VIRTCHNL_VF_OFFLOAD_VLAN capability is reported to iavf driver.
This is wrong because iavf driver should not report VLAN offloading
capability when port VLAN is configured as i40e does not support QinQ
offloading.
Fix the issue by moving VF reset after setting of vf->port_vlan_id
field.
Without this patch:
$ echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
$ ip link set enp2s0f0 vf 0 vlan 3
$ ip link set enp2s0f0v0 up
$ ip link add link enp2s0f0v0 name vlan4 type vlan id 4
$ ip link set vlan4 up
...
$ ethtool -k enp2s0f0v0 | grep vlan-offload
rx-vlan-offload: on
tx-vlan-offload: on
$ dmesg -l err | grep iavf
[1292500.742914] iavf 0000:02:02.0: Failed to add VLAN filter, error IAVF_ERR_INVALID_QP_ID
With this patch:
$ echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
$ ip link set enp2s0f0 vf 0 vlan 3
$ ip link set enp2s0f0v0 up
$ ip link add link enp2s0f0v0 name vlan4 type vlan id 4
$ ip link set vlan4 up
...
$ ethtool -k enp2s0f0v0 | grep vlan-offload
rx-vlan-offload: off [requested on]
tx-vlan-offload: off [requested on]
$ dmesg -l err | grep iavf
Fixes: f9b4b6278d51 ("i40e: Reset the VF upon conflicting VLAN configuration")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
When the iavf driver wants to reconfigure the VLAN filters
(iavf_add_vlan, iavf_del_vlan), it sets a flag in
aq_required:
adapter->aq_required |= IAVF_FLAG_AQ_ADD_VLAN_FILTER;
or:
adapter->aq_required |= IAVF_FLAG_AQ_DEL_VLAN_FILTER;
This is later processed by the watchdog_task, but it runs periodically
every 2 seconds, so it can be a long time before it processes the request.
In the worst case, the interface is unable to receive traffic for more
than 2 seconds for no objective reason.
Fixes: 5eae00c57f5e ("i40evf: main driver core")
Signed-off-by: Petr Oros <poros@redhat.com>
Co-developed-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Co-developed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Ahmed Zaki <ahmed.zaki@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Add helper for set iavf aq request AVF_FLAG_AQ_* and immediately
schedule watchdog_task. Helper will be used in cases where it is
necessary to run aq requests asap
Signed-off-by: Petr Oros <poros@redhat.com>
Co-developed-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Co-developed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Prevent schedule operations for adminq during device remove and when
__IAVF_IN_REMOVE_TASK flag is set. Currently, the iavf_down function
adds operations for adminq that shouldn't be processed when the device
is in the __IAVF_REMOVE state.
Reproduction:
echo 4 > /sys/bus/pci/devices/0000:17:00.0/sriov_numvfs
ip link set dev ens1f0 vf 0 trust on
ip link set dev ens1f0 vf 1 trust on
ip link set dev ens1f0 vf 2 trust on
ip link set dev ens1f0 vf 3 trust on
ip link set dev ens1f0 vf 0 mac 00:22:33:44:55:66
ip link set dev ens1f0 vf 1 mac 00:22:33:44:55:67
ip link set dev ens1f0 vf 2 mac 00:22:33:44:55:68
ip link set dev ens1f0 vf 3 mac 00:22:33:44:55:69
echo 0000:17:02.0 > /sys/bus/pci/devices/0000\:17\:02.0/driver/unbind
echo 0000:17:02.1 > /sys/bus/pci/devices/0000\:17\:02.1/driver/unbind
echo 0000:17:02.2 > /sys/bus/pci/devices/0000\:17\:02.2/driver/unbind
echo 0000:17:02.3 > /sys/bus/pci/devices/0000\:17\:02.3/driver/unbind
sleep 10
echo 0000:17:02.0 > /sys/bus/pci/drivers/iavf/bind
echo 0000:17:02.1 > /sys/bus/pci/drivers/iavf/bind
echo 0000:17:02.2 > /sys/bus/pci/drivers/iavf/bind
echo 0000:17:02.3 > /sys/bus/pci/drivers/iavf/bind
modprobe vfio-pci
echo 8086 154c > /sys/bus/pci/drivers/vfio-pci/new_id
qemu-system-x86_64 -accel kvm -m 4096 -cpu host \
-drive file=centos9.qcow2,if=none,id=virtio-disk0 \
-device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -smp 4 \
-device vfio-pci,host=17:02.0 -net none \
-device vfio-pci,host=17:02.1 -net none \
-device vfio-pci,host=17:02.2 -net none \
-device vfio-pci,host=17:02.3 -net none \
-daemonize -vnc :5
Current result:
There is a probability that the mac of VF in guest is inconsistent with
it in host
Expected result:
When passthrough NIC VF to guest, the VF in guest should always get
the same mac as it in host.
Fixes: 14756b2ae265 ("iavf: Fix __IAVF_RESETTING state usage")
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
While drm_mm test was converted form igt selftest to kunit, unexpected
value of "end" argument equal "start" was introduced to one of calls to a
function that executes the drm_test_mm_insert_range for specific start/end
pair of arguments. As a consequence, DRM_MM_BUG_ON(end <= start) is
triggered. Fix it by restoring the original value.
Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit")
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: "Maíra Canal" <mairacanal@riseup.net>
Cc: Arthur Grillo <arthurgrillo@riseup.net>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Daniel Latypov <dlatypov@google.com>
Cc: stable@vger.kernel.org # v6.1+
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230911130323.7037-2-janusz.krzysztofik@linux.intel.com
|
|
Lengths of SG pointers are kept in the following order in
the SG entries in hardware.
63 48|47 32|31 16|15 0
-----------------------------------------
| Len 0 | Len 1 | Len 2 | Len 3 |
-----------------------------------------
| Ptr 0 |
-----------------------------------------
| Ptr 1 |
-----------------------------------------
| Ptr 2 |
-----------------------------------------
| Ptr 3 |
-----------------------------------------
Dma pointers have to be unmapped based on their
respective lengths given in this format.
Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Alex reported that running ssh over IPv6 does not work with
Thunderbolt/USB4 networking driver. The reason for that is that driver
should call skb_is_gso() before calling skb_is_gso_v6(), and it should
not return false after calculates the checksum successfully. This probably
was a copy paste error from the original driver where it was done properly.
Reported-by: Alex Balcanquall <alex@alexbal.com>
Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit 06f45435d985d60d7d2fe2424fbb9909d177a63d.
John Ogness reports the case that the allocation is in atomic context under
acquired spin-lock.
[ 12.555784] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
[ 12.555808] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 70, name: kworker/1:2
[ 12.555814] preempt_count: 1, expected: 0
[ 12.555820] INFO: lockdep is turned off.
[ 12.555824] irq event stamp: 208
[ 12.555828] hardirqs last enabled at (207): [<c00000000111e414>] ._raw_spin_unlock_irq+0x44/0x80
[ 12.555850] hardirqs last disabled at (208): [<c00000000110ff94>] .__schedule+0x854/0xfe0
[ 12.555859] softirqs last enabled at (188): [<c000000000f73504>] .addrconf_verify_rtnl+0x2c4/0xb70
[ 12.555872] softirqs last disabled at (182): [<c000000000f732b0>] .addrconf_verify_rtnl+0x70/0xb70
[ 12.555884] CPU: 1 PID: 70 Comm: kworker/1:2 Tainted: G S 6.6.0-rc1 #1
[ 12.555893] Hardware name: PowerMac7,2 PPC970 0x390202 PowerMac
[ 12.555898] Workqueue: firewire_ohci .bus_reset_work [firewire_ohci]
[ 12.555939] Call Trace:
[ 12.555944] [c000000009677830] [c0000000010d83c0] .dump_stack_lvl+0x8c/0xd0 (unreliable)
[ 12.555963] [c0000000096778b0] [c000000000140270] .__might_resched+0x320/0x340
[ 12.555978] [c000000009677940] [c000000000497600] .__kmem_cache_alloc_node+0x390/0x460
[ 12.555993] [c000000009677a10] [c0000000003fe620] .__kmalloc+0x70/0x310
[ 12.556007] [c000000009677ac0] [c0003d00004e2268] .fw_core_handle_bus_reset+0x2c8/0xba0 [firewire_core]
[ 12.556060] [c000000009677c20] [c0003d0000491190] .bus_reset_work+0x330/0x9b0 [firewire_ohci]
[ 12.556079] [c000000009677d10] [c00000000011d0d0] .process_one_work+0x280/0x6f0
[ 12.556094] [c000000009677e10] [c00000000011d8a0] .worker_thread+0x360/0x500
[ 12.556107] [c000000009677ef0] [c00000000012e3b4] .kthread+0x154/0x160
[ 12.556120] [c000000009677f90] [c00000000000bfa8] .start_kernel_thread+0x10/0x14
Cc: stable@kernel.org
Reported-by: John Ogness <john.ogness@linutronix.de>
Link: https://lore.kernel.org/lkml/87jzsuv1xk.fsf@jogness.linutronix.de/raw
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The driver can now use PTP if enabled but fails to link built-in
if PTP is a loadable module:
aarch64-linux-ld: drivers/net/ethernet/ti/icssg/icss_iep.o: in function `icss_iep_get_ptp_clock_idx':
icss_iep.c:(.text+0x200): undefined reference to `ptp_clock_index'
Add the usual dependency to avoid this.
Fixes: 186734c158865 ("net: ti: icssg-prueth: add packet timestamping and ptp support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the duprule which
is allocated by kzalloc in vcap_dup_rule() of
test_vcap_xn_rule_creator() is not freed, and it cause the memory leaks
below. Use vcap_del_rule() to free them as other functions do it.
unreferenced object 0xffff6eb4846f6180 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895522 (age 880.004s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 0a 00 00 00 f4 01 00 00 .'..............
00 00 00 00 00 00 00 00 98 61 6f 84 b4 6e ff ff .........ao..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000d2ac4ccb>] vcap_api_rule_insert_in_order_test+0xa4/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4846f6240 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895524 (age 879.996s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 58 62 6f 84 b4 6e ff ff ........Xbo..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<0000000052e6ad35>] vcap_api_rule_insert_in_order_test+0xbc/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4846f6300 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895524 (age 879.996s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 18 63 6f 84 b4 6e ff ff .........co..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<000000001b0895d4>] vcap_api_rule_insert_in_order_test+0xd4/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4846f63c0 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895524 (age 880.012s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 28 00 00 00 c8 00 00 00 .'......(.......
00 00 00 00 00 00 00 00 d8 63 6f 84 b4 6e ff ff .........co..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000134c151f>] vcap_api_rule_insert_in_order_test+0xec/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc180 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.000s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 c8 00 00 00 .'..............
00 00 00 00 00 00 00 00 98 c1 5f 84 b4 6e ff ff .........._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000fa5f64d3>] vcap_api_rule_insert_reverse_order_test+0xc8/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc240 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.000s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 58 c2 5f 84 b4 6e ff ff ........X._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000453dcd80>] vcap_add_rule+0x134/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000a7db42de>] vcap_api_rule_insert_reverse_order_test+0x108/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc300 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.000s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 28 00 00 00 90 01 00 00 .'......(.......
00 00 00 00 00 00 00 00 18 c3 5f 84 b4 6e ff ff .........._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000453dcd80>] vcap_add_rule+0x134/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000ea416c94>] vcap_api_rule_insert_reverse_order_test+0x150/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc3c0 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.020s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 32 00 00 00 f4 01 00 00 .'......2.......
00 00 00 00 00 00 00 00 d8 c3 5f 84 b4 6e ff ff .........._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000453dcd80>] vcap_add_rule+0x134/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000764a39b4>] vcap_api_rule_insert_reverse_order_test+0x198/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb484cd4240 (size 192):
comm "kunit_try_catch", pid 413, jiffies 4294895543 (age 879.956s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 58 42 cd 84 b4 6e ff ff ........XB...n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<0000000023976dd4>] vcap_api_rule_remove_in_front_test+0x158/0x658
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb484cd4300 (size 192):
comm "kunit_try_catch", pid 413, jiffies 4294895543 (age 879.956s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 28 00 00 00 c8 00 00 00 .'......(.......
00 00 00 00 00 00 00 00 18 43 cd 84 b4 6e ff ff .........C...n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<000000000b4760ff>] vcap_api_rule_remove_in_front_test+0x170/0x658
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
Fixes: dccc30cc4906 ("net: microchip: sparx5: Add KUNIT test of counters and sorted rules")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the rule which
is allocated by kzalloc in vcap_alloc_rule(), the field which is
allocated by kzalloc in vcap_rule_add_action() and
vcap_rule_add_key() is not freed, and it cause the memory leaks
below. Use vcap_free_rule() to free them as other drivers do it.
And since the return rule of test_vcap_xn_rule_creator() is not
used, remove it and switch to void.
unreferenced object 0xffff058383334240 (size 192):
comm "kunit_try_catch", pid 309, jiffies 4294894222 (age 639.800s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 00 81 93 84 83 05 ff ff ................
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000231b1097>] vcap_api_rule_insert_in_order_test+0xcc/0x184
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583849380c0 (size 64):
comm "kunit_try_catch", pid 309, jiffies 4294894222 (age 639.800s)
hex dump (first 32 bytes):
40 81 93 84 83 05 ff ff 68 42 33 83 83 05 ff ff @.......hB3.....
22 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000231b1097>] vcap_api_rule_insert_in_order_test+0xcc/0x184
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff058384938100 (size 64):
comm "kunit_try_catch", pid 309, jiffies 4294894222 (age 639.800s)
hex dump (first 32 bytes):
80 81 93 84 83 05 ff ff 58 42 33 83 83 05 ff ff ........XB3.....
7d 00 00 00 01 00 00 00 02 00 00 00 ff 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<00000000ba73cfbe>] vcap_add_type_keyfield+0xfc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000231b1097>] vcap_api_rule_insert_in_order_test+0xcc/0x184
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583833b6240 (size 192):
comm "kunit_try_catch", pid 311, jiffies 4294894225 (age 639.844s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 40 91 8f 84 83 05 ff ff ........@.......
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000509de3f4>] vcap_api_rule_insert_reverse_order_test+0x10c/0x654
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848f9100 (size 64):
comm "kunit_try_catch", pid 311, jiffies 4294894225 (age 639.844s)
hex dump (first 32 bytes):
80 91 8f 84 83 05 ff ff 68 62 3b 83 83 05 ff ff ........hb;.....
22 00 00 00 01 00 00 00 00 00 00 00 a5 b4 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000509de3f4>] vcap_api_rule_insert_reverse_order_test+0x10c/0x654
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848f9140 (size 64):
comm "kunit_try_catch", pid 311, jiffies 4294894225 (age 639.844s)
hex dump (first 32 bytes):
c0 91 8f 84 83 05 ff ff 58 62 3b 83 83 05 ff ff ........Xb;.....
7d 00 00 00 01 00 00 00 02 00 00 00 ff 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<00000000ba73cfbe>] vcap_add_type_keyfield+0xfc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000509de3f4>] vcap_api_rule_insert_reverse_order_test+0x10c/0x654
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff05838264e0c0 (size 192):
comm "kunit_try_catch", pid 313, jiffies 4294894230 (age 639.864s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 0a 00 00 00 f4 01 00 00 .'..............
00 00 00 00 00 00 00 00 40 3a 97 84 83 05 ff ff ........@:......
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000a29794d8>] vcap_api_rule_remove_at_end_test+0xbc/0xb48
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff058384973a80 (size 64):
comm "kunit_try_catch", pid 313, jiffies 4294894230 (age 639.864s)
hex dump (first 32 bytes):
e8 e0 64 82 83 05 ff ff e8 e0 64 82 83 05 ff ff ..d.......d.....
22 00 00 00 01 00 00 00 00 00 00 00 00 80 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000a29794d8>] vcap_api_rule_remove_at_end_test+0xbc/0xb48
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff058384973a40 (size 64):
comm "kunit_try_catch", pid 313, jiffies 4294894230 (age 639.880s)
hex dump (first 32 bytes):
80 39 97 84 83 05 ff ff d8 e0 64 82 83 05 ff ff .9........d.....
7d 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<0000000094335477>] vcap_add_type_keyfield+0xbc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000a29794d8>] vcap_api_rule_remove_at_end_test+0xbc/0xb48
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583832fa240 (size 192):
comm "kunit_try_catch", pid 315, jiffies 4294894233 (age 639.920s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 00 a1 8b 84 83 05 ff ff ................
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000be638a45>] vcap_api_rule_remove_in_middle_test+0xc4/0xb80
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848ba0c0 (size 64):
comm "kunit_try_catch", pid 315, jiffies 4294894233 (age 639.920s)
hex dump (first 32 bytes):
40 a1 8b 84 83 05 ff ff 68 a2 2f 83 83 05 ff ff @.......h./.....
22 00 00 00 01 00 00 00 00 00 00 00 00 80 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000be638a45>] vcap_api_rule_remove_in_middle_test+0xc4/0xb80
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848ba100 (size 64):
comm "kunit_try_catch", pid 315, jiffies 4294894233 (age 639.920s)
hex dump (first 32 bytes):
80 a1 8b 84 83 05 ff ff 58 a2 2f 83 83 05 ff ff ........X./.....
7d 00 00 00 01 00 00 00 02 00 00 00 ff 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<00000000ba73cfbe>] vcap_add_type_keyfield+0xfc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000be638a45>] vcap_api_rule_remove_in_middle_test+0xc4/0xb80
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583827d2180 (size 192):
comm "kunit_try_catch", pid 317, jiffies 4294894238 (age 639.956s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 00 e1 06 83 83 05 ff ff ................
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000e1ed8350>] vcap_api_rule_remove_in_front_test+0x144/0x6c0
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff05838306e0c0 (size 64):
comm "kunit_try_catch", pid 317, jiffies 4294894238 (age 639.956s)
hex dump (first 32 bytes):
40 e1 06 83 83 05 ff ff a8 21 7d 82 83 05 ff ff @........!}.....
22 00 00 00 01 00 00 00 00 00 00 00 00 80 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000e1ed8350>] vcap_api_rule_remove_in_front_test+0x144/0x6c0
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff05838306e180 (size 64):
comm "kunit_try_catch", pid 317, jiffies 4294894238 (age 639.968s)
hex dump (first 32 bytes):
98 21 7d 82 83 05 ff ff 00 e1 06 83 83 05 ff ff .!}.............
67 00 00 00 00 00 00 00 01 01 00 00 ff 00 00 00 g...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<000000006ce4945d>] test_add_def_fields+0x84/0x8c
[<00000000507e0ab6>] vcap_val_rule+0x294/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000e1ed8350>] vcap_api_rule_remove_in_front_test+0x144/0x6c0
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
Fixes: dccc30cc4906 ("net: microchip: sparx5: Add KUNIT test of counters and sorted rules")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202309090950.uOTEKQq3-lkp@intel.com/
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the duprule which
is allocated in vcap_dup_rule() and the vcap enabled port which
is allocated in vcap_enable() of vcap_enable_lookups in
vcap_api_encode_rule_test() is not freed, and it cause the memory
leaks below.
Use vcap_enable_lookups() with false arg to free the vcap enabled
port as other drivers do it. And use vcap_del_rule() to
free the duprule.
unreferenced object 0xffff677a0278bb00 (size 64):
comm "kunit_try_catch", pid 388, jiffies 4294895987 (age 1101.840s)
hex dump (first 32 bytes):
18 bd a5 82 00 80 ff ff 18 bd a5 82 00 80 ff ff ................
40 fe c8 0e be c6 ff ff 00 00 00 00 00 00 00 00 @...............
backtrace:
[<000000007d53023a>] slab_post_alloc_hook+0xb8/0x368
[<0000000076e3f654>] __kmem_cache_alloc_node+0x174/0x290
[<0000000034d76721>] kmalloc_trace+0x40/0x164
[<00000000013380a5>] vcap_enable_lookups+0x1c8/0x70c
[<00000000bbec496b>] vcap_api_encode_rule_test+0x2f8/0xb18
[<000000002c2bfb7b>] kunit_try_run_case+0x50/0xac
[<00000000ff74642b>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<000000004af845ca>] kthread+0x124/0x130
[<0000000038a000ca>] ret_from_fork+0x10/0x20
unreferenced object 0xffff677a027803c0 (size 192):
comm "kunit_try_catch", pid 388, jiffies 4294895988 (age 1101.836s)
hex dump (first 32 bytes):
00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d...
00 00 00 00 00 00 00 00 d8 03 78 02 7a 67 ff ff ..........x.zg..
backtrace:
[<000000007d53023a>] slab_post_alloc_hook+0xb8/0x368
[<0000000076e3f654>] __kmem_cache_alloc_node+0x174/0x290
[<0000000034d76721>] kmalloc_trace+0x40/0x164
[<00000000c1010131>] vcap_dup_rule+0x34/0x14c
[<00000000d43c54a4>] vcap_add_rule+0x29c/0x32c
[<0000000073f1c26d>] vcap_api_encode_rule_test+0x304/0xb18
[<000000002c2bfb7b>] kunit_try_run_case+0x50/0xac
[<00000000ff74642b>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<000000004af845ca>] kthread+0x124/0x130
[<0000000038a000ca>] ret_from_fork+0x10/0x20
Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the field which
is allocated by kzalloc in vcap_rule_add_action() of
vcap_rule_add_action_bit/u32() is not freed, and it cause
the memory leaks below.
unreferenced object 0xffff0276c496b300 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.072s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<00000000ae66c16c>] vcap_api_rule_add_actionvalue_test+0xa4/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b2c0 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.072s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
3c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 <...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<00000000607782aa>] vcap_api_rule_add_actionvalue_test+0x100/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b280 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.072s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<000000004e640602>] vcap_api_rule_add_actionvalue_test+0x15c/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b240 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.092s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
5a 00 00 00 01 00 00 00 32 54 76 98 00 00 00 00 Z.......2Tv.....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<0000000011141bf8>] vcap_api_rule_add_actionvalue_test+0x1bc/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b200 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.092s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
28 00 00 00 01 00 00 00 dd cc bb aa 00 00 00 00 (...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<00000000d5ed3088>] vcap_api_rule_add_actionvalue_test+0x22c/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the field which
is allocated by kzalloc in vcap_rule_add_key() of
vcap_rule_add_key_bit/u32/u128() is not freed, and it cause
the memory leaks below.
unreferenced object 0xffff0276c14b7240 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894220 (age 920.072s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
67 00 00 00 00 00 00 00 00 01 37 2b af ab ff ff g.........7+....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<00000000ff8002d3>] vcap_api_rule_add_keyvalue_test+0x100/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b7280 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.068s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
67 00 00 00 00 00 00 00 01 01 37 2b af ab ff ff g.........7+....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<00000000f5ac9dc7>] vcap_api_rule_add_keyvalue_test+0x168/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b72c0 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.068s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
67 00 00 00 00 00 00 00 00 00 37 2b af ab ff ff g.........7+....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<00000000c918ae7f>] vcap_api_rule_add_keyvalue_test+0x1d0/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b7300 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.084s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
7d 00 00 00 01 00 00 00 32 54 76 98 ab ff 00 ff }.......2Tv.....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<0000000003352814>] vcap_api_rule_add_keyvalue_test+0x240/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b7340 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.084s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
51 00 00 00 07 00 00 00 17 26 35 44 63 62 71 00 Q........&5Dcbq.
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<000000001516f109>] vcap_api_rule_add_keyvalue_test+0x2cc/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In cxl_port_setup_targets() the region driver validates the
configuration of auto-discovered region decoders, as well
as decoders the driver is preparing to program.
The existing calculations use the encoded interleave granularity
value to create an interleave granularity that properly fans out
when routing an x1 interleave to a greater than x1 interleave.
That all worked well, until this config came along:
Host Bridge: 2 way at 256 granularity
Switch Decoder_A: 1 way at 512
Endpoint_X: 2 way at 256
Switch Decoder_B: 1 way at 512
Endpoint_Y: 2 way at 256
When the Host Bridge interleave is greater than 1 and the root
decoder interleave is exactly 1, the region driver needs to
consider the number of targets in the region when calculating
the expected granularity.
While examining the existing logic, and trying to cover the case
above, a couple of simplifications appeared, hence this proposed
refactoring.
The first simplification is to apply the logic to the nominal
values and use the existing helper function granularity_to_eig() to
translate the desired granularity to the encoded form. This means
the comment and code regarding setting address bits is discarded.
Although that logic is not wrong, it adds a level of complexity that
is not required in the granularity selection. The eig and eiw are
indeed part of the routing instructions programmed into the decoders.
Up-level the discussion to nominal ways and granularity for clearer
analysis.
The second simplification reduces the logic to a single granularity
calculation that works for all cases. The new calculation doesn't
care if parent_iw => 1 because parent_iw is used as a multiplier.
The refactor cleans up a useless assignment of eiw made after the
iw is already calculated.
Regression testing included an examination of all of the ways and
granularity selections made during a run of the cxl_test unit tests.
There were no differences in selections before and after this patch.
Fixes: ("27b3f8d13830 cxl/region: Program target lists")
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20230822180928.117596-1-alison.schofield@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Currently, when the region driver attaches a region to a port, it
selects the ports next available decoder to program.
With the addition of auto-discovered regions, a port decoder has
already been programmed so grabbing the next available decoder can
be a mismatch when there is more than one region using the port.
The failure appears like this with CXL DEBUG enabled:
[] cxl_core:alloc_region_ref:754: cxl region0: endpoint9: HPA order violation region0:[mem 0x14780000000-0x1478fffffff flags 0x200] vs [mem 0x880000000-0x185fffffff flags 0x200]
[] cxl_core:cxl_port_attach_region:972: cxl region0: endpoint9: failed to allocate region reference
When CXL DEBUG is not enabled, there is no failure message. The region
just never materializes. Users can suspect this issue if they know their
firmware has programmed decoders so that more than one region is using
a port. Note that the problem may appear intermittently, ie not on
every reboot.
Add a matching method for auto-discovered regions that finds a decoder
based on an HPA range. The decoder range must exactly match the region
resource parameter.
Fixes: a32320b71f08 ("cxl/region: Add region autodiscovery")
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20230905211007.256385-1-alison.schofield@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Fix indentation and other code style issues in the comm.c file.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202309150646.n3iBvbPj-lkp@intel.com/
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
When a CRC error occurs, the HBA asserts an interrupt to indicate an
interface fatal error (PxIS.IFS). The ISR clears PxIE and PxIS, then
does error recovery. If the adapter receives another SDB FIS
with an error (PxIS.TFES) from the device before the start of the EH
recovery process, the interrupt signaling the new SDB cannot be
serviced as PxIE was cleared already. This in turn results in the HBA
inability to issue any command during the error recovery process after
setting PxCMD.ST to 1 because PxIS.TFES is still set.
According to AHCI 1.3.1 specifications section 6.2.2, fatal errors
notified by setting PxIS.HBFS, PxIS.HBDS, PxIS.IFS or PxIS.TFES will
cause the HBA to enter the ERR:Fatal state. In this state, the HBA
shall not issue any new commands.
To avoid this situation, introduce the function
ahci_port_clear_pending_irq() to clear pending interrupts before
executing a COMRESET. This follows the AHCI 1.3.1 - section 6.2.2.2
specification.
Signed-off-by: Szuying Chen <Chloe_Chen@asmedia.com.tw>
Fixes: e0bfd149973d ("[PATCH] ahci: stop engine during hard reset")
Cc: stable@vger.kernel.org
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Short summary of fixes pull:
* radeon: Uninterruptible fence waiting
* tests: Fix use-after-free bug
* vkms: Revert hrtimer fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230914122649.GA28252@linux-uq9g
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
- Only check eDP HPD when AUX CH is shared.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ZQL+NqtIZH5F/Nxr@intel.com
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-6.6-2023-09-13:
amdgpu:
- GC 9.4.3 fixes
- Fix white screen issues with S/G display on system with >= 64G of ram
- Replay fixes
- SMU 13.0.6 fixes
- AUX backlight fix
- NBIO 4.3 SR-IOV fixes for HDP
- RAS fixes
- DP MST resume fix
- Fix segfault on systems with no vbios
- DPIA fixes
amdkfd:
- CWSR grace period fix
- Unaligned doorbell fix
- CRIU fix for GFX11
- Add missing TLB flush on gfx10 and newer
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230913195009.7714-1-alexander.deucher@amd.com
|
|
Pull NVMe fixes from Keith:
"nvme fixes for Linux 6.6
- nvme-tcp iov len fix (Varun)
- nvme-hwmon const qualifier for safety (Krzysztof)
- nvme-fc null pointer checks (Nigel)
- nvme-pci no numa node fix (Pratyush)
- nvme timeout fix for non-compliant controllers (Keith)"
* tag 'nvme-6.6-2023-09-14' of git://git.infradead.org/nvme:
nvme: avoid bogus CRTO values
nvme-pci: do not set the NUMA node of device if it has none
nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()
nvme: host: hwmon: constify pointers to hwmon_channel_info
nvmet-tcp: pass iov_len instead of sg->length to bvec_set_page()
|
|
The WARN_ONCE was issued also in cases that had nothing to do with VM_IO
(e.g. if the start address was just a random value and uaccess fails with
-EFAULT).
There are no reports of WARN_ONCE being issued for actual VM_IO cases, so
just drop it and instead add a note to the comment before the function.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reported-by: Yikebaer Aizezi <yikebaer61@gmail.com>
|
|
If the index provided by the user is bigger than the mask size, we might do
an out of bound read.
CC: stable@kernel.org
Fixes: 40140eda661e ("media: uvcvideo: Implement mask for V4L2_CTRL_TYPE_MENU")
Reported-by: Zubin Mithra <zsm@chromium.org>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
Do not turn on the vcr_hack based on the btv->field value.
This was a change in the bttv vb2 conversion that caused
green lines at the bottom of the picture in tvtime.
It was originally added to the vb2 conversion based on
faulty information that without this there would be glitches
in the video. However, later tests suggest that this is a
problem in the utilities used to test this since tvtime
behaves fine.
This patch reverts the bttv driver to the original pre-vb2
behavior w.r.t. vcr_hack.
Fixes: b7ec3212a73a ("media: bttv: convert to vb2")
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
The commit in Fixes has removed an fwnode_handle_put() call in the error
handling path of the probe.
Remove the same call from the remove function.
Fixes: 1029939b3782 ("media: v4l: async: Simplify async sub-device fwnode matching")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
The .set_fmt() handler tries to avoid updating the sensor configuration
when the mode hasn't changed. It does so by comparing both the mode and
the media bus code. While the latter correctly uses the media bus code
stored in the subdev state, the former compares the mode being set with
the active mode, regardless of whether .set_fmt() is called for the
ACTIVE or TRY format. This can lead to .set_fmt() returning early when
operating on TRY formats.
This could be fixed by replacing the mode comparison with width and
height comparisons, using the frame size stored in the subdev state.
However, the optimization that avoids updates to the sensor
configuration is not very useful, and is not commonly found in sensor
drivers. To improve consistency across sensor drivers, it is better, in
addition to being easier, to simply drop it. Do so.
Fixes: e8a5b1df000e ("media: i2c: imx219: Use subdev active state")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
When moving the imx219 driver to the subdev active state, commit
e8a5b1df000e ("media: i2c: imx219: Use subdev active state") used the
pad crop rectangle stored in the subdev state to report the crop
rectangle of the active mode. That crop rectangle was however not set in
the state when setting the format, which resulted in reporting an
incorrect crop rectangle to userspace. Fix it.
Fixes: e8a5b1df000e ("media: i2c: imx219: Use subdev active state")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
The imx219_init_cfg() function has stopped operating on the try format
since commit 7e700847b1fe ("media: i2c: imx219: Switch from open to
init_cfg"), but a comment in the function wasn't updated. Fix it.
While at it, improve spelling in a second comment in the function.
Fixes: 7e700847b1fe ("media: i2c: imx219: Switch from open to init_cfg")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
The commit in Fixes has removed an fwnode_handle_put() call in the error
handling path of max9286_v4l2_register().
Remove the same call from max9286_v4l2_unregister().
Fixes: 1029939b3782 ("media: v4l: async: Simplify async sub-device fwnode matching")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
