<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/acpi/nfit, branch linux-5.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2023-03-03T10:41:47Z</updated>
<entry>
<title>ACPI: NFIT: fix a potential deadlock during NFIT teardown</title>
<updated>2023-03-03T10:41:47Z</updated>
<author>
<name>Vishal Verma</name>
</author>
<published>2023-01-25T18:34:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ae03fa7ad3436ead92324debc2fe0915f8152ac1'/>
<id>urn:sha1:ae03fa7ad3436ead92324debc2fe0915f8152ac1</id>
<content type='text'>
[ Upstream commit fb6df4366f86dd252bfa3049edffa52d17e7b895 ]

Lockdep reports that acpi_nfit_shutdown() may deadlock against an
opportune acpi_nfit_scrub(). acpi_nfit_scrub () is run from inside a
'work' and therefore has already acquired workqueue-internal locks. It
also acquiires acpi_desc-&gt;init_mutex. acpi_nfit_shutdown() first
acquires init_mutex, and was subsequently attempting to cancel any
pending workqueue items. This reversed locking order causes a potential
deadlock:

    ======================================================
    WARNING: possible circular locking dependency detected
    6.2.0-rc3 #116 Tainted: G           O     N
    ------------------------------------------------------
    libndctl/1958 is trying to acquire lock:
    ffff888129b461c0 ((work_completion)(&amp;(&amp;acpi_desc-&gt;dwork)-&gt;work)){+.+.}-{0:0}, at: __flush_work+0x43/0x450

    but task is already holding lock:
    ffff888129b460e8 (&amp;acpi_desc-&gt;init_mutex){+.+.}-{3:3}, at: acpi_nfit_shutdown+0x87/0xd0 [nfit]

    which lock already depends on the new lock.

    ...

    Possible unsafe locking scenario:

          CPU0                    CPU1
          ----                    ----
     lock(&amp;acpi_desc-&gt;init_mutex);
                                  lock((work_completion)(&amp;(&amp;acpi_desc-&gt;dwork)-&gt;work));
                                  lock(&amp;acpi_desc-&gt;init_mutex);
     lock((work_completion)(&amp;(&amp;acpi_desc-&gt;dwork)-&gt;work));

    *** DEADLOCK ***

Since the workqueue manipulation is protected by its own internal locking,
the cancellation of pending work doesn't need to be done under
acpi_desc-&gt;init_mutex. Move cancel_delayed_work_sync() outside the
init_mutex to fix the deadlock. Any work that starts after
acpi_nfit_shutdown() drops the lock will see ARS_CANCEL, and the
cancel_delayed_work_sync() will safely flush it out.

Reported-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
Link: https://lore.kernel.org/r/20230112-acpi_nfit_lockdep-v1-1-660be4dd10be@intel.com
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: NFIT: Fix support for virtual SPA ranges</title>
<updated>2021-08-18T06:56:57Z</updated>
<author>
<name>Dan Williams</name>
</author>
<published>2021-08-11T18:53:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bc97fde4c668b578444f0c3dd0442cb64ec9cf60'/>
<id>urn:sha1:bc97fde4c668b578444f0c3dd0442cb64ec9cf60</id>
<content type='text'>
commit b93dfa6bda4d4e88e5386490f2b277a26958f9d3 upstream.

Fix the NFIT parsing code to treat a 0 index in a SPA Range Structure as
a special case and not match Region Mapping Structures that use 0 to
indicate that they are not mapped. Without this fix some platform BIOS
descriptions of "virtual disk" ranges do not result in the pmem driver
attaching to the range.

Details:
In addition to typical persistent memory ranges, the ACPI NFIT may also
convey "virtual" ranges. These ranges are indicated by a UUID in the SPA
Range Structure of UUID_VOLATILE_VIRTUAL_DISK, UUID_VOLATILE_VIRTUAL_CD,
UUID_PERSISTENT_VIRTUAL_DISK, or UUID_PERSISTENT_VIRTUAL_CD. The
critical difference between virtual ranges and UUID_PERSISTENT_MEMORY,
is that virtual do not support associations with Region Mapping
Structures.  For this reason the "index" value of virtual SPA Range
Structures is allowed to be 0. If a platform BIOS decides to represent
NVDIMMs with disconnected "Region Mapping Structures" (range-index ==
0), the kernel may falsely associate them with standalone ranges where
the "SPA Range Structure Index" is also zero. When this happens the
driver may falsely require labels where "virtual disks" are expected to
be label-less. I.e. "label-less" is where the namespace-range ==
region-range and the pmem driver attaches with no user action to create
a namespace.

