linux-stable.git/drivers/firewire, branch v6.9

firewire: ohci: fulfill timestamp for some local asynchronous transaction

2024-04-29T09:41:00+00:00

1394 OHCI driver generates packet data for the response subaction to the
request subaction to some local registers. In the case, the driver should
assign timestamp to them by itself.

This commit fulfills the timestamp for the subaction.

Cc: stable@vger.kernel.org
Fixes: dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion")
Link: https://lore.kernel.org/r/20240429084709.707473-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto

firewire: nosy: ensure user_length is taken into account when fetching packet contents

2024-04-29T09:35:55+00:00

Ensure that packet_buffer_get respects the user_length provided. If
the length of the head packet exceeds the user_length, packet_buffer_get
will now return 0 to signify to the user that no data were read
and a larger buffer size is required. Helps prevent user space overflows.

Signed-off-by: Thanassis Avgerinos 
Signed-off-by: Takashi Sakamoto

firewire: ohci: mask bus reset interrupts between ISR and bottom half

2024-04-06T00:36:46+00:00

In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can't clear the bus
reset event flag in irq_handler, because we won't service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won't be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.

Signed-off-by: Adam Goldman 
Signed-off-by: Takashi Sakamoto

firewire: core: add memo about the caller of show functions for device attributes

2024-03-21T12:20:18+00:00

In the case of firewire core function, the caller of show functions for
device attributes is not only sysfs user, but also device initialization.

This commit adds memo about it against the typical assumption that the
functions are just dedicated to sysfs user.

Link: https://lore.kernel.org/lkml/20240318091759.678326-1-o-takashi@sakamocchi.jp/
Signed-off-by: Takashi Sakamoto

Revert "firewire: Kill unnecessary buf check in device_attribute.show"

2024-03-18T09:10:44+00:00

This reverts commit 4a2b06ca33763b363038d333274e212db6ff0de1.

The previous fix didn't consider callers from other than sysfs. Revert
it to fix the NULL dereference

 kernel:  ? sysfs_emit+0xb5/0xc0
 kernel:  show_immediate+0x13f/0x1d0 [firewire_core]
 kernel:  init_fw_attribute_group+0x81/0x150 [firewire_core]
 kernel:  create_units+0x119/0x160 [firewire_core]
 kernel:  fw_device_init+0x1a9/0x330 [firewire_core]
 kernel:  fw_device_workfn+0x12/0x20 [firewire_core]
 kernel:  process_one_work+0x16f/0x350
 kernel:  worker_thread+0x306/0x440
 kernel:  ? __pfx_worker_thread+0x10/0x10
 kernel:  kthread+0xf2/0x120
 kernel:  ? __pfx_kthread+0x10/0x10
 kernel:  ret_from_fork+0x47/0x70
 kernel:  ? __pfx_kthread+0x10/0x10
 kernel:  ret_from_fork_asm+0x1b/0x30
 kernel:  
 kernel: ---[ end trace 0000000000000000 ]---
 kernel: ------------[ cut here ]------------

Fixes: 4a2b06ca3376 ("firewire: Kill unnecessary buf check in device_attribute.show")
Reported-by: Takashi Sakamoto 
Signed-off-by: Li Zhijian 
Link: https://lore.kernel.org/lkml/625470f3-b196-43f7-9844-fa1cb6da99f8@fujitsu.com/
Signed-off-by: Takashi Sakamoto

firewire: core: fix build failure due to the caller of fw_csr_string()

2024-03-11T01:38:13+00:00

