Currently we group delayed dir index items for deletion in a single batch
(single btree operation) as long as they all exist in the same leaf and as
long as their keys are sequential in the key space. For example if we have
a leaf that has dir index items with offsets:
2, 3, 4, 6, 7, 10
And we have delayed dir index items for deleting all these indexes, and
no delayed items for any other index keys in between, then we end up
deleting in 3 batches:
1) First batch for indexes 2, 3 and 4;
2) Second batch for indexes 6 and 7;
3) Third batch for index 10.
This is a waste because we can delete all the index keys in a single
batch. What matters is that each consecutive delayed index key matches
each consecutive dir index key in a leaf.
So update the logic at btrfs_batch_delete_items() to check only for a
key match between delayed dir index items and dir index items in a leaf.
Also avoid the useless first iteration on comparing the key of the
first slot to delete with the key of the first delayed item, as it's
silly since they always match, as the delayed item's key was used for
the btree search that gave us the path we have.
This is more efficient and reduces runtime of running delayed items, as
well as lock contention on the subvolume's tree.
For example, the following test script:
$ cat test.sh
#!/bin/bash
DEV=/dev/sdj
MNT=/mnt/sdj
mkfs.btrfs -f $DEV
mount $DEV $MNT
NUM_FILES=1000
mkdir $MNT/testdir
for ((i = 1; i <= $NUM_FILES; i++)); do
echo -n > $MNT/testdir/file_$i
done
# Now delete every other file, to create gaps in the dir index keys.
for ((i = 1; i <= $NUM_FILES; i += 2)); do
rm -f $MNT/testdir/file_$i
done
# Sync to force any delayed items to be flushed to the tree.
sync
start=$(date +%s%N)
rm -fr $MNT/testdir
end=$(date +%s%N)
dur=$(( (end - start) / 1000000 ))
echo -e "\nrm -fr took $dur milliseconds"
umount $MNT
Running that test script while having the following bpftrace script
running in another shell:
$ cat bpf-measure.sh
#!/usr/bin/bpftrace
/* Add 'noinline' to btrfs_delete_delayed_items()'s definition. */
k:btrfs_delete_delayed_items
{
@start_delete_delayed_items[tid] = nsecs;
}
k:btrfs_del_items
/@start_delete_delayed_items[tid]/
{
@delete_batches = count();
}
kr:btrfs_delete_delayed_items
/@start_delete_delayed_items[tid]/
{
$dur = (nsecs - @start_delete_delayed_items[tid]) / 1000;
@btrfs_delete_delayed_items_total_time = sum($dur);
delete(@start_delete_delayed_items[tid]);
}
Before this change:
@btrfs_delete_delayed_items_total_time: 9563
@delete_batches: 1001
After this change:
@btrfs_delete_delayed_items_total_time: 7328
@delete_batches: 509
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The delayed item deletion entry point, btrfs_delete_delayed_items(), is a
bit convoluted for a few reasons:
1) It's really a loop disguised with labels and goto statements;
2) There's a 'delete_fail' label which isn't only for error cases, we can
jump to that label even if no error happened, if we simply don't have
more delayed items to delete;
3) Unnecessarily keeps track of the current and previous items for no
good reason, as after getting the next item and releasing the current
one, it just jumps to the 'again' label just to look again for the
first delayed item;
4) When a delayed item is not in the tree (because it was already deleted
before), it releases the item while holding a path locked, which is
not necessary and adds more contention to the tree, specially taking
into account that the path came from a deletion search, meaning we have
write locks for nodes at levels 2, 1 and 0. And releasing the item is
not computationally trivial (rb tree deletion, a kfree() and some
trivial things).
So refactor it to use a while loop and add some comments to make it more
obvious why we can have delayed items without a matching item in the tree
as well as why not keep the delayed node locked all the time when running
all its deletion items. This is also a preparation for some upcoming work
involving delayed items.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently, btrfs_delete_delayed_items() ignores any errors returned from
btrfs_batch_delete_items(). This looks fishy but it's not a problem at
the moment because:
1) Two of the errors returned from btrfs_batch_delete_items() are for
impossible cases, cases where a delayed item does not match any item
in the leaf the path points to - btrfs_delete_delayed_items() always
calls btrfs_batch_delete_items() with a path that points to a leaf
that contains an item matching a delayed item;
2) btrfs_batch_delete_items() may return an error from btrfs_del_items(),
in which case it does not release the delayed items of the batch.
At the moment this is harmless because btrfs_del_items() actually is
always able to delete items, even if it returns an error - when it
returns an error it's because it ended up with a leaf mostly empty
(less than 1/3 full) and failed to migrate items from that leaf into
its neighbour leaves - this is not critical, as all the items were
deleted, we just left the tree a bit unbalanced, but it's still a
valid tree and causes no harm, and future operations on the tree will
eventually balance it.
So even if we get an error from btrfs_del_items(), the delayed items
will not be released but the next time we run delayed items we will
find out, at btrfs_delete_delayed_items(), that they are not present
in the tree anymore and then release them.
This is all a bit subtle, and it's certainly prone to be a disaster in
case btrfs_del_items() changes one day and may return errors before being
able to delete all the requested items, in which case we could leave the
filesystem in an inconsistent state as we would commit a transaction
despite a failure from deleting items from the tree.
So make btrfs_delete_delayed_items() check for any errors from the call
to btrfs_batch_delete_items().
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There are a few impossible cases that btrfs_batch_delete_items() tries to
deal with:
1) Getting a path pointing to a NULL leaf;
2) The leaf slot is pointing beyond the last item in the leaf;
3) We can't find a single item to delete.
The first case is impossible because the given path was returned by a
successful call to btrfs_search_slot(). Replace the BUG_ON() with an
ASSERT for this.
The second case is impossible because we are always called when a delayed
item matches an item in the given leaf. So add an ASSERT() for that and
if that condition is not satisfied, trigger a warning and return an error.
The third case is impossible exactly because of the same reason as the
second case. The given delayed item matches one item in the leaf, so we
know that our batch always has at least one item. Add an ASSERT to check
that, trigger a warning if that expectation fails and return an error.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When reflinking extents (clone and deduplication), we need to touch the
btree of the destination inode's subvolume, as well as potentially
create a delayed inode for the destination inode (if it was not created
before). However we are neither balancing the btree dirty pages nor the
delayed items after such operations, so if we have a task that is doing
a long series of clone or deduplication operations, it can result in
accumulation of too many btree dirty pages and delayed items.
So just call btrfs_btree_balance_dirty() after clone and deduplication,
just like we do for every other system call that results on modifying a
btree and adding delayed items.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When creating an inode, through btrfs_create_new_inode(), we release the
path we allocated before once we don't need it anymore. But we keep it
allocated until we return from that function, which is wasteful because
after we release the path we do several things that can allocate yet
another path: inheriting properties, setting the xattrs used by ACLs and
secutiry modules, adding an orphan item (O_TMPFILE case) or adding a
dir item (for the non-O_TMPFILE case).
So instead of releasing the path once we don't need it anymore, free it
instead. This way we avoid having two paths allocated until we return
from btrfs_create_new_inode().
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
A rename operation modifies a subvolume's btree, to remove the old dir
item, add the new dir item, remove an inode ref and add a new inode ref.
It can also create the delayed inode for the inodes involved in the
operation, and it creates two delayed dir index items, one to delete
the old name and another one to add the new name.
However we are neither balancing the btree dirty pages nor the delayed
items after a rename, which can result in accumulation of too many
btree dirty pages and delayed items, specially if a task is doing a
series of rename operations (for example it can happen for package
installations/upgrades through the zypper tool).
So just call btrfs_btree_balance_dirty() after a rename, just like we
do for every other system call that results on modifying a btree and
adding delayed items.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add tracepoint for better insight to how the RAID56 data are submitted.
The output looks like this: (trace event header and UUID skipped)
raid56_read_partial: full_stripe=389152768 devid=3 type=DATA1 offset=32768 opf=0x0 physical=323059712 len=32768
raid56_read_partial: full_stripe=389152768 devid=1 type=DATA2 offset=0 opf=0x0 physical=67174400 len=65536
raid56_write_stripe: full_stripe=389152768 devid=3 type=DATA1 offset=0 opf=0x1 physical=323026944 len=32768
raid56_write_stripe: full_stripe=389152768 devid=2 type=PQ1 offset=0 opf=0x1 physical=323026944 len=32768
The above debug output is from a 32K data write into an empty RAID56
data chunk.
Some explanation on the event output:
full_stripe: the logical bytenr of the full stripe
devid: btrfs devid
type: raid stripe type.
DATA1: the first data stripe
DATA2: the second data stripe
PQ1: the P stripe
PQ2: the Q stripe
offset: the offset inside the stripe.
opf: the bio op type
physical: the physical offset the bio is for
len: the length of the bio
The first two lines are from partial RMW read, which is reading the
remaining data stripes from disks.
The last two lines are for full stripe RMW write, which is writing the
involved two 16K stripes (one for DATA1 stripe, one for P stripe).
The stripe for DATA2 doesn't need to be written.
There are 5 types of trace events:
- raid56_read_partial
Read remaining data for regular read/write path.
- raid56_write_stripe
Write the modified stripes for regular read/write path.
- raid56_scrub_read_recover
Read remaining data for scrub recovery path.
- raid56_scrub_write_stripe
Write the modified stripes for scrub path.
- raid56_scrub_read
Read remaining data for scrub path.
Also, since the trace events are included at super.c, we have to export
needed structure definitions to 'raid56.h' and include the header in
super.c, or we're unable to access those members.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
[ reformat comments ]
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
With added debugging, it turns out the following write sequence would
cause extra read which is unnecessary:
# xfs_io -f -s -c "pwrite -b 32k 0 32k" -c "pwrite -b 32k 32k 32k" \
-c "pwrite -b 32k 64k 32k" -c "pwrite -b 32k 96k 32k" \
$mnt/file
The debug message looks like this (btrfs header skipped):
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=0 physical=323026944 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=32768 physical=22052864 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=0 physical=22020096 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=0 physical=277872640 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
^^^^
Still partial read, even 389152768 is already cached by the first.
write.
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=0 physical=22020096 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
^^^^
Still partial read for 298844160.
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=32768 physical=22052864 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=32768 physical=277905408 len=32768
This means every 32K writes, even they are in the same full stripe,
still trigger read for previously cached data.
This would cause extra RAID56 IO, making the btrfs raid56 cache useless.
[CAUSE]
Commit d4e28d9b5f ("btrfs: raid56: make steal_rbio() subpage
compatible") tries to make steal_rbio() subpage compatible, but during
that conversion, there is one thing missing.
We no longer rely on PageUptodate(rbio->stripe_pages[i]), but
rbio->stripe_nsectors[i].uptodate to determine if a sector is uptodate.
This means, previously if we switch the pointer, everything is done,
as the PageUptodate flag is still bound to that page.
But now we have to manually mark the involved sectors uptodate, or later
raid56_rmw_stripe() will find the stolen sector is not uptodate, and
assemble the read bio for it, wasting IO.
[FIX]
We can easily fix the bug, by also update the
rbio->stripe_sectors[].uptodate in steal_rbio().
With this fixed, now the same write pattern no longer leads to the same
unnecessary read:
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=0 physical=323026944 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=32768 physical=22052864 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=0 physical=22020096 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=0 physical=277872640 len=32768
^^^ No more partial read, directly into the write path.
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=32768 physical=22052864 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=32768 physical=277905408 len=32768
Fixes: d4e28d9b5f ("btrfs: raid56: make steal_rbio() subpage compatible")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Both memzero_page and memcpy_to_page already call flush_dcache_page so
we can remove the calls from btrfs code.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David Sterba <dsterba@suse.com>
If we have only 8K partial write at the beginning of a full RAID56
stripe, we will write the following contents:
0 8K 32K 64K
Disk 1 (data): |XX| | |
Disk 2 (data): | | |
Disk 3 (parity): |XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXX|
|X| means the sector will be written back to disk.
Note that, although we won't write any sectors from disk 2, but we will
write the full 64KiB of parity to disk.
This behavior is fine for now, but not for the future (especially for
RAID56J, as we waste quite some space to journal the unused parity
stripes).
So here we will also utilize the btrfs_raid_bio::dbitmap, anytime we
queue a higher level bio into an rbio, we will update rbio::dbitmap to
indicate which vertical stripes we need to writeback.
And at finish_rmw(), we also check dbitmap to see if we need to write
any sector in the vertical stripe.
So after the patch, above example will only lead to the following
writeback pattern:
0 8K 32K 64K
Disk 1 (data): |XX| | |
Disk 2 (data): | | |
Disk 3 (parity): |XX| | |
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Previously we use "unsigned long *" for those two bitmaps.
But since we only support fixed stripe length (64KiB, already checked in
tree-checker), "unsigned long *" is really a waste of memory, while we
can just use "unsigned long".
This saves us 8 bytes in total for scrub_parity.
To be extra safe, add an ASSERT() making sure calclulated @nsectors is
always smaller than BITS_PER_LONG.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Previsouly we use "unsigned long *" for those two bitmaps.
But since we only support fixed stripe length (64KiB, already checked in
tree-checker), "unsigned long *" is really a waste of memory, while we
can just use "unsigned long".
This saves us 8 bytes in total for btrfs_raid_bio.
To be extra safe, add an ASSERT() making sure calculated
@stripe_nsectors is always smaller than BITS_PER_LONG.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This eliminates 2 labels and makes the code generally more streamlined.
Also rename the 'out_bargs' label to 'out_unlock' since bargs is going
to be freed under the 'out' label. This also fixes a memory leak since
bargs wasn't correctly freed in one of the condition which are now moved
in btrfs_try_lock_balance.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This function contains the factored out locking sequence of
btrfs_ioctl_balance. Having this piece of code separate helps to
simplify btrfs_ioctl_balance which has too complicated. This will be
used in the next patch to streamline the logic in btrfs_ioctl_balance.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Use the new btrfs_bio_for_each_sector iterator to simplify
btrfs_check_read_dio_bio.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add a helper that works similar to __bio_for_each_segment, but instead of
iterating over PAGE_SIZE chunks it iterates over each sector.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
[hch: split from a larger patch, and iterate over the offset instead of
the offset bits]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: David Sterba <dsterba@suse.com>
[ add parameter comments ]
Signed-off-by: David Sterba <dsterba@suse.com>
Add a helper to find the csum for a byte offset into the csum buffer.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David Sterba <dsterba@suse.com>
Untangle the goto and move the code it jumps to so it goes in the order
of the most likely states first.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: David Sterba <dsterba@suse.com>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Add a helper to end I/O on a single sector, which will come in handy
with the new read repair code.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The function submit_data_read_repair() is only called for buffered data
read path, thus those members can be calculated using bvec directly:
- start
start = page_offset(bvec->bv_page) + bvec->bv_offset;
- end
end = start + bvec->bv_len - 1;
- page
page = bvec->bv_page;
- pgoff
pgoff = bvec->bv_offset;
Thus we can safely replace those 4 parameters with just one bio_vec.
Also remove the unused return value.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
[hch: also remove the return value]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David Sterba <dsterba@suse.com>
Although we have several data csum verification code, we never have a
function really just to verify checksum for one sector.
Function check_data_csum() do extra work for error reporting, thus it
requires a lot of extra things like file offset, bio_offset etc.
Function btrfs_verify_data_csum() is even worse, it will utilize page
checked flag, which means it can not be utilized for direct IO pages.
Here we introduce a new helper, btrfs_check_sector_csum(), which really
only accept a sector in page, and expected checksum pointer.
We use this function to implement check_data_csum(), and export it for
incoming patch.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
[hch: keep passing the csum array as an arguments, as the callers want
to print it, rename per request]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The following functions do special handling for RAID56 chunks:
- btrfs_is_parity_mirror()
Check if the range is in RAID56 chunks.
- btrfs_full_stripe_len()
Either return sectorsize for non-RAID56 profiles or full stripe length
for RAID56 chunks.
But if a filesystem without any RAID56 chunks, it will not have RAID56
incompat flags, and we can skip the chunk tree looking up completely.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The <linux/mm.h> already provides the PAGE_ALIGNED macro. Let's
use it instead of IS_ALIGNED and passing PAGE_SIZE directly.
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Fanjun Kong <bh1scw@gmail.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Fix the comment to represent the actual logic used for sb_write_pointer
- Empty[0] && In use[1] should be an invalid state instead of returning
zone 0 wp
- Empty[0] && Full[1] should be returning zone 0 wp instead of zone 1 wp
- In use[0] && Empty[1] should be returning zone 0 wp instead of being an
invalid state
- In use[0] && Full[1] should be returning zone 0 wp instead of returning
zone 1 wp
- Full[0] && Empty[1] should be returning zone 1 wp instead of returning
zone 0 wp
- Full[0] && In use[1] should be returning zone 1 wp instead of returning
zone 0 wp
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
enough in order for the LBR MSR access to not #GP
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmLdD5sACgkQEsHwGGHe
VUoaDA//Yiir+zrTjbCOSnma/pgn3wbWQVe2Y1E1+Tj+av3hBuzTdoAqgDDrFTQ7
zKwJBjGRb+yQduFbLpLCD9BittX2yk2WGIP3gvLB0ffCLMKU/NOCSKPDZ+HDtvPE
MkJ1usBLhAYbExgoQVI0Cu9dBL5AR1hKy+ZAw/W7uUhRdR7g9B2gLd1Hg261jmLS
+imOAQiUgbCAl8d7kMk9lB5gCl3j5DZ+FgpCTYWV4n87cvGBIjAESyjhfAKXRwmg
Y7acUtOWB935LleA9su2HCtejeIhRoLlV5qUrc0oMUiM6GSymkd6PBRykQ16kajL
MzKb56daTiK8q4sEhmte0grNNNdyY0nVp2YmvzQ1Cf16Au0XvHIjhLg9WWI+WYmd
rSP1OXrGoUQ9C2Vex008ajIPQFVDCgRV4euzE8CveiBnNzVp6JCScjNlvVpOgaxM
04Yesok4nAhJYSYLg1IWXuF5caOyNODJYRNj18ypt2FCEJdDxuDwqVL8DW/oqFz5
JxTRAuyvojhir/0ztDdMiQ9IkMTjdSboIp1gbjkj0C1J0gJq8Bh9tqNK/uChw58J
UY9rojGnAa2JEXxQ3P5Dj/zSfw5FoCe7VgACrw+lXw0sJ3CKh08ojRjofP4ET+s1
77ru8deYJ4sy0IyGLml6WpA3hWwUvkjxWVx1cdnyeBHW9oc7fGQ=
=nYW6
-----END PGP SIGNATURE-----
Merge tag 'perf_urgent_for_v5.19_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fix from Borislav Petkov:
- Reorganize the perf LBR init code so that a TSX quirk is applied
early enough in order for the LBR MSR access to not #GP
* tag 'perf_urgent_for_v5.19_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel/lbr: Fix unchecked MSR access error on HSW
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmLdDPMACgkQEsHwGGHe
VUqmvRAAjIKW411+4FH0QRS5itqugSSwx6gAqX8muM4dn5B/aY0P3I14ghxrxnTt
QG9XuevCK1i4OpxKcZLALC5fRqLNKr20WAdO+sNJzJYz1krB264bHOy46UY3MuwL
wv2/nTLiR0MQisLfjE8Cdot0bYcTnIyKqSDvdrfBxqmoKo553A8uRTMZl3iPYU+W
e3NhmG0PPzWzSz4y/Autk1GQMHOKcvvcPdsAUI+S2FwiQt/TIZ/Px2152NSV5Q4Y
TIYfN5ylNw4BZxkq9tM3NMrZnrhT4TRihlYDf7PFf3WHDgh5vQmtOUZvLpH/0ZVO
KUGCH2BPpfTVL4WBxfB2ADJWXoudEVb5r00JdI6TI9yYUXUE726BOOs3TwH+xvhP
nGcLGErJcvFMYABMvJ7tLQpcC5561MNnqfRBO3svcVkNRKQb7r7UGqUpoevkpXLw
63G+HxzDFbs0BOwaOr8hjUnhu78hKVjHXr6IbBTjda7P5WNQgTE0a9oD1JiLAJVa
RLupgq0X0FlTQip+EtbOhdGPui1HTDzYbGRoXkOxFBND4Zce9DEIkF1exsnITQat
hsvCdUjhqOX5aOlrKTSVYAi4utYm5GcOU84x4andvg7z9vYDJpqpDXHFtXjF/za9
TIj3W4PXbNHaPsMD7Ph4RF98HDyrrVvwFce4wfx5u9Xrix/lVHE=
=jolV
-----END PGP SIGNATURE-----
Merge tag 'sched_urgent_for_v5.19_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fix from Borislav Petkov:
"A single fix to correct a wrong BUG_ON() condition for deboosted
tasks"
* tag 'sched_urgent_for_v5.19_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/deadline: Fix BUG_ON condition for deboosted tasks
work if even needed, at all).
- Prevent return thunks patching of the LKDTM modules as it is not needed there
- Avoid writing the SPEC_CTRL MSR on every kernel entry on eIBRS parts
- Enhance error output of apply_returns() when it fails to patch a return thunk
- A sparse fix to the sev-guest module
- Protect EFI fw calls by issuing an IBPB on AMD
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmLdCZIACgkQEsHwGGHe
VUpZHw//frU5tCHiP+4UM/kGdrcDxVy+FutkoprrNzhYszkvVGWOU4GOyExjnbXj
cS47AlIAv5o2T+UKN6pwtH1n6Jb+Qf2zsaMlyIcxI7t1PiyddkT9wvrgP52GPNyl
vrxtDVoo1aYF8z7RxTEtjWHzUlfxQTSlo+olQVtW/JYWnqQOPwvPm+bOA+0MBzwA
gbDV2nM1Z0D9ifo536J9P93/HtYwW/fsrutTj0hICxweRGnEN7Gw11Ci+6cT+Rgq
TYO5feaFnnbv0hnfDbWQXAuDVdgi0aJ06CDuoC6U/WmKNpQo2rpjAASVXN/EEQyh
wwy/bqauj8daOpSU/8/hNx1Rwx3gP6FWEzYpylsn3xP7p9y6dWQnBh4i2ZmMhxUt
zbIlwNqSFWluFJaSpOnaPJJVrQbRj03Yb1ynTPCcuTl1K1ydGr03J351K8SfeXqP
bhkecr+BiddFs2Y3udaq/NYJEFRHtbZi3CdDcUulbmEfKOZIQRN0JMSAvR7SH1sZ
4lljsoSCfJgxKmgP9tVhRc19LD6knxTAzVbtjtyuEmsf1dN36rN5r5Y4lc1AN68s
12ymbV0qc/Qh6Cn8x/Cgv3S6kXjYrKdbSQHVnJXsJE0kz/mqyIn3+LChU+PoIvmu
7uGeEouIlDroBgT5WWFWnTgxujFPZD6O2rPsJwOXvTkp9uDof4Q=
=aSDG
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_v5.19_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Borislav Petkov:
"A couple more retbleed fallout fixes.
It looks like their urgency is decreasing so it seems like we've
managed to catch whatever snafus the limited -rc testing has exposed.
Maybe we're getting ready... :)
- Make retbleed mitigations 64-bit only (32-bit will need a bit more
work if even needed, at all).
- Prevent return thunks patching of the LKDTM modules as it is not
needed there
- Avoid writing the SPEC_CTRL MSR on every kernel entry on eIBRS
parts
- Enhance error output of apply_returns() when it fails to patch a
return thunk
- A sparse fix to the sev-guest module
- Protect EFI fw calls by issuing an IBPB on AMD"
* tag 'x86_urgent_for_v5.19_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/speculation: Make all RETbleed mitigations 64-bit only
lkdtm: Disable return thunks in rodata.c
x86/bugs: Warn when "ibrs" mitigation is selected on Enhanced IBRS parts
x86/alternative: Report missing return thunk details
virt: sev-guest: Pass the appropriate argument type to iounmap()
x86/amd: Use IBPB for firmware calls
driver.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmLc550RHHNib3lkQGtl
cm5lbC5vcmcACgkQrQKIl8bklSW8+xAAwGwZqEpUihrJLYr8wiiXml6cR2mKm9of
tSFlCmwkheAqUONXo/3PikOx3gYRXVP2ATYLic4PkHYPU6znXyzEq7Z3BrOXBSnV
uT8m+mTDF20FqZjEJrzKLc2y2vdOYyyQ9dmxYv/A9YzAWKPq1lEp3nsJjHq4d5hB
vEsofDUJ8Bxy3xW97CQs+OEJVwJaLEVOg8samhxAgbfrTUHqxyNMlbRzR4xU595x
/nRE/47FBEQovCnvqzGiRAw5UHdB/82QQvJ4GxMdqTlraDKrSvkvXj6ncGWVaNwu
/5ixQShXRcpPyBX0F0TRa2ROd/RlRubHchRsku7ysU5/yKSzn0z/FNPd+eZqOnP3
pJFIWDj6xtMCJwkUQFchPKCyPHGuF4K8XER9QLIMcl3hbaNvCbxBfJZmZnLfXsNL
b0+/xdImVPV0eEu7D0EXGZ8RuPY5YdV+a6ZUMuc5XnCgfSmuy4UR21WFW9ZUkJFP
8y7c2kWU5eHxDn4qD9bH3Of0v2Y5BJ+VK7u3Ixz9elarlbESxQFU1r6Jl0cCfltw
DZit48b+g2yEmxZORUO3t7pBQ5TTDIoWvEz+LGNG2EXXPzU0O3LmGM2uEaeNE/Jl
qeJJgwtIskm62Y6pOdDLYqAjQMS3bFvWVbXUJKajS1HhETtACA7RZ8bQ397lm8wS
YaVQbIhG+FA=
=cFGt
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fix from Stephen Boyd:
"One more fix to set the correct IO mapping for a clk gate in the
lan966x driver"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: lan966x: Fix the lan966x clock gate register address
* Fix use of sched_setaffinity in selftests
* Sync kernel headers to tools
* Fix KVM_STATS_UNIT_MAX
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmLaTFwUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroO5Dwf/bRHhFs7XXdC5YU687bEFq/8/XCbY
wczM6cEIsWk0chzx92xIXzjb6DKPhrUFjGNH2C55XhLwHhCCUI+Q0zCfZ89ghjdX
Fe3fNcs6SAq6aLPjRBkk0+vt1jq233KzIV/GQJ5FivocPlWX562FXVEXoB/T26Ml
ljTmtPBn4Hd+LIE+7+HED2qCNzvNYtx3KGGTsZR7hcjoQmfFjXg+OTN0Uqsa+enW
lCEcN/gDMaTWFxY7lII63IJA4mE4WkdfYWjzuzvfUFsNU0IQZk+NrVZpiAP9zXeS
20o9nzetS7h1enLWqdGvJ+m5ot19l24nJeWZ8QQsS3T4XF2h7vL0lY/WBg==
=BDnJ
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
- Check for invalid flags to KVM_CAP_X86_USER_SPACE_MSR
- Fix use of sched_setaffinity in selftests
- Sync kernel headers to tools
- Fix KVM_STATS_UNIT_MAX
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Protect the unused bits in MSR exiting flags
tools headers UAPI: Sync linux/kvm.h with the kernel sources
KVM: selftests: Fix target thread to be migrated in rseq_test
KVM: stats: Fix value for KVM_STATS_UNIT_MAX for boolean stats
The mitigations for RETBleed are currently ineffective on x86_32 since
entry_32.S does not use the required macros. However, for an x86_32
target, the kconfig symbols for them are still enabled by default and
/sys/devices/system/cpu/vulnerabilities/retbleed will wrongly report
that mitigations are in place.
Make all of these symbols depend on X86_64, and only enable RETHUNK by
default on X86_64.
Fixes: f43b9876e8 ("x86/retbleed: Add fine grained Kconfig knobs")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/YtwSR3NNsWp1ohfV@decadent.org.uk
A few more small driver specific fixes, this is obviously rather late
and if you think it's best to leave these until the next release that
would be reasonable.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmLbILwACgkQJNaLcl1U
h9Dd8Af/SQFOeYWyeMFUO0woaPB5qV/RYxO2blUUwWD4l54Io21qW/oh1zv6jbGI
p6L11hDQBaGvWKf85wZLNeKHXeSJU9Mi38PXMUBY8IYrsjT7ytHpdgPRUKslA6BT
Tg2FLNX609FdQosrbN9axjl2DSKoOLi1bZPhoA6pipwuHIbJINXdZGsbrVcwMXhK
iFzEK1ay3qyDmvaOlnlTQjFKRyKs/PGsTD8Co8DEo9jPaFB+0VRoeaq1PwvVEurf
wBBl2gdJdVoDGHrh1hZ0Q/9eKQ5Xc+/xfNT6jOJ3X1TzWtAbnXOeBAwtqTde0j8N
he7CmrsREU+yDfeN8X2i/PmdEi8/Mg==
=Bkey
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v5.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A few more small driver specific fixes"
* tag 'spi-fix-v5.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: spi-rspi: Fix PIO fallback on RZ platforms
spi: spi-cadence: Fix SPI NO Slave Select macro definition
spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers
* Two kexec-related build fixes.
* A DTS update to make the GPIO nodes match the upcoming dtschema.
* A fix that passes -mno-relax directly to the assembler when building
modules, to work around compilers that fail to do so.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEAM520YNJYN/OiG3470yhUCzLq0EFAmLavNcTHHBhbG1lckBk
YWJiZWx0LmNvbQAKCRDvTKFQLMurQfHKD/453cUPBewpQdepY6gKfT6cdGzV7oq6
/faitxnGZwotX2Z5TxN8rTBS7GmuLhfh2IE+zWsMaeNPK+W7pTx4eRMpTkTSbAh3
OpHpx0sy3zbdvMr4g3L4CtGvkBCfDjyxwnYu4djoWl6lj0jbFIvVwSSM0Dnbmzxv
G14p+7QzTzUPO6sGCRVGWqyJY20uAhUYHPs8WMqv0Csdou1M+wjXhusliQvgcQm5
HJOaz8p1V5lXzsjXU4Igg5BvYWsudoEhX9f+RrHxctxaGBVqukfOoZQq0nxMTXYm
OT+Ms+IFP7huYRUgjVlXLgaYhbt2X4An8Jqr97PXRSroOOJzAm/RqyV9m84kOpnL
Q2iSfhIQb7klt1rUec4fN1F6sKnX3jmS48yedOnNy7Sm3I8xxORaDlGPwCv9IwVc
RBY5RgeAPMj7uodx9q+0VFtJpfHAdX5Rgdj98nVVq3n7SM5RGflyctcY/fqo7+Ac
CFpCgSspsq9/COSm88cI2W5xbKfMHXuR/X7/VTfG7qka1l89BO7sNe00LGtGHZGb
+cMQ7tjcHAmU6FSqb1dJsLwoQgm2CDusDxI9ZYPCZJIch0EYAQHchtT2HM+RnqH3
cmwvSysL1RYTyeCC/f6JFHofAylmyrASmzaRujknsRKauTL251UTu85f+4om/MFg
POBZiZPCcpGTlQ==
=CfWz
-----END PGP SIGNATURE-----
Merge tag 'riscv-for-linus-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Palmer Dabbelt:
- Two kexec-related build fixes
- A DTS update to make the GPIO nodes match the upcoming dtschema
- A fix that passes -mno-relax directly to the assembler when building
modules, to work around compilers that fail to do so
* tag 'riscv-for-linus-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: add as-options for modules with assembly compontents
riscv: dts: align gpio-key node names with dtschema
RISC-V: kexec: Fix build error without CONFIG_KEXEC
RISCV: kexec: Fix build error without CONFIG_MODULES
Fix yet another piece of ACPI CPPC changes fallout on AMD
platforms (Mario Limonciello).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmLa6KsSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxh4MP/RYF7zR0gSX+HEiGU8DL4F1vnp2ObRBK
z7x6ih9EKvey6HUNOgoUdn70r3I5i0ZkTw1w9nge6z8PdGRAINwpVcBFeR8JMYch
iuoOEl/rkNmz5Wet7gqyfY95rV6m8AONKnnIuuCh8NLJDdXtDIeXSnp22Q6ogr8W
2rDzjMuH5/5Ry9ZK1vLfzLJvCVFC3GqJcJ2fNUHDuwfMFPqyjuxG1+xRhcbrIpvK
sgGpklOhyTGiSoDlqF/XV0nyn9vfB2sY9HuXO+oUApIG2TbtvJE9yUvHurpFWPt+
NirUTlGX+SuGFfCTva1fXOa75xOT/TSnCohEKXYTkNuQaaD1oTtokrwBhaJr6JiW
MRuCSaNDfURtFFd+5mlksmSreP4iwfyFsa9AY8Ib7ZRtfrTp0h+92fkdzuOIjWTN
+gamA4gULT4VGjDg7Q9XDLggHDhiOy+k+8TW/DV4EfQQuLl8OD+GzuMpkyPjb7yV
dt4vQCxOiauWk89o2DJfP1G10hWbG0zko7BYf4BjlmQsFImPusAF9G/JP2AqL1qG
nSzXA5HDHHGl4FKfahgz1AQQtob1Zt/Ceuvxm6dL9vPhj3KF1A0uuKpc6UGqLjXL
HGIE/QZfJJ+8MNF7EqRrHDNmy97i2FNc1EfA0HDjSdreGTrp3Lv9+MiTjZCyzhqb
DUrWXIJxYOnl
=JirQ
-----END PGP SIGNATURE-----
Merge tag 'acpi-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Fix yet another piece of ACPI CPPC changes fallout on AMD platforms
(Mario Limonciello)"
* tag 'acpi-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: CPPC: Don't require flexible address space if X86_FEATURE_CPPC is supported
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmLaEsMQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgprg0EADcHfSh4bM+37B1rHV3urn+Cmpei69/QUPo
XP9hLHFeNsokZC30JFaEN2oNiHic5oGOO9aoHSrWifnXGKScaN1ZmveGE5ctwA6B
n4mLKVjKNUAWzAG2MWFHCykxW2gXaLSfrMQNl/FIGrjnUwEVjS7b9BsORhSfeM86
AMl2he38Btr9n1PUw63RHf0tC/p0/nBg/dta95Bwu1cjhC/7gv3wBe739PKslo4c
oYimvLPobDkX60LcMXBsZbu9pwT7UR+WKcgOYtgqX9/Dq1G3KtO/mN+cOKJiTwAz
yStCQepnDqYHS9ltvBeh2a6BEtl09YFGMK8WkAVUPo21+AdmzZtAxAZtsuK9erSL
w9i3Z524rLR+PNjo0oW4QGIaLLPrQt152Q+KhCGtD69qdxf/BecO6jOiNMauWZjp
LWJW7I9bNQI8rxiSYIA4mgS8oS/8GXae2N+UYsjaMSXtJY1GMtO+ldI05y01rcJp
8/0MIqC3uhR5uFZ6VFLVGnzZuy0Tsw4KfN/Z/JMzTM5iWoCZvNXHgNTAnNbzLP6u
M3yUGlO3qEhg9UerqNSRi+rOyVNScXL6joP8nKjy+fSxOtS9uYegBKlL4fjrDAQr
fYuYnq+r9dk/Kqm6uQSuowZj8+nEwEEPbYErTLQT1GRO9A+/rIJ5a34FzKeRYWPU
bJAuWCu+BQ==
=lo96
-----END PGP SIGNATURE-----
Merge tag 'io_uring-5.19-2022-07-21' of git://git.kernel.dk/linux-block
Pull io_uring fixes from Jens Axboe:
"Fix for a bad kfree() introduced in this cycle, and a quick fix for
disabling buffer recycling for IORING_OP_READV.
The latter will get reworked for 5.20, but it gets the job done for
5.19"
* tag 'io_uring-5.19-2022-07-21' of git://git.kernel.dk/linux-block:
io_uring: do not recycle buffer in READV
io_uring: fix free of unallocated buffer list
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmLaEtsQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpjuZD/4joqo0PVz+O5MUadOmFxQ+Js2RCzxzDYwN
rfTlzsS2ybcoG2ehs3TPGU2c3Q+vODcgFOLJtrKPsyxEZM49uuu7+romi9/jxW4P
Pju8DmA0037elEGmml4i3EiMoIGyz1ScXFpR2Ii+LLTD6y7hNxHYxC/6PgWWaO59
gIydFz9PenJmz+orlpRI08vkvifdaCCdFfqgnP+KtvJsee2FPUdg2xpA021a1Tzj
7u1qPS1JnylQP1VQypqXnZTiHzmzmkQL4GNQIo/pje/RBstTFb3HOPXEoeVvQKrl
WjNntc80LZvYCMBzcksDkGAT8YLxXOckKvDiaYGObIoEoh/K6E7CBoIo4Smu3mwr
NqoaN3jZXnfTtZ40VEnxI6HnIbXG8Jc96P0/7Us3lL/W/wP0fD4fqNlumbkeMW2d
ualU91J6+YTGrYYWClSTSNyWQF/MNr1XRL9LQiO4GDs0fkIL1WoxaY/+AnUp0Jcc
PF8tm83852PcP+YJOOYgXD04gBmg2JCOrdarE87x+fIKp2Z7V4HPeR/hH5iOu9F3
CbXaBTICJlo7jmVUMKMh5yXvTyx4TqDvpWGbpQweXG4t8c77TPMI2cIHVdj1yqgj
L015BORXfsWnI0yX4IA32RqcoNwZHrrb930OxGDvUlxTrjfodlaLypYJ1wDKwRMi
H8LTxE6igA==
=zviX
-----END PGP SIGNATURE-----
Merge tag 'block-5.19-2022-07-21' of git://git.kernel.dk/linux-block
Pull block fix from Jens Axboe:
"Just a single fix for missing error propagation for an allocation
failure in raid5"
* tag 'block-5.19-2022-07-21' of git://git.kernel.dk/linux-block:
md/raid5: missing error code in setup_conf()
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmLa9I4ACgkQFA3kzBSg
KbYb6w/8CKvJ8R5hl7YNBIJSwRkaL/UrpcjgJ3fn/z7jEQDcjx/PdJczMMgNbUMY
DNiwyQ3cOsivm/nWEkjDe42hoNY0uwZTBUg77ESLvgCrRS+2283TziNxzgW2Dzq7
4LMqtfPdNEbhQUAEx4HchSILzMhfeS0yxMNjK+Crci+yUKgZ0sVY0L5huvsJMGOA
p3TJE9KGEQP2TtDVP8nNzj53DaDQ1VIs4N3MZ7oeewN7m5Ka11zJsn4bG5f48pJ+
cKambWxdpysaYb4WVIRv5/Q4Ubq1Aqk5tyPJHAYlNk08SQjxmEln+juM3uop1L9F
/bGQMySvAkPN9lav/cy8X74l3snqjbxS+h3ZwAys8K0KiuVYP1oUcYf/vSKqHjbi
lN7mbuHwltp5mxcL4hir1WdATxhhAOhl5j7IKH/d3G8oAOSzneZ0uoilA8UWSaaf
LTqzXppb5pRl2w2gFAIB0mQ29Qx4YfIY7ZEkdbM5ukO5R5Sq97muW4vLzeAAh1vw
lIcL7yb1OvVAPzrHbLBRzCTalsKcg3lsvY/l+H9ICycyNWnenX3Y8kGZaoC8EFz5
eebre8vZ9rEQNPPYm/SXlAhw9cDwijgdXFKgrjnyRKV+cDBBz6e8lWpe8x4U+GsQ
3KgFaHvoZfu/2WunKjD7BflEv8RXXFhd8qkQcv1geWISsQQ4J1k=
=C/cu
-----END PGP SIGNATURE-----
Merge tag 'i2c-for-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"Two driver bugfixes and a typo fix"
* tag 'i2c-for-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: cadence: Change large transfer count reset logic to be unconditional
i2c: imx: fix typo in comment
i2c: mlxcpld: Fix register setting for 400KHz frequency
- fix several regmap usage issues in gpio-pca953x
- fix out-of-tree build for GPIO selftests
- fix integer overflow in gpio-xilinx
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmLawUgACgkQEacuoBRx
13JzrRAAnQSIVnIPqMiQ/I0+zQW72SVajxp43j8Buq6ls6V+TjpZ376JJWDw9h/Y
M9rSY5J2H/ENkiid9473/ibAvE3m3OXuq8Jn6arKiuce/7ziTBW7KdrB3a30eZqo
Y6c6mPxSOilVnSqtN+SyfOjBW9J1/LP+TU+lYib/rw+hWm9GxR6qCQRocV0VWXiM
YK1TA6lRfGPMj8Y0shQ2Lz3B9k1QlZ3L2GxlKkRmPSiDiF+ihx7Y9W0mAhp7Q5ds
W19+FnZYkoYYWf6sebAeqL9Ha350T/KbWv5iNng2CcpF/WXazvY1GYNXfGpdHVIa
v+GObHv8bgc04keJ4rrJzjMDKcJTDWVk7aKrI4V3hHTktmm5h5xZzY4IOJnBEKYu
X85YJ+CZ7oxvSLeG2eccJkCalrD4QCgJ3NLdRojPEWuq1bG3Dcf+KdP67wguObB/
G5F0fyJFWAXOdf1uIHf9GOvAVhDBHsHvvmcPp6fMYaAWSgv3t+wmxotaMViifAVY
+/cPrr9J03geQuRUVLOz6U/iVoX6fy8SRJg9Hmx+cBZtMMdi0TdRtJwnY2zymwY8
6bNpC+ZRON7pP1ewhS6Dp/87AtukgpVxyRf2ihJv2/fzIA7Kc5AYpYXgYKYEJpVi
B0kO226C4y033SRc0Rd2uq/0/iqkmAA+lp0Gcd/H8ng7zpGyiZM=
=ZSY3
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix several regmap usage issues in gpio-pca953x
- fix out-of-tree build for GPIO selftests
- fix integer overflow in gpio-xilinx
* tag 'gpio-fixes-for-v5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: gpio-xilinx: Fix integer overflow
selftests: gpio: fix include path to kernel headers for out of tree builds
gpio: pca953x: use the correct register address when regcache sync during init
gpio: pca953x: use the correct range when do regmap sync
gpio: pca953x: only use single read/write for No AI mode
- NULL check for the ralink and sunplus drivers.
- Add Jacky Bai as maintainer for the Freescale pin controllers.
- Fix pin config ops for the Ocelot LAN966x and SparX5.
- Disallow AMD pin control to be a module: the GPIO lines
need to be active in early boot, so no can do.
- Fix the Armada 37xx to use raw spinlocks in the interrupt
handler path to avoid wait context.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmLali0ACgkQQRCzN7AZ
XXOuKg//WiregNcNDBoc1RcIZAAd1qz7nTKsQECHMYlSpyD2NzV1s0gg6lzKFoLc
LirJFBnlYg96CVbuq9Q6HK2K9+9M+DGFz0NbusEEJ9kJWeM2x+7wm1yYjeaYGR3v
pb7rv51NJI2nbENJQIrWGaqDZghdOsKA6HXZPScgSeqpW3dAR7tyzM0kUx03qtHB
s+szDxICaCQC9YwuCL1AIsDCg5Na2tb66hNKKY18EdlPVevYWSYuTCsUa6qAQHec
KvKYkdL/tb13tqhCmWgs04fDe/qNXxpVBKHb1Bf7wqjyTtjQq2oa/gW69gNUNBX6
SgpQXYhX1yfZoafkGe+y11sC8TswoMwsBUUd9Rw1/N/Yer2Ghh6rdFREF8g5Lu+s
DuA6yZi2qSmCskYdQvyVknZ1S73EJRZ2psZj4otT+t2Zufdw4gKx8JIovLZJnS4k
KIptC7vyxOmsJq3m7g2Al8pZCRzavTdpl56KJ4jPj+U7pclVu4CMFFWUmRG42JMM
iCzsBMo1Q8e/lzhQ/A93XDictl3cIeHfaQB8zAz6Mn/LcD2LpdIyqpg5df1ceScC
NEG3O88nZ95n0iZF1g+OPSIQAj9FKyULgMs8J8WCxstzRidk8A4HwShcZDgeJCUw
11kXciB0hqqEpMBJ2aeMqQ/ApOyFG/dgktprzF1pucYO5om3syQ=
=OQRx
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v5.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Only driver fixes:
- NULL check for the ralink and sunplus drivers
- Add Jacky Bai as maintainer for the Freescale pin controllers
- Fix pin config ops for the Ocelot LAN966x and SparX5
- Disallow AMD pin control to be a module: the GPIO lines need to be
active in early boot, so no can do
- Fix the Armada 37xx to use raw spinlocks in the interrupt handler
path to avoid wait context"
* tag 'pinctrl-v5.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: armada-37xx: use raw spinlocks for regmap to avoid invalid wait context
pinctrl: armada-37xx: make irq_lock a raw spinlock to avoid invalid wait context
pinctrl: Don't allow PINCTRL_AMD to be a module
pinctrl: ocelot: Fix pincfg
pinctrl: ocelot: Fix pincfg for lan966x
MAINTAINERS: Update freescale pin controllers maintainer
pinctrl: sunplus: Add check for kcalloc
pinctrl: ralink: Check for null return of devm_kcalloc
Only contains the revert of Rockchip BCLK changes for addressing
a regression.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmLalEIOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/5QBAAoCqNR0QkAwE0bLrrGyKbV7yPagvHFSk++bw7
vu5cC9a58UguvdZ/PIQ6sA19nTAiu8AwWTYB+QV7qb7KM0NWjzz2VIUDRm/UPIj5
Zw1I5+OHl06TdEECYqU1U/Z6SbkHOZMM7+odhQnWeuAodhBhJzAFyDAYdb6KG1UA
IctKUcbwnCrl/zuO7pWmy/if5AD4m4vyk56Ww4K4ivxFAoJNSMzEbxByTiuI8ZOu
aMPGZYm1lJmpjbSMWwCgCrAsolpXNpaqk8imOQvJ+ATtoN5PBXfjj9cubUZr+TL/
XvFIM6U8RZTtfp46prhpiMIf5esODpHe79KglQS4MaSjM85Km82JI80GVWj5IRsK
B/oswe5jRJNfqXKUpIfmJd4eqJv8EcYTv05yBdORmPTukrJeZLJej/c0IHWaxYBm
x134NdO26cnqLO2fve78DkWiO38v02BDFnHlWpqdsS8xhi6q7M3srzvgv7wm9eMT
PpGanDW7pKEf02ytxOi0HnqJSQzkie4XBVOaXknsJThUVYKrbD3w8dzcxwtelboG
2lxhR6agf6bQYU9Xf0/hTarTQz0PN53aIvmK1WpkF3pekr9AR2l1YsgWXUsiGO3S
TUY+A5G5VzLEA7FEmjyhdAjDTOSVGn38UGLLQ2CQYEPp7e2kLehrmBJFHeFfHyij
UGD4hMo=
=JAUy
-----END PGP SIGNATURE-----
Merge tag 'sound-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Only undoes the Rockchip BCLK changes to address a regression"
* tag 'sound-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: rockchip-i2s: Undo BCLK pinctrl changes
ASoC: rockchip: i2s: Fix NULL pointer dereference when pinctrl is not found
scheduler:
- scheduling while atomic fix
ttm:
- locking fix
edp:
- variable typo fix
i915:
- add back support for v69 firmware on ADL-P.
amdgpu:
- Drop redundant buffer cleanup that can lead to a segfault
- Add a bo_list mutex to avoid possible list corruption in CS
- dmub notification fix
imx:
- fix error path
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmLaI7sACgkQDHTzWXnE
hr5yOA/9FRJJODZT9YbVeg6GfOIy+/7lhwgAiOa0w3u91iFrU8rMWxYDqjvdzHZi
yQrpbmtKHQk3VFdkQFRZM17k6oLkBR0Ox/HcSnLghgI4veo5nmxU+ktZ8l4CcK7L
kW2ffyd4Q4LQry71fz7MtMkgj1+Pr7kyP4AHBNfNWhRTSu8j+psOTvMXQ7fmu6Iz
fpKkTfnY/mtmOA8Mw5JEypRiOXep2ZYtB8ve5MSLsPwzI89ku1OG7k03CrHFmE6X
7gieU4KaoqpG8SYxoIWJgsX0mobLk3cGEdjBsSUfyhR3igs64N1KM9lZAoPc3Dn7
4xi4HSJr5vezT9S1Kpzdn8KQYI6BK3+3mjXFYSrXC1rOPick3xN5frjT0Jn5WxZX
BKfESLQUZDrLo1ZVflmK0KNqxxZlFa0FeMB6IHumuqhzvZIuyRtf+2ceI0PDEm6i
N/1rB2E3OeWZt4pQ/cYCoZV8ktbb9HfZeWF3JHseBQSufIUkF5GIYnyktVoATNxr
/9tvno1TvKfTgSU1O219H65r5D+FFg8KjnGOpHTncEegkDExPHuJPL3L3effmnNq
y6OVDVclOzWSCsW1Fyub9qSnVsY4z1Pa3cxugIPrRQ5BqHH0+ESiGiN+AgsjsSrd
oO8l3LMRzBeLKib9VjQFK3xvA7PXCBUBgPkC67cbVqK3c0l1roA=
=p8Uj
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2022-07-22' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Fixes for this week.
The main one is the i915 firmware fix for the phoronix reported issue.
I've written some firmware guidelines as a result, should land in
-next soon. Otherwise a few amdgpu fixes, a scheduler fix, ttm fix and
two other minor ones.
scheduler:
- scheduling while atomic fix
ttm:
- locking fix
edp:
- variable typo fix
i915:
- add back support for v69 firmware on ADL-P
amdgpu:
- Drop redundant buffer cleanup that can lead to a segfault
- Add a bo_list mutex to avoid possible list corruption in CS
- dmub notification fix
imx:
- fix error path"
* tag 'drm-fixes-2022-07-22' of git://anongit.freedesktop.org/drm/drm:
drm/amdgpu: Protect the amdgpu_bo_list list with a mutex v2
drm/imx/dcss: Add missing of_node_put() in fail path
drm/i915/guc: support v69 in parallel to v70
drm/i915/guc: Support programming the EU priority in the GuC descriptor
drm/panel-edp: Fix variable typo when saving hpd absent delay from DT
drm/amdgpu: Remove one duplicated ef removal
drm/ttm: fix locking in vmap/vunmap TTM GEM helpers
drm/scheduler: Don't kill jobs in interrupt context
drm/amd/display: Fix new dmub notification enabling in DM
This pull request contains a pair of commits that fix 282d8998e9 ("srcu:
Prevent expedited GPs and blocking readers from consuming CPU"), which
was itself a fix to an SRCU expedited grace-period problem that could
prevent kernel live patching (KLP) from completing. That SRCU fix for
KLP introduced large (as in minutes) boot-time delays to embedded Linux
kernels running on qemu/KVM. These delays were due to the emulation of
certain MMIO operations controlling memory layout, which were emulated
with one expedited grace period per access. Common configurations
required thousands of boot-time MMIO accesses, and thus thousands of
boot-time expedited SRCU grace periods.
In these configurations, the occasional sleeps that allowed KLP to proceed
caused excessive boot delays. These commits preserve enough sleeps to
permit KLP to proceed, but few enough that the virtual embedded kernels
still boot reasonably quickly.
This represents a regression introduced in the v5.19 merge window,
and the bug is causing significant inconvenience, hence this pull request.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEbK7UrM+RBIrCoViJnr8S83LZ+4wFAmLZ6LoTHHBhdWxtY2tA
a2VybmVsLm9yZwAKCRCevxLzctn7jNHgD/4tb8Un6vZlrEaYbyA/ztUITX/2DisS
kiqbQz1BH8V3B3PxSo4ldEiw+z3fC3SMyIPymuu9bhwm6SFdjEsarFkIqySxkYnX
jnuk0JbWxs4Kk64rIkHHzAxzvM2Iw1EjSzjP1M+DC7iymSJpsgp+0zFJJtcJ8Y87
67hbQRQYk+1T7ZT+vq77NiyAAFEzSd8UydgBVxlsOOdkXQ91NYTyB8D6ldUJAnLU
opwCEpgpu74Sp4Te5q6f9uAt8xZmXsyrm8zJgzTz0KSgivcpt4GmIoyEFYUQczj0
Hewr6+qM9AWfvfQxNvRCS25yeox18kbdp1qdp9rl0BZMtYN2Zsk1Ec4c79s7NBLc
G3TIvJkGLHuZO1dO4BhLkYczgRYlaPxOR/0GKNn4m69/TbVmseUL1WeZS0pswB0q
cH1AKKEg9KdPoaX0hTLoOrlv/vwbgjhKKuoqEv7yEUhJJdACy50rmnhWhSxeuQDb
aIITVKkjkwpDtRX5QTdG1f5uIMoGz9BbUDv7VeodB0mrYHluXEfyNTwlqcISKAgm
T9kLmsdfvMrQ4fLR5S3i3dwnL3b52OB8h5NyfW3YRkXEnA7//ef/XpPiW2HY8BMT
7QwPqOoUSr/IraAcI8j0QxRpioUk1oaNi+UJ3FSHni8re6rZ0kaxatRCT20h6Djq
C9RVLaevw3bGXQ==
=ndhB
-----END PGP SIGNATURE-----
Merge tag 'rcu-urgent.2022.07.21a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
Pull RCU fix from Paul McKenney:
"This contains a pair of commits that fix 282d8998e9 ("srcu: Prevent
expedited GPs and blocking readers from consuming CPU"), which was
itself a fix to an SRCU expedited grace-period problem that could
prevent kernel live patching (KLP) from completing.
That SRCU fix for KLP introduced large (as in minutes) boot-time
delays to embedded Linux kernels running on qemu/KVM. These delays
were due to the emulation of certain MMIO operations controlling
memory layout, which were emulated with one expedited grace period per
access. Common configurations required thousands of boot-time MMIO
accesses, and thus thousands of boot-time expedited SRCU grace
periods.
In these configurations, the occasional sleeps that allowed KLP to
proceed caused excessive boot delays. These commits preserve enough
sleeps to permit KLP to proceed, but few enough that the virtual
embedded kernels still boot reasonably quickly.
This represents a regression introduced in the v5.19 merge window, and
the bug is causing significant inconvenience"
* tag 'rcu-urgent.2022.07.21a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
srcu: Make expedited RCU grace periods block even less frequently
srcu: Block less aggressively for expedited grace periods
Sudip reports that alpha doesn't build properly, with errors like
include/asm-generic/tlb.h:401:1: error: redefinition of 'tlb_update_vma_flags'
401 | tlb_update_vma_flags(struct mmu_gather *tlb, struct vm_area_struct *vma)
| ^~~~~~~~~~~~~~~~~~~~
include/asm-generic/tlb.h:372:1: note: previous definition of 'tlb_update_vma_flags' with type 'void(struct mmu_gather *, struct vm_area_struct *)'
372 | tlb_update_vma_flags(struct mmu_gather *tlb, struct vm_area_struct *vma) { }
the cause being that We have this odd situation where some architectures
were never converted to the newer TLB flushing interfaces that have a
range for the flush. Instead people left them alone, and we have them
select the MMU_GATHER_NO_RANGE config option to make the tlb header
files account for this.
Peter Zijlstra cleaned some of these nasty header file games up in
commits
1e9fdf21a4 ("mmu_gather: Remove per arch tlb_{start,end}_vma()")
18ba064e42 ("mmu_gather: Let there be one tlb_{start,end}_vma() implementation")
but tlb_update_vma_flags() was left alone, and then commit b67fbebd4c
("mmu_gather: Force tlb-flush VM_PFNMAP vmas") ended up removing only
_one_ of the two stale duplicate dummy inline functions.
This removes the other stale one.
Somebody braver than me should try to remove MMU_GATHER_NO_RANGE
entirely, but it requires fixing up the oddball architectures that use
it: alpha, m68k, microblaze, nios2 and openrisc.
The fixups should be fairly straightforward ("fix the build errors it
exposes by adding the appropriate range arguments"), but the reason this
wasn't done in the first place is that so few people end up working on
those architectures. But it could be done one architecture at a time,
hint, hint.
Reported-by: Sudip Mukherjee (Codethink) <sudipm.mukherjee@gmail.com>
Fixes: b67fbebd4c ("mmu_gather: Force tlb-flush VM_PFNMAP vmas")
Link: https://lore.kernel.org/all/YtpXh0QHWwaEWVAY@debian/
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Current implementation is not able to configure more than 32 pins
due to incorrect data type. So type casting with unsigned long
to avoid it.
Fixes: 02b3f84d90 ("xilinx: Switch to use bitmap APIs")
Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
a typo fix for panel-edp and a resource removal fix for imx/dcss
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYtkUfgAKCRDj7w1vZxhR
xWKPAP9xzlLJGWi5wQCollaI+LILoQXDoh+Gmj7MqSAuw8mzJQD/aQ2K+DtfBgW0
zvoPbJjafl8sZytItpHnzbLNOcR3swU=
=HSSq
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2022-07-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
A scheduling-while-atomic fix for drm/scheduler, a locking fix for TTM,
a typo fix for panel-edp and a resource removal fix for imx/dcss
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220721085550.hrwbukj34y56rzva@houat
When trying to load modules built for RISC-V which include assembly files
the kernel loader errors with "unexpected relocation type 'R_RISCV_ALIGN'"
due to R_RISCV_ALIGN relocations being generated by the assembler.
The R_RISCV_ALIGN relocations can be removed at the expense of code space
by adding -mno-relax to gcc and as. In commit 7a8e7da422
("RISC-V: Fixes to module loading") -mno-relax is added to the build
variable KBUILD_CFLAGS_MODULE. See [1] for more info.
The issue is that when kbuild builds a .S file, it invokes gcc with
the -mno-relax flag, but this is not being passed through to the
assembler. Adding -Wa,-mno-relax to KBUILD_AFLAGS_MODULE ensures that
the assembler is invoked correctly. This may have now been fixed in
gcc[2] and this addition should not stop newer gcc and as from working.
[1] https://github.com/riscv/riscv-elf-psabi-doc/issues/183
[2] 3b0a7d624e
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Link: https://lore.kernel.org/r/20220529152200.609809-1-ben.dooks@codethink.co.uk
Fixes: ab1ef68e54 ("RISC-V: Add sections of PLT and GOT for kernel module")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Filipe Manana