Cc: Jacek Zloch &lt;jacek.zloch@intel.com&gt;
Cc: Lukasz Sobieraj &lt;lukasz.sobieraj@intel.com&gt;
Cc: "Lee, Chun-Yi" &lt;jlee@suse.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Fixes: c2f32acdf848 ("acpi, nfit: treat virtual ramdisk SPA as pmem region")
Reported-by: Krzysztof Rusocki &lt;krzysztof.rusocki@intel.com&gt;
Reported-by: Damian Bassa &lt;damian.bassa@intel.com&gt;
Reviewed-by: Jeff Moyer &lt;jmoyer@redhat.com&gt;
Link: https://lore.kernel.org/r/162870796589.2521182.1240403310175570220.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: NFIT: Fix comparison to '-ENXIO'</title>
<updated>2020-11-10T11:37:31Z</updated>
<author>
<name>Zhang Qilong</name>
</author>
<published>2020-10-27T13:49:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=937753df482c57b7e761411bcb257a5f0e410d16'/>
<id>urn:sha1:937753df482c57b7e761411bcb257a5f0e410d16</id>
<content type='text'>
[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ]

Initial value of rc is '-ENXIO', and we should
use the initial value to check it.

Signed-off-by: Zhang Qilong &lt;zhangqilong3@huawei.com&gt;
Reviewed-by: Pankaj Gupta &lt;pankaj.gupta.linux@gmail.com&gt;
Reviewed-by: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>acpi/nfit: improve bounds checking for 'func'</title>
<updated>2020-04-21T07:04:52Z</updated>
<author>
<name>Dan Carpenter</name>
</author>
<published>2020-02-25T16:20:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4542e583e2b82e573b94e4afcc5ca3c04288aae1'/>
<id>urn:sha1:4542e583e2b82e573b94e4afcc5ca3c04288aae1</id>
<content type='text'>
commit 01091c496f920e634ea84b689f480c39016752a8 upstream.

The 'func' variable can come from the user in the __nd_ioctl().  If it's
too high then the (1 &lt;&lt; func) shift in acpi_nfit_clear_to_send() is
undefined.  In acpi_nfit_ctl() we pass 'func' to test_bit(func, &amp;dsm_mask)
which could result in an out of bounds access.

To fix these issues, I introduced the NVDIMM_CMD_MAX (31) define and
updated nfit_dsm_revid() to use that define as well instead of magic
numbers.

Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Link: https://lore.kernel.org/r/20200225161927.hvftuq7kjn547fyj@kili.mountain
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI: NFIT: Fix unlock on error in scrub_show()</title>
<updated>2019-10-22T09:37:13Z</updated>
<author>
<name>Dan Carpenter</name>
</author>
<published>2019-10-18T12:35:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=edffc70f505abdab885f4b4212438b4298dec78f'/>
<id>urn:sha1:edffc70f505abdab885f4b4212438b4298dec78f</id>
<content type='text'>
We change the locking in this function and forgot to update this error
path so we are accidentally still holding the "dev-&gt;lockdep_mutex".

Fixes: 87a30e1f05d7 ("driver-core, libnvdimm: Let device subsystems add local lockdep coverage")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Ira Weiny &lt;ira.weiny@intel.com&gt;
Acked-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: 5.3+ &lt;stable@vger.kernel.org&gt; # 5.3+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>libnvdimm/security: Introduce a 'frozen' attribute</title>
<updated>2019-08-29T20:49:13Z</updated>
<author>
<name>Dan Williams</name>
</author>
<published>2019-08-27T00:54:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d78c620a2e824d7b01a6e991208a8aa2c938cabe'/>
<id>urn:sha1:d78c620a2e824d7b01a6e991208a8aa2c938cabe</id>
<content type='text'>
In the process of debugging a system with an NVDIMM that was failing to
unlock it was found that the kernel is reporting 'locked' while the DIMM
security interface is 'frozen'. Unfortunately the security state is
tracked internally as an enum which prevents it from communicating the
difference between 'locked' and 'locked + frozen'. It follows that the
enum also prevents the kernel from communicating 'unlocked + frozen'
which would be useful for debugging why security operations like 'change
passphrase' are disabled.

