forked from luck/tmp_suning_uos_patched
Char/Misc driver fixes for 5.3-rc7
Here are some small char and misc driver fixes for reported issues for 5.3-rc7 Also included in here is the documentation for how we are handling hardware issues under embargo that everyone has finally agreed on, as well as a MAINTAINERS update for the suckers who agreed to handle the LICENSES/ files. All of these have been in linux-next last week with no reported issues. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -----BEGIN PGP SIGNATURE----- iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXW02Nw8cZ3JlZ0Brcm9h aC5jb20ACgkQMUfUDdst+ylCNQCgwWKnuinNXnxCvRJhqINnlBrwb/YAoMEogKuv olIx01hAZEUNZuAOgAXj =eXfW -----END PGP SIGNATURE----- Merge tag 'char-misc-5.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are some small char and misc driver fixes for reported issues for 5.3-rc7 Also included in here is the documentation for how we are handling hardware issues under embargo that everyone has finally agreed on, as well as a MAINTAINERS update for the suckers who agreed to handle the LICENSES/ files. All of these have been in linux-next last week with no reported issues" * tag 'char-misc-5.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: fsi: scom: Don't abort operations for minor errors vmw_balloon: Fix offline page marking with compaction VMCI: Release resource if the work is already queued Documentation/process: Embargoed hardware security issues lkdtm/bugs: fix build error in lkdtm_EXHAUST_STACK mei: me: add Tiger Lake point LP device ID intel_th: pci: Add Tiger Lake support intel_th: pci: Add support for another Lewisburg PCH stm class: Fix a double free of stm_source_device MAINTAINERS: add entry for LICENSES and SPDX stuff fpga: altera-ps-spi: Fix getting of optional confd gpio
This commit is contained in:
Linus Torvalds
commit
49ffdb4c7c
279
Documentation/process/embargoed-hardware-issues.rst
Normal file
279
Documentation/process/embargoed-hardware-issues.rst
Normal file
|
|
@ -0,0 +1,279 @@
|
|||
Embargoed hardware issues
|
||||
=========================
|
||||
|
||||
Scope
|
||||
-----
|
||||
|
||||
Hardware issues which result in security problems are a different category
|
||||
of security bugs than pure software bugs which only affect the Linux
|
||||
kernel.
|
||||
|
||||
Hardware issues like Meltdown, Spectre, L1TF etc. must be treated
|
||||
differently because they usually affect all Operating Systems ("OS") and
|
||||
therefore need coordination across different OS vendors, distributions,
|
||||
hardware vendors and other parties. For some of the issues, software
|
||||
mitigations can depend on microcode or firmware updates, which need further
|
||||
coordination.
|
||||
|
||||
.. _Contact:
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
The Linux kernel hardware security team is separate from the regular Linux
|
||||
kernel security team.
|
||||
|
||||
The team only handles the coordination of embargoed hardware security
|
||||
issues. Reports of pure software security bugs in the Linux kernel are not
|
||||
handled by this team and the reporter will be guided to contact the regular
|
||||
Linux kernel security team (:ref:`Documentation/admin-guide/
|
||||
<securitybugs>`) instead.
|
||||
|
||||
The team can be contacted by email at <hardware-security@kernel.org>. This
|
||||
is a private list of security officers who will help you to coordinate an
|
||||
issue according to our documented process.
|
||||
|
||||
The list is encrypted and email to the list can be sent by either PGP or
|
||||
S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
|
||||
certificate. The list's PGP key and S/MIME certificate are available from
|
||||
https://www.kernel.org/....
|
||||
|
||||
While hardware security issues are often handled by the affected hardware
|
||||
vendor, we welcome contact from researchers or individuals who have
|
||||
identified a potential hardware flaw.
|
||||
|
||||
Hardware security officers
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The current team of hardware security officers:
|
||||
|
||||
- Linus Torvalds (Linux Foundation Fellow)
|
||||
- Greg Kroah-Hartman (Linux Foundation Fellow)
|
||||
- Thomas Gleixner (Linux Foundation Fellow)
|
||||
|
||||
Operation of mailing-lists
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The encrypted mailing-lists which are used in our process are hosted on
|
||||
Linux Foundation's IT infrastructure. By providing this service Linux
|
||||
Foundation's director of IT Infrastructure security technically has the
|
||||
ability to access the embargoed information, but is obliged to
|
||||
confidentiality by his employment contract. Linux Foundation's director of
|
||||
IT Infrastructure security is also responsible for the kernel.org
|
||||
infrastructure.
|
||||
|
||||
The Linux Foundation's current director of IT Infrastructure security is
|
||||
Konstantin Ryabitsev.
|
||||
|
||||
|
||||
Non-disclosure agreements
|
||||
-------------------------
|
||||
|
||||
The Linux kernel hardware security team is not a formal body and therefore
|
||||
unable to enter into any non-disclosure agreements. The kernel community
|
||||
is aware of the sensitive nature of such issues and offers a Memorandum of
|
||||
Understanding instead.
|
||||
|
||||
|
||||
Memorandum of Understanding
|
||||
---------------------------
|
||||
|
||||
The Linux kernel community has a deep understanding of the requirement to
|
||||
keep hardware security issues under embargo for coordination between
|
||||
different OS vendors, distributors, hardware vendors and other parties.
|
||||
|
||||
The Linux kernel community has successfully handled hardware security
|
||||
issues in the past and has the necessary mechanisms in place to allow
|
||||
community compliant development under embargo restrictions.
|
||||
|
||||
The Linux kernel community has a dedicated hardware security team for
|
||||
initial contact, which oversees the process of handling such issues under
|
||||
embargo rules.
|
||||
|
||||
The hardware security team identifies the developers (domain experts) who
|
||||
will form the initial response team for a particular issue. The initial
|
||||
response team can bring in further developers (domain experts) to address
|
||||
the issue in the best technical way.
|
||||
|
||||
All involved developers pledge to adhere to the embargo rules and to keep
|
||||
the received information confidential. Violation of the pledge will lead to
|
||||
immediate exclusion from the current issue and removal from all related
|
||||
mailing-lists. In addition, the hardware security team will also exclude
|
||||
the offender from future issues. The impact of this consequence is a highly
|
||||
effective deterrent in our community. In case a violation happens the
|
||||
hardware security team will inform the involved parties immediately. If you
|
||||
or anyone becomes aware of a potential violation, please report it
|
||||
immediately to the Hardware security officers.
|
||||
|
||||
|
||||
Process
|
||||
^^^^^^^
|
||||
|
||||
Due to the globally distributed nature of Linux kernel development,
|
||||
face-to-face meetings are almost impossible to address hardware security
|
||||
issues. Phone conferences are hard to coordinate due to time zones and
|
||||
other factors and should be only used when absolutely necessary. Encrypted
|
||||
email has been proven to be the most effective and secure communication
|
||||
method for these types of issues.
|
||||
|
||||
Start of Disclosure
|
||||
"""""""""""""""""""
|
||||
|
||||
Disclosure starts by contacting the Linux kernel hardware security team by
|
||||
email. This initial contact should contain a description of the problem and
|
||||
a list of any known affected hardware. If your organization builds or
|
||||
distributes the affected hardware, we encourage you to also consider what
|
||||
other hardware could be affected.
|
||||
|
||||
The hardware security team will provide an incident-specific encrypted
|
||||
mailing-list which will be used for initial discussion with the reporter,
|
||||
further disclosure and coordination.
|
||||
|
||||
The hardware security team will provide the disclosing party a list of
|
||||
developers (domain experts) who should be informed initially about the
|
||||
issue after confirming with the developers that they will adhere to this
|
||||
Memorandum of Understanding and the documented process. These developers
|
||||
form the initial response team and will be responsible for handling the
|
||||
issue after initial contact. The hardware security team is supporting the
|
||||
response team, but is not necessarily involved in the mitigation
|
||||
development process.
|
||||
|
||||
While individual developers might be covered by a non-disclosure agreement
|
||||
via their employer, they cannot enter individual non-disclosure agreements
|
||||
in their role as Linux kernel developers. They will, however, agree to
|
||||
adhere to this documented process and the Memorandum of Understanding.
|
||||
|
||||
|
||||
Disclosure
|
||||
""""""""""
|
||||
|
||||
The disclosing party provides detailed information to the initial response
|
||||
team via the specific encrypted mailing-list.
|
||||
|
||||
From our experience the technical documentation of these issues is usually
|
||||
a sufficient starting point and further technical clarification is best
|
||||
done via email.
|
||||
|
||||
Mitigation development
|
||||
""""""""""""""""""""""
|
||||
|
||||
The initial response team sets up an encrypted mailing-list or repurposes
|
||||
an existing one if appropriate. The disclosing party should provide a list
|
||||
of contacts for all other parties who have already been, or should be
|
||||
informed about the issue. The response team contacts these parties so they
|
||||
can name experts who should be subscribed to the mailing-list.
|
||||
|
||||
Using a mailing-list is close to the normal Linux development process and
|
||||
has been successfully used in developing mitigations for various hardware
|
||||
security issues in the past.
|
||||
|
||||
The mailing-list operates in the same way as normal Linux development.
|
||||
Patches are posted, discussed and reviewed and if agreed on applied to a
|
||||
non-public git repository which is only accessible to the participating
|
||||
developers via a secure connection. The repository contains the main
|
||||
development branch against the mainline kernel and backport branches for
|
||||
stable kernel versions as necessary.
|
||||
|
||||
The initial response team will identify further experts from the Linux
|
||||
kernel developer community as needed and inform the disclosing party about
|
||||
their participation. Bringing in experts can happen at any time of the
|
||||
development process and often needs to be handled in a timely manner.
|
||||
|
||||
Coordinated release
|
||||
"""""""""""""""""""
|
||||
|
||||
The involved parties will negotiate the date and time where the embargo
|
||||
ends. At that point the prepared mitigations are integrated into the
|
||||
relevant kernel trees and published.
|
||||
|
||||
While we understand that hardware security issues need coordinated embargo
|
||||
time, the embargo time should be constrained to the minimum time which is
|
||||
required for all involved parties to develop, test and prepare the
|
||||
mitigations. Extending embargo time artificially to meet conference talk
|
||||
dates or other non-technical reasons is creating more work and burden for
|
||||
the involved developers and response teams as the patches need to be kept
|
||||
up to date in order to follow the ongoing upstream kernel development,
|
||||
which might create conflicting changes.
|
||||
|
||||
CVE assignment
|
||||
""""""""""""""
|
||||
|
||||
Neither the hardware security team nor the initial response team assign
|
||||
CVEs, nor are CVEs required for the development process. If CVEs are
|
||||
provided by the disclosing party they can be used for documentation
|
||||
purposes.
|
||||
|
||||
Process ambassadors
|
||||
-------------------
|
||||
|
||||
For assistance with this process we have established ambassadors in various
|
||||
organizations, who can answer questions about or provide guidance on the
|
||||
reporting process and further handling. Ambassadors are not involved in the
|
||||
disclosure of a particular issue, unless requested by a response team or by
|
||||
an involved disclosed party. The current ambassadors list:
|
||||
|
||||
============= ========================================================
|
||||
ARM
|
||||
AMD
|
||||
IBM
|
||||
Intel
|
||||
Qualcomm
|
||||
|
||||
Microsoft
|
||||
VMware
|
||||
XEN
|
||||
|
||||
Canonical Tyler Hicks <tyhicks@canonical.com>
|
||||
Debian Ben Hutchings <ben@decadent.org.uk>
|
||||
Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
SUSE Jiri Kosina <jkosina@suse.cz>
|
||||
|
||||
Amazon
|
||||
Google
|
||||
============== ========================================================
|
||||
|
||||
If you want your organization to be added to the ambassadors list, please
|
||||
contact the hardware security team. The nominated ambassador has to
|
||||
understand and support our process fully and is ideally well connected in
|
||||
the Linux kernel community.
|
||||
|
||||
Encrypted mailing-lists
|
||||
-----------------------
|
||||
|
||||
We use encrypted mailing-lists for communication. The operating principle
|
||||
of these lists is that email sent to the list is encrypted either with the
|
||||
list's PGP key or with the list's S/MIME certificate. The mailing-list
|
||||
software decrypts the email and re-encrypts it individually for each
|
||||
subscriber with the subscriber's PGP key or S/MIME certificate. Details
|
||||
about the mailing-list software and the setup which is used to ensure the
|
||||
security of the lists and protection of the data can be found here:
|
||||
https://www.kernel.org/....
|
||||
|
||||
List keys
|
||||
^^^^^^^^^
|
||||
|
||||
For initial contact see :ref:`Contact`. For incident specific mailing-lists
|
||||
the key and S/MIME certificate are conveyed to the subscribers by email
|
||||
sent from the specific list.
|
||||
|
||||
Subscription to incident specific lists
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Subscription is handled by the response teams. Disclosed parties who want
|
||||
to participate in the communication send a list of potential subscribers to
|
||||
the response team so the response team can validate subscription requests.
|
||||
|
||||
Each subscriber needs to send a subscription request to the response team
|
||||
by email. The email must be signed with the subscriber's PGP key or S/MIME
|
||||
certificate. If a PGP key is used, it must be available from a public key
|
||||
server and is ideally connected to the Linux kernel's PGP web of trust. See
|
||||
also: https://www.kernel.org/signature.html.
|
||||
|
||||
The response team verifies that the subscriber request is valid and adds
|
||||
the subscriber to the list. After subscription the subscriber will receive
|
||||
email from the mailing-list which is signed either with the list's PGP key
|
||||
or the list's S/MIME certificate. The subscriber's email client can extract
|
||||
the PGP key or the S/MIME certificate from the signature so the subscriber
|
||||
can send encrypted email to the list.
|
||||
|
||||
|
|
@ -45,6 +45,7 @@ Other guides to the community that are of interest to most developers are:
|
|||
submit-checklist
|
||||
kernel-docs
|
||||
deprecated
|
||||
embargoed-hardware-issues
|
||||
|
||||
These are some overall technical guides that have been put here for now for
|
||||
lack of a better place.
|
||||
|
|
|
|||
12
MAINTAINERS
12
MAINTAINERS
|
|
@ -9229,6 +9229,18 @@ F: include/linux/nd.h
|
|||
F: include/linux/libnvdimm.h
|
||||
F: include/uapi/linux/ndctl.h
|
||||
|
||||
LICENSES and SPDX stuff
|
||||
M: Thomas Gleixner <tglx@linutronix.de>
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
L: linux-spdx@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx.git
|
||||
F: COPYING
|
||||
F: Documentation/process/license-rules.rst
|
||||
F: LICENSES/
|
||||
F: scripts/spdxcheck-test.sh
|
||||
F: scripts/spdxcheck.py
|
||||
|
||||
LIGHTNVM PLATFORM SUPPORT
|
||||
M: Matias Bjorling <mb@lightnvm.io>
|
||||
W: http://github/OpenChannelSSD
|
||||
|
|
|
|||
|
|
@ -210,7 +210,7 @@ static int altera_ps_write_complete(struct fpga_manager *mgr,
|
|||
return -EIO;
|
||||
}
|
||||
|
||||
if (!IS_ERR(conf->confd)) {
|
||||
if (conf->confd) {
|
||||
if (!gpiod_get_raw_value_cansleep(conf->confd)) {
|
||||
dev_err(&mgr->dev, "CONF_DONE is inactive!\n");
|
||||
return -EIO;
|
||||
|
|
@ -289,10 +289,13 @@ static int altera_ps_probe(struct spi_device *spi)
|
|||
return PTR_ERR(conf->status);
|
||||
}
|
||||
|
||||
conf->confd = devm_gpiod_get(&spi->dev, "confd", GPIOD_IN);
|
||||
conf->confd = devm_gpiod_get_optional(&spi->dev, "confd", GPIOD_IN);
|
||||
if (IS_ERR(conf->confd)) {
|
||||
dev_warn(&spi->dev, "Not using confd gpio: %ld\n",
|
||||
PTR_ERR(conf->confd));
|
||||
dev_err(&spi->dev, "Failed to get confd gpio: %ld\n",
|
||||
PTR_ERR(conf->confd));
|
||||
return PTR_ERR(conf->confd);
|
||||
} else if (!conf->confd) {
|
||||
dev_warn(&spi->dev, "Not using confd gpio");
|
||||
}
|
||||
|
||||
/* Register manager with unique name */
|
||||
|
|
|
|||
|
|
@ -38,8 +38,7 @@
|
|||
#define SCOM_STATUS_PIB_RESP_MASK 0x00007000
|
||||
#define SCOM_STATUS_PIB_RESP_SHIFT 12
|
||||
|
||||
#define SCOM_STATUS_ANY_ERR (SCOM_STATUS_ERR_SUMMARY | \
|
||||
SCOM_STATUS_PROTECTION | \
|
||||
#define SCOM_STATUS_ANY_ERR (SCOM_STATUS_PROTECTION | \
|
||||
SCOM_STATUS_PARITY | \
|
||||
SCOM_STATUS_PIB_ABORT | \
|
||||
SCOM_STATUS_PIB_RESP_MASK)
|
||||
|
|
@ -251,11 +250,6 @@ static int handle_fsi2pib_status(struct scom_device *scom, uint32_t status)
|
|||
/* Return -EBUSY on PIB abort to force a retry */
|
||||
if (status & SCOM_STATUS_PIB_ABORT)
|
||||
return -EBUSY;
|
||||
if (status & SCOM_STATUS_ERR_SUMMARY) {
|
||||
fsi_device_write(scom->fsi_dev, SCOM_FSI2PIB_RESET_REG, &dummy,
|
||||
sizeof(uint32_t));
|
||||
return -EIO;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -164,6 +164,11 @@ static const struct pci_device_id intel_th_pci_id_table[] = {
|
|||
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa1a6),
|
||||
.driver_data = (kernel_ulong_t)0,
|
||||
},
|
||||
{
|
||||
/* Lewisburg PCH */
|
||||
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa226),
|
||||
.driver_data = (kernel_ulong_t)0,
|
||||
},
|
||||
{
|
||||
/* Gemini Lake */
|
||||
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x318e),
|
||||
|
|
@ -199,6 +204,11 @@ static const struct pci_device_id intel_th_pci_id_table[] = {
|
|||
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x45c5),
|
||||
.driver_data = (kernel_ulong_t)&intel_th_2x,
|
||||
},
|
||||
{
|
||||
/* Tiger Lake PCH */
|
||||
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa0a6),
|
||||
.driver_data = (kernel_ulong_t)&intel_th_2x,
|
||||
},
|
||||
{ 0 },
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -1276,7 +1276,6 @@ int stm_source_register_device(struct device *parent,
|
|||
|
||||
err:
|
||||
put_device(&src->dev);
|
||||
kfree(src);
|
||||
|
||||
return err;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ struct lkdtm_list {
|
|||
* recurse past the end of THREAD_SIZE by default.
|
||||
*/
|
||||
#if defined(CONFIG_FRAME_WARN) && (CONFIG_FRAME_WARN > 0)
|
||||
#define REC_STACK_SIZE (CONFIG_FRAME_WARN / 2)
|
||||
#define REC_STACK_SIZE (_AC(CONFIG_FRAME_WARN, UL) / 2)
|
||||
#else
|
||||
#define REC_STACK_SIZE (THREAD_SIZE / 8)
|
||||
#endif
|
||||
|
|
@ -91,7 +91,7 @@ void lkdtm_LOOP(void)
|
|||
|
||||
void lkdtm_EXHAUST_STACK(void)
|
||||
{
|
||||
pr_info("Calling function with %d frame size to depth %d ...\n",
|
||||
pr_info("Calling function with %lu frame size to depth %d ...\n",
|
||||
REC_STACK_SIZE, recur_count);
|
||||
recursive_loop(recur_count);
|
||||
pr_info("FAIL: survived without exhausting stack?!\n");
|
||||
|
|
|
|||
|
|
@ -81,6 +81,8 @@
|
|||
|
||||
#define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */
|
||||
|
||||
#define MEI_DEV_ID_TGP_LP 0xA0E0 /* Tiger Lake Point LP */
|
||||
|
||||
#define MEI_DEV_ID_MCC 0x4B70 /* Mule Creek Canyon (EHL) */
|
||||
#define MEI_DEV_ID_MCC_4 0x4B75 /* Mule Creek Canyon 4 (EHL) */
|
||||
|
||||
|
|
|
|||
|
|
@ -98,6 +98,8 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
|
|||
|
||||
{MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
|
||||
|
||||
{MEI_PCI_DEVICE(MEI_DEV_ID_TGP_LP, MEI_ME_PCH12_CFG)},
|
||||
|
||||
{MEI_PCI_DEVICE(MEI_DEV_ID_MCC, MEI_ME_PCH12_CFG)},
|
||||
{MEI_PCI_DEVICE(MEI_DEV_ID_MCC_4, MEI_ME_PCH8_CFG)},
|
||||
|
||||
|
|
|
|||
|
|
@ -691,7 +691,6 @@ static int vmballoon_alloc_page_list(struct vmballoon *b,
|
|||
}
|
||||
|
||||
if (page) {
|
||||
vmballoon_mark_page_offline(page, ctl->page_size);
|
||||
/* Success. Add the page to the list and continue. */
|
||||
list_add(&page->lru, &ctl->pages);
|
||||
continue;
|
||||
|
|
@ -930,7 +929,6 @@ static void vmballoon_release_page_list(struct list_head *page_list,
|
|||
|
||||
list_for_each_entry_safe(page, tmp, page_list, lru) {
|
||||
list_del(&page->lru);
|
||||
vmballoon_mark_page_online(page, page_size);
|
||||
__free_pages(page, vmballoon_page_order(page_size));
|
||||
}
|
||||
|
||||
|
|
@ -1005,6 +1003,7 @@ static void vmballoon_enqueue_page_list(struct vmballoon *b,
|
|||
enum vmballoon_page_size_type page_size)
|
||||
{
|
||||
unsigned long flags;
|
||||
struct page *page;
|
||||
|
||||
if (page_size == VMW_BALLOON_4K_PAGE) {
|
||||
balloon_page_list_enqueue(&b->b_dev_info, pages);
|
||||
|
|
@ -1014,6 +1013,11 @@ static void vmballoon_enqueue_page_list(struct vmballoon *b,
|
|||
* for the balloon compaction mechanism.
|
||||
*/
|
||||
spin_lock_irqsave(&b->b_dev_info.pages_lock, flags);
|
||||
|
||||
list_for_each_entry(page, pages, lru) {
|
||||
vmballoon_mark_page_offline(page, VMW_BALLOON_2M_PAGE);
|
||||
}
|
||||
|
||||
list_splice_init(pages, &b->huge_pages);
|
||||
__count_vm_events(BALLOON_INFLATE, *n_pages *
|
||||
vmballoon_page_in_frames(VMW_BALLOON_2M_PAGE));
|
||||
|
|
@ -1056,6 +1060,8 @@ static void vmballoon_dequeue_page_list(struct vmballoon *b,
|
|||
/* 2MB pages */
|
||||
spin_lock_irqsave(&b->b_dev_info.pages_lock, flags);
|
||||
list_for_each_entry_safe(page, tmp, &b->huge_pages, lru) {
|
||||
vmballoon_mark_page_online(page, VMW_BALLOON_2M_PAGE);
|
||||
|
||||
list_move(&page->lru, pages);
|
||||
if (++i == n_req_pages)
|
||||
break;
|
||||
|
|
|
|||
|
|
@ -310,7 +310,8 @@ int vmci_dbell_host_context_notify(u32 src_cid, struct vmci_handle handle)
|
|||
|
||||
entry = container_of(resource, struct dbell_entry, resource);
|
||||
if (entry->run_delayed) {
|
||||
schedule_work(&entry->work);
|
||||
if (!schedule_work(&entry->work))
|
||||
vmci_resource_put(resource);
|
||||
} else {
|
||||
entry->notify_cb(entry->client_data);
|
||||
vmci_resource_put(resource);
|
||||
|
|
@ -361,7 +362,8 @@ static void dbell_fire_entries(u32 notify_idx)
|
|||
atomic_read(&dbell->active) == 1) {
|
||||
if (dbell->run_delayed) {
|
||||
vmci_resource_get(&dbell->resource);
|
||||
schedule_work(&dbell->work);
|
||||
if (!schedule_work(&dbell->work))
|
||||
vmci_resource_put(&dbell->resource);
|
||||
} else {
|
||||
dbell->notify_cb(dbell->client_data);
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user