<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/fs/debugfs, branch v6.8.12</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.8.12</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.8.12'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-04-03T13:32:17Z</updated>
<entry>
<title>debugfs: fix wait/cancellation handling during remove</title>
<updated>2024-04-03T13:32:17Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2024-02-29T14:36:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3d08cca5fd0aabb62b7015067ab40913b33da906'/>
<id>urn:sha1:3d08cca5fd0aabb62b7015067ab40913b33da906</id>
<content type='text'>
[ Upstream commit 952c3fce297f12c7ff59380adb66b564e2bc9b64 ]

Ben Greear further reports deadlocks during concurrent debugfs
remove while files are being accessed, even though the code in
question now uses debugfs cancellations. Turns out that despite
all the review on the locking, we missed completely that the
logic is wrong: if the refcount hits zero we can finish (and
need not wait for the completion), but if it doesn't we have
to trigger all the cancellations. As written, we can _never_
get into the loop triggering the cancellations. Fix this, and
explain it better while at it.

Cc: stable@vger.kernel.org
Fixes: 8c88a474357e ("debugfs: add API to allow debugfs operations cancellation")
Reported-by: Ben Greear &lt;greearb@candelatech.com&gt;
Closes: https://lore.kernel.org/r/1c9fa9e5-09f1-0522-fdbc-dbcef4d255ca@candelatech.com
Tested-by: Madhan Sai &lt;madhan.singaraju@candelatech.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Link: https://lore.kernel.org/r/20240229153635.6bfab7eb34d3.I6c7aeff8c9d6628a8bc1ddcf332205a49d801f17@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branches 'acpi-pm', 'acpi-video', 'acpi-apei' and 'acpi-extlog'</title>
<updated>2024-01-04T12:19:40Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2024-01-04T12:19:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=22349e79b98cd3c61c28c2fc0d3a034bb854210e'/>
<id>urn:sha1:22349e79b98cd3c61c28c2fc0d3a034bb854210e</id>
<content type='text'>
Merge an ACPI power management change, ACPI backlight driver changes, APEI
updates and ACPI extlog driver changes for 6.8-rc1:

 - Modify the ACPI LPIT table handling code to avoid u32 multiplication
   overflows in state residency computations (Nikita Kiryushin).

 - Drop an unused helper function from the ACPI backlight (video) driver
   and add a clarifying comment to it (Hans de Goede).

 - Update the ACPI backlight driver to avoid using uninitialized memory
   in some cases (Nikita Kiryushin).

 - Add ACPI backlight quirk for the Colorful X15 AT 23 laptop (Yuluo
   Qiu).

 - Add support for vendor-defined error types to the ACPI APEI error
   injection code (Avadhut Naik).

 - Adjust APEI to properly set MF_ACTION_REQUIRED on synchronous memory
   failure events, so they are handled differently from the asynchronous
   ones (Shuai Xue).

 - Fix NULL pointer dereference check in the ACPI extlog driver (Prarit
   Bhargava).

 - Adjust the ACPI extlog driver to clear the Extended Error Log status
   when RAS_CEC handled the error (Tony Luck).

* acpi-pm:
  ACPI: LPIT: Avoid u32 multiplication overflow

* acpi-video:
  ACPI: video: Add quirk for the Colorful X15 AT 23 Laptop
  ACPI: video: check for error while searching for backlight device parent
  ACPI: video: Drop should_check_lcd_flag()
  ACPI: video: Add comment about acpi_video_backlight_use_native() usage

* acpi-apei:
  ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
  ACPI: APEI: EINJ: Add support for vendor defined error types
  platform/chrome: cros_ec_debugfs: Fix permissions for panicinfo
  fs: debugfs: Add write functionality to debugfs blobs
  ACPI: APEI: EINJ: Refactor available_error_type_show()

* acpi-extlog:
  ACPI: extlog: Clear Extended Error Log status when RAS_CEC handled the error
  ACPI: extlog: fix NULL pointer dereference check
