The range of valid CPUs is [0, nr_cpu_ids). Some cpumask functions are
passed with a shifted CPU index, and for them, the valid range is
[-1, nr_cpu_ids-1). Currently for those functions, we check the index
against [-1, nr_cpu_ids), which is wrong.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Moving an iterator of the macros inside conditional part of for-loop
helps to generate a better code. It had been first implemented in commit
7baac8b91f ("cpumask: make for_each_cpu_mask a bit smaller").
Now that cpumask for-loops are the aliases to bitmap loops, it's worth
to optimize them the same way.
Bloat-o-meter says:
add/remove: 8/12 grow/shrink: 147/592 up/down: 4876/-24416 (-19540)
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Add for_each_set_bit_wrap() macro and use it in for_each_cpu_wrap(). The
new macro is based on __for_each_wrap() iterator, which is simpler and
smaller than cpumask_next_wrap().
Signed-off-by: Yury Norov <yury.norov@gmail.com>
The helper is better optimized for the worst case: in case of empty
cpumask, current code traverses 2 * size:
next = cpumask_next_and(prev, src1p, src2p);
if (next >= nr_cpu_ids)
next = cpumask_first_and(src1p, src2p);
At bitmap level we can stop earlier after checking 'size + offset' bits.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
The difference between for_each_cpu() and for_each_set_bit()
is that the latter uses cpumask_next() instead of find_next_bit(),
and so calls cpumask_check().
This check is useless because the iterator value is not provided by
user. It generates false-positives for the very last iteration
of for_each_cpu().
Signed-off-by: Yury Norov <yury.norov@gmail.com>
The functions require to be passed with a cpu index prior to one that is
the first to start search, so the valid input range is [-1, nr_cpu_ids-1).
However, the code checks against [-1, nr_cpu_ids).
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Pull USB/Thunderbolt fixes from Greg KH:
"Here are some tiny USB and Thunderbolt driver fixes and quirks.
Included in here are:
- three uas/usb-storage driver quirks to get the devices working
properly due to broken firmware images in them (they can not run at
high data rates, and are also throttled on other operating systems
because of this)
- thunderbolt bugfix for plug event delays
- typec runtime warning removal
- dwc3 st driver bugfix. Note, a follow-on fix for this will end up
coming in for 6.1-rc1 as the developers are still arguing over what
the final solution will be, but this should be sufficient for now
All of these have been in linux-next with no reported problems"
* tag 'usb-6.0-final' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
uas: ignore UAS for Thinkplus chips
usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS
uas: add no-uas quirk for Hiksemi usb_disk
usb: dwc3: st: Fix node's child name
usb: typec: ucsi: Remove incorrect warning
thunderbolt: Explicitly reset plug events delay back to USB4 spec value
Johan writes:
"USB-serial fixes for 6.0-rc8
Here's one more modem device id for 6.0-rc8/final.
All have been in linux-next with no reported issues."
* tag 'usb-serial-6.0-rc8' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: qcserial: add new usb-id for Dell branded EM7455
Pull media fixes from Mauro Carvalho Chehab:
- some fixes for the v4l2 ioctl handler logic
- a fix for an out of bound access in the DVB videobuf2 handler
- three driver fixes (rkvdec, mediatek/vcodek and uvcvideo)
* tag 'media/v6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
media: rkvdec: Disable H.264 error detection
media: mediatek: vcodec: Drop platform_get_resource(IORESOURCE_IRQ)
media: dvb_vb2: fix possible out of bound access
media: v4l2-ioctl.c: fix incorrect error path
media: v4l2-compat-ioctl32.c: zero buffer passed to v4l2_compat_get_array_args()
media: uvcvideo: Fix InterfaceProtocol for Quanta camera
Pull more hotfixes from Andrew Morton:
"One MAINTAINERS update, two MM fixes, both cc:stable"
The previous pull wasn't fated to be the last one..
* tag 'mm-hotfixes-stable-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
damon/sysfs: fix possible memleak on damon_sysfs_add_target
mm: fix BUG splat with kvmalloc + GFP_ATOMIC
MAINTAINERS: drop entry to removed file in ARM/RISCPC ARCHITECTURE
Nearly all other firmware environments have some way of passing a RNG
seed to initialize the RNG: DTB's rng-seed, EFI's RNG protocol, m68k's
bootinfo block, x86's setup_data, and so forth. This adds something
similar for MIPS, which will allow various firmware environments,
bootloaders, and hypervisors to pass an RNG seed to initialize the
kernel's RNG.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Counterintuitively, mod_timer(..., jiffies + 1) will cause the timer to
fire not in the next jiffy, but in two jiffies. The way to cause
the timer to fire in the next jiffy is with mod_timer(..., jiffies).
Doing so then lets us bump the upper bound back up again.
Fixes: 50ee7529ec ("random: try to actively add entropy rather than passively wait for it")
Fixes: 829d680e82 ("random: cap jitter samples per bit to factor of HZ")
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* kvm-arm64/misc-6.1:
: .
: Misc KVM/arm64 fixes and improvement for v6.1
:
: - Simplify the affinity check when moving a GICv3 collection
:
: - Tone down the shouting when kvm-arm.mode=protected is passed
: to a guest
:
: - Fix various comments
:
: - Advertise the new kvmarm@lists.linux.dev and deprecate the
: old Columbia list
: .
KVM: arm64: Advertise new kvmarm mailing list
KVM: arm64: Fix comment typo in nvhe/switch.c
KVM: selftests: Update top-of-file comment in psci_test
KVM: arm64: Ignore kvm-arm.mode if !is_hyp_mode_available()
KVM: arm64: vgic: Remove duplicate check in update_affinity_collection()
Signed-off-by: Marc Zyngier <maz@kernel.org>
* kvm-arm64/dirty-log-ordered:
: .
: Retrofit some ordering into the existing API dirty-ring by:
:
: - relying on acquire/release semantics which are the default on x86,
: but need to be explicit on arm64
:
: - adding a new capability that indicate which flavor is supported, either
: with explicit ordering (arm64) or both implicit and explicit (x86),
: as suggested by Paolo at KVM Forum
:
: - documenting the requirements for this new capability on weakly ordered
: architectures
:
: - updating the selftests to do the right thing
: .
KVM: selftests: dirty-log: Use KVM_CAP_DIRTY_LOG_RING_ACQ_REL if available
KVM: selftests: dirty-log: Upgrade flag accesses to acquire/release semantics
KVM: Document weakly ordered architecture requirements for dirty ring
KVM: x86: Select CONFIG_HAVE_KVM_DIRTY_RING_ACQ_REL
KVM: Add KVM_CAP_DIRTY_LOG_RING_ACQ_REL capability and config option
KVM: Use acquire/release semantics when accessing dirty ring GFN state
Signed-off-by: Marc Zyngier <maz@kernel.org>
As announced on the kvmarm list, we're moving the mailing list over
to kvmarm@lists.linux.dev:
<quote>
As you probably all know, the kvmarm mailing has been hosted on
Columbia's machines for as long as the project existed (over 13
years). After all this time, the university has decided to retire the
list infrastructure and asked us to find a new hosting.
A new mailing list has been created on lists.linux.dev[1], and I'm
kindly asking everyone interested in following the KVM/arm64
developments to start subscribing to it (and start posting your
patches there). I hope that people will move over to it quickly enough
that we can soon give Columbia the green light to turn their systems
off.
Note that the new list will only get archived automatically once we
fully switch over, but I'll make sure we fill any gap and not lose any
message. In the meantime, please Cc both lists.
[...]
[1] https://subspace.kernel.org/lists.linux.dev.html
</quote>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221001091245.3900668-1-maz@kernel.org
The HDMI driver skips the notification handling from the graphics
driver when the codec driver is being in the PM operation. This
behavior was introduced by the commit eb399d3c99 ("ALSA: hda - Skip
ELD notification during PM process"). This skip may cause a problem,
as we may miss the ELD update when the connection/disconnection
happens right at the runtime-PM operation of the audio codec.
Although this workaround was valid at that time, it's no longer true;
the fix was required just because the ELD update procedure needed to
wake up the audio codec, which had lead to a runtime-resume during a
runtime-suspend. Meanwhile, the ELD update procedure doesn't need a
codec wake up any longer since the commit 788d441a16 ("ALSA: hda -
Use component ops for i915 HDMI/DP audio jack handling"); i.e. there
is no much reason for skipping the notification.
Let's drop those checks for addressing the missing notification.
Fixes: 788d441a16 ("ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling")
Reported-by: Brent Lu <brent.lu@intel.com>
Link: https://lore.kernel.org/r/20220927135807.4097052-1-brent.lu@intel.com
Link: https://lore.kernel.org/r/20221001074809.7461-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Convert the hid-over-i2c binding to DT schema format. The supplies should
probably be specific to a specific device, but it seems they are already
in use otherwise. 'wakeup-source' is added as it was not explicitly
documented.
There's a few warnings for undocumented properties 'vcc-supply' and
'reset-gpios'. Those remain as they probably should have a specific
compatible as well.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220927150916.1091217-1-robh@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain
space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read
when mounting corrupt file system image.
ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this
three tags will read data during scan, tag length couldn't less than data length
which will read.
Cc: stable@kernel.org
Signed-off-by: Ye Bin <yebin10@huawei.com>
Link: https://lore.kernel.org/r/20220924075233.2315259-4-yebin10@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Now we load the super block from the disk in two steps. First we load
the super block with the default block size(EXT4_MIN_BLOCK_SIZE). Second
we load the super block with the real block size. The second step is a
little far from the first step. This patch move these two steps together
in a new function.
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20220916141527.1012715-15-yanaijie@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The 'cantfind_ext4' error handler is just a error msg print and then
goto failed_mount. This two level goto makes the code complex and not
easy to read. The only benefit is that is saves a little bit code.
However some branches can merge and some branches dot not even need it.
So do some refactor and remove it.
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Link: https://lore.kernel.org/r/20220916141527.1012715-3-yanaijie@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Before these two branches neither loaded the journal nor created the
xattr cache. So the right label to goto is 'failed_mount3a'. Although
this did not cause any issues because the error handler validated if the
pointer is null. However this still made me confused when reading
the code. So it's still worth to modify to goto the right label.
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Link: https://lore.kernel.org/r/20220916141527.1012715-2-yanaijie@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
