<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/base, branch v4.18.14</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.18.14</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.18.14'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-10-13T07:33:13Z</updated>
<entry>
<title>PM / core: Clear the direct_complete flag on errors</title>
<updated>2018-10-13T07:33:13Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2018-10-04T09:08:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a92f4488357e3a5baa444d0b51ef240003805c06'/>
<id>urn:sha1:a92f4488357e3a5baa444d0b51ef240003805c06</id>
<content type='text'>
commit 69e445ab8b66a9f30519842ef18be555d3ee9b51 upstream.

If __device_suspend() runs asynchronously (in which case the device
passed to it is in dpm_suspended_list at that point) and it returns
early on an error or pending wakeup, and the power.direct_complete
flag has been set for the device already, the subsequent
device_resume() will be confused by that and it will call
pm_runtime_enable() incorrectly, as runtime PM has not been
disabled for the device by __device_suspend().

To avoid that, clear power.direct_complete if __device_suspend()
is not going to disable runtime PM for the device before returning.

Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily)
Reported-by: Al Cooper &lt;alcooperx@gmail.com&gt;
Tested-by: Al Cooper &lt;alcooperx@gmail.com&gt;
Reviewed-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Cc: 3.16+ &lt;stable@vger.kernel.org&gt; # 3.16+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>firmware: Always initialize the fw_priv list object</title>
<updated>2018-10-10T06:56:07Z</updated>
<author>
<name>Bjorn Andersson</name>
<email>bjorn.andersson@linaro.org</email>
</author>
<published>2018-09-20T01:09:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5105f039ef26df26b0ffd830e1e8e36221b47be9'/>
<id>urn:sha1:5105f039ef26df26b0ffd830e1e8e36221b47be9</id>
<content type='text'>
commit 7012040576c6ae25a47035659ee48673612c2c27 upstream.

When freeing the fw_priv the item is taken off the list. This causes an
oops in the FW_OPT_NOCACHE case as the list object is not initialized.

Make sure to initialize the list object regardless of this flag.

Fixes: 422b3db2a503 ("firmware: Fix security issue with request_firmware_into_buf()")
Cc: stable@vger.kernel.org
Cc: Rishabh Bhatnagar &lt;rishabhb@codeaurora.org&gt;
Signed-off-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Reviewed-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>firmware: Fix security issue with request_firmware_into_buf()</title>
<updated>2018-10-10T06:56:06Z</updated>
<author>
<name>Rishabh Bhatnagar</name>
<email>rishabhb@codeaurora.org</email>
</author>
<published>2018-08-31T15:43:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=aa26105b73b0a68524f655fc6336e05906843fc2'/>
<id>urn:sha1:aa26105b73b0a68524f655fc6336e05906843fc2</id>
<content type='text'>
commit 422b3db2a5036add39a82425b1dd9fb6c96481e8 upstream.

When calling request_firmware_into_buf() with the FW_OPT_NOCACHE flag
it is expected that firmware is loaded into buffer from memory.
But inside alloc_lookup_fw_priv every new firmware that is loaded is
added to the firmware cache (fwc) list head. So if any driver requests
a firmware that is already loaded the code iterates over the above
mentioned list and it can end up giving a pointer to other device driver's
firmware buffer.
Also the existing copy may either be modified by drivers, remote processors
or even freed. This causes a potential security issue with batched requests
when using request_firmware_into_buf.

Fix alloc_lookup_fw_priv to not add to the fwc head list if FW_OPT_NOCACHE
is set, and also don't do the lookup in the list.

Fixes: 0e742e9275 ("firmware: provide infrastructure to make fw caching optional")
[mcgrof: broken since feature introduction on v4.8]

Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Vikram Mulukutla &lt;markivx@codeaurora.org&gt;
Signed-off-by: Rishabh Bhatnagar &lt;rishabhb@codeaurora.org&gt;
Signed-off-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drivers/base: stop new probing during shutdown</title>
<updated>2018-09-26T06:39:28Z</updated>
<author>
<name>Pingfan Liu</name>
<email>kernelfans@gmail.com</email>
</author>
<published>2018-07-19T05:14:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ee4fa1801dfb8113866bbe91ba9f1e7c0b2dbdb7'/>
<id>urn:sha1:ee4fa1801dfb8113866bbe91ba9f1e7c0b2dbdb7</id>
<content type='text'>
[ Upstream commit 3297c8fc65af5d40501ea7cddff1b195cae57e4e ]

There is a race window in device_shutdown(), which may cause
-1. parent device shut down before child or
-2. no shutdown on a new probing device.

