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
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 <labb...@redhat.com>
---
v2: Switch to a tighter upper bo
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 <l
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.
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 <mark.rutl...@arm.com>
This patch implements nospec_ptr() for arm, following the recommended
architectural sequences for the arm and
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
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
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
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
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
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
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:
An extra entry for MDIO_XGENE got added during merging.
Delete it.
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
drivers/net/phy/Kconfig | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/phy/Kconf
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
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 <labb...@redhat.com>
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
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 =
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
On 03/14/2016 12:24 PM, David Miller wrote:
From: Claudio Imbrenda <imbre...@linux.vnet.ibm.com>
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 con
row 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 <v...@freedesktop.org>
Tested-by: Vinson Lee <v...@freedesktop.org>
Signed-off-by: Laura Abbott <labb...@fedoraproject.org>
---
v2: fix same issue in
row the scope of
the prepare_to_wait to avoid the bad call.
Signed-off-by: Laura Abbott <labb...@fedoraproject.org>
---
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 issu
n.
Modify the check to use rcu_dereference_check() to permit this.
Fixes: 9513c5e18a0d ("iwlwifi: mvm: Avoid dereferencing sta if it was already
flushed")
Reported-by: Laura Abbott <labb...@redhat.com>
Signed-off-by: Johannes Berg <johannes.b...@intel.com>
Thanks, it's working f
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!
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")
copy_to_user so it should
not be called inside a prepare_to_wait. Narrow the scope of
the prepare_to_wait to avoid the bad call.
Signed-off-by: Laura Abbott labb...@fedoraproject.org
---
The bug report looks valid but I haven't heard back from the reporter whether
or not it fixed the problem, hence
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 labb...@fedoraproject.org
---
Now the setup function is called again with the HCI_RESET_RESUME
flag set. The various functions could then use
HCI_RESET_RESUME will be set to allow
drivers to differentate.
Signed-off-by: Laura Abbott labb...@fedoraproject.org
---
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
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
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),
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?
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.
-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 labb...@fedoraproject.org
---
I think this should be fixing the actual root cause.
---
net/bluetooth/hci_core.c | 3
34 matches
Mail list logo