* [PATCH AUTOSEL 5.5 115/542] selftests: settings: tests can be in subsubdirs
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Matthieu Baerts, Kees Cook, Shuah Khan, Sasha Levin,
linux-kselftest
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Matthieu Baerts <matthieu.baerts@tessares.net>
[ Upstream commit ac87813d4372f4c005264acbe3b7f00c1dee37c4 ]
Commit 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second
timeout per test") adds support for a new per-test-directory "settings"
file. But this only works for tests not in a sub-subdirectories, e.g.
- tools/testing/selftests/rtc (rtc) is OK,
- tools/testing/selftests/net/mptcp (net/mptcp) is not.
We have to increase the timeout for net/mptcp tests which are not
upstreamed yet but this fix is valid for other tests if they need to add
a "settings" file, see the full list with:
tools/testing/selftests/*/*/**/Makefile
Note that this patch changes the text header message printed at the end
of the execution but this text is modified only for the tests that are
in sub-subdirectories, e.g.
ok 1 selftests: net/mptcp: mptcp_connect.sh
Before we had:
ok 1 selftests: mptcp: mptcp_connect.sh
But showing the full target name is probably better, just in case a
subsubdir has the same name as another one in another subdirectory.
Fixes: 852c8cbf34d3 (selftests/kselftest/runner.sh: Add 45 second timeout per test)
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/kselftest/runner.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kselftest/runner.sh b/tools/testing/selftests/kselftest/runner.sh
index a8d20cbb711cf..e84d901f85672 100644
--- a/tools/testing/selftests/kselftest/runner.sh
+++ b/tools/testing/selftests/kselftest/runner.sh
@@ -91,7 +91,7 @@ run_one()
run_many()
{
echo "TAP version 13"
- DIR=$(basename "$PWD")
+ DIR="${PWD#${BASE_DIR}/}"
test_num=0
total=$(echo "$@" | wc -w)
echo "1..$total"
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 116/542] rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Geert Uytterhoeven, kbuild test robot, Alexandre Belloni,
Sasha Levin, linux-rtc
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
[ Upstream commit 34719de919af07682861cb0fa2bcf64da33ecf44 ]
Merely enabling I2C and RTC selects REGMAP_I2C and REGMAP_SPI, even when
no driver needs it. While the former can be moduler, the latter cannot,
and thus becomes built-in.
Fix this by moving the select statements for REGMAP_I2C and REGMAP_SPI
from the RTC_I2C_AND_SPI helper to the individual drivers that depend on
it.
Note that the comment for RTC_I2C_AND_SPI refers to SND_SOC_I2C_AND_SPI
for more information, but the latter does not select REGMAP_{I2C,SPI}
itself, and defers that to the individual drivers, too.
Fixes: 080481f54ef62121 ("rtc: merge ds3232 and ds3234")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: kbuild test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20200112171349.22268-1-geert@linux-m68k.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d77515d8382c7..738fa07188409 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -848,14 +848,14 @@ config RTC_I2C_AND_SPI
default m if I2C=m
default y if I2C=y
default y if SPI_MASTER=y
- select REGMAP_I2C if I2C
- select REGMAP_SPI if SPI_MASTER
comment "SPI and I2C RTC drivers"
config RTC_DRV_DS3232
tristate "Dallas/Maxim DS3232/DS3234"
depends on RTC_I2C_AND_SPI
+ select REGMAP_I2C if I2C
+ select REGMAP_SPI if SPI_MASTER
help
If you say yes here you get support for Dallas Semiconductor
DS3232 and DS3234 real-time clock chips. If an interrupt is associated
@@ -875,6 +875,8 @@ config RTC_DRV_DS3232_HWMON
config RTC_DRV_PCF2127
tristate "NXP PCF2127"
depends on RTC_I2C_AND_SPI
+ select REGMAP_I2C if I2C
+ select REGMAP_SPI if SPI_MASTER
select WATCHDOG_CORE if WATCHDOG
help
If you say yes here you get support for the NXP PCF2127/29 RTC
@@ -891,6 +893,8 @@ config RTC_DRV_PCF2127
config RTC_DRV_RV3029C2
tristate "Micro Crystal RV3029/3049"
depends on RTC_I2C_AND_SPI
+ select REGMAP_I2C if I2C
+ select REGMAP_SPI if SPI_MASTER
help
If you say yes here you get support for the Micro Crystal
RV3029 and RV3049 RTC chips.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH nf-next v4 5/9] nf_tables: Add set type for arbitrary concatenation of ranges
From: Pablo Neira Ayuso @ 2020-02-14 18:16 UTC (permalink / raw)
To: Stefano Brivio
Cc: netfilter-devel, Florian Westphal, Kadlecsik József,
Eric Garver, Phil Sutter
In-Reply-To: <20200210161047.370582c5@redhat.com>
On Mon, Feb 10, 2020 at 04:10:47PM +0100, Stefano Brivio wrote:
> On Fri, 7 Feb 2020 12:23:08 +0100
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[...]
> > Did you tests with 8-bits grouping instead of 4-bits?
>
> Yes, at the very beginning, not with the final implementation. It was
> somewhat faster (on x86_64, I don't remember how much) for small
> numbers of rules, then I thought we would use too much memory, because:
>
> > Assuming a concatenation of 12 bytes (each field 4 bytes, hence 3
> > fields):
> >
> > * Using 4-bits groups: the number of buckets is 2^4 = 16 multiplied
> > by the bucket word (assuming one long word, 8 bytes, 64 pipapo
> > rules) is 16 * 8 = 128 bytes per group-row in the looking table. Then,
> > the number of group-rows is 8 given that 32 bits, then 32 / 4 = 8
> > group-rows.
> >
> > 8 * 128 bytes = 1024 bytes per lookup table.
> >
> > Assuming 3 fields, then this is 1024 * 3 = 3072 bytes.
> >
> > * Using 8-bits groups: 2^8 = 256, then 256 * 8 = 2048 bytes per
> > group-row. Then, 32 / 8 = 4 group-rows in total.
> >
> > 4 * 2048 bytes = 8192 bytes per lookup table.
> >
> > Therefore, 3 * 8192 = 24576 bytes. Still rather small.
> >
> > This is missing the mapping table that links the lookup tables in the
> > memory counting. And I'm assuming that the number of pipapo rules in
> > the lookup table fits into 64-bits bucket long word.
>
> ...the (reasonable?) worst case I wanted to cover was two IPv6
> addresses, one port, one MAC address (in ipset terms
> "net,net,port,mac"), with 2 ^ 16 unique, non-overlapping entries each
> (or ranges expanding to that amount of rules), because that's what
> (single, non-concatenated) ipset "bitmap" types can do.
I see, so you were considering the worst case. You're assuming each
element takes exactly one pipapo rule, so it's 2^16 elements, correct?
You refer to a property that says that you can split a range into a
2*n netmasks IIRC. Do you know what is the worst case when splitting
ranges?
There is no ipset set like this, but I agree usecase might happen.
> Also ignoring the mapping table (it's "small"), with 4-bit buckets:
>
> - for the IPv6 addresses, we have 16 buckets, each 2 ^ 16
> bits wide, and 32 groups (128 bits / 4 bits), that is, 8MiB in
> total
>
> - for the MAC address, 16 buckets, each 2 ^ 16 bits wide, and 12
> groups, 1.5MiB
>
> - for the port, 16 buckets, each 2 ^ 12 bits wide, 2 groups, 0.25MiB
>
> that is, 9.75MiB.
>
> With 8-bit buckets: we can just multiply everything by 8 (that is,
> 2 ^ 8 / 2 ^ 4 / 2, because we have 2 ^ (8 - 4) times the buckets, with
> half the groups), 78MiB.
Yes, this is large. Compared to a hashtable with 2^16 entries, then
it's 2^17 hashtable buckets and using struct hlist_head, this is 2
MBytes. Then, each hlist_node is 16 bytes, so 2^16 * 16 ~= 1 MByte.
That is 3 MBytes if my maths are fine.
Just telling this to find what could be considered as reasonable
amount of memory to be consumed. ~10 MBytes is slightly more than, but
I agree you selected a reasonable worst through this "complex tuple".
> And that started feeling like "a lot". However, I'm probably overdoing
> with the worst case -- this was just to explain what brought me to the
> 4-bit choice, now I start doubting about it.
>
> > Anyway, my understanding is that the more bits you use for grouping,
> > the larger the lookup table becomes.
> >
> > Still, both look very small in terms of memory consumption for these
> > days.
> >
> > I'm just telling this because the C implementation can probably get
> > better numbers at the cost of consuming more memory? Probably do this
> > at some point?
>
> Another topic is the additional amount of cachelines we would use. I
> don't expect that effect to be visible, but I might be wrong.
>
> So yes, I think it's definitely worth a try, thanks for the hint! I'll
> try to look into this soon and test it on a few archs (something with
> small cachelines, say MIPS r2k, would be worth checking, too).
>
> We could even consider to dynamically adjust group size depending on
> the set size, I don't know yet if that gets too convoluted.
Yes, keeping this maintainable is a good idea.
The per-cpu scratch index is only required if we cannot fit in the
"result bitmap" into the stack, right?
Probably up to 256 bytes result bitmap in the stack is reasonable?
That makes 8192 pipapo rules. There will be no need to disable bh and
make use of the percpu scratchpad area in that case.
If adjusting the code to deal with variable length "pipapo word" size
is not too convoluted, then you could just deal with the variable word
size from the insert / delete / get (slow) path and register one
lookup function for the version that is optimized for this pipapo word
size.
Probably adding helper function to deal with pipapo words would help
to prepare for such update in the future. There is the ->estimate
function that allows to calculate for the best word size depending on
all the information this gets from the set definition.
Just to keep this in the radar for future work.
Thanks.
^ permalink raw reply
* [PATCH AUTOSEL 5.5 118/542] RDMA/umem: Fix ib_umem_find_best_pgsz()
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Artemy Kovalyov, Leon Romanovsky, Gal Pressman, Jason Gunthorpe,
Sasha Levin, linux-rdma
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Artemy Kovalyov <artemyko@mellanox.com>
[ Upstream commit 36798d5ae1af62e830c5e045b2e41ce038690c61 ]
Except for the last entry, the ending iova alignment sets the maximum
possible page size as the low bits of the iova must be zero when starting
the next chunk.
Fixes: 4a35339958f1 ("RDMA/umem: Add API to find best driver supported page size in an MR")
Link: https://lore.kernel.org/r/20200128135612.174820-1-leon@kernel.org
Signed-off-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Tested-by: Gal Pressman <galpress@amazon.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/core/umem.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 7a3b99597eada..40cadb889114f 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -166,10 +166,13 @@ unsigned long ib_umem_find_best_pgsz(struct ib_umem *umem,
* for any address.
*/
mask |= (sg_dma_address(sg) + pgoff) ^ va;
- if (i && i != (umem->nmap - 1))
- /* restrict by length as well for interior SGEs */
- mask |= sg_dma_len(sg);
va += sg_dma_len(sg) - pgoff;
+ /* Except for the last entry, the ending iova alignment sets
+ * the maximum possible page size as the low bits of the iova
+ * must be zero when starting the next chunk.
+ */
+ if (i != (umem->nmap - 1))
+ mask |= va;
pgoff = 0;
}
best_pg_bit = rdma_find_pg_bit(mask, pgsz_bitmap);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 123/542] Btrfs: keep pages dirty when using btrfs_writepage_fixup_worker
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Chris Mason, Josef Bacik, David Sterba, Sasha Levin, linux-btrfs
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Chris Mason <clm@fb.com>
[ Upstream commit 25f3c5021985e885292980d04a1423fd83c967bb ]
For COW, btrfs expects pages dirty pages to have been through a few setup
steps. This includes reserving space for the new block allocations and marking
the range in the state tree for delayed allocation.
A few places outside btrfs will dirty pages directly, especially when unmapping
mmap'd pages. In order for these to properly go through COW, we run them
through a fixup worker to wait for stable pages, and do the delalloc prep.
87826df0ec36 added a window where the dirty pages were cleaned, but pending
more action from the fixup worker. We clear_page_dirty_for_io() before
we call into writepage, so the page is no longer dirty. The commit
changed it so now we leave the page clean between unlocking it here and
the fixup worker starting at some point in the future.
During this window, page migration can jump in and relocate the page. Once our
fixup work actually starts, it finds page->mapping is NULL and we end up
freeing the page without ever writing it.
This leads to crc errors and other exciting problems, since it screws up the
whole statemachine for waiting for ordered extents. The fix here is to keep
the page dirty while we're waiting for the fixup worker to get to work.
This is accomplished by returning -EAGAIN from btrfs_writepage_cow_fixup
if we queued the page up for fixup, which will cause the writepage
function to redirty the page.
Because we now expect the page to be dirty once it gets to the fixup
worker we must adjust the error cases to call clear_page_dirty_for_io()
on the page. That is the bulk of the patch, but it is not the fix, the
fix is the -EAGAIN from btrfs_writepage_cow_fixup. We cannot separate
these two changes out because the error conditions change with the new
expectations.
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/inode.c | 61 ++++++++++++++++++++++++++++++++++--------------
1 file changed, 44 insertions(+), 17 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index c70baafb2a392..27f2c554cac32 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2204,17 +2204,27 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
struct inode *inode;
u64 page_start;
u64 page_end;
- int ret;
+ int ret = 0;
fixup = container_of(work, struct btrfs_writepage_fixup, work);
page = fixup->page;
again:
lock_page(page);
- if (!page->mapping || !PageDirty(page) || !PageChecked(page)) {
- ClearPageChecked(page);
+
+ /*
+ * Before we queued this fixup, we took a reference on the page.
+ * page->mapping may go NULL, but it shouldn't be moved to a different
+ * address space.
+ */
+ if (!page->mapping || !PageDirty(page) || !PageChecked(page))
goto out_page;
- }
+ /*
+ * We keep the PageChecked() bit set until we're done with the
+ * btrfs_start_ordered_extent() dance that we do below. That drops and
+ * retakes the page lock, so we don't want new fixup workers queued for
+ * this page during the churn.
+ */
inode = page->mapping->host;
page_start = page_offset(page);
page_end = page_offset(page) + PAGE_SIZE - 1;
@@ -2239,24 +2249,22 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
ret = btrfs_delalloc_reserve_space(inode, &data_reserved, page_start,
PAGE_SIZE);
- if (ret) {
- mapping_set_error(page->mapping, ret);
- end_extent_writepage(page, ret, page_start, page_end);
- ClearPageChecked(page);
+ if (ret)
goto out;
- }
ret = btrfs_set_extent_delalloc(inode, page_start, page_end, 0,
&cached_state);
- if (ret) {
- mapping_set_error(page->mapping, ret);
- end_extent_writepage(page, ret, page_start, page_end);
- ClearPageChecked(page);
+ if (ret)
goto out_reserved;
- }
- ClearPageChecked(page);
- set_page_dirty(page);
+ /*
+ * Everything went as planned, we're now the owner of a dirty page with
+ * delayed allocation bits set and space reserved for our COW
+ * destination.
+ *
+ * The page was dirty when we started, nothing should have cleaned it.
+ */
+ BUG_ON(!PageDirty(page));
out_reserved:
btrfs_delalloc_release_extents(BTRFS_I(inode), PAGE_SIZE);
if (ret)
@@ -2266,6 +2274,17 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
unlock_extent_cached(&BTRFS_I(inode)->io_tree, page_start, page_end,
&cached_state);
out_page:
+ if (ret) {
+ /*
+ * We hit ENOSPC or other errors. Update the mapping and page
+ * to reflect the errors and clean the page.
+ */
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ clear_page_dirty_for_io(page);
+ SetPageError(page);
+ }
+ ClearPageChecked(page);
unlock_page(page);
put_page(page);
kfree(fixup);
@@ -2293,6 +2312,13 @@ int btrfs_writepage_cow_fixup(struct page *page, u64 start, u64 end)
if (TestClearPagePrivate2(page))
return 0;
+ /*
+ * PageChecked is set below when we create a fixup worker for this page,
+ * don't try to create another one if we're already PageChecked()
+ *
+ * The extent_io writepage code will redirty the page if we send back
+ * EAGAIN.
+ */
if (PageChecked(page))
return -EAGAIN;
@@ -2305,7 +2331,8 @@ int btrfs_writepage_cow_fixup(struct page *page, u64 start, u64 end)
btrfs_init_work(&fixup->work, btrfs_writepage_fixup_worker, NULL, NULL);
fixup->page = page;
btrfs_queue_work(fs_info->fixup_workers, &fixup->work);
- return -EBUSY;
+
+ return -EAGAIN;
}
static int insert_reserved_file_extent(struct btrfs_trans_handle *trans,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 124/542] drivers/block/zram/zram_drv.c: fix error return codes not being returned in writeback_store
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Colin Ian King, Minchan Kim, Sergey Senozhatsky, Jens Axboe,
Andrew Morton, Linus Torvalds, Sasha Levin, linux-block
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Colin Ian King <colin.king@canonical.com>
[ Upstream commit 3b82a051c10143639a378dcd12019f2353cc9054 ]
Currently when an error code -EIO or -ENOSPC in the for-loop of
writeback_store the error code is being overwritten by a ret = len
assignment at the end of the function and the error codes are being
lost. Fix this by assigning ret = len at the start of the function and
remove the assignment from the end, hence allowing ret to be preserved
when error codes are assigned to it.
Addresses Coverity ("Unused value")
Link: http://lkml.kernel.org/r/20191128122958.178290-1-colin.king@canonical.com
Fixes: a939888ec38b ("zram: support idle/huge page writeback")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/zram/zram_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4285e75e52c34..1bf4a908a0bd9 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -626,7 +626,7 @@ static ssize_t writeback_store(struct device *dev,
struct bio bio;
struct bio_vec bio_vec;
struct page *page;
- ssize_t ret;
+ ssize_t ret = len;
int mode;
unsigned long blk_idx = 0;
@@ -762,7 +762,6 @@ static ssize_t writeback_store(struct device *dev,
if (blk_idx)
free_block_bdev(zram, blk_idx);
- ret = len;
__free_page(page);
release_init_lock:
up_read(&zram->init_lock);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 117/542] drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zero
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Harry Wentland, Louis Li, Wenjing Liu, Hersen Wu, Eric Yang,
Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Harry Wentland <harry.wentland@amd.com>
[ Upstream commit 3eb6d7aca53d81ce888624f09cd44dc0302161e8 ]
[WHY]
Two years ago the patch referenced by the Fixes tag stopped running
dp_verify_link_cap_with_retries during DP detection when the reason
for the detection was a short-pulse interrupt. This effectively meant
that we were no longer doing the verify_link_cap training on active
dongles when their SINK_COUNT changed from 0 to 1.
A year ago this was partly remedied with:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")
This made sure that we trained the dongle on initial hotplug (without
connected downstream devices).
This is all fine and dandy if it weren't for the fact that there are
some dongles on the market that don't like link training when SINK_COUNT
is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately
after hotplug, even when a downstream device is connected, and then
trigger a shortpulse interrupt indicating a SINK_COUNT change to 1.
In order to play nicely we will need our policy to not link train an
active DP dongle when SINK_COUNT is 0 but ensure we train it when the
SINK_COUNT changes to 1.
[HOW]
Call dp_verify_link_cap_with_retries on detection even when the detection
is triggered from a short pulse interrupt.
With this change we can also revert this commit which we'll do in a separate
follow-up change:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")
Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure")
Suggested-by: Louis Li <Ching-shih.Li@amd.com>
Tested-by: Louis Li <Ching-shih.Li@amd.com>
Cc: Wenjing Liu <Wenjing.Liu@amd.com>
Cc: Hersen Wu <hersenxs.wu@amd.com>
Cc: Eric Yang <Eric.Yang2@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 4619f94f0ac78..70846ae7d854d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -968,8 +968,7 @@ static bool dc_link_detect_helper(struct dc_link *link,
same_edid = is_same_edid(&prev_sink->dc_edid, &sink->dc_edid);
if (link->connector_signal == SIGNAL_TYPE_DISPLAY_PORT &&
- sink_caps.transaction_type == DDC_TRANSACTION_TYPE_I2C_OVER_AUX &&
- reason != DETECT_REASON_HPDRX) {
+ sink_caps.transaction_type == DDC_TRANSACTION_TYPE_I2C_OVER_AUX) {
/*
* TODO debug why Dell 2413 doesn't like
* two link trainings
--
2.20.1
^ permalink raw reply related
* [PATCH v2] x86/resctrl: Preserve CDP enable over cpuhp
From: James Morse @ 2020-02-14 18:16 UTC (permalink / raw)
To: x86, linux-kernel
Cc: Fenghua Yu, Reinette Chatre, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, James Morse
Resctrl assumes that all CPUs are online when the filesystem is
mounted, and that CPUs remember their CDP-enabled state over CPU
hotplug.
This goes wrong when resctrl's CDP-enabled state changes while all
the CPUs in a domain are offline.
When a domain comes online, enable (or disable!) CDP to match resctrl's
current setting.
Fixes: 5ff193fbde20 ("x86/intel_rdt: Add basic resctrl filesystem support")
Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
Changes since v1:
* Explicitly test for L2/L3 resources to ignore duplicate calls.
* Poke the LxDATA resources to avoid confusing CDP-off with CDP-unsupported.
* Moved code to rdtgroup.c for fewer exported functions.
v1: lore.kernel.org/r/20200212185359.163111-1-james.morse@arm.com
---
arch/x86/kernel/cpu/resctrl/core.c | 2 ++
arch/x86/kernel/cpu/resctrl/internal.h | 1 +
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 18 ++++++++++++++++++
3 files changed, 21 insertions(+)
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 89049b343c7a..d8cc5223b7ce 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -578,6 +578,8 @@ static void domain_add_cpu(int cpu, struct rdt_resource *r)
d->id = id;
cpumask_set_cpu(cpu, &d->cpu_mask);
+ rdt_domain_reconfigure_cdp(r);
+
if (r->alloc_capable && domain_setup_ctrlval(r, d)) {
kfree(d);
return;
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
index 181c992f448c..3dd13f3a8b23 100644
--- a/arch/x86/kernel/cpu/resctrl/internal.h
+++ b/arch/x86/kernel/cpu/resctrl/internal.h
@@ -601,5 +601,6 @@ bool has_busy_rmid(struct rdt_resource *r, struct rdt_domain *d);
void __check_limbo(struct rdt_domain *d, bool force_free);
bool cbm_validate_intel(char *buf, u32 *data, struct rdt_resource *r);
bool cbm_validate_amd(char *buf, u32 *data, struct rdt_resource *r);
+void rdt_domain_reconfigure_cdp(struct rdt_resource *r);
#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 064e9ef44cd6..5967320a1951 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -1831,6 +1831,9 @@ static int set_cache_qos_cfg(int level, bool enable)
struct rdt_domain *d;
int cpu;
+ /* CDP state is restored during cpuhp, which takes this lock */
+ lockdep_assert_held(&rdtgroup_mutex);
+
if (level == RDT_RESOURCE_L3)
update = l3_qos_cfg_update;
else if (level == RDT_RESOURCE_L2)
@@ -1859,6 +1862,21 @@ static int set_cache_qos_cfg(int level, bool enable)
return 0;
}
+/* Restore the qos cfg state when a package comes online */
+void rdt_domain_reconfigure_cdp(struct rdt_resource *r)
+{
+ lockdep_assert_held(&rdtgroup_mutex);
+
+ if (!r->alloc_capable)
+ return;
+
+ if (r == &rdt_resources_all[RDT_RESOURCE_L2DATA])
+ l2_qos_cfg_update(&r->alloc_enabled);
+
+ if (r == &rdt_resources_all[RDT_RESOURCE_L3DATA])
+ l3_qos_cfg_update(&r->alloc_enabled);
+}
+
/*
* Enable or disable the MBA software controller
* which helps user specify bandwidth in MBps.
--
2.24.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 126/542] netfilter: flowtable: Fix hardware flush order on nf_flow_table_cleanup
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Paul Blakey, Pablo Neira Ayuso, Sasha Levin, netfilter-devel,
coreteam, netdev
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Paul Blakey <paulb@mellanox.com>
[ Upstream commit 91bfaa15a379e9af24f71fb4ee08d8019b6e8ec7 ]
On netdev down event, nf_flow_table_cleanup() is called for the relevant
device and it cleans all the tables that are on that device.
If one of those tables has hardware offload flag,
nf_flow_table_iterate_cleanup flushes hardware and then runs the gc.
But the gc can queue more hardware work, which will take time to execute.
Instead first add the work, then flush it, to execute it now.
Fixes: c29f74e0df7a ("netfilter: nf_flow_table: hardware offload support")
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/netfilter/nf_flow_table_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
index 640a46fd710d2..ec402baf16d64 100644
--- a/net/netfilter/nf_flow_table_core.c
+++ b/net/netfilter/nf_flow_table_core.c
@@ -530,9 +530,9 @@ static void nf_flow_table_do_cleanup(struct flow_offload *flow, void *data)
static void nf_flow_table_iterate_cleanup(struct nf_flowtable *flowtable,
struct net_device *dev)
{
- nf_flow_table_offload_flush(flowtable);
nf_flow_table_iterate(flowtable, nf_flow_table_do_cleanup, dev);
flush_delayed_work(&flowtable->gc_work);
+ nf_flow_table_offload_flush(flowtable);
}
void nf_flow_table_cleanup(struct net_device *dev)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 127/542] block, bfq: do not plug I/O for bfq_queues with no proc refs
From: Sasha Levin @ 2020-02-14 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Paolo Valente, Oleksandr Natalenko, Patrick Dung, Jens Axboe,
Sasha Levin, linux-block
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Paolo Valente <paolo.valente@linaro.org>
[ Upstream commit f718b093277df582fbf8775548a4f163e664d282 ]
Commit 478de3380c1c ("block, bfq: deschedule empty bfq_queues not
referred by any process") fixed commit 3726112ec731 ("block, bfq:
re-schedule empty queues if they deserve I/O plugging") by
descheduling an empty bfq_queue when it remains with not process
reference. Yet, this still left a case uncovered: an empty bfq_queue
with not process reference that remains in service. This happens for
an in-service sync bfq_queue that is deemed to deserve I/O-dispatch
plugging when it remains empty. Yet no new requests will arrive for
such a bfq_queue if no process sends requests to it any longer. Even
worse, the bfq_queue may happen to be prematurely freed while still in
service (because there may remain no reference to it any longer).
This commit solves this problem by preventing I/O dispatch from being
plugged for the in-service bfq_queue, if the latter has no process
reference (the bfq_queue is then prevented from remaining in service).
Fixes: 3726112ec731 ("block, bfq: re-schedule empty queues if they deserve I/O plugging")
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Reported-by: Patrick Dung <patdung100@gmail.com>
Tested-by: Patrick Dung <patdung100@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
block/bfq-iosched.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index ad4af4aaf2ced..5c239c540c47a 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -3444,6 +3444,10 @@ static void bfq_dispatch_remove(struct request_queue *q, struct request *rq)
static bool idling_needed_for_service_guarantees(struct bfq_data *bfqd,
struct bfq_queue *bfqq)
{
+ /* No point in idling for bfqq if it won't get requests any longer */
+ if (unlikely(!bfqq_process_refs(bfqq)))
+ return false;
+
return (bfqq->wr_coeff > 1 &&
(bfqd->wr_busy_queues <
bfq_tot_busy_queues(bfqd) ||
@@ -4077,6 +4081,10 @@ static bool idling_boosts_thr_without_issues(struct bfq_data *bfqd,
bfqq_sequential_and_IO_bound,
idling_boosts_thr;
+ /* No point in idling for bfqq if it won't get requests any longer */
+ if (unlikely(!bfqq_process_refs(bfqq)))
+ return false;
+
bfqq_sequential_and_IO_bound = !BFQQ_SEEKY(bfqq) &&
bfq_bfqq_IO_bound(bfqq) && bfq_bfqq_has_short_ttime(bfqq);
@@ -4170,6 +4178,10 @@ static bool bfq_better_to_idle(struct bfq_queue *bfqq)
struct bfq_data *bfqd = bfqq->bfqd;
bool idling_boosts_thr_with_no_issue, idling_needed_for_service_guar;
+ /* No point in idling for bfqq if it won't get requests any longer */
+ if (unlikely(!bfqq_process_refs(bfqq)))
+ return false;
+
if (unlikely(bfqd->strict_guarantees))
return true;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices
From: Jason A. Donenfeld @ 2020-02-14 18:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Netdev, Eric Dumazet
In-Reply-To: <135ffa7a-f06a-80e3-4412-17457b202c77@gmail.com>
On Fri, Feb 14, 2020 at 6:56 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Oh dear, can you describe what do you expect of a wireguard device with mtu == 0 or mtu == 1
>
> Why simply not allowing silly configurations, instead of convoluted tests in fast path ?
>
> We are speaking of tunnels adding quite a lot of headers, so we better not try to make them
> work on networks with tiny mtu. Just say no to syzbot.
The idea was that wireguard might still be useful for the persistent
keepalive stuff. This branch becomes very cold very fast, so I don't
think it makes a difference performance wise, but if you feel strongly
about it, I can get rid of it and set a non-zero min_mtu that's the
smallest thing wireguard's xmit semantics will accept. It sounds like
you'd prefer that?
^ permalink raw reply
* [PATCH AUTOSEL 5.5 132/542] mt76: mt7615: fix max_nss in mt7615_eeprom_parse_hw_cap
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lorenzo Bianconi, Kalle Valo, Sasha Levin, linux-wireless, netdev,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
[ Upstream commit d08f3010f4a32eec3c8aa771f03a1b342a1472fa ]
Fix u8 cast reading max_nss from MT_TOP_STRAP_STA register in
mt7615_eeprom_parse_hw_cap routine
Fixes: acf5457fd99db ("mt76: mt7615: read {tx,rx} mask from eeprom")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index eccad4987ac83..17e277bf39e0f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -92,8 +92,9 @@ static int mt7615_check_eeprom(struct mt76_dev *dev)
static void mt7615_eeprom_parse_hw_cap(struct mt7615_dev *dev)
{
- u8 val, *eeprom = dev->mt76.eeprom.data;
+ u8 *eeprom = dev->mt76.eeprom.data;
u8 tx_mask, rx_mask, max_nss;
+ u32 val;
val = FIELD_GET(MT_EE_NIC_WIFI_CONF_BAND_SEL,
eeprom[MT_EE_WIFI_CONF]);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 134/542] bpf, sockhash: Synchronize_rcu before free'ing map
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jakub Sitnicki, Daniel Borkmann, John Fastabend, Sasha Levin,
netdev, bpf
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Jakub Sitnicki <jakub@cloudflare.com>
[ Upstream commit 0b2dc83906cf1e694e48003eae5df8fa63f76fd9 ]
We need to have a synchronize_rcu before free'ing the sockhash because any
outstanding psock references will have a pointer to the map and when they
use it, this could trigger a use after free.
This is a sister fix for sockhash, following commit 2bb90e5cc90e ("bpf:
sockmap, synchronize_rcu before free'ing map") which addressed sockmap,
which comes from a manual audit.
Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20200206111652.694507-3-jakub@cloudflare.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/sock_map.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 8998e356f4232..058422b932607 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -250,6 +250,7 @@ static void sock_map_free(struct bpf_map *map)
raw_spin_unlock_bh(&stab->lock);
rcu_read_unlock();
+ /* wait for psock readers accessing its map link */
synchronize_rcu();
bpf_map_area_free(stab->sks);
@@ -873,6 +874,9 @@ static void sock_hash_free(struct bpf_map *map)
}
rcu_read_unlock();
+ /* wait for psock readers accessing its map link */
+ synchronize_rcu();
+
bpf_map_area_free(htab->buckets);
kfree(htab);
}
--
2.20.1
^ permalink raw reply related
* Re: RPI4: fail too boot with an initrd
From: James Morse @ 2020-02-14 18:15 UTC (permalink / raw)
To: LABBE Corentin
Cc: nsaenzjulienne, linux-kernel, u-boot, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <20200214132748.GA23276@Red>
Hi Corentin,
On 14/02/2020 13:27, LABBE Corentin wrote:
> Since the inclusion of the "enable network support in RPi4 config" serie on uboot, I
> have started to work on adding the rpi4 in kernelCI.
> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
>
> Using booti I hit:
> [ 0.000000] Linux version 5.6.0-rc1-next-20200212 (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> [ 0.000000] Machine model: Raspberry Pi 4 Model B
> [ 0.000000] earlycon: uart0 at MMIO32 0x00000000fe215040 (options '')
> [ 0.000000] printk: bootconsole [uart0] enabled
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: UEFI not found.
So no EFI,
> [ 0.000000] OF: reserved mem: failed to allocate memory for node 'linux,cma'
Out of memory.
> [ 0.000000] cma: Failed to reserve 32 MiB
> [ 0.000000] Kernel panic - not syncing: Failed to allocate page table page
Out of memory...
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc1-next-20200212 #66
> [ 0.000000] Hardware name: Raspberry Pi 4 Model B (DT)
> [ 0.000000] Call trace:
> [ 0.000000] dump_backtrace+0x0/0x1a0
> [ 0.000000] show_stack+0x14/0x20
> [ 0.000000] dump_stack+0xbc/0x104
> [ 0.000000] panic+0x16c/0x37c
> [ 0.000000] early_pgtable_alloc+0x30/0xa0
... really early!
> [ 0.000000] __create_pgd_mapping+0x36c/0x588
> [ 0.000000] map_kernel_segment+0x70/0xa4
> [ 0.000000] paging_init+0xf4/0x528
> [ 0.000000] setup_arch+0x250/0x5d8
> [ 0.000000] start_kernel+0x90/0x6d8
>
>
> Since the same kernel boot with bootefi and that bootefi lack ramdisk address,
Booting with EFI will cause linux to use the EFI memory map.
Does your DT have a memory node? (or does it expect EFI to provide the information)
> I tried to add the address in the dtb via:
> fdt addr 0x02400000; fdt resize; fdt set /chosen linux,initrd-start 0x02700000; fdt set /chosen linux,initrd-end 0x10000000; bootefi 0x00080000 0x02400000
> But with that, I get:
> initrd not fully accessible via the linear mapping -- please check your bootloader ...
So this one is an EFI boot, but you can't find where to put the initramfs such that the
kernel agrees its in memory.
If you boot with 'efi=debug', linux will print the EFI memory map. Could you compare that
to where U-Boot thinks memory is?
(it sounds like your DT memory node is missing, and your EFI memory map is surprisingly small)
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH AUTOSEL 5.5 135/542] bpf, sockmap: Check update requirements after locking
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lorenz Bauer, Daniel Borkmann, Jakub Sitnicki, Sasha Levin,
netdev, bpf
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Lorenz Bauer <lmb@cloudflare.com>
[ Upstream commit 85b8ac01a421791d66c3a458a7f83cfd173fe3fa ]
It's currently possible to insert sockets in unexpected states into
a sockmap, due to a TOCTTOU when updating the map from a syscall.
sock_map_update_elem checks that sk->sk_state == TCP_ESTABLISHED,
locks the socket and then calls sock_map_update_common. At this
point, the socket may have transitioned into another state, and
the earlier assumptions don't hold anymore. Crucially, it's
conceivable (though very unlikely) that a socket has become unhashed.
This breaks the sockmap's assumption that it will get a callback
via sk->sk_prot->unhash.
Fix this by checking the (fixed) sk_type and sk_protocol without the
lock, followed by a locked check of sk_state.
Unfortunately it's not possible to push the check down into
sock_(map|hash)_update_common, since BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB
run before the socket has transitioned from TCP_SYN_RECV into
TCP_ESTABLISHED.
Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20200207103713.28175-1-lmb@cloudflare.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/sock_map.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 058422b932607..b16ff3b8c6503 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -417,14 +417,16 @@ static int sock_map_update_elem(struct bpf_map *map, void *key,
ret = -EINVAL;
goto out;
}
- if (!sock_map_sk_is_suitable(sk) ||
- sk->sk_state != TCP_ESTABLISHED) {
+ if (!sock_map_sk_is_suitable(sk)) {
ret = -EOPNOTSUPP;
goto out;
}
sock_map_sk_acquire(sk);
- ret = sock_map_update_common(map, idx, sk, flags);
+ if (sk->sk_state != TCP_ESTABLISHED)
+ ret = -EOPNOTSUPP;
+ else
+ ret = sock_map_update_common(map, idx, sk, flags);
sock_map_sk_release(sk);
out:
fput(sock->file);
@@ -740,14 +742,16 @@ static int sock_hash_update_elem(struct bpf_map *map, void *key,
ret = -EINVAL;
goto out;
}
- if (!sock_map_sk_is_suitable(sk) ||
- sk->sk_state != TCP_ESTABLISHED) {
+ if (!sock_map_sk_is_suitable(sk)) {
ret = -EOPNOTSUPP;
goto out;
}
sock_map_sk_acquire(sk);
- ret = sock_hash_update_common(map, key, sk, flags);
+ if (sk->sk_state != TCP_ESTABLISHED)
+ ret = -EOPNOTSUPP;
+ else
+ ret = sock_hash_update_common(map, key, sk, flags);
sock_map_sk_release(sk);
out:
fput(sock->file);
--
2.20.1
^ permalink raw reply related
* [PATCH] xfs: fix iclog release error check race with shutdown
From: Brian Foster @ 2020-02-14 18:15 UTC (permalink / raw)
To: linux-xfs; +Cc: Zorro Lang
Prior to commit df732b29c8 ("xfs: call xlog_state_release_iclog with
l_icloglock held"), xlog_state_release_iclog() always performed a
locked check of the iclog error state before proceeding into the
sync state processing code. As of this commit, part of
xlog_state_release_iclog() was open-coded into
xfs_log_release_iclog() and as a result the locked error state check
was lost.
The lockless check still exists, but this doesn't account for the
possibility of a race with a shutdown being performed by another
task causing the iclog state to change while the original task waits
on ->l_icloglock. This has reproduced very rarely via generic/475
and manifests as an assert failure in __xlog_state_release_iclog()
due to an unexpected iclog state.
Restore the locked error state check in xlog_state_release_iclog()
to ensure that an iclog state update via shutdown doesn't race with
the iclog release state processing code.
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/xfs_log.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index f6006d94a581..f38fc492a14d 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -611,6 +611,10 @@ xfs_log_release_iclog(
}
if (atomic_dec_and_lock(&iclog->ic_refcnt, &log->l_icloglock)) {
+ if (iclog->ic_state == XLOG_STATE_IOERROR) {
+ spin_unlock(&log->l_icloglock);
+ return -EIO;
+ }
sync = __xlog_state_release_iclog(log, iclog);
spin_unlock(&log->l_icloglock);
if (sync)
--
2.21.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 136/542] bpf: Improve bucket_log calculation logic
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Martin KaFai Lau, Randy Dunlap, Luc Van Oostenryck,
Linus Torvalds, Daniel Borkmann, Sasha Levin, netdev, bpf
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Martin KaFai Lau <kafai@fb.com>
[ Upstream commit 88d6f130e5632bbf419a2e184ec7adcbe241260b ]
It was reported that the max_t, ilog2, and roundup_pow_of_two macros have
exponential effects on the number of states in the sparse checker.
This patch breaks them up by calculating the "nbuckets" first so that the
"bucket_log" only needs to take ilog2().
In addition, Linus mentioned:
Patch looks good, but I'd like to point out that it's not just sparse.
You can see it with a simple
make net/core/bpf_sk_storage.i
grep 'smap->bucket_log = ' net/core/bpf_sk_storage.i | wc
and see the end result:
1 365071 2686974
That's one line (the assignment line) that is 2,686,974 characters in
length.
Now, sparse does happen to react particularly badly to that (I didn't
look to why, but I suspect it's just that evaluating all the types
that don't actually ever end up getting used ends up being much more
expensive than it should be), but I bet it's not good for gcc either.
Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Link: https://lore.kernel.org/bpf/20200207081810.3918919-1-kafai@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/bpf_sk_storage.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index 458be6b3eda97..3ab23f698221c 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -643,9 +643,10 @@ static struct bpf_map *bpf_sk_storage_map_alloc(union bpf_attr *attr)
return ERR_PTR(-ENOMEM);
bpf_map_init_from_attr(&smap->map, attr);
+ nbuckets = roundup_pow_of_two(num_possible_cpus());
/* Use at least 2 buckets, select_bucket() is undefined behavior with 1 bucket */
- smap->bucket_log = max_t(u32, 1, ilog2(roundup_pow_of_two(num_possible_cpus())));
- nbuckets = 1U << smap->bucket_log;
+ nbuckets = max_t(u32, 2, nbuckets);
+ smap->bucket_log = ilog2(nbuckets);
cost = sizeof(*smap->buckets) * nbuckets + sizeof(*smap);
ret = bpf_map_charge_init(&smap->map.memory, cost);
--
2.20.1
^ permalink raw reply related
* Re: RPI4: fail too boot with an initrd
From: James Morse @ 2020-02-14 18:15 UTC (permalink / raw)
To: LABBE Corentin
Cc: u-boot, nsaenzjulienne, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20200214132748.GA23276@Red>
Hi Corentin,
On 14/02/2020 13:27, LABBE Corentin wrote:
> Since the inclusion of the "enable network support in RPi4 config" serie on uboot, I
> have started to work on adding the rpi4 in kernelCI.
> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
>
> Using booti I hit:
> [ 0.000000] Linux version 5.6.0-rc1-next-20200212 (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> [ 0.000000] Machine model: Raspberry Pi 4 Model B
> [ 0.000000] earlycon: uart0 at MMIO32 0x00000000fe215040 (options '')
> [ 0.000000] printk: bootconsole [uart0] enabled
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: UEFI not found.
So no EFI,
> [ 0.000000] OF: reserved mem: failed to allocate memory for node 'linux,cma'
Out of memory.
> [ 0.000000] cma: Failed to reserve 32 MiB
> [ 0.000000] Kernel panic - not syncing: Failed to allocate page table page
Out of memory...
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc1-next-20200212 #66
> [ 0.000000] Hardware name: Raspberry Pi 4 Model B (DT)
> [ 0.000000] Call trace:
> [ 0.000000] dump_backtrace+0x0/0x1a0
> [ 0.000000] show_stack+0x14/0x20
> [ 0.000000] dump_stack+0xbc/0x104
> [ 0.000000] panic+0x16c/0x37c
> [ 0.000000] early_pgtable_alloc+0x30/0xa0
... really early!
> [ 0.000000] __create_pgd_mapping+0x36c/0x588
> [ 0.000000] map_kernel_segment+0x70/0xa4
> [ 0.000000] paging_init+0xf4/0x528
> [ 0.000000] setup_arch+0x250/0x5d8
> [ 0.000000] start_kernel+0x90/0x6d8
>
>
> Since the same kernel boot with bootefi and that bootefi lack ramdisk address,
Booting with EFI will cause linux to use the EFI memory map.
Does your DT have a memory node? (or does it expect EFI to provide the information)
> I tried to add the address in the dtb via:
> fdt addr 0x02400000; fdt resize; fdt set /chosen linux,initrd-start 0x02700000; fdt set /chosen linux,initrd-end 0x10000000; bootefi 0x00080000 0x02400000
> But with that, I get:
> initrd not fully accessible via the linear mapping -- please check your bootloader ...
So this one is an EFI boot, but you can't find where to put the initramfs such that the
kernel agrees its in memory.
If you boot with 'efi=debug', linux will print the EFI memory map. Could you compare that
to where U-Boot thinks memory is?
(it sounds like your DT memory node is missing, and your EFI memory map is surprisingly small)
Thanks,
James
^ permalink raw reply
* RPI4: fail too boot with an initrd
From: James Morse @ 2020-02-14 18:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200214132748.GA23276@Red>
Hi Corentin,
On 14/02/2020 13:27, LABBE Corentin wrote:
> Since the inclusion of the "enable network support in RPi4 config" serie on uboot, I
> have started to work on adding the rpi4 in kernelCI.
> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
>
> Using booti I hit:
> [ 0.000000] Linux version 5.6.0-rc1-next-20200212 (clabbe at build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> [ 0.000000] Machine model: Raspberry Pi 4 Model B
> [ 0.000000] earlycon: uart0 at MMIO32 0x00000000fe215040 (options '')
> [ 0.000000] printk: bootconsole [uart0] enabled
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: UEFI not found.
So no EFI,
> [ 0.000000] OF: reserved mem: failed to allocate memory for node 'linux,cma'
Out of memory.
> [ 0.000000] cma: Failed to reserve 32 MiB
> [ 0.000000] Kernel panic - not syncing: Failed to allocate page table page
Out of memory...
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc1-next-20200212 #66
> [ 0.000000] Hardware name: Raspberry Pi 4 Model B (DT)
> [ 0.000000] Call trace:
> [ 0.000000] dump_backtrace+0x0/0x1a0
> [ 0.000000] show_stack+0x14/0x20
> [ 0.000000] dump_stack+0xbc/0x104
> [ 0.000000] panic+0x16c/0x37c
> [ 0.000000] early_pgtable_alloc+0x30/0xa0
... really early!
> [ 0.000000] __create_pgd_mapping+0x36c/0x588
> [ 0.000000] map_kernel_segment+0x70/0xa4
> [ 0.000000] paging_init+0xf4/0x528
> [ 0.000000] setup_arch+0x250/0x5d8
> [ 0.000000] start_kernel+0x90/0x6d8
>
>
> Since the same kernel boot with bootefi and that bootefi lack ramdisk address,
Booting with EFI will cause linux to use the EFI memory map.
Does your DT have a memory node? (or does it expect EFI to provide the information)
> I tried to add the address in the dtb via:
> fdt addr 0x02400000; fdt resize; fdt set /chosen linux,initrd-start 0x02700000; fdt set /chosen linux,initrd-end 0x10000000; bootefi 0x00080000 0x02400000
> But with that, I get:
> initrd not fully accessible via the linear mapping -- please check your bootloader ...
So this one is an EFI boot, but you can't find where to put the initramfs such that the
kernel agrees its in memory.
If you boot with 'efi=debug', linux will print the EFI memory map. Could you compare that
to where U-Boot thinks memory is?
(it sounds like your DT memory node is missing, and your EFI memory map is surprisingly small)
Thanks,
James
^ permalink raw reply
* [PATCH AUTOSEL 5.5 140/542] drm/amdgpu: remove set but not used variable 'dig_connector'
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: yu kuai, Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: yu kuai <yukuai3@huawei.com>
[ Upstream commit 5bea7fedb7fe4d5e6d3ba9f385dd3619fb004ce7 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c: In function
‘amdgpu_atombios_dp_get_panel_mode’:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c:364:36: warning: variable
‘dig_connector’ set but not used [-Wunused-but-set-variable]
It is never used, so can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 6858cde9fc5d3..94265306ab11f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -361,7 +361,6 @@ int amdgpu_atombios_dp_get_panel_mode(struct drm_encoder *encoder,
struct drm_connector *connector)
{
struct amdgpu_connector *amdgpu_connector = to_amdgpu_connector(connector);
- struct amdgpu_connector_atom_dig *dig_connector;
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
u16 dp_bridge = amdgpu_connector_encoder_get_dp_bridge_encoder_id(connector);
u8 tmp;
@@ -369,8 +368,6 @@ int amdgpu_atombios_dp_get_panel_mode(struct drm_encoder *encoder,
if (!amdgpu_connector->con_priv)
return panel_mode;
- dig_connector = amdgpu_connector->con_priv;
-
if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
/* DP bridge chips */
if (drm_dp_dpcd_readb(&amdgpu_connector->ddc_bus->aux,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 142/542] drm/amdgpu: remove always false comparison in 'amdgpu_atombios_i2c_process_i2c_ch'
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: yu kuai, Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: yu kuai <yukuai3@huawei.com>
[ Upstream commit 220ac8d1444054ade07ce14498fcda266410f90e ]
Fixes gcc '-Wtype-limits' warning:
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c: In function
‘amdgpu_atombios_i2c_process_i2c_ch’:
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c:79:11: warning: comparison is
always false due to limited range of data type [-Wtype-limits]
'num' is 'u8', so it will never be greater than 'TOM_MAX_HW_I2C_READ',
which is defined as 255. Therefore, the comparison can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
index 980c363b1a0ae..b4cc7c55fa16f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
@@ -76,11 +76,6 @@ static int amdgpu_atombios_i2c_process_i2c_ch(struct amdgpu_i2c_chan *chan,
}
args.lpI2CDataOut = cpu_to_le16(out);
} else {
- if (num > ATOM_MAX_HW_I2C_READ) {
- DRM_ERROR("hw i2c: tried to read too many bytes (%d vs 255)\n", num);
- r = -EINVAL;
- goto done;
- }
args.ucRegIndex = 0;
args.lpI2CDataOut = 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 131/542] drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS mode
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Yong Zhao, Felix Kuehling, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Yong Zhao <Yong.Zhao@amd.com>
[ Upstream commit f38abc15d157b7b31fa7f651dc8bf92858c963f8 ]
The sdma_queue_count increment should be done before
execute_queues_cpsch(), which calls pm_calc_rlib_size() where
sdma_queue_count is used to calculate whether over_subscription is
triggered.
With the previous code, when a SDMA queue is created,
compute_queue_count in pm_calc_rlib_size() is one more than the
actual compute queue number, because the queue_count has been
incremented while sdma_queue_count has not. This patch fixes that.
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 984c2f2b24b60..d128a8bbe19d0 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1225,16 +1225,18 @@ static int create_queue_cpsch(struct device_queue_manager *dqm, struct queue *q,
list_add(&q->list, &qpd->queues_list);
qpd->queue_count++;
+
+ if (q->properties.type == KFD_QUEUE_TYPE_SDMA)
+ dqm->sdma_queue_count++;
+ else if (q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI)
+ dqm->xgmi_sdma_queue_count++;
+
if (q->properties.is_active) {
dqm->queue_count++;
retval = execute_queues_cpsch(dqm,
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
}
- if (q->properties.type == KFD_QUEUE_TYPE_SDMA)
- dqm->sdma_queue_count++;
- else if (q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI)
- dqm->xgmi_sdma_queue_count++;
/*
* Unconditionally increment this counter, regardless of the queue's
* type or whether the queue is active.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 0/3] random: add random.rng_seed to bootconfig entry
From: Rob Herring @ 2020-02-14 18:14 UTC (permalink / raw)
To: Mark Salyzyn
Cc: Masami Hiramatsu, linux-kernel@vger.kernel.org,
Android Kernel Team, Theodore Ts'o, Arnd Bergmann,
Greg Kroah-Hartman, Richard Henderson, Mark Brown, Kees Cook,
Hsin-Yi Wang, Vasily Gorbik, Andrew Morton, Steven Rostedt,
Mike Rapoport, Arvind Sankar, Dominik Brodowski, Thomas Gleixner,
Alexander Potapenko, Jonathan Corbet, Mauro Carvalho Chehab,
Josh Poimboeuf, Pawan Gupta, Juergen Gross,
Linux Doc Mailing List
In-Reply-To: <1694f42c-bfc9-570a-64d2-3984965c8940@android.com>
On Fri, Feb 14, 2020 at 11:00 AM Mark Salyzyn <salyzyn@android.com> wrote:
>
> On 2/14/20 5:49 AM, Rob Herring wrote:
> > On Fri, Feb 14, 2020 at 12:10 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >> Hi,
> >>
> >> The following series is bootconfig based implementation of
> >> the rng_seed option patch originally from Mark Salyzyn.
> >> Note that I removed unrelated command line fixes from this
> >> series.
> > Why do we need this? There's already multiple other ways to pass
> > random seed and this doesn't pass the "too complex for the command
> > line" argument you had for needing bootconfig.
> >
> > Rob
>
> Android is the use case I can vouch for. But also KVM.
>
> Android Cuttlefish is an emulated device used extensively in the testing
> and development infrastructure for In-house, partner, and system and
> application developers for Android. There is no bootloader, per-se.
> Because of the Android GKI distribution, there is also no rng virtual
> driver built in, it is loaded later as a module, too late for many
> aspects of KASLR and networking. There is no Device Tree, it does
> however have access to the content of the initrd image, and to the
> command line for the kernel. The only convenient way to get early
> entropy is going to have to be one of those two places.
I'm familiar with Cuttlefish somewhat. Guess who got virtio-gpu
working on Android[1]. :) I assume DT doesn't work for you because you
need x86 builds, but doesn't QEMU use UEFI in that case which also has
a mechanism for passing entropy.
To clarify my question: Why do we need random seed in bootconfig
rather than just the kernel command line? I'm not understanding why
things changed from your original patch.
> In addition, 2B Android devices on the planet, especially in light of
> the Android GKI distribution were everything that is vendor created is
> in a module, needs a way to collect early entropy prior to module load
> and pass it to the kernel. Yes, they do have access to the recently
> added Device Tree approach, and we expect them to use it, as I have an
> active backport for the mechanism into the Android 4.19 and 5.4 kernels.
> There may also be some benefit to allowing the 13000 different
> bootloaders an option to use bootconfig as a way of propagating the much
> needed entropy to their kernels. I could make a case to also allow them
> command line as another option to relieve their development stress to
> deliver product, but we can stop there. Regardless, this early entropy
> has the benefit of greatly improving security and precious boot time.
We're going to update 13000 bootloaders to understand bootconfig
rather than use the infrastructure already in place (DT and/or command
line)?
bootconfig is an ftrace feature only IMO. If it's more than that, I
imagine there will be some opinions about that. Adding new
bootloader-kernel interfaces is painful and not something to just add
without much review.
Rob
^ permalink raw reply
* Re: [PATCH 2/3] random: rng-seed source is utf-8
From: Hsin-Yi Wang @ 2020-02-14 18:14 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: lkml, kernel-team, Mark Salyzyn, Theodore Ts'o, Arnd Bergmann,
Greg Kroah-Hartman, Richard Henderson, Mark Brown, Kees Cook,
Vasily Gorbik, Andrew Morton, Steven Rostedt, Mike Rapoport,
Arvind Sankar, Dominik Brodowski, Thomas Gleixner,
Alexander Potapenko, Jonathan Corbet, Mauro Carvalho Chehab,
Josh Poimboeuf, Pawan Gupta, Juergen Gross, Rob Herring,
linux-doc
In-Reply-To: <158166062748.9887.15284887096084339722.stgit@devnote2>
On Fri, Feb 14, 2020 at 2:10 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> From: Mark Salyzyn <salyzyn@android.com>
>
> commit 428826f5358c922dc378830a1717b682c0823160
> ("fdt: add support for rng-seed") makes the assumption that the data
> in rng-seed is binary, when it is typically constructed of utf-8
> characters which has a bitness of roughly 6 to give appropriate
> credit due for the entropy.
>
> Fixes: 428826f5358c ("fdt: add support for rng-seed")
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: kernel-team@android.com
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Theodore Y. Ts'o <tytso@mit.edu>
> ---
> drivers/char/random.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index c7f9584de2c8..ee21a6a584b1 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -2306,7 +2306,7 @@ EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
> void add_bootloader_randomness(const void *buf, unsigned int size)
> {
> if (IS_ENABLED(CONFIG_RANDOM_TRUST_BOOTLOADER))
> - add_hwgenerator_randomness(buf, size, size * 8);
> + add_hwgenerator_randomness(buf, size, size * 6);
Hi,
In the next patch, entropy is added by
+ add_device_randomness(rng_seed, strlen(rng_seed));
+ credit_trusted_entropy_bits(strlen(rng_seed) * 6);
If the add_bootloader_randomness() function is only used for dt, do we
need to shorten the credit bits?
In dt-schema[1] we stated that this is a uint8 array, and dt is able
to generate this. It doesn't need to avoid using space for parameter
splitting.
For some device, asking for random number is time consuming. Shorten
the credit length makes it have to generate longer seed for dt to meet
the CRNG_INIT_CNT_THRESH threshold.
[1] https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml#L55
Thanks
^ permalink raw reply
* [PATCH AUTOSEL 5.5 147/542] drm/amdgpu: remove set but not used variable 'amdgpu_connector'
From: Sasha Levin @ 2020-02-14 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: yu kuai, Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: yu kuai <yukuai3@huawei.com>
[ Upstream commit 4f2922d12d6c63d0f4aa4e859ad95aee6d0d4ea0 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function
‘amdgpu_display_crtc_scaling_mode_fixup’:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:693:27: warning: variable
‘amdgpu_connector’ set but not used [-Wunused-but-set-variable]
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 3cadb0b76f221..4e699071d1443 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -690,7 +690,6 @@ bool amdgpu_display_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_encoder *amdgpu_encoder;
struct drm_connector *connector;
- struct amdgpu_connector *amdgpu_connector;
u32 src_v = 1, dst_v = 1;
u32 src_h = 1, dst_h = 1;
@@ -702,7 +701,6 @@ bool amdgpu_display_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
continue;
amdgpu_encoder = to_amdgpu_encoder(encoder);
connector = amdgpu_get_connector_for_encoder(encoder);
- amdgpu_connector = to_amdgpu_connector(connector);
/* set scaling */
if (amdgpu_encoder->rmx_type == RMX_OFF)
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.