For 1st, taking the following scenario:
         device_shutdown                        new plugin device
  list_del_init(parent_dev);
  spin_unlock(list_lock);
                                                  device_add(child)
                                                  probe child
  shutdown parent_dev
       --&gt; now child is on the tail of devices_kset

For 2nd, taking the following scenario:
         device_shutdown                        new plugin device
                                                  device_add(dev)
  device_lock(dev);
  ...
  device_unlock(dev);
                                                  probe dev
       --&gt; now, the new occurred dev has no opportunity to shutdown

To fix this race issue, just prevent the new probing request. With this
logic, device_shutdown() is more similar to dpm_prepare().

Signed-off-by: Pingfan Liu &lt;kernelfans@gmail.com&gt;
Reviewed-by: Rafael J. Wysocki &lt;rafael@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>memory_hotplug: fix kernel_panic on offline page processing</title>
<updated>2018-09-19T20:41:20Z</updated>
<author>
<name>Mikhail Zaslonko</name>
<email>zaslonko@linux.ibm.com</email>
</author>
<published>2018-09-04T22:46:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=15a6f8974a8c14d02dc1c471219aa2ab16a0b692'/>
<id>urn:sha1:15a6f8974a8c14d02dc1c471219aa2ab16a0b692</id>
<content type='text'>
commit 4e8346d0be889c7ab5eb2d3deedc18111d741e99 upstream.

Within show_valid_zones() the function test_pages_in_a_zone() should be
called for online memory blocks only.

Otherwise it might lead to the VM_BUG_ON due to uninitialized struct
pages (when CONFIG_DEBUG_VM_PGFLAGS kernel option is set):

 page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
 ------------[ cut here ]------------
 Call Trace:
 ([&lt;000000000038f91e&gt;] test_pages_in_a_zone+0xe6/0x168)
  [&lt;0000000000923472&gt;] show_valid_zones+0x5a/0x1a8
  [&lt;0000000000900284&gt;] dev_attr_show+0x3c/0x78
  [&lt;000000000046f6f0&gt;] sysfs_kf_seq_show+0xd0/0x150
  [&lt;00000000003ef662&gt;] seq_read+0x212/0x4b8
  [&lt;00000000003bf202&gt;] __vfs_read+0x3a/0x178
  [&lt;00000000003bf3ca&gt;] vfs_read+0x8a/0x148
  [&lt;00000000003bfa3a&gt;] ksys_read+0x62/0xb8
  [&lt;0000000000bc2220&gt;] system_call+0xdc/0x2d8

