[BUG]
When running btrfs/004 with 4K fs block size and 64K page size,
sometimes fsstress workload can take 100% CPU for a while, but not long
enough to trigger a 120s hang warning.
[CAUSE]
When such 100% CPU usage happens, btrfs_punch_hole_lock_range() is
always in the call trace.
One example when this problem happens, the function
btrfs_punch_hole_lock_range() got the following parameters:
lock_start = 4096, lockend = 20469
Then we calculate @page_lockstart by rounding up lock_start to page
boundary, which is 64K (page size is 64K).
For @page_lockend, we round down the value towards page boundary, which
result 0. Then since we need to pass an inclusive end to
filemap_range_has_page(), we subtract 1 from the rounded down value,
resulting in (u64)-1.
In the above case, the range is inside the same page, and we do not even
need to call filemap_range_has_page(), not to mention to call it with
(u64)-1 at the end.
This behavior will cause btrfs_punch_hole_lock_range() to busy loop
waiting for irrelevant range to have its pages dropped.
[FIX]
Calculate @page_lockend by just rounding down @lockend, without
decreasing the value by one. So @page_lockend will no longer overflow.
Then exit early if @page_lockend is no larger than @page_lockstart.
As it means either the range is inside the same page, or the two pages
are adjacent already.
Finally only decrease @page_lockend when calling filemap_range_has_page().
Fixes: 0528476b6a ("btrfs: fix the filemap_range_has_page() call in btrfs_punch_hole_lock_range()")
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Inside the macro, subpage_calc_start_bit(), we need to calculate the
offset to the beginning of the folio.
But we're using offset_in_page(), on systems with 4K page size and 4K fs
block size, this means we will always return offset 0 for a large folio,
causing all kinds of errors.
Fix it by using offset_in_folio() instead.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
RZ/G2L General PWM Timer (GPT) composed of 8 channels with 32-bit timer
(GPT32E). It supports the following functions
* 32 bits x 8 channels
* Up-counting or down-counting (saw waves) or up/down-counting
(triangle waves) for each counter.
* Clock sources independently selectable for each channel
* Two I/O pins per channel
* Two output compare/input capture registers per channel
* For the two output compare/input capture registers of each channel,
four registers are provided as buffer registers and are capable of
operating as comparison registers when buffering is not in use.
* In output compare operation, buffer switching can be at crests or
troughs, enabling the generation of laterally asymmetric PWM waveforms.
* Registers for setting up frame cycles in each channel (with capability
for generating interrupts at overflow or underflow)
* Generation of dead times in PWM operation
* Synchronous starting, stopping and clearing counters for arbitrary
channels
* Starting, stopping, clearing and up/down counters in response to input
level comparison
* Starting, clearing, stopping and up/down counters in response to a
maximum of four external triggers
* Output pin disable function by dead time error and detected
short-circuits between output pins
* A/D converter start triggers can be generated (GPT32E0 to GPT32E3)
* Enables the noise filter for input capture and external trigger
operation
Add basic pwm support for RZ/G2L GPT driver by creating separate
logical channels for each IOs.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20250226144531.176819-4-biju.das.jz@bp.renesas.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Better explain how pwm_round_waveform_might_sleep() (and so the
respective lowlevel driver callback) is supposed to round and the
meaning of the return value.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/db84abf1e82e4498fc0e7c318d2673771d0039fe.1744120697.git.ukleinek@kernel.org
[ukleinek: Fix a rst formatting issue reported by Stephen Rothwell]
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
There is a copy and paste bug so we accidentally returned
PTR_ERR(ddata->clk) instead of "ret".
Fixes: 2b62c89448 ("pwm: Add Loongson PWM controller support")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Binbin Zhou <zhoubinbin@loongson.cn>
Link: https://lore.kernel.org/r/6965a480-745c-426f-b17b-e96af532578f@stanley.mountain
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Several issues with this change:
* The analysis is flawed and it's unclear what problem is being
fixed. There is no difference between wait_event_freezable_timeout()
and wait_event_timeout() with respect to device interrupts. And of
course "the interrupt notifying the finish of an operation happens
during wait_event_freezable_timeout()" -- that's how it's supposed
to work.
* The link at the "Closes:" tag appears to be an unrelated
use-after-free in idxd.
* It introduces a regression: dmatest threads are meant to be
freezable and this change breaks that.
See discussion here:
https://lore.kernel.org/dmaengine/878qpa13fe.fsf@AUSNATLYNCH.amd.com/
Fixes: e87ca16e99 ("dmaengine: dmatest: Fix dmatest waiting less when interrupted")
Signed-off-by: Nathan Lynch <nathan.lynch@amd.com>
Link: https://lore.kernel.org/r/20250403-dmaengine-dmatest-revert-waiting-less-v1-1-8227c5a3d7c8@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
If USB3.x device references USB4 host interface, USB4 port can be
connected with appropriate Type-C port. By using component framework,
and in turn by creating symlinks, userspace can benefit from having
Thunderbolt/USB4 connection to Type-C ports.
Note: This change introduces dependency on Thunderbolt driver as it's
required to properly map USB4 port to Type-C port.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This function checks whether given USB4 port device matches with USB3.x
port device, using ACPI _DSD property.
It is designed to be used by component framework to match
USB4 ports with Type-C ports they are connected to.
Also, added USB4 config stub in case mapping function is not reachable.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Make usb4_port_index() available to other files in the driver, rename
and add function documentation.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cleans up the comments in both the c and the h file.
Standardises the comment type (/* */) and the indentation.
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://lore.kernel.org/r/20250415151246.30337-1-rubenru09@aol.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The blamed commit exposes a possible issue with flow_offload_teardown():
We might remove the offload bit of a conntrack entry that has been
offloaded again.
1. conntrack entry c1 is offloaded via flow f1 (f1->ct == c1).
2. f1 times out and is pushed back to slowpath, c1 offload bit is
removed. Due to bug, f1 is not unlinked from rhashtable right away.
3. a new packet arrives for the flow and re-offload is triggered, i.e.
f2->ct == c1. This is because lookup in flowtable skip entries with
teardown bit set.
4. Next flowtable gc cycle finds f1 again
5. flow_offload_teardown() is called again for f1 and c1 offload bit is
removed again, even though we have f2 referencing the same entry.
This is harmless, but clearly not correct.
Fix the bug that exposes this: set 'teardown = true' to have the gc
callback unlink the flowtable entry from the table right away instead of
the unintentional defer to the next round.
Also prevent flow_offload_teardown() from fixing up the ct state more than
once: We could also be called from the data path or a notifier, not only
from the flowtable gc callback.
NF_FLOW_TEARDOWN can never be unset, so we can use it as synchronization
point: if we observe did not see a 0 -> 1 transition, then another CPU
is already doing the ct state fixups for us.
Fixes: 03428ca5ce ("netfilter: conntrack: rework offload nf_conn timeout extension logic")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Resolved duplicate entry for IbaSPollBit vs IbaSpollBit.
Correct CamelCase for IBA enums
Adhere to Linux kernel coding style.
Reported by checkpatch
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250416203259.7862-2-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Removing gpib_interface_t to adhere to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-19-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-18-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-17-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-16-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-15-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-14-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-13-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-12-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-11-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-10-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-9-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-8-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-7-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-6-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-5-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-4-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for struct gpib_interface.
Adhering to Linux code style.
Reported by checkpatch.pl
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-3-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"Having the word "_struct" in the name of the struct doesn't add any
information so rename "struct gpib_interface_struct" to
"struct gpib_interface".
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Link: https://lore.kernel.org/r/20250417003246.84445-2-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix and improve documentation related to landlock_restrict_self(2)'s
flags. Update the LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF
documentation according to the current semantic.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Link: https://lore.kernel.org/r/20250416154716.1799902-3-mic@digikod.net
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Fix, deduplicate, and improve rendering of landlock_restrict_self(2)'s
flags documentation.
The flags are now rendered like the syscall's parameters and
description.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Link: https://lore.kernel.org/r/20250416154716.1799902-2-mic@digikod.net
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Move and fix the flags documentation, and improve formatting.
It makes more sense and it eases maintenance to document syscall flags
in landlock.h, where they are defined. This is already the case for
landlock_restrict_self(2)'s flags.
The flags are now rendered like the syscall's parameters and
description.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Link: https://lore.kernel.org/r/20250416154716.1799902-1-mic@digikod.net
Signed-off-by: Mickaël Salaün <mic@digikod.net>
