cifs vs Go: EINTR and ENOENT errors from getdents64

Hi, author of gocryptfs here, an encrypted overlay filesystem written in Go. A gocryptfs user reported [1] hitting EINTR errors when gocryptfs is used on a cifs mount. I wrote a minimal reproducer, getdents.go [2], that runs getdents64 in a loop and I can reproduce the issue easily. I

Re: [PATCH v5 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 25.04.18 17:34, Marc Kleine-Budde wrote: Applied to linux-can-next. Thanks, Marc Marc, is the patch supposed to show up on https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/ or am I looking at the wrong tree? Thanks, Jakob

Re: [PATCH v5 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 25.04.18 17:34, Marc Kleine-Budde wrote: Applied to linux-can-next. Thanks, Marc Marc, is the patch supposed to show up on https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/ or am I looking at the wrong tree? Thanks, Jakob

Re: [regression, bisected] rockchip rk3399 video output breakage

On 24.04.18 15:33, JeffyChen wrote: [   36.076577] WARNING: CPU: 1 PID: 83 at drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1004 vop_crtc_atomic_flush+0x1c0/0x1c8 this looks like an issue recently reported by heiko, we found that might due to an unbalanced irq disable in vop driver. my test

Re: [regression, bisected] rockchip rk3399 video output breakage

On 24.04.18 15:33, JeffyChen wrote: [   36.076577] WARNING: CPU: 1 PID: 83 at drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1004 vop_crtc_atomic_flush+0x1c0/0x1c8 this looks like an issue recently reported by heiko, we found that might due to an unbalanced irq disable in vop driver. my test

Re: [regression, bisected] rockchip rk3399 video output breakage

On 24.04.18 14:37, JeffyChen wrote: right, i think it's a known issue, as the iommu failed to get clks: [    1.525153] rk_iommu ff8f3f00.iommu: Failed to get clk 'iface': -2 [    1.525316] rk_iommu: probe of ff8f3f00.iommu failed with error -2 [    1.525484] rk_iommu ff903f00.iommu: Failed to

Re: [regression, bisected] rockchip rk3399 video output breakage

On 24.04.18 14:37, JeffyChen wrote: right, i think it's a known issue, as the iommu failed to get clks: [    1.525153] rk_iommu ff8f3f00.iommu: Failed to get clk 'iface': -2 [    1.525316] rk_iommu: probe of ff8f3f00.iommu failed with error -2 [    1.525484] rk_iommu ff903f00.iommu: Failed to

[regression, bisected] rockchip rk3399 video output breakage

I am working on getting HDMI output enabled in mainline Linux for our RK3399-Q7 module. It works fine on v4.16, but testing with v4.17-rc2 I get this, and the screen stays black: [7.142712] alloc_contig_range: [7f061, 7f062) PFNs busy [7.148862] alloc_contig_range: [7f066, 7f067) PFNs

[regression, bisected] rockchip rk3399 video output breakage

I am working on getting HDMI output enabled in mainline Linux for our RK3399-Q7 module. It works fine on v4.16, but testing with v4.17-rc2 I get this, and the screen stays black: [7.142712] alloc_contig_range: [7f061, 7f062) PFNs busy [7.148862] alloc_contig_range: [7f066, 7f067) PFNs

[PATCH] can: dev: increase bus-off message severity

the "restarted" message at dbg for now as the "bus-off" message should be enough for the user to notice and investigate the problem. Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-systems.com> Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.

[PATCH] can: dev: increase bus-off message severity

the "restarted" message at dbg for now as the "bus-off" message should be enough for the user to notice and investigate the problem. Signed-off-by: Jakob Unterwurzacher Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/net/can/dev.c | 2 +- 1 file

[PATCH v5 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber <martin.elshu...@theobroma-systems.com> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-systems.com> Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> Acked-by: Wolfgang Grandegger <w...@grandegger.com> --- Documentation/networki

[PATCH v5 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber Signed-off-by: Jakob Unterwurzacher Signed-off-by: Philipp Tomsich Acked-by: Wolfgang Grandegger --- Documentation/networking/can_ucan_protocol.rst | 332 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kconfig| 10 + drivers/net/can

[PATCH v5 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

; "context_array" to prevent confusion * add __func__ to all errors and warnings, and to info where it made sense Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst | 332 + Documentation/networking/ind

[PATCH v5 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

; "context_array" to prevent confusion * add __func__ to all errors and warnings, and to info where it made sense Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst | 332 + Documentation/networking/ind

[PATCH v4 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

ion * add __func__ to all errors and warnings, and to info where it made sense Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kco

[PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber <martin.elshu...@theobroma-systems.com> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-systems.com> Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> --- Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/ne

[PATCH v4 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

ion * add __func__ to all errors and warnings, and to info where it made sense Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kco

[PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber Signed-off-by: Jakob Unterwurzacher Signed-off-by: Philipp Tomsich --- Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kconfig| 10 + drivers/net/can/usb/Makefile

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 23.03.18 11:04, Wolfgang Grandegger wrote: But I'm open to other suggestions (use a fixed "ucan: " prefix?) or to drop it entirely if you think it is not worth it. But there is already a device prefix, e.g.: peak_usb 1-6:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial (1

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 23.03.18 11:04, Wolfgang Grandegger wrote: But I'm open to other suggestions (use a fixed "ucan: " prefix?) or to drop it entirely if you think it is not worth it. But there is already a device prefix, e.g.: peak_usb 1-6:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial (1

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 23.03.18 09:32, Wolfgang Grandegger wrote: * add __func__ to all errors and warnings, and to info where it made sense The final output messages in the driver should especially be useful for the end user... and not the developer! This is also true for the function names. You already use more

Re: [PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 23.03.18 09:32, Wolfgang Grandegger wrote: * add __func__ to all errors and warnings, and to info where it made sense The final output messages in the driver should especially be useful for the end user... and not the developer! This is also true for the function names. You already use more

[PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

errors and warnings, and to info where it made sense Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kconfig

[PATCH v3 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

errors and warnings, and to info where it made sense Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kconfig

[PATCH v3 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber <martin.elshu...@theobroma-systems.com> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-systems.com> Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> --- Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/ne

[PATCH v3 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber Signed-off-by: Jakob Unterwurzacher Signed-off-by: Philipp Tomsich --- Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kconfig| 10 + drivers/net/can/usb/Makefile

Re: [bug, bisected] pfifo_fast causes packet reordering

On 21.03.18 21:52, John Fastabend wrote: Can you try this, diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index d4907b5..1e596bd 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -30,6 +30,7 @@ struct qdisc_rate_table { enum qdisc_state_t {

Re: [bug, bisected] pfifo_fast causes packet reordering

On 21.03.18 21:52, John Fastabend wrote: Can you try this, diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index d4907b5..1e596bd 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -30,6 +30,7 @@ struct qdisc_rate_table { enum qdisc_state_t {

Re: [bug, bisected] pfifo_fast causes packet reordering

On 21.03.18 19:43, John Fastabend wrote: Thats my theory at least. Are you able to test a patch if I generate one to fix this? Yes, no problem. I just tested with the flag change you suggested (see below, I had to keep TCQ_F_CPUSTATS to prevent a crash) and I have NOT seen OOO so far.

Re: [bug, bisected] pfifo_fast causes packet reordering

On 21.03.18 19:43, John Fastabend wrote: Thats my theory at least. Are you able to test a patch if I generate one to fix this? Yes, no problem. I just tested with the flag change you suggested (see below, I had to keep TCQ_F_CPUSTATS to prevent a crash) and I have NOT seen OOO so far.

Re: [bug, bisected] pfifo_fast causes packet reordering

On 16.03.18 11:26, Jakob Unterwurzacher wrote: On 15.03.18 23:30, John Fastabend wrote: I have reproduced it using two USB network cards connected to each other. The test tool sends UDP packets containing a counter and listens on the other interface, it is available at https://github.com

Re: [bug, bisected] pfifo_fast causes packet reordering

On 16.03.18 11:26, Jakob Unterwurzacher wrote: On 15.03.18 23:30, John Fastabend wrote: I have reproduced it using two USB network cards connected to each other. The test tool sends UDP packets containing a counter and listens on the other interface, it is available at https://github.com

Re: [bug, bisected] pfifo_fast causes packet reordering

On 19.03.18 13:32, Paolo Abeni wrote: Is not clear to me if you can reproduce the bug with the vanilla kernel, or if you need some out-of-tree nic driver. Can you please clarify which NIC/driver are you using? Yes I reproduced it with a vanilla kernel. I use two off-the-shelf USB NICs, lsusb

Re: [bug, bisected] pfifo_fast causes packet reordering

On 19.03.18 13:32, Paolo Abeni wrote: Is not clear to me if you can reproduce the bug with the vanilla kernel, or if you need some out-of-tree nic driver. Can you please clarify which NIC/driver are you using? Yes I reproduced it with a vanilla kernel. I use two off-the-shelf USB NICs, lsusb

Re: [bug, bisected] pfifo_fast causes packet reordering

On 15.03.18 23:30, John Fastabend wrote: I have reproduced it using two USB network cards connected to each other. The test tool sends UDP packets containing a counter and listens on the other interface, it is available at https://github.com/jakob-tsd/pfifo_stress/blob/master/pfifo_stress.py

Re: [bug, bisected] pfifo_fast causes packet reordering

On 15.03.18 23:30, John Fastabend wrote: I have reproduced it using two USB network cards connected to each other. The test tool sends UDP packets containing a counter and listens on the other interface, it is available at https://github.com/jakob-tsd/pfifo_stress/blob/master/pfifo_stress.py

Re: [bug, bisected] pfifo_fast causes packet reordering

On 14.03.18 05:03, John Fastabend wrote: On 03/13/2018 11:35 AM, Dave Taht wrote: On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-systems.com> wrote: During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux v4.16-rc4-383-

Re: [bug, bisected] pfifo_fast causes packet reordering

On 14.03.18 05:03, John Fastabend wrote: On 03/13/2018 11:35 AM, Dave Taht wrote: On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher wrote: During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 11:04, Wolfgang Grandegger wrote: (000.000443) can0 2034 [8] 00 0C 00 00 00 00 78 00 ERRORFRAME controller-problem{rx-error-warning,tx-error-warning} transceiver-status no-acknowledgement-on-tx error-counter-tx-rx{{120}{0}} (000.000444) can0 2034

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 11:04, Wolfgang Grandegger wrote: (000.000443) can0 2034 [8] 00 0C 00 00 00 00 78 00 ERRORFRAME controller-problem{rx-error-warning,tx-error-warning} transceiver-status no-acknowledgement-on-tx error-counter-tx-rx{{120}{0}} (000.000444) can0 2034

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 11:04, Wolfgang Grandegger wrote: controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive} Just, controller-problem{rx-error-passive,tx-error-passive} Ok. (1b) cable gets connected:  (000.000883)  can0  2034   [8]  00 3C 00

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 11:04, Wolfgang Grandegger wrote: controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive} Just, controller-problem{rx-error-passive,tx-error-passive} Ok. (1b) cable gets connected:  (000.000883)  can0  2034   [8]  00 3C 00

Re: [bug, bisected] pfifo_fast causes packet reordering

On 14.03.18 05:03, John Fastabend wrote: During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are delivered out-of-order. Is the stress-testing tool available somewhere? What type of packets are

Re: [bug, bisected] pfifo_fast causes packet reordering

On 14.03.18 05:03, John Fastabend wrote: During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are delivered out-of-order. Is the stress-testing tool available somewhere? What type of packets are

Re: rx_packets/bytes stats for error frames

On 14.03.18 10:46, Wolfgang Grandegger wrote: We do count them, as errors! This is what happens when you transmit a single CAN frame with nothing connected: "TX errors" shoots up but "RX packets" stays zero. This is handled not consistent in the existing CAN drivers. In flexcan all and c_can

Re: rx_packets/bytes stats for error frames

On 14.03.18 10:46, Wolfgang Grandegger wrote: We do count them, as errors! This is what happens when you transmit a single CAN frame with nothing connected: "TX errors" shoots up but "RX packets" stays zero. This is handled not consistent in the existing CAN drivers. In flexcan all and c_can

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 10:25, Wolfgang Grandegger wrote: Counting the state changes is one thing but you should also generate error messages for them. The usual test here is: $ candump -td -e any,0:0,# should report proper state changes, if you send messages with 1. no cable connected 2. CAN

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 10:25, Wolfgang Grandegger wrote: Counting the state changes is one thing but you should also generate error messages for them. The usual test here is: $ candump -td -e any,0:0,# should report proper state changes, if you send messages with 1. no cable connected 2. CAN

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 10:17, Wolfgang Grandegger wrote: Counting the state changes is one thing but you should also generate error messages for them. We do for BUS-OFF already (see below), but not for other states - will do in v3. + /* we switched into a worse state */ + up->can.state =

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 10:17, Wolfgang Grandegger wrote: Counting the state changes is one thing but you should also generate error messages for them. We do for BUS-OFF already (see below), but not for other states - will do in v3. + /* we switched into a worse state */ + up->can.state =

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 10:11, Wolfgang Grandegger wrote: +    /* handle error frames */ +    canid = le32_to_cpu(m->msg.can_msg.id); +    if (canid & CAN_ERR_FLAG) { +    ucan_handle_error_frame(up, m, canid); +    /* drop frame if berr-reporting is off */ +    if (!(up->can.ctrlmode &

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 10:11, Wolfgang Grandegger wrote: +    /* handle error frames */ +    canid = le32_to_cpu(m->msg.can_msg.id); +    if (canid & CAN_ERR_FLAG) { +    ucan_handle_error_frame(up, m, canid); +    /* drop frame if berr-reporting is off */ +    if (!(up->can.ctrlmode &

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 08:51, Marc Kleine-Budde wrote: + memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc); + + /* don't count error frames as real packets */ + if (!(canid & CAN_ERR_FLAG)) { + stats->rx_packets++; + stats->rx_bytes += cf->can_dlc; +

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 14.03.18 08:51, Marc Kleine-Budde wrote: + memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc); + + /* don't count error frames as real packets */ + if (!(canid & CAN_ERR_FLAG)) { + stats->rx_packets++; + stats->rx_bytes += cf->can_dlc; +

[bug, bisected] pfifo_fast causes packet reordering

During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are delivered out-of-order. We have tracked the problem down to the driver interface level, and it seems that the driver's

[bug, bisected] pfifo_fast causes packet reordering

During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are delivered out-of-order. We have tracked the problem down to the driver interface level, and it seems that the driver's

Re: [PATCH v2 0/1] Open questions

This email addresses open questions from the v1 review cycle. Three emails are answered, you can skip to sections by searching for the header text: * On 07.02.18 08:17, Wolfgang Grandegger wrote * On 09.02.18 11:40, Marc Kleine-Budde wrote * On 06.02.18 12:58, Andri Yngvason wrote Best

Re: [PATCH v2 0/1] Open questions

This email addresses open questions from the v1 review cycle. Three emails are answered, you can skip to sections by searching for the header text: * On 07.02.18 08:17, Wolfgang Grandegger wrote * On 09.02.18 11:40, Marc Kleine-Budde wrote * On 06.02.18 12:58, Andri Yngvason wrote Best

[PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber <martin.elshu...@theobroma-systems.com> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-systems.com> Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> --- Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/ne

[PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

Elshuber Signed-off-by: Jakob Unterwurzacher Signed-off-by: Philipp Tomsich --- Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kconfig| 10 + drivers/net/can/usb/Makefile

[PATCH v2 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

completion message has been added. A few questions and review comments are still open. I will post an email gathering all answers in a reply to this cover letter. Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst

[PATCH v2 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

completion message has been added. A few questions and review comments are still open. I will post an email gathering all answers in a reply to this cover letter. Jakob Unterwurzacher (1): can: ucan: add driver for Theobroma Systems UCAN devices Documentation/networking/can_ucan_protocol.rst

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 13.03.18 18:44, Marc Kleine-Budde wrote: On 03/13/2018 06:35 PM, Jakob Unterwurzacher wrote: [...] Please mark all multibyte values going over the USB as either le or be. This is documented in can_ucan_protocol.rst, All multi-byte integers are encoded as Little Endian. but it's

Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

On 13.03.18 18:44, Marc Kleine-Budde wrote: On 03/13/2018 06:35 PM, Jakob Unterwurzacher wrote: [...] Please mark all multibyte values going over the USB as either le or be. This is documented in can_ucan_protocol.rst, All multi-byte integers are encoded as Little Endian. but it's

Re: [PATCH v2 0/1] Open questions

On 13.03.18 18:42, Dr. Philipp Tomsich wrote: On 13 Mar 2018, at 18:40, Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-systems.com> wrote: +/* get the urb context */ +if (WARN_ON(!context)) +return; Can this happen? Not unless there is a bug in the code.

Re: [PATCH v2 0/1] Open questions

On 13.03.18 18:42, Dr. Philipp Tomsich wrote: On 13 Mar 2018, at 18:40, Jakob Unterwurzacher wrote: +/* get the urb context */ +if (WARN_ON(!context)) +return; Can this happen? Not unless there is a bug in the code. But we want to get a message before dereferencing

fuse readdirplus skip one entry when interrupted by signal

A user running a Haskell program [1] noticed a problem with fuse's readdirplus: when it is interrupted by a signal, it skips one directory entry. The problem is most apparent with Haskell as it uses SIGVTALRM to interrupt it's own green threads. A minimal reproducer in C, "ls-count.c", is

fuse readdirplus skip one entry when interrupted by signal

A user running a Haskell program [1] noticed a problem with fuse's readdirplus: when it is interrupted by a signal, it skips one directory entry. The problem is most apparent with Haskell as it uses SIGVTALRM to interrupt it's own green threads. A minimal reproducer in C, "ls-count.c", is

Re: [PATCH] ASoC: sgtl5000: add support for a fixed sysclk frequency

> On 16. Oct 2017, at 13:19, Fabio Estevam wrote: > >> I think I see a way to fix this without adding a DTS property, I’ll send out >> a patch later this afternoon. > > Ok, great. Hi Fabio, I think I found a way to get our use-case working with just DTS configuration for

Re: [PATCH] ASoC: sgtl5000: add support for a fixed sysclk frequency

> On 16. Oct 2017, at 13:19, Fabio Estevam wrote: > >> I think I see a way to fix this without adding a DTS property, I’ll send out >> a patch later this afternoon. > > Ok, great. Hi Fabio, I think I found a way to get our use-case working with just DTS configuration for simple-audio-card.

Re: [PATCH] ASoC: sgtl5000: add support for a fixed sysclk frequency

> On 16. Oct 2017, at 12:51, Fabio Estevam <feste...@gmail.com> wrote: > > Hi Jakob, > > On Mon, Oct 16, 2017 at 7:46 AM, Jakob Unterwurzacher > <jakob.unterwurzac...@theobroma-systems.com> wrote: >> Hi Fabio, that’s interesting. >> >> Looks l

Re: [PATCH] ASoC: sgtl5000: add support for a fixed sysclk frequency

> On 16. Oct 2017, at 12:51, Fabio Estevam wrote: > > Hi Jakob, > > On Mon, Oct 16, 2017 at 7:46 AM, Jakob Unterwurzacher > wrote: >> Hi Fabio, that’s interesting. >> >> Looks like the fsl,imx-audio-sgtl5000 sound card driver that is used on the >&g

Re: [PATCH] ASoC: sgtl5000: add support for a fixed sysclk frequency

ee your message in the mailing list] > > Hi Jakob, > > arch/arm/boot/dts/imx51-babbage.dts has SYS_MCLK generated by an external > fixed oscillator and it works fine. > > Do you really need this new property? > From: Jakob Unterwurzacher <jakob.unterwurzac...@theobroma-syst

Re: [PATCH] ASoC: sgtl5000: add support for a fixed sysclk frequency

] > > Hi Jakob, > > arch/arm/boot/dts/imx51-babbage.dts has SYS_MCLK generated by an external > fixed oscillator and it works fine. > > Do you really need this new property? > From: Jakob Unterwurzacher > Sent: Friday, October 6, 2017 5:34:44 AM > To: l

Re: tmpfs returns incorrect data on concurrent pread() and truncate()

First of all, thanks for your replies! On 02.11.2016 00:51, Hugh Dickins wrote: > I don't think that there will be much appetite for changing the > kernel's VFS to prevent that. I hope that gocryptfs can provide > the serialization that it needs for itself, or otherwise handle > those zeroes

Re: tmpfs returns incorrect data on concurrent pread() and truncate()

First of all, thanks for your replies! On 02.11.2016 00:51, Hugh Dickins wrote: > I don't think that there will be much appetite for changing the > kernel's VFS to prevent that. I hope that gocryptfs can provide > the serialization that it needs for itself, or otherwise handle > those zeroes

tmpfs returns incorrect data on concurrent pread() and truncate()

tmpfs seems to be incorrectly returning 0-bytes when reading from a file that is concurrently being truncated. This is causing crashes in gocryptfs, a cryptographic FUSE overlay, when it reads a nonce from disk that should absolutely positively never be all-zero. I have written a reproducer in C

tmpfs returns incorrect data on concurrent pread() and truncate()

tmpfs seems to be incorrectly returning 0-bytes when reading from a file that is concurrently being truncated. This is causing crashes in gocryptfs, a cryptographic FUSE overlay, when it reads a nonce from disk that should absolutely positively never be all-zero. I have written a reproducer in C

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 12.04.2016 13:09, Tejun Heo wrote: >> >> Probably you want to look into: >> https://lkml.org/lkml/2016/3/10/21 >> >> The patch mentioned above solves the issue for me. > > Heh, I tracked it down to wb_over_bg_thresh() and fell asleep. Yeah, > that is the right fix. Works wonderfully now,

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 12.04.2016 13:09, Tejun Heo wrote: >> >> Probably you want to look into: >> https://lkml.org/lkml/2016/3/10/21 >> >> The patch mentioned above solves the issue for me. > > Heh, I tracked it down to wb_over_bg_thresh() and fell asleep. Yeah, > that is the right fix. Works wonderfully now,

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 30.03.2016 20:47, Tejun Heo wrote: > Hmmm... cgroup writeback support shouldn't affect fuse at all as the > backing device doesn't enable cgroup support. I probably made some > silly mistake. Is there a simple reproducer I can play with? Hi Tejun! A simple reproducer is at

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 30.03.2016 20:47, Tejun Heo wrote: > Hmmm... cgroup writeback support shouldn't affect fuse at all as the > backing device doesn't enable cgroup support. I probably made some > silly mistake. Is there a simple reproducer I can play with? Hi Tejun! A simple reproducer is at

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 16.03.2016 10:44, Miklos Szeredi wrote: > On Tue, Mar 15, 2016 at 8:55 AM, Jakob Unterwurzacher > <jakob...@gmail.com> wrote: >> Just for anybody finding this thread: This still happens in v4.4, it >> just took longer to trigger. >> >> I have posted more

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 16.03.2016 10:44, Miklos Szeredi wrote: > On Tue, Mar 15, 2016 at 8:55 AM, Jakob Unterwurzacher > wrote: >> Just for anybody finding this thread: This still happens in v4.4, it >> just took longer to trigger. >> >> I have posted more details to linux-kerne

Regression for mmap writes through FUSE in 4.2+

I have noticed an annoying regression that was introduced in 4.2 and is still there in 4.4. mmap writes to FUSE filesystems are throttled down to basically zero. Reproducer: https://github.com/rfjakob/mmapwrite , testing against encfs: $ mmapwrite /tmp/encfs-mnt/foo 1

Regression for mmap writes through FUSE in 4.2+

I have noticed an annoying regression that was introduced in 4.2 and is still there in 4.4. mmap writes to FUSE filesystems are throttled down to basically zero. Reproducer: https://github.com/rfjakob/mmapwrite , testing against encfs: $ mmapwrite /tmp/encfs-mnt/foo 1