[PATCH] Bluetooth: Make request workqueue freezable

-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

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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.

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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

[PATCH 2/2] Bluetooth: btusb: Add reset_resume function

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

[PATCH 1/2] Bluetooth: Add reset_resume function

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

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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),

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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?

[RFC][NOT TESTED][PATCH] vsock: Fix blocking ops call in prepare_to_wait

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

Re: [PATCH v2 net-next] net/core: ensure features get disabled on new lower devs

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")

Re: [PATCH] iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

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

Suspicious RCU from iwlwifi driver

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!

[PATCHv2] vsock: Fix blocking ops call in prepare_to_wait

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

[RESEND][RFC][PATCH] vsock: Fix blocking ops call in prepare_to_wait

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

Re: [PATCH v2 1/2] Revert "vsock: Fix blocking ops call in prepare_to_wait"

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

Re: [PATCHv2] vsock: Fix blocking ops call in prepare_to_wait

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

[PATCH] drivers: net: phy: Correct duplicate MDIO_XGENE entry

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

Duplicate MDIO_XGENE Kconfig entries

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

Re: [REGRESSION] Select hang with zero sized UDP packets

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

[REGRESSION] Select hang with zero sized UDP packets

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 =

Oops with CONFIG_VMAP_STCK and bond device + virtio-net

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:

Re: [net/bpf] 3051bf36c2 BUG: unable to handle kernel paging request at 0000a7cf

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

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

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,

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

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

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

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

Lockdep splat with tc filter on 4.11

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

Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression

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

319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression

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:

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

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

Re: [PATCH 04/18] arm: implement nospec_ptr()

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

Re: [PATCH 04/18] arm: implement nospec_ptr()

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

Re: [PATCH 27/38] sctp: Copy struct sctp_sock.autoclose to userspace using put_user()

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.

[PATCH] mISDN: Remove VLAs

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

[PATCHv2] mISDN: Remove VLAs

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

Regression with 5dcd8400884c ("macsec: missing dev_put() on error in macsec_newlink()")

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