A commit 47dc55181dcb ("firewire: core: search descriptor leaf just after
vendor directory entry in root directory") for v6.8-rc3 and a commit
67a5a58c0443 ("firewire: Kill unnecessary buf check in
device_attribute.show") for v6.9 bring build failure in for-next tree due
to the change of the name of local variable.

This commit fixes it.

Reported-by: Stephen Rothwell 
Closes: https://lore.kernel.org/lkml/20240202111602.6f6e2c1a@canb.auug.org.au/
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202402022343.NkgsMITA-lkp@intel.com/
Link: https://lore.kernel.org/r/20240205060448.13881-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto

firewire: Convert snprintf/sprintf to sysfs_emit

2024-03-11T01:38:13+00:00

Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.

coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().

> drivers/firewire/core-device.c:326:8-16: WARNING: please use sysfs_emit or sysfs_emit_at

No functional change intended

Signed-off-by: Li Zhijian 
Link: https://lore.kernel.org/r/20240122053942.80648-2-lizhijian@fujitsu.com
Signed-off-by: Takashi Sakamoto

firewire: Kill unnecessary buf check in device_attribute.show

2024-03-11T01:38:13+00:00

Per Documentation/filesystems/sysfs.rst:
> sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the
> method.

So we can kill the unnecessary buf check safely.

Signed-off-by: Li Zhijian 
Link: https://lore.kernel.org/r/20240122053942.80648-1-lizhijian@fujitsu.com
Signed-off-by: Takashi Sakamoto

firewire: ohci: prevent leak of left-over IRQ on unbind

2024-03-06T13:35:22+00:00

Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ")
also removed the call to free_irq() in pci_remove(), leading to a
leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove()
when unbinding the driver from the device

remove_proc_entry: removing non-empty directory 'irq/136', leaking at
least 'firewire_ohci'
Call Trace:
 ? remove_proc_entry+0x19c/0x1c0
 ? __warn+0x81/0x130
 ? remove_proc_entry+0x19c/0x1c0
 ? report_bug+0x171/0x1a0
 ? console_unlock+0x78/0x120
 ? handle_bug+0x3c/0x80
 ? exc_invalid_op+0x17/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? remove_proc_entry+0x19c/0x1c0
 unregister_irq_proc+0xf4/0x120
 free_desc+0x3d/0xe0
 ? kfree+0x29f/0x2f0
 irq_free_descs+0x47/0x70
 msi_domain_free_locked.part.0+0x19d/0x1d0
 msi_domain_free_irqs_all_locked+0x81/0xc0
 pci_free_msi_irqs+0x12/0x40
 pci_disable_msi+0x4c/0x60
 pci_remove+0x9d/0xc0 [firewire_ohci
     01b483699bebf9cb07a3d69df0aa2bee71db1b26]
 pci_device_remove+0x37/0xa0
 device_release_driver_internal+0x19f/0x200
 unbind_store+0xa1/0xb0

remove irq with devm_free_irq() before pci_disable_msi()
also remove it in fail_msi: of pci_probe() as this would lead to
an identical leak

Cc: stable@vger.kernel.org
Fixes: 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ")
Signed-off-by: Edmund Raile 
Link: https://lore.kernel.org/r/20240229144723.13047-2-edmund.raile@proton.me
Signed-off-by: Takashi Sakamoto

firewire: core: use long bus reset on gap count error

2024-02-29T13:18:14+00:00

When resetting the bus after a gap count error, use a long rather than
short bus reset.

IEEE 1394-1995 uses only long bus resets. IEEE 1394a adds the option of
short bus resets. When video or audio transmission is in progress and a
device is hot-plugged elsewhere on the bus, the resulting bus reset can
cause video frame drops or audio dropouts. Short bus resets reduce or
eliminate this problem. Accordingly, short bus resets are almost always
preferred.

However, on a mixed 1394/1394a bus, a short bus reset can trigger an
immediate additional bus reset. This double bus reset can be interpreted
differently by different nodes on the bus, resulting in an inconsistent gap
count after the bus reset. An inconsistent gap count will cause another bus
reset, leading to a neverending bus reset loop. This only happens for some
bus topologies, not for all mixed 1394/1394a buses.

By instead sending a long bus reset after a gap count inconsistency, we
avoid the doubled bus reset, restoring the bus to normal operation.

Signed-off-by: Adam Goldman 
Link: https://sourceforge.net/p/linux1394/mailman/message/58741624/
Signed-off-by: Takashi Sakamoto