</content>
</entry>
<entry>
<title>debugfs: initialize cancellations earlier</title>
<updated>2023-12-22T06:33:02Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2023-12-21T14:04:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=159f5bdadcdda638aad5a234b58d6031aa4ef8aa'/>
<id>urn:sha1:159f5bdadcdda638aad5a234b58d6031aa4ef8aa</id>
<content type='text'>
Tetsuo Handa pointed out that in the (now reverted)
lockdep commit I initialized the data too late. The
same is true for the cancellation data, it must be
initialized before the cmpxchg(), otherwise it may
be done twice and possibly even overwriting data in
there already when there's a race. Fix that, which
also requires destroying the mutex in case we lost
the race.

Fixes: 8c88a474357e ("debugfs: add API to allow debugfs operations cancellation")
Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Link: https://lore.kernel.org/r/20231221150444.1e47a0377f80.If7e8ba721ba2956f12c6e8405e7d61e154aa7ae7@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"</title>
<updated>2023-12-04T06:43:16Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2023-12-02T10:49:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=88ac06a9f938c158bbeafec16adb483b0c66142f'/>
<id>urn:sha1:88ac06a9f938c158bbeafec16adb483b0c66142f</id>
<content type='text'>
This reverts commit f4acfcd4deb1 ("debugfs: annotate debugfs handlers
vs. removal with lockdep"), it appears to have false positives and
really shouldn't have been in the -rc series with the fixes anyway.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Link: https://lore.kernel.org/r/20231202114936.fd55431ab160.I911aa53abeeca138126f690d383a89b13eb05667@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'wireless-2023-11-29' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless</title>
<updated>2023-11-30T03:43:34Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2023-11-30T03:43:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=300fbb247eb3d2146b37c8dc127056f695091218'/>
<id>urn:sha1:300fbb247eb3d2146b37c8dc127056f695091218</id>
<content type='text'>
Johannes Berg says:

====================
wireless fixes:
 - debugfs had a deadlock (removal vs. use of files),
   fixes going through wireless ACKed by Greg
 - support for HT STAs on 320 MHz channels, even if it's
   not clear that should ever happen (that's 6 GHz), best
   not to WARN()
 - fix for the previous CQM fix that broke most cases
 - various wiphy locking fixes
 - various small driver fixes

* tag 'wireless-2023-11-29' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
  wifi: mac80211: use wiphy locked debugfs for sdata/link
  wifi: mac80211: use wiphy locked debugfs helpers for agg_status
  wifi: cfg80211: add locked debugfs wrappers
  debugfs: add API to allow debugfs operations cancellation
  debugfs: annotate debugfs handlers vs. removal with lockdep
  debugfs: fix automount d_fsdata usage
  wifi: mac80211: handle 320 MHz in ieee80211_ht_cap_ie_to_sta_ht_cap
  wifi: avoid offset calculation on NULL pointer
  wifi: cfg80211: hold wiphy mutex for send_interface
  wifi: cfg80211: lock wiphy mutex for rfkill poll
  wifi: cfg80211: fix CQM for non-range use
  wifi: mac80211: do not pass AP_VLAN vif pointer to drivers during flush
  wifi: iwlwifi: mvm: fix an error code in iwl_mvm_mld_add_sta()
  wifi: mt76: mt7925: fix typo in mt7925_init_he_caps
  wifi: mt76: mt7921: fix 6GHz disabled by the missing default CLC config
====================

Link: https://lore.kernel.org/r/20231129150809.31083-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>debugfs: add API to allow debugfs operations cancellation</title>
<updated>2023-11-27T10:24:55Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2023-11-24T16:25:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8c88a474357ead632b07c70bf7f119ace8c3b39e'/>
<id>urn:sha1:8c88a474357ead632b07c70bf7f119ace8c3b39e</id>
<content type='text'>
In some cases there might be longer-running hardware accesses
in debugfs files, or attempts to acquire locks, and we want
to still be able to quickly remove the files.

Introduce a cancellations API to use inside the debugfs handler
functions to be able to cancel such operations on a per-file
basis.

Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>debugfs: annotate debugfs handlers vs. removal with lockdep</title>
<updated>2023-11-27T10:24:50Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2023-11-24T16:25:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f4acfcd4deb158b96595250cc332901b282d15b0'/>
<id>urn:sha1:f4acfcd4deb158b96595250cc332901b282d15b0</id>
<content type='text'>
When you take a lock in a debugfs handler but also try
to remove the debugfs file under that lock, things can
deadlock since the removal has to wait for all users
to finish.

Add lockdep annotations in debugfs_file_get()/_put()
to catch such issues.

Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>debugfs: fix automount d_fsdata usage</title>
<updated>2023-11-27T10:24:45Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2023-11-24T16:25:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0ed04a1847a10297595ac24dc7d46b35fb35f90a'/>
<id>urn:sha1:0ed04a1847a10297595ac24dc7d46b35fb35f90a</id>
<content type='text'>
debugfs_create_automount() stores a function pointer in d_fsdata,
but since commit 7c8d469877b1 ("debugfs: add support for more
elaborate -&gt;d_fsdata") debugfs_release_dentry() will free it, now
conditionally on DEBUGFS_FSDATA_IS_REAL_FOPS_BIT, but that's not
set for the function pointer in automount. As a result, removing
an automount dentry would attempt to free the function pointer.
Luckily, the only user of this (tracing) never removes it.

Nevertheless, it's safer if we just handle the fsdata in one way,
namely either DEBUGFS_FSDATA_IS_REAL_FOPS_BIT or allocated. Thus,
change the automount to allocate it, and use the real_fops in the
data to indicate whether or not automount is filled, rather than
adding a type tag. At least for now this isn't actually needed,
but the next changes will require it.

Also check in debugfs_file_get() that it gets only called
on regular files, just to make things clearer.

Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>fs: debugfs: Add write functionality to debugfs blobs</title>
<updated>2023-11-21T20:10:44Z</updated>
<author>
<name>Avadhut Naik</name>
<email>Avadhut.Naik@amd.com</email>
</author>
<published>2023-11-16T22:47:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=71cd3c636404ceb08226b5095ca36a04eb578ca1'/>
<id>urn:sha1:71cd3c636404ceb08226b5095ca36a04eb578ca1</id>
<content type='text'>
Currently, debugfs_create_blob() creates read-only debugfs binary blob
files.

In some cases, however, userspace tools need to write variable length
data structures into predetermined memory addresses. An example is when
injecting Vendor-defined error types through the einj module. In such
cases, the functionality to write to these blob files in debugfs would
be desired since the mapping aspect can be handled within the modules
with userspace tools only needing to write into the blob files.

Implement a write callback to enable writing to these blob files, created
in debugfs, by owners only.

Signed-off-by: Avadhut Naik &lt;Avadhut.Naik@amd.com&gt;
Reviewed-by: Alexey Kardashevskiy &lt;aik@amd.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'driver-core-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core</title>
<updated>2023-11-04T01:15:47Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-11-04T01:15:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b06f58ad8e8c4154bc88d83b4fd70f74ede50193'/>
<id>urn:sha1:b06f58ad8e8c4154bc88d83b4fd70f74ede50193</id>
<content type='text'>
Pull driver core updates from Greg KH:
 "Here is the set of driver core updates for 6.7-rc1. Nothing major in
  here at all, just a small number of changes including:

   - minor cleanups and updates from Andy Shevchenko

   - __counted_by addition

   - firmware_loader update for aborting loads cleaner

   - other minor changes, details in the shortlog

   - documentation update

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'driver-core-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (21 commits)
  firmware_loader: Abort all upcoming firmware load request once reboot triggered
  firmware_loader: Refactor kill_pending_fw_fallback_reqs()
  Documentation: security-bugs.rst: linux-distros relaxed their rules
  driver core: Release all resources during unbind before updating device links
  driver core: class: remove boilerplate code
  driver core: platform: Annotate struct irq_affinity_devres with __counted_by
  resource: Constify resource crosscheck APIs
  resource: Unify next_resource() and next_resource_skip_children()
  resource: Reuse for_each_resource() macro
  PCI: Implement custom llseek for sysfs resource entries
  kernfs: sysfs: support custom llseek method for sysfs entries
  debugfs: Fix __rcu type comparison warning
  device property: Replace custom implementation of COUNT_ARGS()
  drivers: base: test: Make property entry API test modular
  driver core: Add missing parameter description to __fwnode_link_add()
  device property: Clarify usage scope of some struct fwnode_handle members
  devres: rename the first parameter of devm_add_action(_or_reset)
  driver core: platform: Unify the firmware node type check
  driver core: platform: Use temporary variable in platform_device_add()
  driver core: platform: Refactor error path in a couple places
  ...
</content>
</entry>
</feed>
