started between v4.5 and v4.6
and prevails up to v4.14.
Using the dirty_tx before acquiring the spin lock is clearly
wrong and was first introduced with v4.6.
Fixes: e3ad57c96715 ("stmmac: review RX/TX ring management")
Signed-off-by: Bernd Edlinger <bernd.edlin...@hotmail.de>
ing theory is the cache might freeze before
all data is written out.
Signed-off-by: Bernd Edlinger
---
arch/arm/Kconfig| 7 +++
arch/arm/include/asm/spinlock.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f8e7f..f96a
Ping...
Sorry, I had actually completely forgotten about this one.
On 07/07/18 19:52, Bernd Edlinger wrote:
> The terminating NUL byte is only there because the buffer is
> allocated with kzalloc(PAGE_SIZE, GFP_KERNEL), but since the
> range-check is off-by-one, and PAGE_SIZE=
the returned string
will not be zero-terminated if it is exactly PATH_MAX characters.
Furthermore also the initial loop may theoretically exceed PATH_MAX
and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
On 07/07/18 16:01, Greg Kroah-Hartman wrote:
> On Sat, Jul 07, 2018 at 09:41:03AM +0000, Bernd Edlinger wrote:
>> The strncpy causes a warning [-Wstringop-truncation] here,
>> which indicates that it never appends a NUL byte to the path.
>> The NUL byte is only the
the returned string
will not be zero-terminated if it is exactly PATH_MAX characters.
Furthermore also the initial loop may theoretically exceed PATH_MAX
and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
may theoretically exceed PATH_MAX and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/kernfs/symlink.c b/fs/kernfs/symlink.c
index 08ccabd..774bada 100644
--- a/fs/kernfs/symlink.c
+++ b/fs/kernfs
On 07/08/18 12:41, Masahiro Yamada wrote:
> 2018-07-08 17:09 GMT+09:00 Bernd Edlinger :
>> On 07/08/18 08:31, Bernd Edlinger wrote:
>>> The next make after an oldconfig reads in the outdated
>>> include/config/auto.conf which can kill the make before
>>> it i
is failure.
Signed-off-by: Bernd Edlinger
---
scripts/kconfig/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index a3ac2c9..ef34275 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -62,6 +62,7 @@ PHONY += $(simple
On 07/08/18 08:31, Bernd Edlinger wrote:
> The next make after an oldconfig reads in the outdated
> include/config/auto.conf which can kill the make before
> it is able to call the syncconfig target.
>
> $ make defconfig
> *** Default configuration is based on 'x86_64_d
Hi Eric,
I think I remembered from a previous discussion about this topic,
that it was unclear if the rw_semaphores are working the same
in RT-Linux. Will this fix work in RT as well?
On 12/3/20 9:12 PM, Eric W. Biederman wrote:
> --- a/kernel/kcmp.c
> +++ b/kernel/kcmp.c
> @@ -70,25 +70,25 @@
On 12/4/20 9:10 PM, Linus Torvalds wrote:
> On Fri, Dec 4, 2020 at 11:35 AM Eric W. Biederman
> wrote:
>>
>> From a deadlock perspective the change is strictly better than what we
>> have today. The readers will no longer block on each other.
>
> No, agreed, it's better regardless.
>
>> For
started between v4.5 and v4.6
and prevails up to v4.14.
Using the dirty_tx before acquiring the spin lock is clearly
wrong and was first introduced with v4.6.
Fixes: e3ad57c96715 ("stmmac: review RX/TX ring management")
Signed-off-by: Bernd Edlinger
---
drivers/net/ethernet/stmi
On 4/30/20 6:40 PM, Linus Torvalds wrote:
> On Thu, Apr 30, 2020 at 7:29 AM Bernd Edlinger
> wrote:
>>
>> Ah, now I see, that was of course not the intended effect,
>> but that is not where the pseudo-deadlock happens at all,
>> would returning -RESTARTNOINTR in th
On 4/29/20 7:58 PM, Linus Torvalds wrote:
> On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
>>
>> On Wed, Apr 29, 2020 at 12:14 AM Linus Torvalds
>> wrote:
>>>
>>> - we move check_unsafe_exec() down. As far as I can tell, there's no
>>> reason it's that early - the flags it sets aren't
On 4/29/20 9:26 PM, Jann Horn wrote:
> On Wed, Apr 29, 2020 at 9:23 PM Bernd Edlinger
> wrote:
>> On 4/29/20 7:58 PM, Linus Torvalds wrote:
>>> On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
>>>>
>>>> On Wed, Apr 29, 2020 at 12:14 AM Linus
On 4/30/20 1:59 AM, Jann Horn wrote:
> On Thu, Apr 30, 2020 at 1:22 AM Linus Torvalds
> wrote:
>> On Wed, Apr 29, 2020 at 3:38 PM Linus Torvalds
>> wrote:
>>>
>>> If you do it properly, with a helper function instead of repeating
>>> that fragile nasty thing, maybe it will look better to me.
I
On 4/30/20 4:16 AM, Linus Torvalds wrote:
> On Wed, Apr 29, 2020 at 5:00 PM Jann Horn wrote:
>>
>> Wouldn't you end up livelocked in the scenario that currently deadlocks?
>
> The test case that we already know is broken, and any fix will have to
> change anyway?
>
The purpose of the test case
Hi Linus,
On 4/30/20 3:47 PM, Linus Torvalds wrote:
> On Thu, Apr 30, 2020 at 6:39 AM Bernd Edlinger
> wrote:
>>
>> Excuse me, but what in my /proc folder there is no attr/something
>> is there a procfs equivalent of pthread_attach ?
>>
>> What exactly
Reading from /dev/random may return data while the getrandom
syscall is still blocking.
Those bytes are not yet cryptographically secure.
Make read and select for reading on /dev/random wait until
the crng is fully initialized.
Signed-off-by: Bernd Edlinger
---
drivers/char/random.c | 10
On 1/25/19 1:24 PM, Bernd Edlinger wrote:
> On 1/25/19 12:39 PM, Miguel Ojeda wrote:
>> On Fri, Jan 25, 2019 at 11:58 AM Arnd Bergmann wrote:
>>>
>>> On Fri, Jan 25, 2019 at 11:43 AM Laura Abbott wrote:
>>>>
>>>> Commit bee20031772a ("di
hared keys,
by returning EOPNOTSUPP. However, pairwise keys are
still handled by hardware which works just fine.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 93 ++--
1 file changed, 4 insertions(+), 89 deletions(-)
diff --git a/d
>> Signed-off-by: Laura Abbott
>>> ---
>>> This is RFC because it feels ugly. I went ahead and did the obvious fixup
>>> but it's worth discussing if we're going to end up with an explosion or
>>> if there's a better way to handle this in one macro.
>>
>
On 07/07/18 16:01, Greg Kroah-Hartman wrote:
> On Sat, Jul 07, 2018 at 09:41:03AM +0000, Bernd Edlinger wrote:
>> The strncpy causes a warning [-Wstringop-truncation] here,
>> which indicates that it never appends a NUL byte to the path.
>> The NUL byte is only the
may theoretically exceed PATH_MAX and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/kernfs/symlink.c b/fs/kernfs/symlink.c
index 08ccabd..774bada 100644
--- a/fs/kernfs/symlink.c
+++ b/fs/kernfs
is failure.
Signed-off-by: Bernd Edlinger
---
scripts/kconfig/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index a3ac2c9..ef34275 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -62,6 +62,7 @@ PHONY += $(simple
On 07/08/18 08:31, Bernd Edlinger wrote:
> The next make after an oldconfig reads in the outdated
> include/config/auto.conf which can kill the make before
> it is able to call the syncconfig target.
>
> $ make defconfig
> *** Default configuration is based on 'x86_64_d
On 07/08/18 12:41, Masahiro Yamada wrote:
> 2018-07-08 17:09 GMT+09:00 Bernd Edlinger :
>> On 07/08/18 08:31, Bernd Edlinger wrote:
>>> The next make after an oldconfig reads in the outdated
>>> include/config/auto.conf which can kill the make before
>>> it i
Ping...
Sorry, I had actually completely forgotten about this one.
On 07/07/18 19:52, Bernd Edlinger wrote:
> The terminating NUL byte is only there because the buffer is
> allocated with kzalloc(PAGE_SIZE, GFP_KERNEL), but since the
> range-check is off-by-one, and PAGE_SIZE=
> @@ -1826,7 +1830,9 @@ _random_read(int nonblock, char __user *buf, size_t
> nbytes)
>
> nbytes = min_t(size_t, nbytes, SEC_XFER_SIZE);
> while (1) {
> - n = extract_entropy_user(_pool, buf, nbytes);
> + n = input_pool.initialized
> +
on entropy which would make /dev/random block
unexpectedly.
Signed-off-by: Bernd Edlinger
---
v4 makes the /dev/random block until the input_pool has
reached 128 bits of entropy at least once. Now make
everything depend on input_pool.initialized.
Additionally fixed a potential issue with jiffies
Hi Theodore,
On 2/21/19 1:32 AM, Theodore Y. Ts'o wrote:
> Hi Brend,
>
> I've been looking at your patch, and as far as the core part of what
> you're patching, I think this patch below is a conceptually simpler
> way of fixing the original core problem. Please take a look and let
> me know
On 2/22/19 12:18 AM, Theodore Y. Ts'o wrote:
> The whole premise of reading from /dev/random is that it should only
> allow reads up to available estimated entropy. I'm assuming here that
> sane users of /dev/random will be reading in chunks of at least 128
> bits, reading smaller amounts for,
On 2/15/19 2:47 AM, Bernd Edlinger wrote:
> while (1) {
> - n = extract_entropy_user(_pool, buf, nbytes);
> + n = crng_ready()
> + ? extract_entropy_user(_pool, buf, nbytes)
> + : 0;
Aehm, the whitespace after ?
and select on /dev/random wait until
the crng is fully initialized.
Signed-off-by: Bernd Edlinger
---
v2: Fixed one white space in the code.
Also added some more details about the problem
to the commit message.
---
drivers/char/random.c | 10 +++---
1 file changed, 7 insertions(+), 3
On 2/16/19 7:23 PM, Theodore Y. Ts'o wrote:
>
> This really isn't a correct way to fix things; since the blocking_pool
> used for /dev/random and the CRNG state are different things, and are
> fed by different sources of entropy.
>
It is interesting that random_poll does only look at
and select on /dev/random wait until
the crng is fully initialized and the blocking_pool is
also initialized which means that more than 128 bits of
entopy have been accumulated in the blocking_pool.
Signed-off-by: Bernd Edlinger
---
The v3 version waits much longer than the v2 version,
since
On 2/17/19 9:44 AM, Bernd Edlinger wrote:
>
> + if (crng_ready() && !blocking_pool.initialized &&
After some more debugging I realize that blocking_pool.initialized
is true after 128 bits of input entropy, but that is only 80 bits
credited, due to the as
on entropy which would make /dev/random block
unexpectedly.
Signed-off-by: Bernd Edlinger
---
v4 makes the /dev/random block until the input_pool has
reached 128 bits of entropy at least once. Now make
everything depend on input_pool.initialized.
Additionally fixed a potential issue with jiffies
-activated once a firmware
update is available.
v3: Make the title of each patch fit in one line.
Bernd Edlinger (4):
rtl8723ae: Take the FW LPS mode handling out
rtl8723ae: Dont use old data for input gain control
rtl8723ae: Re-introduce the adaptive rate control
rtlwifi: Don't clear
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
v2: Adjust the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
-by: Bernd Edlinger
---
v2: Improved patch description.
v3: Make the title fit in one line.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/realtek
This patch moves the clearing of rtlpriv->link_info.num_rx_inperiod in
rtl_watchdog_wq_callback a few lines down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Sign
no beacon was received.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
v2: Improve patch description.
v3: Improve patch description, mention that dm.undec_sm_pwdb
is not used when no beacon received.
Make the title fit in one line.
---
.../net/wireless
rtl8723e_dm_refresh_rate_adaptive_mask
This function was present in a previous version of the code base,
it works just fine for me -- as long as it is not using stale data.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek
with the rtl8723ae PCI card in my laptop
against a FRITZ!Box 7590 AP -- the WiFi connection works now
very reliable for me.
Bernd Edlinger (4):
rtlwifi: rtl8723ae: Take the FW LPS mode handling out
rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control
when no beacon
rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines
down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Signed-off-by: Bernd Edlinger
-
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c| 20
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw
gain control when no beacon was received in the connected state.
This avoids sporadic "Connection to AP ... lost" errors.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
On 1/5/19 3:44 AM, Larry Finger wrote:
> On 1/4/19 6:48 AM, Bernd Edlinger wrote:
>> This appears to trigger a firmware bug and causes severe
>> problems with rtl8723ae PCI devices.
>>
>> When the power save mode is activated for longer periods
>> of time the firm
On 1/5/19 5:13 PM, Larry Finger wrote:
>> but this works:
>>
>> modprobe rtl8723ae debug_mask=0x debug_level=5 swlps=1 fwlps=0
>
> Yes, I think that is a better thing to do now. If and when Realtek finds a
> firmware bug, and when the new firmware is readily available, then there will
>
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
-activated once a firmware
update is available.
Bernd Edlinger (4):
rtlwifi: rtl8723ae: Take the FW LPS mode handling out
rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control
when no beacon was received in the connected state
rtlwifi: rtl8723ae: Re-introduce
pre_cck_fa_state/cur_cck_fa_state in
rtl_dm_diginit.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi
rtl8723e_dm_refresh_rate_adaptive_mask
This function was present in a previous version of the code base,
it works just fine for me -- as long as it is not using stale data.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek
rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines
down
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Signed-off-by: Bernd Edlinger
---
driv
On 1/8/19 6:27 PM, Kalle Valo wrote:
> Bernd Edlinger writes:
>
>> This appears to trigger a firmware bug and causes severe
>> problems with rtl8723ae PCI devices.
>>
>> When the power save mode is activated for longer periods
>> of time the f
-by: Bernd Edlinger
---
v2: Improved patch description.
v3: Make the title fit in one line.
v4: Try to fix the line endings the message body.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
v2: Adjust the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
-activated once a firmware
update is available.
v3: Make the title of each patch fit in one line.
v4: Try to fix the line endings the message body.
Which is an exchange server issue.
The patch does not change at all.
Bernd Edlinger (4):
rtl8723ae: Take the FW LPS mode handling out
no beacon was received.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
v2: Improve patch description.
v3: Improve patch description, mention that dm.undec_sm_pwdb
is not used when no beacon received.
Make the title fit in one line.
v4: Try to fix the line
This patch moves the clearing of rtlpriv->link_info.num_rx_inperiod in
rtl_watchdog_wq_callback a few lines down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Sign
the returned string
will not be zero-terminated if it is exactly PATH_MAX characters.
Furthermore also the initial loop may theoretically exceed PATH_MAX
and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
the returned string
will not be zero-terminated if it is exactly PATH_MAX characters.
Furthermore also the initial loop may theoretically exceed PATH_MAX
and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
ing theory is the cache might freeze before
all data is written out.
Signed-off-by: Bernd Edlinger
---
arch/arm/Kconfig| 7 +++
arch/arm/include/asm/spinlock.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f8e7f..f96a
65 matches
Mail list logo