Ditch the security state enum for a set of flags and introduce a new
sysfs attribute explicitly for the 'frozen' state. The regression risk
is low because the 'frozen' state was already blocked behind the
'locked' state, but will need to revisit if there were cases where
applications need 'frozen' to show up in the primary 'security'
attribute. The expectation is that communicating 'frozen' is mostly a
helper for debug and status monitoring.

Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Reported-by: Jeff Moyer &lt;jmoyer@redhat.com&gt;
Reviewed-by: Jeff Moyer &lt;jmoyer@redhat.com&gt;
Link: https://lore.kernel.org/r/156686729474.184120.5835135644278860826.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'libnvdimm-fixes-5.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm</title>
<updated>2019-07-27T15:25:51Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2019-07-27T15:25:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=523634db145a22cd5562714d4c59ea74686afe38'/>
<id>urn:sha1:523634db145a22cd5562714d4c59ea74686afe38</id>
<content type='text'>
Pull libnvdimm fixes from Dan Williams:
 "A collection of locking and async operations fixes for v5.3-rc2. These
  had been soaking in a branch targeting the merge window, but missed
  due to a regression hunt. This fixed up version has otherwise been in
  -next this past week with no reported issues.

  In order to gain confidence in the locking changes the pull also
  includes a debug / instrumentation patch to enable lockdep coverage
  for libnvdimm subsystem operations that depend on the device_lock for
  exclusion. As mentioned in the changelog it is a hack, but it works
  and documents the locking expectations of the sub-system in a way that
  others can use lockdep to verify. The driver core touches got an ack
  from Greg.

  Summary:

   - Fix duplicate device_unregister() calls (multiple threads competing
     to do unregister work when scheduling device removal from a sysfs
     attribute of the self-same device).

   - Fix badblocks registration order bug. Ensure region badblocks are
     initialized in advance of namespace registration.

   - Fix a deadlock between the bus lock and probe operations.

   - Export device-core infrastructure to coordinate async operations
     via the device -&gt;dead state.

   - Add device-core infrastructure to validate device_lock() usage with
     lockdep"

* tag 'libnvdimm-fixes-5.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  driver-core, libnvdimm: Let device subsystems add local lockdep coverage
  libnvdimm/bus: Fix wait_nvdimm_bus_probe_idle() ABBA deadlock
  libnvdimm/bus: Stop holding nvdimm_bus_list_mutex over __nd_ioctl()
  libnvdimm/bus: Prepare the nd_ioctl() path to be re-entrant
  libnvdimm/region: Register badblocks before namespaces
  libnvdimm/bus: Prevent duplicate device_unregister() calls
  drivers/base: Introduce kill_device()
</content>
</entry>
<entry>
<title>driver-core, libnvdimm: Let device subsystems add local lockdep coverage</title>
<updated>2019-07-18T23:23:27Z</updated>
<author>
<name>Dan Williams</name>
</author>
<published>2019-07-18T01:08:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=87a30e1f05d73a34e6d1895065541369131aaf1c'/>
<id>urn:sha1:87a30e1f05d73a34e6d1895065541369131aaf1c</id>
<content type='text'>
For good reason, the standard device_lock() is marked
lockdep_set_novalidate_class() because there is simply no sane way to
describe the myriad ways the device_lock() ordered with other locks.
However, that leaves subsystems that know their own local device_lock()
ordering rules to find lock ordering mistakes manually. Instead,
introduce an optional / additional lockdep-enabled lock that a subsystem
can acquire in all the same paths that the device_lock() is acquired.

A conversion of the NFIT driver and NVDIMM subsystem to a
lockdep-validate device_lock() scheme is included. The
debug_nvdimm_lock() implementation implements the correct lock-class and
stacking order for the libnvdimm device topology hierarchy.

Yes, this is a hack, but hopefully it is a useful hack for other
subsystems device_lock() debug sessions. Quoting Greg:

    "Yeah, it feels a bit hacky but it's really up to a subsystem to mess up
     using it as much as anything else, so user beware :)

     I don't object to it if it makes things easier for you to debug."

Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Ira Weiny &lt;ira.weiny@intel.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Keith Busch &lt;keith.busch@intel.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
Cc: "Rafael J. Wysocki" &lt;rjw@rjwysocki.net&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Ira Weiny &lt;ira.weiny@intel.com&gt;
Link: https://lore.kernel.org/r/156341210661.292348.7014034644265455704.stgit@dwillia2-desk3.amr.corp.intel.com
</content>
</entry>
<entry>
<title>libnvdimm: nd_region flush callback support</title>
<updated>2019-07-05T22:19:10Z</updated>
<author>
<name>Pankaj Gupta</name>
</author>
<published>2019-07-05T14:03:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c5d4355d10d414a96ca870b731756b89d068d57a'/>
<id>urn:sha1:c5d4355d10d414a96ca870b731756b89d068d57a</id>
<content type='text'>
This patch adds functionality to perform flush from guest
to host over VIRTIO. We are registering a callback based
on 'nd_region' type. virtio_pmem driver requires this special
flush function. For rest of the region types we are registering
existing flush function. Report error returned by host fsync
failure to userspace.

Signed-off-by: Pankaj Gupta &lt;pagupta@redhat.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 295</title>
<updated>2019-06-05T15:36:38Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2019-05-29T14:18:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5b497af42fab12cadc0e29bcb7052cf9963603f5'/>
<id>urn:sha1:5b497af42fab12cadc0e29bcb7052cf9963603f5</id>
<content type='text'>
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of version 2 of the gnu general public license as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 64 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Alexios Zavras &lt;alexios.zavras@intel.com&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141901.894819585@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