That VM_BUG_ON was triggered by the page poisoning introduced in
mm/sparse.c with the git commit d0dc12e86b31 ("mm/memory_hotplug:
optimize memory hotplug").

With the same commit the new 'nid' field has been added to the struct
memory_block in order to store and later on derive the node id for
offline pages (instead of accessing struct page which might be
uninitialized).  But one reference to nid in show_valid_zones() function
has been overlooked.  Fixed with current commit.  Also, nr_pages will
not be used any more after test_pages_in_a_zone() call, do not update
it.

Link: http://lkml.kernel.org/r/20180828090539.41491-1-zaslonko@linux.ibm.com
Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug")
Signed-off-by: Mikhail Zaslonko &lt;zaslonko@linux.ibm.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Reviewed-by: Pavel Tatashin &lt;pavel.tatashin@microsoft.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;	[4.17+]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>PM / clk: signedness bug in of_pm_clk_add_clks()</title>
<updated>2018-09-05T07:29:55Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-08-23T13:59:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=86b0dd9d0ebc78a799075c13f34ca48cc9fc2cc0'/>
<id>urn:sha1:86b0dd9d0ebc78a799075c13f34ca48cc9fc2cc0</id>
<content type='text'>
commit 5e2e2f9f76e157063a656351728703cb02b068f1 upstream.

"count" needs to be signed for the error handling to work.  I made "i"
signed as well so they match.

Fixes: 02113ba93ea4 (PM / clk: Add support for obtaining clocks from device-tree)
Cc: 4.6+ &lt;stable@vger.kernel.org&gt; # 4.6+
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86/speculation/l1tf: Add sysfs reporting for l1tf</title>
<updated>2018-08-15T15:37:25Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@linux.intel.com</email>
</author>
<published>2018-06-13T22:48:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dcd1b1099b59cef17fdd5f90ee564e7b304619c2'/>
<id>urn:sha1:dcd1b1099b59cef17fdd5f90ee564e7b304619c2</id>
<content type='text'>
commit 17dbca119312b4e8173d4e25ff64262119fcef38 upstream.

L1TF core kernel workarounds are cheap and normally always enabled, However
they still should be reported in sysfs if the system is vulnerable or
mitigated. Add the necessary CPU feature/bug bits.

- Extend the existing checks for Meltdowns to determine if the system is
  vulnerable. All CPUs which are not vulnerable to Meltdown are also not
  vulnerable to L1TF

- Check for 32bit non PAE and emit a warning as there is no practical way
  for mitigation due to the limited physical address bits

- If the system has more than MAX_PA/2 physical memory the invert page
  workarounds don't protect the system against the L1TF attack anymore,
  because an inverted physical address will also point to valid
  memory. Print a warning in this case and report that the system is
  vulnerable.

Add a function which returns the PFN limit for the L1TF mitigation, which
will be used in follow up patches for sanity and range checks.

[ tglx: Renamed the CPU feature bit to L1TF_PTEINV ]

Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Acked-by: Dave Hansen &lt;dave.hansen@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'driver-core-4.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core</title>
<updated>2018-07-26T16:25:03Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-07-26T16:25:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a5f9e5dab35ac0c3e6d03a2ab71477aff250d21b'/>
<id>urn:sha1:a5f9e5dab35ac0c3e6d03a2ab71477aff250d21b</id>
<content type='text'>
Pull driver core fix from Greg KH:
 "This is a single driver core fix for 4.18-rc7. It partially reverts a
  previous commit to resolve some reported issues.

  It has been in linux-next for a while now with no reported issues"

* tag 'driver-core-4.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  driver core: Partially revert "driver core: correct device's shutdown order"
</content>
</entry>
<entry>
<title>driver core: Partially revert "driver core: correct device's shutdown order"</title>
<updated>2018-07-10T15:47:43Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2018-07-10T12:51:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=722e5f2b1eec7de61117b7c0a7914761e3da2eda'/>
<id>urn:sha1:722e5f2b1eec7de61117b7c0a7914761e3da2eda</id>
<content type='text'>
Commit 52cdbdd49853 (driver core: correct device's shutdown order)
introduced a regression by breaking device shutdown on some systems.

Namely, the devices_kset_move_last() call in really_probe() added by
that commit is a mistake as it may cause parents to follow children
in the devices_kset list which then causes shutdown to fail.  For
example, if a device has children before really_probe() is called
for it (which is not uncommon), that call will cause it to be
reordered after the children in the devices_kset list and the
ordering of that list will not reflect the correct device shutdown
order any more.

Also it causes the devices_kset list to be constantly reordered
until all drivers have been probed which is totally pointless
overhead in the majority of cases and it only covered an issue
with system shutdown, while system-wide suspend/resume potentially
had the same issue on the affected platforms (which was not covered).

Moreover, the shutdown issue originally addressed by the change in
really_probe() made by commit 52cdbdd49853 is not present in 4.18-rc
any more, since dra7 started to use the sdhci-omap driver which
doesn't disable any regulators during shutdown, so the really_probe()
part of commit 52cdbdd49853 can be safely reverted.  [The original
issue was related to the omap_hsmmc driver used by dra7 previously.]

For the above reasons, revert the really_probe() modifications made
by commit 52cdbdd49853.

The other code changes made by commit 52cdbdd49853 are useful and
they need not be reverted.

Fixes: 52cdbdd49853 (driver core: correct device's shutdown order)
Link: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/
Reported-by: Pingfan Liu &lt;kernelfans@gmail.com&gt;
Tested-by: Pingfan Liu &lt;kernelfans@gmail.com&gt;
Reviewed-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PM / Domains: Don't power on at attach for the multi PM domain case</title>
<updated>2018-07-03T14:42:51Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2018-06-29T09:15:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=895b66129ad8c562865b64306032bdb378f4484f'/>
<id>urn:sha1:895b66129ad8c562865b64306032bdb378f4484f</id>
<content type='text'>
There are no legacy behavior in drivers to consider while attaching a
device to genpd - for the multiple PM domain case.

For that reason, let's instead require the driver to runtime resume the
device, via calling pm_runtime_get_sync() for example, when it needs to
power on the corresponding PM domain.

This allows us to improve the situation during attach. Instead of always
power on the PM domain, which may be unnecessary, let's leave it in its
current state. Additionally, to avoid the PM domain to stay powered on,
let's schedule a power off work.

Fixes: 3c095f32a92b (PM / Domains: Add support for multi PM domains ...)
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
</feed>
