Hi,
Fedora got a bug report of a regression when trying to remove the
the macsec module (https://bugzilla.redhat.com/show_bug.cgi?id=1566410).
I did a bisect and found
commit 5dcd8400884cc4a043a6d4617e042489e5d566a9
Author: Dan Carpenter
Date: Wed Mar 21 11:09:01 2018 +0300
macsec: missi
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Remove the VLAs from the mISDN code by switching to using
kstrdup in one place and using an upper bound in another.
Signed-off-by: Laura Abbott
---
v2: Switch to a tighter upper bound so we are allocat
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Remove the VLAs from the mISDN code by switching to using
kstrdup in one place and just using the upper bound in another.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
dr
On 01/10/2018 06:02 PM, Kees Cook wrote:
From: David Windsor
The autoclose field can be copied with put_user(), so there is no need to
use copy_to_user(). In both cases, hardened usercopy is being bypassed
since the size is constant, and not open to runtime manipulation.
This patch is verbatim
On 01/09/2018 11:40 PM, Hanjun Guo wrote:
On 2018/1/10 10:04, Laura Abbott wrote:
On 01/05/2018 05:10 PM, Dan Williams wrote:
From: Mark Rutland
This patch implements nospec_ptr() for arm, following the recommended
architectural sequences for the arm and thumb instruction sets.
Fedora
On 01/05/2018 05:10 PM, Dan Williams wrote:
From: Mark Rutland
This patch implements nospec_ptr() for arm, following the recommended
architectural sequences for the arm and thumb instruction sets.
Fedora picked up the series and it fails on arm:
In file included from ./include/linux/compile
On 11/07/2017 02:32 AM, Tobin C. Harding wrote:
Currently we are leaking addresses from the kernel to user space. This
script is an attempt to find some of those leakages. Script parses
`dmesg` output and /proc and /sys files for hex strings that look like
kernel addresses.
Only works for 64 bit
On 09/12/2017 04:12 PM, Josef Bacik wrote:
First I’m super sorry for the top post, I’m at plumbers and I forgot to upload
my muttrc to my new cloud instance, so I’m screwed using outlook.
I have a completely untested, uncompiled patch that I think will fix the
problem, would you mind giving it
Hi,
Fedora got a bug report
https://bugzilla.redhat.com/show_bug.cgi?id=1432684 of a regression with
automatic spice port
assignment. The libvirt team reduced this to the attached test
case run as follows:
In a separate terminal, qemu-kvm -vnc 127.0.0.1:0 to grab port 5900.
Then do this:
$
On 07/28/2017 07:23 AM, Tom Bogendoerfer wrote:
> On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote:
>> I don't know the intricacies of the Mustang hardware but external
>> aborts have been a symptom of missing clocks on other hardware.
>
> you are right,
On 07/27/2017 02:39 PM, Tom Bogendoerfer wrote:
> On Thu, Jul 27, 2017 at 02:03:42PM -0700, Laura Abbott wrote:
>> This change causes boot failures for me on my APM Mustang system running
>> Fedora rawhide:
>>
>> [ 16.669089] Synchronous External Abort: synchronous ex
On 07/13/2017 01:57 AM, Thomas Bogendoerfer wrote:
> From: Thomas Bogendoerfer
>
> This change fixes following problem
>
> [1.827940] xgene-enet: probe of 1f210030.ethernet failed with error -2
>
> which leads to a missing ethernet interface (reproducable at least on
> Gigabyte MP30-AR0 and
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1459626
of a hang on 4.11.3 with lockdep splat:
[ 129.100206] BUG: sleeping function called from invalid context at
mm/slab.h:432
[ 129.100237] in_atomic(): 1, irqs_disabled(): 0, pid: 1793, name: tc
[ 129.100239] 2 locks
On 03/08/2017 02:36 PM, Kees Cook wrote:
> On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
>> [ 28.474232] rodata_test: test data was not read only
>> [...]
>
> In my tests so far, I've never been able to get rodata_test to fail
> (Qemu 2.5.0, Ubuntu). I'll retry with your .config and se
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1401612
In qemu with two virtio-net interfaces:
$ ip l
...
5: ens14: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:e9:64:41 brd ff:ff:ff:ff:ff:ff
6: ens15: mtu 1500 qdisc noop
An extra entry for MDIO_XGENE got added during merging.
Delete it.
Reviewed-by: Andrew Lunn
Signed-off-by: Laura Abbott
---
drivers/net/phy/Kconfig | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5078a0d
Hi,
While working on the Fedora tree today, I noticed that there
seem to be two entries for CONFIG_MDIO_XGENE. It looks like
this might have been fall out from d75b4a22b255 ("net: phy:
Sort Makefile and Kconfig"). I can submit the following if
this isn't fixed up elsewhere already
diff --git a/d
On 08/23/2016 12:03 PM, Eric Dumazet wrote:
On Tue, 2016-08-23 at 11:25 -0700, David Miller wrote:
From: Laura Abbott
Date: Tue, 23 Aug 2016 10:53:26 -0700
Fedora received a report[1] of a unit test failing on Ruby when using
the
4.7 kernel. This was a test to send a zero sized UDP packet
Hi,
Fedora received a report[1] of a unit test failing on Ruby when using the
4.7 kernel. This was a test to send a zero sized UDP packet. With the
4.7 kernel, the test now timing out on a select instead of completing.
The reduced ruby test is
def test_udp_recvfrom_nonblock
u1 = UDPSocket.
On 03/17/2016 09:12 AM, Claudio Imbrenda wrote:
This reverts commit 5988818008257ca42010d6b43a3e0e48afec9898 ("vsock: Fix
blocking ops call in prepare_to_wait")
I don't think having this as a separate patch does a lot of good. You
can probably fold this into the next patch with a note saying t
On 03/14/2016 12:24 PM, David Miller wrote:
From: Claudio Imbrenda
Date: Fri, 11 Mar 2016 13:39:23 +0100
I think I found a problem with the patch submitted by Laura Abbott
( https://lkml.org/lkml/2016/2/4/711 ): we might miss wakeups.
Since the condition is not checked between the
the scope of
the prepare_to_wait to avoid the bad call. This also applies
to vsock_stream_recvmsg as well.
Reported-by: Vinson Lee
Tested-by: Vinson Lee
Signed-off-by: Laura Abbott
---
v2: fix same issue in recvmsg path as well.
---
net/vmw_vsock/af_vsock.c | 19 ++-
1 file chan
the scope of
the prepare_to_wait to avoid the bad call.
Signed-off-by: Laura Abbott
---
Resending since I never heard back. This has been reported by
a couple of times again but nobody ever gets back to me about
whether this actually works. Still seems to be an issue as well.
---
net/vmw_vs
use rcu_dereference_check() to permit this.
Fixes: 9513c5e18a0d ("iwlwifi: mvm: Avoid dereferencing sta if it was already
flushed")
Reported-by: Laura Abbott
Signed-off-by: Johannes Berg
Thanks, it's working for me.
Tested-by: Laura Abbott
--
To unsubscribe from this list: send the line &
Hi,
I'm currently seeing a suspicous RCU usage warning:
===
[ INFO: suspicious RCU usage. ]
4.4.0-rc4-next-20151210 #23 Not tainted
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226 suspicious
rcu_dereference_protected() usage!
o
On 11/13/2015 02:51 AM, Nikolay Aleksandrov wrote:
On 11/13/2015 11:29 AM, Jiri Pirko wrote:
Fri, Nov 13, 2015 at 01:26:18AM CET, f.faine...@gmail.com wrote:
On 04/11/15 18:56, David Miller wrote:
Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down
stack")
..
the scope of
the prepare_to_wait to avoid the bad call.
Signed-off-by: Laura Abbott
---
The bug report looks valid but I haven't heard back from the reporter whether
or not it fixed the problem, hence the submit as an RFC.
---
net/vmw_vsock/af_vsock.c | 7 ++-
1 file changed, 2 insertio
Some USB hubs may lose power across suspend/resume.
Add a reset_resume callback to properly reset those bluetoot devices.
Signed-off-by: Laura Abbott
---
Now the setup function is called again with the HCI_RESET_RESUME
flag set. The various functions could then use that RESET_RESUME
flag to
HCI_RESET_RESUME will be set to allow
drivers to differentate.
Signed-off-by: Laura Abbott
---
This matches with what hci_reset_dev does and also ensures
the setup function gets called again.
---
include/net/bluetooth/hci.h | 1 +
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth
On 05/21/2015 08:13 PM, Marcel Holtmann wrote:
Hi Laura,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
Th
On 05/21/2015 11:11 AM, Takashi Iwai wrote:
At Thu, 21 May 2015 13:37:56 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
A
On 05/20/2015 05:44 AM, Takashi Iwai wrote:
At Wed, 20 May 2015 11:46:31 +0200,
Marcel Holtmann wrote:
Hi Oliver,
The data is cached in RAM. More specifically, the former loaded
firmware files are reloaded and saved at suspend for each device
object. See fw_pm_notify() in firmware_class.c.
g and
usermodehelper has not yet been re-enabled. Fix this by
making the request workqueue freezable. This ensures
the work will not run until unfreezing occurs and usermodehelper
is re-enabled.
Signed-off-by: Laura Abbott
---
I think this should be fixing the actual root cause.
---
net/bluetooth/hci_core.
34 matches
Mail list logo
