Re: O_DIRECT to md raid 6 is slow
On Wed, 15 Aug 2012 18:50:44 -0500 Stan Hoeppner wrote: > TTBOMK there are two, and only two, COW filesystems in existence: ZFS and > BTRFS. There is also NILFS2: http://www.nilfs.org/en/ And in general, any https://en.wikipedia.org/wiki/Log-structured_file_system is COW by design, but afaik of those only NILFS is also in the mainline Linux kernel AND is not aimed just for some niche like flash-based devices, but for general-purpose usage. -- With respect, Roman ~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." signature.asc Description: PGP signature
Re: [GIT PULL] Update LZO compression
On Thu, 16 Aug 2012 17:06:47 +0200
Johannes Stezenbach wrote:
> Well, ~2x speedup on x86 is certainly a good achievement, but there
> are more ARM based devices than there are PCs, and I guess many
> embedded devices use lzo compressed kernels and file systems
> while I'm not convinced many PCs rely on lzo in the kernel.
Keep in mind that a major user of LZO is the BTRFS filesystem, and I believe it
is used much more often on larger machines than on ARM, in fact it had problems
operating on ARM at all, until quite recently.
> I know everyone's either busy or on vacation, but it would
> be so cool if someone could test on a more modern ARM core,
> with the userspace test code I posted it should be easy to do.
I have locked the Allwinner A10 CPU in my Mele A2000 to 60 MHz using
cpufreq-set,
and ran your test. rnd.lzo is a 9 MB file from /dev/urandom compressed with lzo.
There doesn't seem to be a significant difference between all three variants.
# time for i in {1..20}; do old/unlzop < rnd.lzo >/dev/null ; done
real0m11.353s
user0m3.060s
sys 0m8.170s
# time for i in {1..20}; do new/unlzop < rnd.lzo >/dev/null ; done
real0m11.416s
user0m3.030s
sys 0m8.200s
# time for i in {1..20}; do test/unlzop < rnd.lzo >/dev/null ; done
real0m11.310s
user0m3.100s
sys 0m8.150s
--
With respect,
Roman
~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."
signature.asc
Description: PGP signature
Re: Filesystem corruption MD (imsm) Raid0 via 2 SSD's + discard
On Wed, 20 May 2015 20:12:31 + (UTC) Holger Kiehl wrote: > The kernel I was running when I discovered the > problem was 4.0.2 from kernel.org. However, after reinstalling from DVD > I updated to Fedora's lattest kernel, which was 3.19.? (I do not remember > the last numbers). So that kernel seems also effected, but I assume it > contains many 'fixes' from 4.0.x. As filesystem I use ext4, distribution > is Fedora 21 and hardware is: Xeon E3-1275, 16GB ECC Ram. > > My system seems to be now running stable for some days with kernel.org > kernel 4.0.3 and with discard DISABLED. But I am still unsure what could > be the real cause. It is a bug in the 4.0.2 kernel, fixed in 4.0.3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 https://bbs.archlinux.org/viewtopic.php?id=197400 https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/d2dc317d564a46dfc683978a2e5a4f91434e9711 -- With respect, Roman signature.asc Description: PGP signature
Re: [PATCH] Revert "ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb"
On Wed, 1 Jul 2020 17:53:27 +0200
Viktor Jägersküpper wrote:
> Kalle Valo writes:
> > Roman Mamedov writes:
> >
> >> On Sat, 4 Apr 2020 12:18:38 +0800
> >> Qiujun Huang wrote:
> >>
> >>> In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
> >>> usb_ifnum_to_if(urb->dev, 0)
> >>> But it isn't always true.
> >>>
> >>> The case reported by syzbot:
> >>> https://lore.kernel.org/linux-usb/666c9c05a1c05...@google.com
> >>> usb 2-1: new high-speed USB device number 2 using dummy_hcd
> >>> usb 2-1: config 1 has an invalid interface number: 2 but max is 0
> >>> usb 2-1: config 1 has no interface number 0
> >>> usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
> >>> 1.08
> >>> usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> >>> general protection fault, probably for non-canonical address
> >>> 0xdc15: [#1] SMP KASAN
> >>> KASAN: null-ptr-deref in range [0x00a8-0x00af]
> >>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0
> >>>
> >>> Call Trace
> >>> __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
> >>> usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
> >>> dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
> >>> call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
> >>> expire_timers kernel/time/timer.c:1449 [inline]
> >>> __run_timers kernel/time/timer.c:1773 [inline]
> >>> __run_timers kernel/time/timer.c:1740 [inline]
> >>> run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
> >>> __do_softirq+0x21e/0x950 kernel/softirq.c:292
> >>> invoke_softirq kernel/softirq.c:373 [inline]
> >>> irq_exit+0x178/0x1a0 kernel/softirq.c:413
> >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> >>> smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
> >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> >>>
> >>> Reported-and-tested-by:
> >>> syzbot+40d5d2e8a4680952f...@syzkaller.appspotmail.com
> >>> Signed-off-by: Qiujun Huang
> >>
> >> This causes complete breakage of ath9k operation across all the stable
> >> kernel
> >> series it got backported to, and I guess the mainline as well. Please see:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=208251
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1848631
> >
> > So there's no fix for this? I was under impression that someone fixed
> > this, but maybe I'm mixing with something else.
> >
> > If this is not fixed can someone please submit a patch to revert the
> > offending commit (or commits) so that we get ath9k working again?
> >
>
> This reverts commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 ("ath9k: Fix
> general protection fault
> in ath9k_hif_usb_rx_cb") because the driver gets stuck like this:
>
> [5.778803] usb 1-5: Manufacturer: ATHEROS
> [ 21.697488] usb 1-5: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw
> requested
> [ 21.701377] usbcore: registered new interface driver ath9k_htc
> [ 22.053705] usb 1-5: ath9k_htc: Transferred FW:
> ath9k_htc/htc_9271-1.4.0.fw, size: 51008
> [ 22.306182] ath9k_htc 1-5:1.0: ath9k_htc: HTC initialized with 33 credits
> [ 115.708513] ath9k_htc: Failed to initialize the device
> [ 115.708683] usb 1-5: ath9k_htc: USB layer deinitialized
>
> Reported-by: Roman Mamedov
> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=208251
> Fixes: 2bbcaaee1fcb ("ath9k: Fix general protection fault in
> ath9k_hif_usb_rx_cb")
> Tested-by: Viktor Jägersküpper
> Signed-off-by: Viktor Jägersküpper
> ---
>
> I couldn't find any fix for this, so here is the patch which reverts the
> offending commit. I have tested it with 5.8.0-rc3 and with 5.7.4.
>
> Feel free to change the commit message if it is necessary or appropriate, I am
> just a user affected by this bug.
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
> b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 4ed21dad6a8e..6049d3766c64 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -643,9 +643,9 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb
> *hif_dev,
>
> static void ath9k_hif_usb_rx_cb(struct urb *urb)
> {
> - struct rx_buf *
Re: ath9k broken [was: Linux 5.7.3]
On Thu, 25 Jun 2020 06:57:13 +0200 Jiri Slaby wrote: > I fail to see how the commit could cause an issue like this. Is this > really reproducibly broken with the commit and irreproducible without > it? As it looks like a USB/wiring problem: > usb 1-2: USB disconnect, device number 2 > ath: phy0: Reading Magic # failed > ath: phy0: Unable to initialize hardware; initialization status: -5 > ... > usb 1-2: device descriptor read/64, error -110 > usb 1-2: device descriptor read/64, error -71 > > Ccing ath9k maintainers too. Note that this has been previously reported in: https://bugzilla.kernel.org/show_bug.cgi?id=208251 and confirmed by several people on various stable series and the mainline that the referenced commit is indeed causing the problem. I don't get the "device descriptor read" errors though, my dmesg is posted on the bug report, it just says "ath9k_htc: Failed to initialize the device". > > I don't have so much info about the HW, besides a dmesg showing the > > phy breaking. > > I also added the reporter to CC too. > > > > https://gist.github.com/AngryPenguinPL/1e545f0da3c2339e443b9e5044fcccea > > > > If you need more info, please let me know and I'll try my best to get > > it as fast as possible for you. -- With respect, Roman
[BISECTED REGRESSION] ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
On Sat, 4 Apr 2020 12:18:38 +0800
Qiujun Huang wrote:
> In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
> usb_ifnum_to_if(urb->dev, 0)
> But it isn't always true.
>
> The case reported by syzbot:
> https://lore.kernel.org/linux-usb/666c9c05a1c05...@google.com
> usb 2-1: new high-speed USB device number 2 using dummy_hcd
> usb 2-1: config 1 has an invalid interface number: 2 but max is 0
> usb 2-1: config 1 has no interface number 0
> usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
> 1.08
> usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> general protection fault, probably for non-canonical address
> 0xdc15: [#1] SMP KASAN
> KASAN: null-ptr-deref in range [0x00a8-0x00af]
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0
>
> Call Trace
> __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
> usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
> dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
> call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
> expire_timers kernel/time/timer.c:1449 [inline]
> __run_timers kernel/time/timer.c:1773 [inline]
> __run_timers kernel/time/timer.c:1740 [inline]
> run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
> __do_softirq+0x21e/0x950 kernel/softirq.c:292
> invoke_softirq kernel/softirq.c:373 [inline]
> irq_exit+0x178/0x1a0 kernel/softirq.c:413
> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
>
> Reported-and-tested-by: syzbot+40d5d2e8a4680952f...@syzkaller.appspotmail.com
> Signed-off-by: Qiujun Huang
This causes complete breakage of ath9k operation across all the stable kernel
series it got backported to, and I guess the mainline as well. Please see:
https://bugzilla.kernel.org/show_bug.cgi?id=208251
https://bugzilla.redhat.com/show_bug.cgi?id=1848631
Thanks
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 48 ++--
> drivers/net/wireless/ath/ath9k/hif_usb.h | 5 +++
> 2 files changed, 42 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
> b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 6049d3766c64..4ed21dad6a8e 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -643,9 +643,9 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb
> *hif_dev,
>
> static void ath9k_hif_usb_rx_cb(struct urb *urb)
> {
> - struct sk_buff *skb = (struct sk_buff *) urb->context;
> - struct hif_device_usb *hif_dev =
> - usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
> + struct rx_buf *rx_buf = (struct rx_buf *)urb->context;
> + struct hif_device_usb *hif_dev = rx_buf->hif_dev;
> + struct sk_buff *skb = rx_buf->skb;
> int ret;
>
> if (!skb)
> @@ -685,14 +685,15 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> return;
> free:
> kfree_skb(skb);
> + kfree(rx_buf);
> }
>
> static void ath9k_hif_usb_reg_in_cb(struct urb *urb)
> {
> - struct sk_buff *skb = (struct sk_buff *) urb->context;
> + struct rx_buf *rx_buf = (struct rx_buf *)urb->context;
> + struct hif_device_usb *hif_dev = rx_buf->hif_dev;
> + struct sk_buff *skb = rx_buf->skb;
> struct sk_buff *nskb;
> - struct hif_device_usb *hif_dev =
> - usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
> int ret;
>
> if (!skb)
> @@ -750,6 +751,7 @@ static void ath9k_hif_usb_reg_in_cb(struct urb *urb)
> return;
> free:
> kfree_skb(skb);
> + kfree(rx_buf);
> urb->context = NULL;
> }
>
> @@ -795,7 +797,7 @@ static int ath9k_hif_usb_alloc_tx_urbs(struct
> hif_device_usb *hif_dev)
> init_usb_anchor(&hif_dev->mgmt_submitted);
>
> for (i = 0; i < MAX_TX_URB_NUM; i++) {
> - tx_buf = kzalloc(sizeof(struct tx_buf), GFP_KERNEL);
> + tx_buf = kzalloc(sizeof(*tx_buf), GFP_KERNEL);
> if (!tx_buf)
> goto err;
>
> @@ -832,8 +834,9 @@ static void ath9k_hif_usb_dealloc_rx_urbs(struct
> hif_device_usb *hif_dev)
>
> static int ath9k_hif_usb_alloc_rx_urbs(struct hif_device_usb *hif_dev)
> {
> - struct urb *urb = NULL;
> + struct rx_buf *rx_buf = NULL;
> struct sk_buff *skb = NULL;
> + struct urb *urb = NULL;
> int i, ret;
>
> init_usb_anchor(&hif_dev->rx_submitted);
> @@ -841,6 +844,12 @@ static int ath9k_hif_usb_alloc_rx_urbs(struct
> hif_device_usb *hif_dev)
>
> for (i = 0; i < MAX_RX_URB_NUM; i++) {
>
> + rx_buf = kzalloc(sizeof(*rx_buf), GFP_KERNEL);
> + if (!rx_buf) {
> + ret = -ENOMEM;
> + goto err_rxb;
> + }
> +
> /* Allocate URB */
> urb = usb_alloc_
