Re: [PATCH v8 v5 1/3] media: dt-bindings: ov8856: Document YAML bindings
Hi Robert, On 20-04-28 20:07, Robert Foss wrote: > From: Dongchun Zhu > > This patch adds documentation of device tree in YAML schema for the > OV8856 CMOS image sensor. > > Signed-off-by: Dongchun Zhu > Signed-off-by: Robert Foss > --- > > - Changes since v7: > * Marco: Make 'port' property optional Sorry if my comment was not precise enough but this wasn't my intention. The port property must be required. > * Maxime & Sakari: Add 'link-frequencies' property to dt binding > * robher: Improve description for 'port' property > > - Changes since v6: > * Marco: remove qcom specifics from DT example This was my intention :) Regards, Marco
[GIT PULL] Crypto Fixes for 5.7
Hi Linus: This push fixes a bunch of bugs detected by KASAN in the caam driver. The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus for you to fetch changes up to 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d: crypto: caam - fix the address of the last entry of S/G (2020-04-16 16:48:56 +1000) Iuliana Prodan (5): crypto: caam - fix use-after-free KASAN issue for SKCIPHER algorithms crypto: caam - fix use-after-free KASAN issue for AEAD algorithms crypto: caam - fix use-after-free KASAN issue for HASH algorithms crypto: caam - fix use-after-free KASAN issue for RSA algorithms crypto: caam - fix the address of the last entry of S/G drivers/crypto/caam/caamalg.c | 10 +++--- drivers/crypto/caam/caamhash.c | 8 ++-- drivers/crypto/caam/caampkc.c | 8 ++-- 3 files changed, 19 insertions(+), 7 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/2] mtd: spi-nor: macronix: Add support for mx25l512/mx25u512
Hi Tudor, > > 2020/04/28 下午 04:39 > > To > > , > > cc > > , , , > , , > > Subject > > Re: [PATCH v2 0/2] mtd: spi-nor: macronix: Add support for mx25l512/mx25u512 > > On Thursday, April 23, 2020 11:38:41 AM EEST Mason Yang wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > Hi, > > > > mx25l51245g/mx25u51245g is a mass production for new design and > > replace mx66l51235l/mx66u51235f(phase out). > > > > Validated by read, erase, read back, write and read back > > on Xilinx Zynq PicoZed FPGA board which included > > Macronix SPI Host (driver/spi/spi-mxic.c). > > > > change log: > > v2: > > Add which controller we tested the mx25l/u51245g. > > > > Mason Yang (2): > > mtd: spi-nor: macronix: Add support for mx25l51245g > > mtd: spi-nor: macronix: Add support for mx25u51245g > > > > drivers/mtd/spi-nor/macronix.c | 6 ++ > > 1 file changed, 6 insertions(+) > > Both applied. In 2/2 I ordered the entry alphabetically. Would you send a > patch to order all entries in macronix.c in alphabetical order? It's a mess > right now. thanks you and I will send a patch to do that. > > Cheers, > ta > > best regards, Mason CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. = CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =
Re: [PATCH V11.2] Documentation/dax: Update Usage section
On 4/28/20 9:33 PM, ira.we...@intel.com wrote: > From: Ira Weiny > > Update the Usage section to reflect the new individual dax selection > functionality. > > Signed-off-by: Ira Weiny > > --- Acked-by: Randy Dunlap Thanks. > --- > Documentation/filesystems/dax.txt | 142 +- > 1 file changed, 139 insertions(+), 3 deletions(-) -- ~Randy
[PATCH][v2] kvm: x86: emulate APERF/MPERF registers
Guest kernel reports a fixed cpu frequency in /proc/cpuinfo,
this is confused to user when turbo is enable, and aperf/mperf
can be used to show current cpu frequency after 7d5905dc14a
"(x86 / CPU: Always show current CPU frequency in /proc/cpuinfo)"
so we should emulate aperf mperf to achieve it
the period of aperf/mperf in guest mode are accumulated as
emulated value, and add per-VM knod to enable emulate mperfaperf
diff v1:
1. support AMD
2. support per-vm capability to enable
Signed-off-by: Li RongQing
Signed-off-by: Chai Wen
Signed-off-by: Jia Lina
---
Documentation/virt/kvm/api.rst | 7 +++
arch/x86/include/asm/kvm_host.h | 4
arch/x86/kvm/cpuid.c| 13 -
arch/x86/kvm/svm.c | 6 ++
arch/x86/kvm/vmx/vmx.c | 6 ++
arch/x86/kvm/x86.c | 37 +
arch/x86/kvm/x86.h | 6 ++
include/uapi/linux/kvm.h| 1 +
8 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index efbbe570aa9b..dc4b4036e5d2 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6109,3 +6109,10 @@ KVM can therefore start protected VMs.
This capability governs the KVM_S390_PV_COMMAND ioctl and the
KVM_MP_STATE_LOAD MP_STATE. KVM_SET_MP_STATE can fail for protected
guests when the state change is invalid.
+
+8.23 KVM_CAP_MPERFAPERF
+
+
+:Architectures: x86
+
+This capability indicates that KVM supports APERF and MPERF MSR registers
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 42a2d0d3984a..58fd3254804f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -820,6 +820,9 @@ struct kvm_vcpu_arch {
/* AMD MSRC001_0015 Hardware Configuration */
u64 msr_hwcr;
+
+ u64 v_mperf;
+ u64 v_aperf;
};
struct kvm_lpage_info {
@@ -979,6 +982,7 @@ struct kvm_arch {
bool guest_can_read_msr_platform_info;
bool exception_payload_enabled;
+ bool guest_has_mperfaperf;
struct kvm_pmu_event_filter *pmu_event_filter;
struct task_struct *nx_lpage_recovery_thread;
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 901cd1fdecd9..3bdd907981b5 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -124,6 +124,14 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
MSR_IA32_MISC_ENABLE_MWAIT);
}
+ best = kvm_find_cpuid_entry(vcpu, 6, 0);
+ if (best) {
+ if (guest_has_mperfaperf(vcpu->kvm) &&
+ boot_cpu_has(X86_FEATURE_APERFMPERF))
+ best->ecx |= 1;
+ else
+ best->ecx &= ~1;
+ }
/* Update physical-address width */
vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
kvm_mmu_reset_context(vcpu);
@@ -558,7 +566,10 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array
*array, u32 function)
case 6: /* Thermal management */
entry->eax = 0x4; /* allow ARAT */
entry->ebx = 0;
- entry->ecx = 0;
+ if (boot_cpu_has(X86_FEATURE_APERFMPERF))
+ entry->ecx = 0x1;
+ else
+ entry->ecx = 0x0;
entry->edx = 0;
break;
/* function 7 has additional index. */
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 851e9cc79930..1d157a8dba46 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -4310,6 +4310,12 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
case MSR_F10H_DECFG:
msr_info->data = svm->msr_decfg;
break;
+ case MSR_IA32_MPERF:
+ msr_info->data = vcpu->arch.v_mperf;
+ break;
+ case MSR_IA32_APERF:
+ msr_info->data = vcpu->arch.v_aperf;
+ break;
default:
return kvm_get_msr_common(vcpu, msr_info);
}
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 91749f1254e8..b05e276e262b 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1914,6 +1914,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
!guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP))
return 1;
goto find_shared_msr;
+ case MSR_IA32_MPERF:
+ msr_info->data = vcpu->arch.v_mperf;
+ break;
+ case MSR_IA32_APERF:
+ msr_info->data = vcpu->arch.v_aperf;
+ break;
default:
find_shared_msr:
msr = find_msr_entry(vmx, msr_info->index);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b8124b562dea..38deb11b1544 100644
--- a/arch/x86/kvm/x86.c
+++
Re: [PATCH] usb: typec: mux: intel: Handle alt mode HPD_LVL
Sorry, didn't compose the Commit message quite right, have sent out v2.
Thanks,
On Tue, Apr 28, 2020 at 10:34 PM Prashant Malani wrote:
>
> According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
> 0.6, when a device is transitioning to DP Alternate Mode state, if the
> HPD_LVL in the status update command VDO is set, the HPD_HIGH field in
> the Alternate Mode request “mode_data” field (bit 14) should also be
> set. Ensure the bit is correctly handled while issuing the Alternate
> Mode request.
>
> Signed-off-by: Prashant Malani
> Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
> ---
> drivers/usb/typec/mux/intel_pmc_mux.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c
> b/drivers/usb/typec/mux/intel_pmc_mux.c
> index f5c5e0aef66f..c599112559e7 100644
> --- a/drivers/usb/typec/mux/intel_pmc_mux.c
> +++ b/drivers/usb/typec/mux/intel_pmc_mux.c
> @@ -157,6 +157,10 @@ pmc_usb_mux_dp(struct pmc_usb_port *port, struct
> typec_mux_state *state)
> req.mode_data |= (state->mode - TYPEC_STATE_MODAL) <<
> PMC_USB_ALTMODE_DP_MODE_SHIFT;
>
> + if (data->status & DP_STATUS_HPD_STATE)
> + req.mode_data |= PMC_USB_DP_HPD_LVL <<
> +PMC_USB_ALTMODE_DP_MODE_SHIFT;
> +
> return pmc_usb_command(port, (void *), sizeof(req));
> }
>
> --
> 2.26.2.303.gf8c07b1a785-goog
>
[PATCH v2] usb: typec: mux: intel: Handle alt mode HPD_HIGH
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, when a device is transitioning to DP Alternate Mode state, if the
HPD_STATE (bit 7) field in the status update command VDO is set to
HPD_HIGH, the HPD_HIGH field in the Alternate Mode request “mode_data”
field (bit 14) should also be set. Ensure the bit is correctly handled
while issuing the Alternate Mode request.
Signed-off-by: Prashant Malani
Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
---
Changes in v2:
- Clarified the commit message to mention the proper field names.
drivers/usb/typec/mux/intel_pmc_mux.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c
b/drivers/usb/typec/mux/intel_pmc_mux.c
index f5c5e0aef66f..c599112559e7 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -157,6 +157,10 @@ pmc_usb_mux_dp(struct pmc_usb_port *port, struct
typec_mux_state *state)
req.mode_data |= (state->mode - TYPEC_STATE_MODAL) <<
PMC_USB_ALTMODE_DP_MODE_SHIFT;
+ if (data->status & DP_STATUS_HPD_STATE)
+ req.mode_data |= PMC_USB_DP_HPD_LVL <<
+PMC_USB_ALTMODE_DP_MODE_SHIFT;
+
return pmc_usb_command(port, (void *), sizeof(req));
}
--
2.26.2.303.gf8c07b1a785-goog
Re: [PATCH 5/5] virtio: Add bounce DMA ops
On 2020/4/29 12:57, Michael S. Tsirkin wrote: On Wed, Apr 29, 2020 at 10:22:32AM +0800, Lu Baolu wrote: On 2020/4/29 4:41, Michael S. Tsirkin wrote: On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote: * Michael S. Tsirkin [2020-04-28 12:17:57]: Okay, but how is all this virtio specific? For example, why not allow separate swiotlbs for any type of device? For example, this might make sense if a given device is from a different, less trusted vendor. Is swiotlb commonly used for multiple devices that may be on different trust boundaries (and not behind a hardware iommu)? Even a hardware iommu does not imply a 100% security from malicious hardware. First lots of people use iommu=pt for performance reasons. Second even without pt, unmaps are often batched, and sub-page buffers might be used for DMA, so we are not 100% protected at all times. For untrusted devices, IOMMU is forced on even iommu=pt is used; I think you are talking about untrusted *drivers* like with VFIO. No. I am talking about untrusted devices like thunderbolt peripherals. We always trust drivers hosted in kernel and the DMA APIs are designed for them, right? Please refer to this series. https://lkml.org/lkml/2019/9/6/39 Best regards, baolu On the other hand, I am talking about things like thunderbolt peripherals being less trusted than on-board ones. Or possibly even using swiotlb for specific use-cases where speed is less of an issue. E.g. my wifi is pretty slow anyway, and that card is exposed to malicious actors all the time, put just that behind swiotlb for security, and leave my graphics card with pt since I'm trusting it with secrets anyway. and iotlb flush is in strict mode (no batched flushes); ATS is also not allowed. Swiotlb is used to protect sub-page buffers since IOMMU can only apply page granularity protection. Swiotlb is now used for devices from different trust zone. Best regards, baolu
Re: [net-next PATCH v2 0/3] Introduce new APIs to support phylink and phy layers
On Mon, Apr 27, 2020 at 03:48:07PM +0100, Russell King - ARM Linux admin wrote: > On Mon, Apr 27, 2020 at 08:02:38PM +0530, Calvin Johnson wrote: > > On Mon, Apr 27, 2020 at 02:58:20PM +0100, Russell King - ARM Linux admin > > wrote: > > > On Mon, Apr 27, 2020 at 06:54:06PM +0530, Calvin Johnson wrote: > > > > Following functions are defined: > > > > phylink_fwnode_phy_connect() > > > > phylink_device_phy_connect() > > > > fwnode_phy_find_device() > > > > device_phy_find_device() > > > > fwnode_get_phy_node() > > > > > > > > First two help in connecting phy to phylink instance. > > > > Next two help in finding a phy on a mdiobus. > > > > Last one helps in getting phy_node from a fwnode. > > > > > > > > Changes in v2: > > > > move phy code from base/property.c to net/phy/phy_device.c > > > > replace acpi & of code to get phy-handle with fwnode_find_reference > > > > replace of_ and acpi_ code with generic fwnode to get phy-handle. > > > > > > > > Calvin Johnson (3): > > > > device property: Introduce phy related fwnode functions > > > > net: phy: alphabetically sort header includes > > > > phylink: Introduce phylink_fwnode_phy_connect() > > > > > > Thanks for this, but there's more work that needs to be done here. I > > > also think that we must have an ack from ACPI people before this can be > > > accepted - you are in effect proposing a new way for representing PHYs > > > in ACPI. > > > > Thanks for your review. > > > > Agree that we need an ack from ACPI people. > > However, I don't think it is a completely new way as similar acpi approach > > to > > get phy-handle is already in place. > > Please see this: > > https://elixir.bootlin.com/linux/v5.7-rc3/source/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c#L832 > > That was added by: > > commit 8089a96f601bdfe3e1b41d14bb703aafaf1b8f34 > Author: Iyappan Subramanian > Date: Mon Jul 25 17:12:41 2016 -0700 > > drivers: net: xgene: Add backward compatibility > > This patch adds xgene_enet_check_phy_hanlde() function that checks whether > MDIO driver is probed successfully and sets pdata->mdio_driver to true. > If MDIO driver is not probed, ethernet driver falls back to backward > compatibility mode. > > Since enum xgene_enet_cmd is used by MDIO driver, removing this from > ethernet driver. > > Signed-off-by: Iyappan Subramanian > Tested-by: Fushen Chen > Tested-by: Toan Le > Signed-off-by: David S. Miller > > The commit message says nothing about adding ACPI stuff, and searching > the 'net for the posting of this patch seems to suggest that it wasn't > obviously copied to any ACPI people: > > https://lists.openwall.net/netdev/2016/07/26/11 > > Annoyingly, searching for: > > "drivers: net: xgene: Add backward compatibility" site:lore.kernel.org > > doesn't find it on lore, so can't get the full headers and therefore > addresses. > > So, yes, there's another driver using it, but the ACPI folk probably > never got a look-in on that instance. Even if they had been copied, > the patch description is probably sufficiently poor that they wouldn't > have read the patch. > > I'd say there's questions over whether ACPI people will find this an > acceptable approach. > > Given that your patch moves this from one driver to a subsystem thing, > it needs to be ratified by ACPI people, because it's effectively > becoming a standardised way to represent a PHY in ACPI. How can we get attention/response from ACPI people? I've now added ACPI maintainers in the To list. Thanks Calvin
Re: [PATCH v7 3/7] tpm: tpm_tis: Rewrite "tpm_tis_req_canceled()"
On Mon, Apr 27, 2020 at 03:49:27PM +0300, amirmi...@gmail.com wrote: > From: Amir Mizinski > > Using this function while reading/writing data resulted in an aborted > operation. > After investigating the issue according to the TCG TPM Profile (PTP) > Specifications, I found that "request to cancel" should occur only if > TPM_STS.commandReady bit is lit. > Note that i couldn't find a case where the present condition > (in the linux kernel) is valid, so I'm removing the case for > "TPM_VID_WINBOND" since we have no need for it. > > Also, the default comparison is wrong. Only cmdReady bit needs to be > compared instead of the full lower status register byte. > > Fixes: 1f86605 (tpm: Fix cancellation of TPM commands (polling mode)) Needs to have exactly 12 hex digits of the hash. /Jarkko
Re: [PATCH v7 2/7] tpm: tpm_tis: Add verify_data_integrity handle toy tpm_tis_phy_ops
On Mon, Apr 27, 2020 at 03:49:26PM +0300, amirmi...@gmail.com wrote: > + bool (*verify_data_integrity)(struct tpm_tis_data *data, const u8 *buf, > + size_t len); Why can't the i2c driver verify this in the end of read_bytes()? /Jarkko
[PATCH] usb: typec: mux: intel: Handle alt mode HPD_LVL
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, when a device is transitioning to DP Alternate Mode state, if the
HPD_LVL in the status update command VDO is set, the HPD_HIGH field in
the Alternate Mode request “mode_data” field (bit 14) should also be
set. Ensure the bit is correctly handled while issuing the Alternate
Mode request.
Signed-off-by: Prashant Malani
Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
---
drivers/usb/typec/mux/intel_pmc_mux.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c
b/drivers/usb/typec/mux/intel_pmc_mux.c
index f5c5e0aef66f..c599112559e7 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -157,6 +157,10 @@ pmc_usb_mux_dp(struct pmc_usb_port *port, struct
typec_mux_state *state)
req.mode_data |= (state->mode - TYPEC_STATE_MODAL) <<
PMC_USB_ALTMODE_DP_MODE_SHIFT;
+ if (data->status & DP_STATUS_HPD_STATE)
+ req.mode_data |= PMC_USB_DP_HPD_LVL <<
+PMC_USB_ALTMODE_DP_MODE_SHIFT;
+
return pmc_usb_command(port, (void *), sizeof(req));
}
--
2.26.2.303.gf8c07b1a785-goog
Re: [PATCH v29 00/20] Intel SGX foundations
On Sun, Apr 26, 2020 at 11:57:53AM -0500, Dr. Greg wrote: > On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote: > > Good day, I hope the weekend is going well for everyone. > > > Intel(R) SGX is a set of CPU instructions that can be used by applications > > to set aside private regions of code and data. The code outside the enclave > > is disallowed to access the memory inside the enclave by the CPU access > > control. > > > > ... [ elided ] .. > > > > The current implementation requires that the firmware sets > > IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can > > decide what enclaves it wants run. The implementation does not create > > any bottlenecks to support read-only MSRs later on. > > It seems highly unlikely that a driver implementation with any type of > support for read-only launch control registers would ever get into the > kernel. All one needs to do is review the conversations that Matthew > Garrett's lockdown patches engender to get a sense of that, ie: > > https://lwn.net/Articles/818277/ We do not require read-only MSRs. /Jarkko
Re: [PATCH -next] ipc: use GFP_ATOMIC under spin lock
Hello together,
On 4/28/20 1:14 PM, Matthew Wilcox wrote:
On Tue, Apr 28, 2020 at 03:47:36AM +, Wei Yongjun wrote:
The function ipc_id_alloc() is called from ipc_addid(), in which
a spin lock is held, so we should use GFP_ATOMIC instead.
Fixes: de5738d1c364 ("ipc: convert ipcs_idr to XArray")
Signed-off-by: Wei Yongjun
I see why you think that, but it's not true. Yes, we hold a spinlock, but
the spinlock is in an object which is not reachable from any other CPU.
Is it really allowed that spin_lock()/spin_unlock may happen on
different cpus?
CPU1: spin_lock()
CPU1: schedule() -> sleeps
CPU2: -> schedule() returns
CPU2: spin_unlock().
Converting to GFP_ATOMIC is completely wrong.
What is your solution proposal?
xa_store() also gets a gfp_ flag. Thus even splitting _alloc() and
_store() won't help
xa_alloc(,entry=NULL,)
new->seq = ...
spin_lock();
xa_store(,entry=new,GFP_KERNEL);
--
Manfred
Re: [PATCH v29 00/20] Intel SGX foundations
On Wed, Apr 22, 2020 at 09:48:58AM -0700, Connor Kuehl wrote: > On 4/21/20 2:52 PM, Jarkko Sakkinen wrote: > > v29: > > * The selftest has been moved to selftests/sgx. Because SGX is an execution > >environment of its own, it really isn't a great fit with more "standard" > >x86 tests. > > > >The RSA key is now generated on fly and the whole signing process has > >been made as part of the enclave loader instead of signing the enclave > >during the compilation time. > > > >Finally, the enclave loader loads now the test enclave directly from its > >ELF file, which means that ELF file does not need to be coverted as raw > >binary during the build process. > > * Version the mm_list instead of using on synchronize_mm() when adding new > >entries. We hold the write lock for the mm_struct, and dup_mm() can thus > >deadlock with the page reclaimer, which could hold the lock for the old > >mm_struct. > > * Disallow mmap(PROT_NONE) from /dev/sgx. Any mapping (e.g. anonymous) can > >be used to reserve the address range. Now /dev/sgx supports only opaque > >mappings to the (initialized) enclave data. > > * Make the vDSO callable directly from C by preserving RBX and taking leaf > >from RCX. > > Hi all, > > I've been producing Fedora 32 kernel builds with the SGX patches applied for > a few of weeks and I've just produced a build with this latest revision[1]. > We've been using these kernels to enable SGX for some of our > development/test machines. Thanks a lot! /Jarkko
Re: [PATCH 0/2] Add support for StorageD3Enable _DSD property
On Tue, 2020-04-28 at 08:27 -0700, David E. Box wrote: > On Tue, 2020-04-28 at 16:22 +0200, Christoph Hellwig wrote: > > On Tue, Apr 28, 2020 at 07:09:59AM -0700, David E. Box wrote: > > > > I'm not sure who came up with the idea to put this into ACPI, > > > > but > > > > it > > > > belongs into NVMe. Please talk to the NVMe technical working > > > > group > > > > instead of trying to overrules them in an unrelated group that > > > > doesn't > > > > apply to all of PCIe. > > > > > > Agreed that this is not ideal since it does not apply to all of > > > PCIe. > > > But as the property already exists on shipping systems, we need > > > to > > > be > > > able to read it in the NVMe driver and the patch is consitent > > > with > > > the > > > way properties under PCI ports are read. > > > > The point is that it is not the BIOSes job do decide how Linux does > > power management. For example D3 has really horrible entry and > > exit > > latencies in many cases, and will lead to higher power usage. > > The platform can know which pm policies will save the most power. But > since the solution doesn't apply to all PCIe devices (despite BIOS > specifying it that way) I'll withdraw this patch. Thanks. Wait, why withdraw? In this case the platform is unfortunately preventing the standard driver from making a proper determination. So while I agree that it's not the BIOSes job, when the platform actively prevents proper operation due to some ill conceived non-standard platform property what is Linux left to do on these systems? The *patch* is not trying to overrule NVME, and the best I can say is that the Intel Linux team was not in the loop when this was being decided between the platform BIOS implemenation and whomever thought they could just publish random ACPI properties that impacted NVME operation [1]. So now David is trying to get these platform unbroken because they are already shipping with this b0rkage. [1]: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
Re: [RESEND PATCH v6 1/4] mfd: syscon: Add fwnode_to_regmap
On 4/28/2020 6:29 PM, Arnd Bergmann wrote: On Tue, Apr 28, 2020 at 12:05 PM Lee Jones wrote: On Tue, 21 Apr 2020, Dilip Kota wrote: But, i feel return error for ACPI or oother, looks better because 'device_node' has fwnode pointer. And provide description in the header file, mentioning function is success for 'OF' and returns error for the rest. I don't think this patch adds much to be honest. Better to just do: device_node_get_regmap(to_of_node(fwnode), false); ... from the call site I think. Agreed, or just use the of_node pointer consistently in the driver that uses it and avoid the use of the fwnode interface entirely when dealing with a modern driver that does not need to support board files any more. Arnd Ok, I will do it in the driver itself and remove the fwnode_to_regmap() definition. Regards, Dilip
Re: [f2fs-dev] [PATCH V2] f2fs: Avoid double lock for cp_rwsem during checkpoint
Hi Markus On 4/27/2020 4:08 PM, Markus Elfring wrote: … This results in deadlock as iput() tries to hold cp_rwsem, which is already held at the beginning by checkpoint->block_operations(). Will another imperative wording become helpful besides the provided information for this change description? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=6a8b55ed4056ea5559ebe4f6a4b247f627870d4c#n151 Would you like to add the tag “Fixes” because of adjustments for the data synchronisation? I couldn't find any past commit which suits to be added under "Fixes" here. Let me know if you have any other comment. Regards, Markus
Re: [PATCH 5/5] virtio: Add bounce DMA ops
On Wed, Apr 29, 2020 at 10:22:32AM +0800, Lu Baolu wrote: > On 2020/4/29 4:41, Michael S. Tsirkin wrote: > > On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote: > > > * Michael S. Tsirkin [2020-04-28 12:17:57]: > > > > > > > Okay, but how is all this virtio specific? For example, why not allow > > > > separate swiotlbs for any type of device? > > > > For example, this might make sense if a given device is from a > > > > different, less trusted vendor. > > > Is swiotlb commonly used for multiple devices that may be on different > > > trust > > > boundaries (and not behind a hardware iommu)? > > Even a hardware iommu does not imply a 100% security from malicious > > hardware. First lots of people use iommu=pt for performance reasons. > > Second even without pt, unmaps are often batched, and sub-page buffers > > might be used for DMA, so we are not 100% protected at all times. > > > > For untrusted devices, IOMMU is forced on even iommu=pt is used; I think you are talking about untrusted *drivers* like with VFIO. On the other hand, I am talking about things like thunderbolt peripherals being less trusted than on-board ones. Or possibly even using swiotlb for specific use-cases where speed is less of an issue. E.g. my wifi is pretty slow anyway, and that card is exposed to malicious actors all the time, put just that behind swiotlb for security, and leave my graphics card with pt since I'm trusting it with secrets anyway. > and > iotlb flush is in strict mode (no batched flushes); ATS is also not > allowed. Swiotlb is used to protect sub-page buffers since IOMMU can > only apply page granularity protection. Swiotlb is now used for devices > from different trust zone. > > Best regards, > baolu
Re: [PATCH 1/3] staging: qlge: Remove multi-line dereferences from qlge_main.c
On Tue, Apr 28, 2020 at 09:31:10PM -0700, Joe Perches wrote:
> On Wed, 2020-04-29 at 00:04 -0400, Rylan Dmello wrote:
> > Fix checkpatch.pl warnings:
> >
> > WARNING: Avoid multiple line dereference - prefer 'qdev->func'
> > WARNING: Avoid multiple line dereference - prefer 'qdev->flags'
>
> Assuming you are doing this for exercise:
>
> It'd be better to unindent all the switch/case
> blocks for the entire function so more functions
> fit on single lines
>
> switch (foo) {
> case bar:
> {
> ...;
>
> should be:
>
> switch (foo) {
> case bar: {
> ...;
>
> goto exit; might as well be break; and remove
> the exit label too.
>
Thank you - I noticed that clang-format unindented the switch-case blocks, but
wasn't sure whether to include that in this patch set or not.
I will send a V2 patch that unindents these switch-case blocks throughout
the two functions listed here, and also removes the exit label from this
function.
> > Signed-off-by: Rylan Dmello
> > ---
> > drivers/staging/qlge/qlge_main.c | 9 -
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/staging/qlge/qlge_main.c
> > b/drivers/staging/qlge/qlge_main.c
> > index d7e4dfafc1a3..10daae025790 100644
> > --- a/drivers/staging/qlge/qlge_main.c
> > +++ b/drivers/staging/qlge/qlge_main.c
> > @@ -396,8 +396,7 @@ static int ql_set_mac_addr_reg(struct ql_adapter *qdev,
> > u8 *addr, u32 type,
> > * the route field to NIC core.
> > */
> > cam_output = (CAM_OUT_ROUTE_NIC |
> > - (qdev->
> > - func << CAM_OUT_FUNC_SHIFT) |
> > + (qdev->func << CAM_OUT_FUNC_SHIFT) |
> > (0 << CAM_OUT_CQ_ID_SHIFT));
> > if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX)
> > cam_output |= CAM_OUT_RV;
> > @@ -3432,9 +3431,9 @@ static int ql_request_irq(struct ql_adapter *qdev)
> > >rx_ring[0]);
> > status =
> > request_irq(pdev->irq, qlge_isr,
> > - test_bit(QL_MSI_ENABLED,
> > ->
> > -flags) ? 0 : IRQF_SHARED,
> > + test_bit(QL_MSI_ENABLED, >flags)
> > + ? 0
> > + : IRQF_SHARED,
> > intr_context->name, >rx_ring[0]);
> > if (status)
> > goto err_irq;
>
Re: [PATCH] perf: perf can not parser the backtrace of app in the 32bit system and 64bit kernel.
We test it as the following steps. # gcc -g -mthumb -gdwarf -o test test.c # export CALLGRAPH=dwarf #(./perftest ./test profiling 1; cd ./profiling/; perf script) Thanks, Jiping On 04/29/2020 12:01 PM, Jiping Ma wrote: Record PC value from regs[15], it should be regs[32], which cause perf parser the backtrace failed. Signed-off-by: Jiping Ma --- arch/arm64/kernel/perf_regs.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c index 0bbac61..04088e6 100644 --- a/arch/arm64/kernel/perf_regs.c +++ b/arch/arm64/kernel/perf_regs.c @@ -32,6 +32,10 @@ u64 perf_reg_value(struct pt_regs *regs, int idx) if ((u32)idx == PERF_REG_ARM64_PC) return regs->pc; + if (perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32 + && idx == 15) + return regs->regs[PERF_REG_ARM64_PC]; + return regs->regs[idx]; }
Re: [PATCH v4 1/4] dt-bindings: net: phy: Add support for NXP TJA11xx
On 4/28/2020 9:38 PM, Oleksij Rempel wrote: > @Rob, thank you for the review. > > @David, should I send fixes or reworked initial patches? You need to send incremental patches, once David applies the patches, they are part of the git history for the trees he maintains. -- Florian
Re: [PATCH v4 1/4] dt-bindings: net: phy: Add support for NXP TJA11xx
@Rob, thank you for the review.
@David, should I send fixes or reworked initial patches?
On Tue, Apr 28, 2020 at 12:30:06PM -0500, Rob Herring wrote:
> On Fri, Mar 13, 2020 at 12:23 AM Oleksij Rempel
> wrote:
> >
> > Document the NXP TJA11xx PHY bindings.
>
> Given the discussion, I'd marked this one as "changes requested"
> expecting a new version to review the schema. And gmail decided to
> make a new thread due to the extra 'RE:'. So it fell off my radar.
>
> This schema is fundamentally broken as there's no way to match for
> when to apply this schema. How do we find a NXP TJA11xx PHY? I suppose
> we can look for 'ethernet-phy' with a child node 'ethernet-phy', but
> then that would apply to any phy like this one. This needs a
> compatible string IMO given it is non-standard.
>
> >
> > Signed-off-by: Oleksij Rempel
> > ---
> > .../devicetree/bindings/net/nxp,tja11xx.yaml | 61 +++
> > 1 file changed, 61 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> > b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> > new file mode 100644
> > index ..42be0255512b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> > @@ -0,0 +1,61 @@
> > +# SPDX-License-Identifier: GPL-2.0+
>
> Dual license new bindings:
>
> (GPL-2.0-only OR BSD-2-Clause)
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/nxp,tja11xx.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP TJA11xx PHY
> > +
> > +maintainers:
> > + - Andrew Lunn
> > + - Florian Fainelli
> > + - Heiner Kallweit
> > +
> > +description:
> > + Bindings for NXP TJA11xx automotive PHYs
>
> Perhaps some information about how this phy is special.
>
> > +
> > +allOf:
> > + - $ref: ethernet-phy.yaml#
>
> Not needed here as ethernet-phy.yaml already has a 'select' condition to
> apply.
>
> > +
> > +patternProperties:
> > + "^ethernet-phy@[0-9a-f]+$":
> > +type: object
> > +description: |
> > + Some packages have multiple PHYs. Secondary PHY should be defines as
> > + subnode of the first (parent) PHY.
> > +
> > +properties:
> > + reg:
> > +minimum: 0
> > +maximum: 31
> > +description:
> > + The ID number for the child PHY. Should be +1 of parent PHY.
> > +
> > +required:
> > + - reg
> > +
> > +examples:
> > + - |
> > +mdio {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +tja1101_phy0: ethernet-phy@4 {
> > +reg = <0x4>;
> > +};
> > +};
> > + - |
> > +mdio {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +tja1102_phy0: ethernet-phy@4 {
> > +reg = <0x4>;
>
> > +#address-cells = <1>;
> > +#size-cells = <0>;
>
> These aren't documented.
>
> > +
> > +tja1102_phy1: ethernet-phy@5 {
> > +reg = <0x5>;
> > +};
> > +};
> > +};
> > --
> > 2.25.1
> >
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
[PATCH] video: fbdev: pxa3xx_gcu: Fix some resource leak in an error handling path in 'pxa3xx_gcu_probe()'
If an error occurs in the loop where we call 'pxa3xx_gcu_add_buffer()',
any resource already allocated should be freed.
In order to fix it, add a call to 'pxa3xx_gcu_free_buffers()' in the error
handling path, as already done in the remove function.
Fixes: 364dbdf3b6c3 ("video: add driver for PXA3xx 2D graphics accelerator")
Signed-off-by: Christophe JAILLET
---
drivers/video/fbdev/pxa3xx-gcu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 4279e13a3b58..68d9c7a681d4 100644
--- a/drivers/video/fbdev/pxa3xx-gcu.c
+++ b/drivers/video/fbdev/pxa3xx-gcu.c
@@ -675,6 +675,7 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev)
err_disable_clk:
clk_disable_unprepare(priv->clk);
+ pxa3xx_gcu_free_buffers(dev, priv);
return ret;
}
--
2.25.1
[PATCH V11.2] Documentation/dax: Update Usage section
From: Ira Weiny Update the Usage section to reflect the new individual dax selection functionality. Signed-off-by: Ira Weiny --- Changes from V11.1: Make filesystem/file system consistently filesystem grammatical fixes Changes from V11: Minor changes from Darrick Changes from V10: Clarifications from Dave Add '-c' to xfs_io examples Changes from V9: Fix missing ')' Fix trailing '"' (fixed this!) Changes from V8: Updates from Darrick Changes from V7: Cleanups/clarifications from Darrick and Dan Changes from V6: Update to allow setting FS_XFLAG_DAX any time. Update with list of behaviors from Darrick https://lore.kernel.org/lkml/20200409165927.GD6741@magnolia/ Changes from V5: Update to reflect the agreed upon semantics https://lore.kernel.org/lkml/20200405061945.ga94...@iweiny-desk2.sc.intel.com/ --- Documentation/filesystems/dax.txt | 142 +- 1 file changed, 139 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt index 679729442fd2..735fb4b54117 100644 --- a/Documentation/filesystems/dax.txt +++ b/Documentation/filesystems/dax.txt @@ -20,8 +20,144 @@ Usage If you have a block device which supports DAX, you can make a filesystem on it as usual. The DAX code currently only supports files with a block size equal to your kernel's PAGE_SIZE, so you may need to specify a block -size when creating the filesystem. When mounting it, use the "-o dax" -option on the command line or add 'dax' to the options in /etc/fstab. +size when creating the filesystem. + +Currently 3 filesystems support DAX: ext2, ext4 and xfs. Enabling DAX on them +is different. + +Enabling DAX on ext4 and ext2 +- + +When mounting the filesystem, use the "-o dax" option on the command line or +add 'dax' to the options in /etc/fstab. This works to enable DAX on all files +within the filesystem. It is equivalent to the '-o dax=always' behavior below. + + +Enabling DAX on xfs +--- + +Summary +--- + + 1. There exists an in-kernel file access mode flag S_DAX that corresponds to +the statx flag STATX_ATTR_DAX. See the manpage for statx(2) for details +about this access mode. + + 2. There exists a persistent flag FS_XFLAG_DAX that can be applied to regular +files and directories. This advisory flag can be set or cleared at any +time, but doing so does not immediately affect the S_DAX state. + + 3. If the persistent FS_XFLAG_DAX flag is set on a directory, this flag will +be inherited by all regular files and subdirectories that are subsequently +created in this directory. Files and subdirectories that exist at the time +this flag is set or cleared on the parent directory are not modified by +this modification of the parent directory. + + 4. There exist dax mount options which can override FS_XFLAG_DAX in the +setting of the S_DAX flag. Given underlying storage which supports DAX the +following hold: + +"-o dax=inode" means "follow FS_XFLAG_DAX" and is the default. + +"-o dax=never" means "never set S_DAX, ignore FS_XFLAG_DAX." + +"-o dax=always" means "always set S_DAX ignore FS_XFLAG_DAX." + +"-o dax"is a legacy option which is an alias for "dax=always". + This may be removed in the future so "-o dax=always" is + the preferred method for specifying this behavior. + +NOTE: Modifications to and the inheritance behavior of FS_XFLAG_DAX remain +the same even when the filesystem is mounted with a dax option. However, +in-core inode state (S_DAX) will be overridden until the filesystem is +remounted with dax=inode and the inode is evicted from kernel memory. + + 5. The S_DAX policy can be changed via: + +a) Setting the parent directory FS_XFLAG_DAX as needed before files are + created + +b) Setting the appropriate dax="foo" mount option + +c) Changing the FS_XFLAG_DAX flag on existing regular files and + directories. This has runtime constraints and limitations that are + described in 6) below. + + 6. When changing the S_DAX policy via toggling the persistent FS_XFLAG_DAX flag, +the change in behaviour for existing regular files may not occur +immediately. If the change must take effect immediately, the administrator +needs to: + +a) stop the application so there are no active references to the data set + the policy change will affect + +b) evict the data set from kernel caches so it will be re-instantiated when + the application is restarted. This can be achieved by: + + i. drop-caches + ii. a filesystem unmount and mount cycle + iii. a system reboot + + +Details +--- + +There are 2 per-file dax flags. One is a persistent inode setting (FS_XFLAG_DAX) +and the other is a volatile
Re: [PATCH 1/3] staging: qlge: Remove multi-line dereferences from qlge_main.c
On Wed, 2020-04-29 at 00:04 -0400, Rylan Dmello wrote:
> Fix checkpatch.pl warnings:
>
> WARNING: Avoid multiple line dereference - prefer 'qdev->func'
> WARNING: Avoid multiple line dereference - prefer 'qdev->flags'
Assuming you are doing this for exercise:
It'd be better to unindent all the switch/case
blocks for the entire function so more functions
fit on single lines
switch (foo) {
case bar:
{
...;
should be:
switch (foo) {
case bar: {
...;
goto exit; might as well be break; and remove
the exit label too.
> Signed-off-by: Rylan Dmello
> ---
> drivers/staging/qlge/qlge_main.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/qlge/qlge_main.c
> b/drivers/staging/qlge/qlge_main.c
> index d7e4dfafc1a3..10daae025790 100644
> --- a/drivers/staging/qlge/qlge_main.c
> +++ b/drivers/staging/qlge/qlge_main.c
> @@ -396,8 +396,7 @@ static int ql_set_mac_addr_reg(struct ql_adapter *qdev,
> u8 *addr, u32 type,
>* the route field to NIC core.
>*/
> cam_output = (CAM_OUT_ROUTE_NIC |
> - (qdev->
> -func << CAM_OUT_FUNC_SHIFT) |
> + (qdev->func << CAM_OUT_FUNC_SHIFT) |
> (0 << CAM_OUT_CQ_ID_SHIFT));
> if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX)
> cam_output |= CAM_OUT_RV;
> @@ -3432,9 +3431,9 @@ static int ql_request_irq(struct ql_adapter *qdev)
>>rx_ring[0]);
> status =
> request_irq(pdev->irq, qlge_isr,
> - test_bit(QL_MSI_ENABLED,
> - >
> - flags) ? 0 : IRQF_SHARED,
> + test_bit(QL_MSI_ENABLED, >flags)
> + ? 0
> + : IRQF_SHARED,
> intr_context->name, >rx_ring[0]);
> if (status)
> goto err_irq;
Re: [PATCH V11.1] Documentation/dax: Update Usage section
On Tue, Apr 28, 2020 at 07:21:18PM -0700, Randy Dunlap wrote: > On 4/28/20 3:21 PM, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > Update the Usage section to reflect the new individual dax selection > > functionality. > > > > Signed-off-by: Ira Weiny > > > > --- > > Changes from V11: > > Minor changes from Darrick > > > > Changes from V10: > > Clarifications from Dave > > Add '-c' to xfs_io examples > > > > Changes from V9: > > Fix missing ')' > > Fix trialing '"' > > trailing Thanks > > > > > Changes from V8: > > Updates from Darrick > > > > Changes from V7: > > Cleanups/clarifications from Darrick and Dan > > > > Changes from V6: > > Update to allow setting FS_XFLAG_DAX any time. > > Update with list of behaviors from Darrick > > https://lore.kernel.org/lkml/20200409165927.GD6741@magnolia/ > > > > Changes from V5: > > Update to reflect the agreed upon semantics > > > > https://lore.kernel.org/lkml/20200405061945.ga94...@iweiny-desk2.sc.intel.com/ > > --- > > Documentation/filesystems/dax.txt | 142 +- > > 1 file changed, 139 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/filesystems/dax.txt > > b/Documentation/filesystems/dax.txt > > index 679729442fd2..dc1c1aa36cc2 100644 > > --- a/Documentation/filesystems/dax.txt > > +++ b/Documentation/filesystems/dax.txt > > @@ -17,11 +17,147 @@ For file mappings, the storage device is mapped > > directly into userspace. > > Usage > > - > > > > -If you have a block device which supports DAX, you can make a filesystem > > +If you have a block device which supports DAX, you can make a file system > > on it as usual. The DAX code currently only supports files with a block > > size equal to your kernel's PAGE_SIZE, so you may need to specify a block > > -size when creating the filesystem. When mounting it, use the "-o dax" > > -option on the command line or add 'dax' to the options in /etc/fstab. > > +size when creating the file system. > > + > > +Currently 3 filesystems support DAX: ext2, ext4 and xfs. Enabling DAX on > > them > > Why "file system" in the first paragraph when "filesystem" is used here and > below? AFAIK they are interchangeable. https://en.wikipedia.org/wiki/File_system But consistency is a reasonable request. The rest of the doc (save 1 place) uses filesystem so I will adopt that here, and clean up that 1 place. > > > +is different. > > + > > +Enabling DAX on ext4 and ext2 > > +- > > + > > +When mounting the filesystem, use the "-o dax" option on the command line > > or > > +add 'dax' to the options in /etc/fstab. This works to enable DAX on all > > files > > +within the filesystem. It is equivalent to the '-o dax=always' behavior > > below. > > + > > + > > +Enabling DAX on xfs > > +--- > > + > > +Summary > > +--- > > + > > + 1. There exists an in-kernel file access mode flag S_DAX that corresponds > > to > > +the statx flag STATX_ATTR_DAX. See the manpage for statx(2) for > > details > > +about this access mode. > > + > > + 2. There exists a persistent flag FS_XFLAG_DAX that can be applied to > > regular > > +files and directories. This advisory flag can be set or cleared at any > > +time, but doing so does not immediately affect the S_DAX state. > > + > > + 3. If the persistent FS_XFLAG_DAX flag is set on a directory, this flag > > will > > +be inherited by all regular files and subdirectories that are > > subsequently > > +created in this directory. Files and subdirectories that exist at the > > time > > +this flag is set or cleared on the parent directory are not modified by > > +this modification of the parent directory. > > + > > + 4. There exists dax mount options which can override FS_XFLAG_DAX in the > > exist Ah yea, Done. > > > +setting of the S_DAX flag. Given underlying storage which supports > > DAX the > > +following hold: > > + > > +"-o dax=inode" means "follow FS_XFLAG_DAX" and is the default. > > + > > +"-o dax=never" means "never set S_DAX, ignore FS_XFLAG_DAX." > > + > > +"-o dax=always" means "always set S_DAX ignore FS_XFLAG_DAX." > > + > > +"-o dax"is a legacy option which is an alias for "dax=always". > > + This may be removed in the future so "-o dax=always" is > > + the preferred method for specifying this behavior. > > + > > +NOTE: Modifications to and the inheritance behavior of FS_XFLAG_DAX > > remain > > +the same even when the file system is mounted with a dax option. > > However, > > +in-core inode state (S_DAX) will be overridden until the file system is > > "file system" (2 times above) Done. > > > +remounted with dax=inode and the inode is evicted from kernel memory. > > + > > + 5. The S_DAX policy can be changed via: > > + > > +a) Setting
[PATCH RESEND] MAINTAINERS: remove entry after hp100 driver removal
Commit a10079c66290 ("staging: remove hp100 driver") removed all files
from ./drivers/staging/hp/, but missed to adjust MAINTAINERS.
Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: drivers/staging/hp/hp100.*
So, drop HP100 Driver entry in MAINTAINERS now.
Signed-off-by: Lukas Bulwahn
---
Greg, here is a minor non-urgent patch for staging.
applies cleanly on v5.7-rc3, current master and next-20200428
MAINTAINERS | 5 -
1 file changed, 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 26f281d9f32a..41e2b577488f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7746,11 +7746,6 @@ L: platform-driver-...@vger.kernel.org
S: Orphan
F: drivers/platform/x86/tc1100-wmi.c
-HP100: Driver for HP 10/100 Mbit/s Voice Grade Network Adapter Series
-M: Jaroslav Kysela
-S: Obsolete
-F: drivers/staging/hp/hp100.*
-
HPET: High Precision Event Timers driver
M: Clemens Ladisch
S: Maintained
--
2.17.1
Re: [PATCH net-next v2 4/4] net: phy: bcm54140: add second PHY ID
On 4/28/2020 4:06 PM, Michael Walle wrote: > This PHY has two PHY IDs depending on its mode. Adjust the mask so that > it includes both IDs. > > Signed-off-by: Michael Walle Reviewed-by: Florian Fainelli For future submissions to netdev, if you have a patch count > 1, please include a cover letter: Thanks! -- Florian
Re: [PATCH/RFC] clk: gate: Add some kunit test suites
On Tue, Apr 14, 2020 at 7:46 PM Vaittinen, Matti
wrote:
>
> Hello Stephen & All,
>
> Prologue:
>
> I have been traumatized in the past - by unit tests :) Thus I am always
> a bit jumpy when I see people adding UTs. I always see the inertia UTs
> add to development - when people change anything they must also change
> impacted UTs - and every unnecessary UT case is actually burden. I was
> once buried under such burden.. Back at those times I quite often found
> myself wondering why I spend two days fixing UT cases after I did a
> necessary code change which took maybe 10 minutes. Please see my
> comments knowing this history and do your decisions based on less
> biased - brighter understanding :]
>
>
Hey Matti,
As someone who's definitely wasted a lot of time fixing
poorly-thought-through tests, but who is nevertheless working
enthusiastically on KUnit, I wanted to respond quickly here.
Certainly, the goal is not to reduce development velocity, though it
is redistributed a bit: hopefully the extra time spent updating tests
will be more than paid back in identifying and fixing bugs earlier, as
well as making testing one's own changes simpler. Only time will tell
if we're right or not, but if they turn out to cause more problems
than they solve we can always adjust or remove them. I remain
optimistic, though.
I do think that these tests are unlikely to increase the burden on
developers much: they seem mostly to test interfaces and behaviour
which is used quite a bit elsewhere in the kernel: changes that break
them seem likely to be reasonably disruptive anyway, so these tests
aren't going to add too much to that overall, and may ultimately make
things a bit simpler by helping to document and verify the changes.
A few other notes inline:
> On Tue, 2020-04-07 at 20:56 -0700, Stephen Boyd wrote:
> > Test various parts of the clk gate implementation with the kunit
> > testing
> > framework.
> >
> > Cc: Brendan Higgins
> > Cc:
> > Signed-off-by: Stephen Boyd
> > ---
> >
> > This patch is on top of this series[1] that allows the clk
> > framework to be selected by Kconfig language.
> >
> > [1]
> > https://lore.kernel.org/r/20200405025123.154688-1-sb...@kernel.org
> >
> > drivers/clk/Kconfig | 8 +
> > drivers/clk/Makefile| 1 +
> > drivers/clk/clk-gate-test.c | 481
> >
> > 3 files changed, 490 insertions(+)
> > create mode 100644 drivers/clk/clk-gate-test.c
> >
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index 6ea0631e3956..66193673bcdf 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -377,4 +377,12 @@ source "drivers/clk/ti/Kconfig"
> > source "drivers/clk/uniphier/Kconfig"
> > source "drivers/clk/zynqmp/Kconfig"
> >
> > +# Kunit test cases
> > +config CLK_GATE_TEST
> > + tristate "Basic gate type Kunit test"
> > + depends on KUNIT
> > + default KUNIT
> > + help
> > + Kunit test for the basic clk gate type.
> > +
> > endif
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index f4169cc2fd31..0785092880fd 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -7,6 +7,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-divider.o
> > obj-$(CONFIG_COMMON_CLK) += clk-fixed-factor.o
> > obj-$(CONFIG_COMMON_CLK) += clk-fixed-rate.o
> > obj-$(CONFIG_COMMON_CLK) += clk-gate.o
> > +obj-$(CONFIG_CLK_GATE_TEST) += clk-gate-test.o
> > obj-$(CONFIG_COMMON_CLK) += clk-multiplier.o
> > obj-$(CONFIG_COMMON_CLK) += clk-mux.o
> > obj-$(CONFIG_COMMON_CLK) += clk-composite.o
> > diff --git a/drivers/clk/clk-gate-test.c b/drivers/clk/clk-gate-
> > test.c
> > new file mode 100644
> > index ..b1d6c21e9698
> > --- /dev/null
> > +++ b/drivers/clk/clk-gate-test.c
> > @@ -0,0 +1,481 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * KUnit test for clk gate basic type
> > + */
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +static void clk_gate_register_test_dev(struct kunit *test)
> > +{
> > + struct clk_hw *ret;
> > + struct platform_device *pdev;
> > +
> > + pdev = platform_device_register_simple("test_gate_device", -1,
> > NULL, 0);
> > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
> > +
> > + ret = clk_hw_register_gate(>dev, "test_gate", NULL, 0,
> > NULL,
> > +0, 0, NULL);
> > + KUNIT_EXPECT_NOT_ERR_OR_NULL(test, ret);
> > + KUNIT_EXPECT_STREQ(test, "test_gate", clk_hw_get_name(ret));
> > + KUNIT_EXPECT_EQ(test, 0UL, clk_hw_get_flags(ret));
> > +
> > + clk_hw_unregister_gate(ret);
> > + platform_device_put(pdev);
> > +}
> > +
> > +static void clk_gate_register_test_parent_names(struct kunit *test)
> > +{
> > + struct clk_hw *parent;
> > + struct clk_hw *ret;
> > +
> > + parent = clk_hw_register_fixed_rate(NULL, "test_parent", NULL,
> > 0,
> > + 100);
> > +
Re: [PATCH v2] eventpoll: fix missing wakeup for ovflist in ep_poll_callback
On 4/28/20 2:10 PM, Roman Penyaev wrote:
> On 2020-04-27 22:38, Jason Baron wrote:
>> On 4/25/20 4:59 PM, Khazhismel Kumykov wrote:
>>> On Sat, Apr 25, 2020 at 9:17 AM Jason Baron wrote:
On 4/24/20 3:00 PM, Khazhismel Kumykov wrote:
> In the event that we add to ovflist, before 339ddb53d373 we would be
> woken up by ep_scan_ready_list, and did no wakeup in ep_poll_callback.
> With that wakeup removed, if we add to ovflist here, we may never wake
> up. Rather than adding back the ep_scan_ready_list wakeup - which was
> resulting in unnecessary wakeups, trigger a wake-up in ep_poll_callback.
I'm just curious which 'wakeup' we are talking about here? There is:
wake_up(>wq) for the 'ep' and then there is the nested one via:
ep_poll_safewake(ep, epi). It seems to me that its only about the later
one being missing not both? Is your workload using nested epoll?
If so, it might make sense to just do the later, since the point of
the original patch was to minimize unnecessary wakeups.
>>>
>>> The missing wake-ups were when we added to ovflist instead of rdllist.
>>> Both are "the ready list" together - so I'd think we'd want the same
>>> wakeups regardless of which specific list we added to.
>>> ep_poll_callback isn't nested specific?
>>>
>>
>> So I was thinking that ep_poll() would see these events on the
>> ovflist without an explicit wakeup, b/c the overflow list being active
>> implies that the ep_poll() path would add them to the rdllist in
>> ep_scan_read_list(). Thus, it will see the events either in the
>> current ep_poll() context or via a subsequent syscall to epoll_wait().
>>
>> However, there are other paths that can call ep_scan_ready_list() thus
>> I agree with you that both wakeups here are necessary.
>>
>> I do think are are still (smaller) potential races in ep_scan_ready_list()
>> where we have:
>>
>> write_lock_irq(>lock);
>> list_splice_init(>rdllist, );
>> WRITE_ONCE(ep->ovflist, NULL);
>> write_unlock_irq(>lock);
>>
>> And in the ep_poll path we have:
>>
>> static inline int ep_events_available(struct eventpoll *ep)
>> {
>> return !list_empty_careful(>rdllist) ||
>> READ_ONCE(ep->ovflist) != EP_UNACTIVE_PTR;
>> }
>>
>>
>> Seems to me that first bit needs to be the following, since
>> ep_events_available() is now checked in a lockless way:
>>
>>
>> write_lock_irq(>lock);
>> WRITE_ONCE(ep->ovflist, NULL);
>> smp_wmb();
>> list_splice_init(>rdllist, );
>> write_unlock_irq(>lock);
>
>
> Hi Jason,
>
> For the first chunk you refer the order seems irrelevant.
> Either you see something not empty, you go take the lock
> and then check lists under the lock, either you see all
> lists are empty.
>
Hi Roman,
It does matter. Let's say we have:
epfd1->epfd2->socket. And thread a is doing an
epoll_wait() on epfd1, and thread b is doing
epoll_wait on epfd2. then:
1) data comes in on socket
ep_poll_callback() wakes up threads a and b
2) thread a runs
ep_poll()
ep_scan_ready_list()
ep_send_events_proc()
ep_item_poll()
ep_scan_ready_list()
list_splice_init(>rdllist, );
3) now thread b is running
ep_poll()
ep_events_available()
returns false
schedule_hrtimeout_range()
Thus, thread c has missed a wakeup and will never
get it.
Similarly, for the second chunk I referenced.
>>
>> And also this bit:
>>
>> WRITE_ONCE(ep->ovflist, EP_UNACTIVE_PTR)>>
>> /*
>> * Quickly re-inject items left on "txlist".
>> */
>> list_splice(, >rdllist);
>>
>> Should I think better be reversed as well to:
>>
>> list_splice(, >rdllist);
>> smp_wmb();
>> WRITE_ONCE(ep->ovflist, EP_UNACTIVE_PTR);
>
> But this one is much more interesting. I understand what you
> are trying to achieve: we can't leave both lists empty for the
> short period of time, if there is something left the caller
> of ep_events_available() should be able to see one of the lists
> is not empty, otherwise it can be too late.
>
> But the problem you've spotted is much worse. Some remains
> can be in the txlist (this can happen if caller of epoll_wait
> wants to harvest only 1 event, but there are more in the ->rdlist).
> And we again get the lost wakeup.
>
> Problem is reproduced by the test below. The idea is simple:
> we have 10 threads and 10 event fds. Each thread can harvest
> only 1 event. 1 producer fires all 10 events at once and waits
> that all 10 events will be observed by 10 threads.
>
> The fix is basically a revert of 339ddb53d373 with 1 major
> exception: we do wakeups from ep_scan_ready_list() but
> if txlist is not empty && if ep_scan_ready_list() is called
> from the routine, which sends events, not reads it
> (thus we protect ourselves from repeated wake ups)
>
> I will send the code a bit later.
This was discussed as part of the original discussion around
339ddb53d373:
[PATCH -next v2] hinic: Use ARRAY_SIZE for nic_vf_cmd_msg_handler
fix coccinelle warning, use ARRAY_SIZE
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:713:43-44: WARNING: Use
ARRAY_SIZE
--
v1-->v2:
remove cmd_number
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
index b24788e..af70cca 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
@@ -704,17 +704,15 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
struct hinic_hwdev *dev = hwdev;
struct hinic_func_to_io *nic_io;
struct hinic_pfhwdev *pfhwdev;
- u32 i, cmd_number;
+ u32 i;
int err = 0;
if (!hwdev)
return -EFAULT;
- cmd_number = sizeof(nic_vf_cmd_msg_handler) /
- sizeof(struct vf_cmd_msg_handle);
pfhwdev = container_of(dev, struct hinic_pfhwdev, hwdev);
nic_io = >func_to_io;
- for (i = 0; i < cmd_number; i++) {
+ for (i = 0; i < ARRAY_SIZE(nic_vf_cmd_msg_handler); i++) {
vf_msg_handle = _vf_cmd_msg_handler[i];
if (cmd == vf_msg_handle->cmd &&
vf_msg_handle->cmd_msg_handler) {
@@ -725,7 +723,7 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
break;
}
}
- if (i == cmd_number)
+ if (i == ARRAY_SIZE(nic_vf_cmd_msg_handler))
err = hinic_msg_to_mgmt(>pf_to_mgmt, HINIC_MOD_L2NIC,
cmd, buf_in, in_size, buf_out,
out_size, HINIC_MGMT_MSG_SYNC);
--
2.6.2
Re: [PATCH 5/5] virtio: Add bounce DMA ops
* Stefano Stabellini [2020-04-28 16:04:34]:
> > > Is swiotlb commonly used for multiple devices that may be on different
> > > trust
> > > boundaries (and not behind a hardware iommu)?
>
> The trust boundary is not a good way of describing the scenario and I
> think it leads to miscommunication.
>
> A better way to describe the scenario would be that the device can only
> DMA to/from a small reserved-memory region advertised on device tree.
>
> Do we have other instances of devices that can only DMA to/from very
> specific and non-configurable address ranges? If so, this series could
> follow their example.
AFAICT there is no such notion in current DMA API.
static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size,
bool is_ram)
{
return end <= min_not_zero(*dev->dma_mask, dev->bus_dma_limit);
}
Only the max address a device can access is defined and not a range that we seem
to need here. I think we need to set the bus_dma_limit to 0 for virtio devices
which will force the use of swiotlb_map API. We should also have a per-device
swiotlb pool defined, so that swiotlb can use the pool meant for the given
device.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/3] staging: qlge: Fix suspect indentation warning in qlge_main.c
Fix checkpatch.pl warning:
WARNING: suspect code indent for conditional statements (16, 23)
Signed-off-by: Rylan Dmello
---
drivers/staging/qlge/qlge_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c
index 10daae025790..0edeea525fef 100644
--- a/drivers/staging/qlge/qlge_main.c
+++ b/drivers/staging/qlge/qlge_main.c
@@ -4436,7 +4436,8 @@ static int ql_init_device(struct pci_dev *pdev, struct
net_device *ndev,
} else {
err = dma_set_mask(>dev, DMA_BIT_MASK(32));
if (!err)
- err = dma_set_coherent_mask(>dev,
DMA_BIT_MASK(32));
+ err = dma_set_coherent_mask(>dev,
+ DMA_BIT_MASK(32));
}
if (err) {
--
2.26.2
[PATCH 3/3] staging: qlge: Fix function argument alignment warning in qlge_main.c
Fix checkpatch.pl check:
CHECK: Alignment should match open parenthesis
Signed-off-by: Rylan Dmello
---
drivers/staging/qlge/qlge_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c
index 0edeea525fef..c493da03e45f 100644
--- a/drivers/staging/qlge/qlge_main.c
+++ b/drivers/staging/qlge/qlge_main.c
@@ -4450,7 +4450,7 @@ static int ql_init_device(struct pci_dev *pdev, struct
net_device *ndev,
pci_save_state(pdev);
qdev->reg_base =
ioremap(pci_resource_start(pdev, 1),
- pci_resource_len(pdev, 1));
+ pci_resource_len(pdev, 1));
if (!qdev->reg_base) {
dev_err(>dev, "Register mapping failed.\n");
err = -ENOMEM;
@@ -4460,7 +4460,7 @@ static int ql_init_device(struct pci_dev *pdev, struct
net_device *ndev,
qdev->doorbell_area_size = pci_resource_len(pdev, 3);
qdev->doorbell_area =
ioremap(pci_resource_start(pdev, 3),
- pci_resource_len(pdev, 3));
+ pci_resource_len(pdev, 3));
if (!qdev->doorbell_area) {
dev_err(>dev, "Doorbell register mapping failed.\n");
err = -ENOMEM;
--
2.26.2
[PATCH 1/3] staging: qlge: Remove multi-line dereferences from qlge_main.c
Fix checkpatch.pl warnings: WARNING: Avoid multiple line dereference - prefer 'qdev->func' WARNING: Avoid multiple line dereference - prefer 'qdev->flags' Signed-off-by: Rylan Dmello --- drivers/staging/qlge/qlge_main.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c index d7e4dfafc1a3..10daae025790 100644 --- a/drivers/staging/qlge/qlge_main.c +++ b/drivers/staging/qlge/qlge_main.c @@ -396,8 +396,7 @@ static int ql_set_mac_addr_reg(struct ql_adapter *qdev, u8 *addr, u32 type, * the route field to NIC core. */ cam_output = (CAM_OUT_ROUTE_NIC | - (qdev-> - func << CAM_OUT_FUNC_SHIFT) | + (qdev->func << CAM_OUT_FUNC_SHIFT) | (0 << CAM_OUT_CQ_ID_SHIFT)); if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX) cam_output |= CAM_OUT_RV; @@ -3432,9 +3431,9 @@ static int ql_request_irq(struct ql_adapter *qdev) >rx_ring[0]); status = request_irq(pdev->irq, qlge_isr, - test_bit(QL_MSI_ENABLED, -> -flags) ? 0 : IRQF_SHARED, + test_bit(QL_MSI_ENABLED, >flags) + ? 0 + : IRQF_SHARED, intr_context->name, >rx_ring[0]); if (status) goto err_irq; -- 2.26.2
[PATCH v2] workqueue: Use IS_ERR and PTR_ERR instead of PTR_ERR_OR_ZERO.
Replace inline function PTR_ERR_OR_ZERO with IS_ERR and PTR_ERR to
remove redundant parameter definitions and checks.
Reduce code size.
Before:
textdata bss dec hex filename
475105979 840 54329d439 kernel/workqueue.o
After:
textdata bss dec hex filename
474745979 840 54293d415 kernel/workqueue.o
Signed-off-by: Sean Fu
---
Changes in v2:
- make commit message more clear.
kernel/workqueue.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 891ccad5f271..ddf0537dce14 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4197,7 +4197,6 @@ static int wq_clamp_max_active(int max_active, unsigned
int flags,
static int init_rescuer(struct workqueue_struct *wq)
{
struct worker *rescuer;
- int ret;
if (!(wq->flags & WQ_MEM_RECLAIM))
return 0;
@@ -4208,10 +4207,9 @@ static int init_rescuer(struct workqueue_struct *wq)
rescuer->rescue_wq = wq;
rescuer->task = kthread_create(rescuer_thread, rescuer, "%s", wq->name);
- ret = PTR_ERR_OR_ZERO(rescuer->task);
- if (ret) {
+ if (IS_ERR(rescuer->task)) {
kfree(rescuer);
- return ret;
+ return PTR_ERR(rescuer->task);
}
wq->rescuer = rescuer;
--
2.16.4
[PATCH] perf: perf can not parser the backtrace of app in the 32bit system and 64bit kernel.
Record PC value from regs[15], it should be regs[32], which cause perf parser the backtrace failed. Signed-off-by: Jiping Ma --- arch/arm64/kernel/perf_regs.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c index 0bbac61..04088e6 100644 --- a/arch/arm64/kernel/perf_regs.c +++ b/arch/arm64/kernel/perf_regs.c @@ -32,6 +32,10 @@ u64 perf_reg_value(struct pt_regs *regs, int idx) if ((u32)idx == PERF_REG_ARM64_PC) return regs->pc; + if (perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32 + && idx == 15) + return regs->regs[PERF_REG_ARM64_PC]; + return regs->regs[idx]; } -- 1.9.1
[PATCH v0 linux master] i2c/busses: Avoid i2c interrupt status clear race condition.
In AST2600 there have a slow peripheral bus between CPU
and i2c controller.
Therefore GIC i2c interrupt status clear have delay timing,
when CPU issue write clear i2c controller interrupt status.
To avoid this issue, the driver need have read after write
clear at i2c ISR.
Signed-off-by: ryan_chen
---
drivers/i2c/busses/i2c-aspeed.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 07c1993274c5..f51702d86a90 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -603,6 +603,7 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
/* Ack all interrupts except for Rx done */
writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
bus->base + ASPEED_I2C_INTR_STS_REG);
+ readl(bus->base + ASPEED_I2C_INTR_STS_REG);
irq_remaining = irq_received;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
@@ -645,9 +646,11 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void
*dev_id)
irq_received, irq_handled);
/* Ack Rx done */
- if (irq_received & ASPEED_I2CD_INTR_RX_DONE)
+ if (irq_received & ASPEED_I2CD_INTR_RX_DONE) {
writel(ASPEED_I2CD_INTR_RX_DONE,
bus->base + ASPEED_I2C_INTR_STS_REG);
+ readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+ }
spin_unlock(>lock);
return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
}
--
2.17.1
Re: [PATCH] samples: fix binderfs sample
Hi Arnd,
On Wed, Apr 29, 2020 at 6:26 AM Arnd Bergmann wrote:
>
> A routine check for misspelled Kconfig symbols showed on instance
> from last year, the correct symbol name is CONFIG_ANDROID_BINDERFS,
> not CONFIG_CONFIG_ANDROID_BINDERFS, so the extra prefix must
> be removed in the Kconfig file to allow enabling the sample.
>
> As the actual sample fails to build as a kernel module, change the
> Makefile enough to get to build as a hostprog instead.
>
> Fixes: 9762dc1432e1 ("samples: add binderfs sample program")
> Signed-off-by: Arnd Bergmann
> ---
Nice catch!
I am working on a new syntax 'userprogs'.
This builds programs for the target architecture
instead of the host.
Once, my series lands,
you can use 'userprogs', like this:
https://patchwork.kernel.org/patch/11515977/
Then 'ifndef CROSS_COMPILE' will go away.
--
Best Regards
Masahiro Yamada
Re: [PATCH v3 1/2] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
On Mon, 2020-04-27 at 16:32 -0500, Rob Herring wrote: > On Mon, 27 Apr 2020 10:52:56 +0800, EastL wrote: > > Document the devicetree bindings for MediaTek Command-Queue DMA controller > > which could be found on MT6779 SoC or other similar Mediatek SoCs. > > > > Signed-off-by: EastL > > --- > > .../devicetree/bindings/dma/mtk-cqdma.yaml | 98 > > ++ > > 1 file changed, 98 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma/mtk-cqdma.example.dt.yaml: > dma-controller@10212000: interrupts: [[0, 139, 8], [0, 140, 8], [0, 141, 8]] > is too short > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma/mtk-cqdma.example.dt.yaml: > dma-controller@10212000: reg: [[0, 270606336, 0, 128], [0, 270606464, 0, > 128], [0, 270606592, 0, 128]] is too short > > See https://patchwork.ozlabs.org/patch/1277292 > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure dt-schema is up to date: > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > Please check and re-submit. OK, I'll fix it in next version.
Re: [PATCH -next] hinic: Use ARRAY_SIZE for nic_vf_cmd_msg_handler
Hi Joe,
Thanks for your comments, I will modify and send the v2
On 2020/4/29 11:23, Joe Perches wrote:
On Wed, 2020-04-29 at 11:15 +0800, Zou Wei wrote:
fix coccinelle warning, use ARRAY_SIZE
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:713:43-44: WARNING: Use
ARRAY_SIZE
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
index b24788e..ac12725 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
@@ -710,8 +710,7 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
if (!hwdev)
return -EFAULT;
- cmd_number = sizeof(nic_vf_cmd_msg_handler) /
- sizeof(struct vf_cmd_msg_handle);
+ cmd_number = ARRAY_SIZE(nic_vf_cmd_msg_handler);
pfhwdev = container_of(dev, struct hinic_pfhwdev, hwdev);
nic_io = >func_to_io;
for (i = 0; i < cmd_number; i++) {
Probably better to remove cmd_number altogether
---
drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
index b24788..af70cc 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
@@ -704,17 +704,15 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
struct hinic_hwdev *dev = hwdev;
struct hinic_func_to_io *nic_io;
struct hinic_pfhwdev *pfhwdev;
- u32 i, cmd_number;
+ u32 i;
int err = 0;
if (!hwdev)
return -EFAULT;
- cmd_number = sizeof(nic_vf_cmd_msg_handler) /
- sizeof(struct vf_cmd_msg_handle);
pfhwdev = container_of(dev, struct hinic_pfhwdev, hwdev);
nic_io = >func_to_io;
- for (i = 0; i < cmd_number; i++) {
+ for (i = 0; i < ARRAY_SIZE(nic_vf_cmd_msg_handler); i++) {
vf_msg_handle = _vf_cmd_msg_handler[i];
if (cmd == vf_msg_handle->cmd &&
vf_msg_handle->cmd_msg_handler) {
@@ -725,7 +723,7 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
break;
}
}
- if (i == cmd_number)
+ if (i == ARRAY_SIZE(nic_vf_cmd_msg_handler))
err = hinic_msg_to_mgmt(>pf_to_mgmt, HINIC_MOD_L2NIC,
cmd, buf_in, in_size, buf_out,
out_size, HINIC_MGMT_MSG_SYNC);
.
[PATCH v2 08/15] samples: hidraw: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/. 'make headers' always works for the target architecture (i.e. the same architecture as the kernel), so the sample program should be built for the target as well. Kbuild now supports 'userprogs' for that. I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig | 2 +- samples/hidraw/Makefile | 9 +++-- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index 2560e87c9cae..08f2d025ca05 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -118,7 +118,7 @@ config SAMPLE_CONNECTOR config SAMPLE_HIDRAW bool "hidraw sample" - depends on HEADERS_INSTALL + depends on CC_CAN_LINK && HEADERS_INSTALL config SAMPLE_PIDFD bool "pidfd sample" diff --git a/samples/hidraw/Makefile b/samples/hidraw/Makefile index 8bd25f77671f..d2c77ed60b39 100644 --- a/samples/hidraw/Makefile +++ b/samples/hidraw/Makefile @@ -1,8 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -# List of programs to build -hostprogs := hid-example -always-y := $(hostprogs) +userprogs := hid-example +always-y := $(userprogs) -HOSTCFLAGS_hid-example.o += -I$(objtree)/usr/include - -all: hid-example +userccflags += -I usr/include -- 2.25.1
[PATCH V2] net: hns3: adds support for reading module eeprom info
From: Yonglong Liu
This patch adds support for reading the optical module eeprom
info via "ethtool -m".
Signed-off-by: Yonglong Liu
Signed-off-by: Huazhong Tan
---
V2: replace self-defined macro with the SFF8024_ID_* in sfp.h
suggested by Jakub Kicinski.
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 4 +
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 75 +++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 15 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 102 +
4 files changed, 196 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 6291aa9..5602bf2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -374,6 +374,8 @@ struct hnae3_ae_dev {
* Set the max tx rate of specified vf.
* set_vf_mac
* Configure the default MAC for specified VF
+ * get_module_eeprom
+ * Get the optical module eeprom info.
*/
struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -548,6 +550,8 @@ struct hnae3_ae_ops {
int (*set_vf_rate)(struct hnae3_handle *handle, int vf,
int min_tx_rate, int max_tx_rate, bool force);
int (*set_vf_mac)(struct hnae3_handle *handle, int vf, u8 *p);
+ int (*get_module_eeprom)(struct hnae3_handle *handle, u32 offset,
+u32 len, u8 *data);
};
struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 4d9c85f..1a105f2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include "hns3_enet.h"
@@ -12,6 +13,11 @@ struct hns3_stats {
int stats_offset;
};
+struct hns3_sfp_type {
+ u8 type;
+ u8 ext_type;
+};
+
/* tqp related stats */
#define HNS3_TQP_STAT(_string, _member){ \
.stats_string = _string,\
@@ -1386,6 +1392,73 @@ static int hns3_set_fecparam(struct net_device *netdev,
return ops->set_fec(handle, fec_mode);
}
+static int hns3_get_module_info(struct net_device *netdev,
+ struct ethtool_modinfo *modinfo)
+{
+#define HNS3_SFF_8636_V1_3 0x03
+
+ struct hnae3_handle *handle = hns3_get_handle(netdev);
+ const struct hnae3_ae_ops *ops = handle->ae_algo->ops;
+ struct hns3_sfp_type sfp_type;
+ int ret;
+
+ if (handle->pdev->revision == 0x20 || !ops->get_module_eeprom)
+ return -EOPNOTSUPP;
+
+ memset(_type, 0, sizeof(sfp_type));
+ ret = ops->get_module_eeprom(handle, 0, sizeof(sfp_type) / sizeof(u8),
+(u8 *)_type);
+ if (ret)
+ return ret;
+
+ switch (sfp_type.type) {
+ case SFF8024_ID_SFP:
+ modinfo->type = ETH_MODULE_SFF_8472;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
+ break;
+ case SFF8024_ID_QSFP_8438:
+ modinfo->type = ETH_MODULE_SFF_8436;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8436_MAX_LEN;
+ break;
+ case SFF8024_ID_QSFP_8436_8636:
+ if (sfp_type.ext_type < HNS3_SFF_8636_V1_3) {
+ modinfo->type = ETH_MODULE_SFF_8436;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8436_MAX_LEN;
+ } else {
+ modinfo->type = ETH_MODULE_SFF_8636;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8636_MAX_LEN;
+ }
+ break;
+ case SFF8024_ID_QSFP28_8636:
+ modinfo->type = ETH_MODULE_SFF_8636;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8636_MAX_LEN;
+ break;
+ default:
+ netdev_err(netdev, "Optical module unknown: %#x\n",
+ sfp_type.type);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int hns3_get_module_eeprom(struct net_device *netdev,
+ struct ethtool_eeprom *ee, u8 *data)
+{
+ struct hnae3_handle *handle = hns3_get_handle(netdev);
+ const struct hnae3_ae_ops *ops = handle->ae_algo->ops;
+
+ if (handle->pdev->revision == 0x20 || !ops->get_module_eeprom)
+ return -EOPNOTSUPP;
+
+ if (!ee->len)
+ return -EINVAL;
+
+ memset(data, 0, ee->len);
+
+ return ops->get_module_eeprom(handle, ee->offset, ee->len, data);
+}
+
#define HNS3_ETHTOOL_COALESCE (ETHTOOL_COALESCE_USECS | \
ETHTOOL_COALESCE_USE_ADAPTIVE |\
ETHTOOL_COALESCE_RX_USECS_HIGH | \
@@ -1449,6 +1522,8 @@ static const struct ethtool_ops
[PATCH v2 06/15] samples: uhid: fix warnings in uhid-example
From: Sam Ravnborg
Fix warnings seen when building for 32-bit architecture.
Use "%xd" for arguments of type size_t to fix the warnings.
Signed-off-by: Sam Ravnborg
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
samples/uhid/uhid-example.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/samples/uhid/uhid-example.c b/samples/uhid/uhid-example.c
index b72d645ce828..015cb06a241e 100644
--- a/samples/uhid/uhid-example.c
+++ b/samples/uhid/uhid-example.c
@@ -165,7 +165,7 @@ static int uhid_write(int fd, const struct uhid_event *ev)
fprintf(stderr, "Cannot write to uhid: %m\n");
return -errno;
} else if (ret != sizeof(*ev)) {
- fprintf(stderr, "Wrong size written to uhid: %ld != %lu\n",
+ fprintf(stderr, "Wrong size written to uhid: %zd != %zu\n",
ret, sizeof(ev));
return -EFAULT;
} else {
@@ -236,7 +236,7 @@ static int event(int fd)
fprintf(stderr, "Cannot read uhid-cdev: %m\n");
return -errno;
} else if (ret != sizeof(ev)) {
- fprintf(stderr, "Invalid size read from uhid-dev: %ld != %lu\n",
+ fprintf(stderr, "Invalid size read from uhid-dev: %zd != %zu\n",
ret, sizeof(ev));
return -EFAULT;
}
--
2.25.1
[PATCH v2 12/15] samples: mei: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/. 'make headers' always works for the target architecture (i.e. the same architecture as the kernel), so the sample program should be built for the target as well. Kbuild now supports 'userprogs' for that. I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig | 1 + samples/mei/Makefile | 9 +++-- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index c68d391c0602..69699db49675 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -193,6 +193,7 @@ config SAMPLE_VFS config SAMPLE_INTEL_MEI bool "Build example program working with intel mei driver" depends on INTEL_MEI + depends on CC_CAN_LINK && HEADERS_INSTALL help Build a sample program to work with mei device. diff --git a/samples/mei/Makefile b/samples/mei/Makefile index f5b9d02be2cd..329411f82369 100644 --- a/samples/mei/Makefile +++ b/samples/mei/Makefile @@ -1,10 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 # Copyright (c) 2012-2019, Intel Corporation. All rights reserved. -hostprogs := mei-amt-version +userprogs := mei-amt-version +always-y := $(userprogs) -HOSTCFLAGS_mei-amt-version.o += -I$(objtree)/usr/include - -always-y := $(hostprogs) - -all: mei-amt-version +userccflags += -I usr/include -- 2.25.1
[PATCH v2 05/15] kbuild: doc: document the new syntax 'userprogs'
Kbuild now supports the syntax 'userprogs' to compile userspace programs for the same architecture as the kernel. Insert the section '5 Userspace Program support' to explain it. I copy-pasted '4 Host Program support' and fixed it up. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None Documentation/kbuild/makefiles.rst | 183 + 1 file changed, 135 insertions(+), 48 deletions(-) diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index b80257a03830..234492351031 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -29,31 +29,37 @@ This document describes the Linux kernel Makefiles. --- 4.4 Controlling compiler options for host programs --- 4.5 When host programs are actually built - === 5 Kbuild clean infrastructure - - === 6 Architecture Makefiles - --- 6.1 Set variables to tweak the build to the architecture - --- 6.2 Add prerequisites to archheaders: - --- 6.3 Add prerequisites to archprepare: - --- 6.4 List directories to visit when descending - --- 6.5 Architecture-specific boot images - --- 6.6 Building non-kbuild targets - --- 6.7 Commands useful for building a boot image - --- 6.8 Custom kbuild commands - --- 6.9 Preprocessing linker scripts - --- 6.10 Generic header files - --- 6.11 Post-link pass - - === 7 Kbuild syntax for exported headers - --- 7.1 no-export-headers - --- 7.2 generic-y - --- 7.3 generated-y - --- 7.4 mandatory-y - - === 8 Kbuild Variables - === 9 Makefile language - === 10 Credits - === 11 TODO + === 5 Userspace Program support + --- 5.1 Simple Userspace Program + --- 5.2 Composite Userspace Programs + --- 5.3 Controlling compiler options for userspace programs + --- 5.4 When userspace programs are actually built + + === 6 Kbuild clean infrastructure + + === 7 Architecture Makefiles + --- 7.1 Set variables to tweak the build to the architecture + --- 7.2 Add prerequisites to archheaders: + --- 7.3 Add prerequisites to archprepare: + --- 7.4 List directories to visit when descending + --- 7.5 Architecture-specific boot images + --- 7.6 Building non-kbuild targets + --- 7.7 Commands useful for building a boot image + --- 7.8 Custom kbuild commands + --- 7.9 Preprocessing linker scripts + --- 7.10 Generic header files + --- 7.11 Post-link pass + + === 8 Kbuild syntax for exported headers + --- 8.1 no-export-headers + --- 8.2 generic-y + --- 8.3 generated-y + --- 8.4 mandatory-y + + === 9 Kbuild Variables + === 10 Makefile language + === 11 Credits + === 12 TODO 1 Overview == @@ -732,7 +738,88 @@ Both possibilities are described in the following. This will tell kbuild to build lxdialog even if not referenced in any rule. -5 Kbuild clean infrastructure +5 Userspace Program support +=== + +Just like host programs, Kbuild also supports building userspace executables +for the target architecture (i.e. the same architecture as you are building +the kernel for). + +The syntax is quite similar. The difference is to use "userprogs" instead of +"hostprogs". + +5.1 Simple Userspace Program + + + The following line tells kbuild that the program bpf-direct shall be + built for the target architecture. + + Example:: + + userprogs := bpf-direct + + Kbuild assumes in the above example that bpf-direct is made from a + single C source file named bpf-direct.c located in the same directory + as the Makefile. + +5.2 Composite Userspace Programs + + + Userspace programs can be made up based on composite objects. + The syntax used to define composite objects for userspace programs is + similar to the syntax used for kernel objects. + $(-objs) lists all objects used to link the final + executable. + + Example:: + + #samples/seccomp/Makefile + userprogs := bpf-fancy + bpf-fancy-objs := bpf-fancy.o bpf-helper.o + + Objects with extension .o are compiled from the corresponding .c + files. In the above example, bpf-fancy.c is compiled to bpf-fancy.o + and bpf-helper.c is compiled to bpf-helper.o. + + Finally, the two .o files are linked to the executable, bpf-fancy. + Note: The syntax -y is not permitted for userspace programs. + +5.3 Controlling compiler options for userspace programs +--- + +
[PATCH v2 15/15] samples: watchdog: use 'userprogs' syntax
Kbuild now supports the 'userprogs' syntax to compile userspace programs for the same architecture as the kernel. Add the entry to samples/Makefile to put this into the build bot coverage. I also added the CONFIG option guarded by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig | 3 +++ samples/Makefile | 1 + samples/watchdog/Makefile | 10 ++ 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index a8629a0d4f96..5005f74ac0eb 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -205,5 +205,8 @@ config SAMPLE_INTEL_MEI help Build a sample program to work with mei device. +config SAMPLE_WATCHDOG + bool "watchdog sample" + depends on CC_CAN_LINK endif # SAMPLES diff --git a/samples/Makefile b/samples/Makefile index 042208326689..29c66aadd954 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -26,3 +26,4 @@ obj-$(CONFIG_VIDEO_PCI_SKELETON) += v4l/ obj-y += vfio-mdev/ subdir-$(CONFIG_SAMPLE_VFS)+= vfs obj-$(CONFIG_SAMPLE_INTEL_MEI) += mei/ +subdir-$(CONFIG_SAMPLE_WATCHDOG) += watchdog diff --git a/samples/watchdog/Makefile b/samples/watchdog/Makefile index a9430fa60253..17384cfb387e 100644 --- a/samples/watchdog/Makefile +++ b/samples/watchdog/Makefile @@ -1,9 +1,3 @@ # SPDX-License-Identifier: GPL-2.0 -CC := $(CROSS_COMPILE)gcc -PROGS := watchdog-simple - -all: $(PROGS) - -clean: - rm -fr $(PROGS) - +userprogs := watchdog-simple +always-y := $(userprogs) -- 2.25.1
[PATCH v2 11/15] samples: pidfd: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/. 'make headers' always works for the target architecture (i.e. the same architecture as the kernel), so the sample program should be built for the target as well. Kbuild now supports 'userprogs' for that. I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig| 2 +- samples/pidfd/Makefile | 8 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index 831a7ecd3352..c68d391c0602 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -122,7 +122,7 @@ config SAMPLE_HIDRAW config SAMPLE_PIDFD bool "pidfd sample" - depends on HEADERS_INSTALL + depends on CC_CAN_LINK && HEADERS_INSTALL config SAMPLE_SECCOMP bool "Build seccomp sample code" diff --git a/samples/pidfd/Makefile b/samples/pidfd/Makefile index ee2979849d92..6e5b67e648c2 100644 --- a/samples/pidfd/Makefile +++ b/samples/pidfd/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 -hostprogs := pidfd-metadata -always-y := $(hostprogs) -HOSTCFLAGS_pidfd-metadata.o += -I$(objtree)/usr/include -all: pidfd-metadata +usertprogs := pidfd-metadata +always-y := $(userprogs) + +userccflags += -I usr/include -- 2.25.1
[PATCH v2 09/15] samples: connector: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/. 'make headers' always works for the target architecture (i.e. the same architecture as the kernel), so the sample program should be built for the target as well. Kbuild now supports 'userprogs' for that. $(CC) can always compile cn_text.o since it is the kenrel-space code, but building ucon requires libc. I guarded it by: always-$(CONFIG_CC_CAN_LINK) := $(userprogs) Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/connector/Makefile | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/samples/connector/Makefile b/samples/connector/Makefile index b785cbde5ffa..50cb40e09a7b 100644 --- a/samples/connector/Makefile +++ b/samples/connector/Makefile @@ -1,13 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_SAMPLE_CONNECTOR) += cn_test.o -# List of programs to build -hostprogs := ucon -always-y := $(hostprogs) +userprogs := ucon +always-$(CONFIG_CC_CAN_LINK) := $(userprogs) -HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include - -all: modules - -modules clean: - $(MAKE) -C ../.. M=$(CURDIR) $@ +userccflags += -I usr/include -- 2.25.1
[PATCH v2 01/15] bpfilter: match bit size of bpfilter_umh to that of the kernel
bpfilter_umh is built for the default machine bit of the compiler, which may not match to the bit size of the kernel. This happens in the scenario below: You can use biarch GCC that defaults to 64-bit for building the 32-bit kernel. In this case, Kbuild passes -m32 to teach the compiler to produce 32-bit kernel space objects. However, it is missing when building bpfilter_umh. It is built as a 64-bit ELF, and then embedded into the 32-bit kernel. The 32-bit kernel and 64-bit umh is a bad combination. In theory, we can have 32-bit umh running on 64-bit kernel, but we do not have a good reason to support such a usecase. The best is to match the bit size between them. Pass -m32 or -m64 to the umh build command if it is found in $(KBUILD_CFLAGS). Evaluate CC_CAN_LINK against the kernel bit-size. Signed-off-by: Masahiro Yamada --- Changes in v2: - New patch init/Kconfig | 4 +++- net/bpfilter/Makefile | 5 +++-- usr/include/Makefile | 4 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index a494212a3a79..57562a8e2761 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -45,7 +45,9 @@ config CLANG_VERSION default $(shell,$(srctree)/scripts/clang-version.sh $(CC)) config CC_CAN_LINK - def_bool $(success,$(srctree)/scripts/cc-can-link.sh $(CC)) + bool + default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(m64-flag)) if 64BIT + default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(m32-flag)) config CC_HAS_ASM_GOTO def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC)) diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile index 36580301da70..f6209e4827b9 100644 --- a/net/bpfilter/Makefile +++ b/net/bpfilter/Makefile @@ -5,14 +5,15 @@ hostprogs := bpfilter_umh bpfilter_umh-objs := main.o -KBUILD_HOSTCFLAGS += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi +KBUILD_HOSTCFLAGS += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi \ + $(filter -m32 -m64, $(KBUILD_CFLAGS)) HOSTCC := $(CC) ifeq ($(CONFIG_BPFILTER_UMH), y) # builtin bpfilter_umh should be compiled with -static # since rootfs isn't mounted at the time of __init # function is called and do_execv won't find elf interpreter -KBUILD_HOSTLDFLAGS += -static +KBUILD_HOSTLDFLAGS += -static $(filter -m32 -m64, $(KBUILD_CFLAGS)) endif $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh diff --git a/usr/include/Makefile b/usr/include/Makefile index 5a7ee3e5ed86..55362f3ab393 100644 --- a/usr/include/Makefile +++ b/usr/include/Makefile @@ -8,6 +8,10 @@ # We cannot go as far as adding -Wpedantic since it emits too many warnings. UAPI_CFLAGS := -std=c90 -Wall -Werror=implicit-function-declaration +# In theory, we do not care -m32 or -m64 for header compile tests. +# It is here just because CONFIG_CC_CAN_LINK is tested with -m32 or -m64. +UAPI_CFLAGS += $(filter -m32 -m64, $(KBUILD_CFLAGS)) + override c_flags = $(UAPI_CFLAGS) -Wp,-MMD,$(depfile) -I$(objtree)/usr/include # The following are excluded for now because they fail to build. -- 2.25.1
[PATCH v2 10/15] samples: vfs: build sample programs for target architecture
These userspace programs include UAPI headers exported to usr/include/. 'make headers' always works for the target architecture (i.e. the same architecture as the kernel), so the sample programs should be built for the target as well. Kbuild now supports 'userprogs' for that. I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig | 2 +- samples/vfs/Makefile | 11 +++ 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index 08f2d025ca05..831a7ecd3352 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -184,7 +184,7 @@ config SAMPLE_ANDROID_BINDERFS config SAMPLE_VFS bool "Build example programs that use new VFS system calls" - depends on HEADERS_INSTALL + depends on CC_CAN_LINK && HEADERS_INSTALL help Build example userspace programs that use new VFS system calls such as mount API and statx(). Note that this is restricted to the x86 diff --git a/samples/vfs/Makefile b/samples/vfs/Makefile index 65acdde5c117..00b6824f9237 100644 --- a/samples/vfs/Makefile +++ b/samples/vfs/Makefile @@ -1,10 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only -# List of programs to build -hostprogs := \ - test-fsmount \ - test-statx +userprogs := test-fsmount test-statx +always-y := $(userprogs) -always-y := $(hostprogs) - -HOSTCFLAGS_test-fsmount.o += -I$(objtree)/usr/include -HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include +userccflags += -I usr/include -- 2.25.1
[PATCH v2 00/15] kbuild: support 'userprogs' syntax
Several Makefiles use 'hostprogs' to build programs for the host architecture where it is not appropriate to do so. This is just because Kbuild lacks the support for building programs for the target architecture. This series introduce 'userprogs' syntax and use it from sample and bpf Makefiles. Sam worked on this in 2014. https://lkml.org/lkml/2014/7/13/154 He used 'uapiprogs-y' but I just thought the meaning of "UAPI programs" is unclear. Naming the syntax is one of the most difficult parts. I chose 'userprogs'. Anothor choice I had in my mind was 'targetprogs'. You can test this series quickly by 'make allmodconfig samples/' When building objects for userspace, [U] is displayed. masahiro@oscar:~/workspace/linux$ make allmodconfig samples/ [snip] AR samples/vfio-mdev/built-in.a CC [M] samples/vfio-mdev/mtty.o CC [M] samples/vfio-mdev/mdpy.o CC [M] samples/vfio-mdev/mdpy-fb.o CC [M] samples/vfio-mdev/mbochs.o AR samples/mei/built-in.a CC [U] samples/mei/mei-amt-version CC [U] samples/auxdisplay/cfag12864b-example CC [M] samples/configfs/configfs_sample.o CC [M] samples/connector/cn_test.o CC [U] samples/connector/ucon CC [M] samples/ftrace/ftrace-direct.o CC [M] samples/ftrace/ftrace-direct-too.o CC [M] samples/ftrace/ftrace-direct-modify.o CC [M] samples/ftrace/sample-trace-array.o CC [U] samples/hidraw/hid-example CC [M] samples/hw_breakpoint/data_breakpoint.o CC [M] samples/kdb/kdb_hello.o CC [M] samples/kfifo/bytestream-example.o CC [M] samples/kfifo/dma-example.o CC [M] samples/kfifo/inttype-example.o CC [M] samples/kfifo/record-example.o CC [M] samples/kobject/kobject-example.o CC [M] samples/kobject/kset-example.o CC [M] samples/kprobes/kprobe_example.o CC [M] samples/kprobes/kretprobe_example.o CC [M] samples/livepatch/livepatch-sample.o CC [M] samples/livepatch/livepatch-shadow-mod.o CC [M] samples/livepatch/livepatch-shadow-fix1.o CC [M] samples/livepatch/livepatch-shadow-fix2.o CC [M] samples/livepatch/livepatch-callbacks-demo.o CC [M] samples/livepatch/livepatch-callbacks-mod.o CC [M] samples/livepatch/livepatch-callbacks-busymod.o CC [M] samples/rpmsg/rpmsg_client_sample.o CC [U] samples/seccomp/bpf-fancy.o CC [U] samples/seccomp/bpf-helper.o LD [U] samples/seccomp/bpf-fancy CC [U] samples/seccomp/dropper CC [U] samples/seccomp/bpf-direct CC [U] samples/seccomp/user-trap CC [U] samples/timers/hpet_example CC [M] samples/trace_events/trace-events-sample.o CC [M] samples/trace_printk/trace-printk.o CC [U] samples/uhid/uhid-example CC [M] samples/v4l/v4l2-pci-skeleton.o CC [U] samples/vfs/test-fsmount CC [U] samples/vfs/test-statx samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared inside parameter list will not be visible outside of this definition or declaration 24 | #define statx foo | ^~~ CC [U] samples/watchdog/watchdog-simple AR samples/built-in.a Changes for v2: - Fix ARCH=i386 build error for bpfilter_umh - Rename 'user-ccflags' to 'userccflags' because 'user-ccflags' would conflict if an object called 'user.o' exists in the directory. - Support 'userldflags' Masahiro Yamada (14): bpfilter: match bit size of bpfilter_umh to that of the kernel kbuild: add infrastructure to build userspace programs bpfilter: use 'userprogs' syntax to build bpfilter_umh samples: seccomp: build sample programs for target architecture kbuild: doc: document the new syntax 'userprogs' samples: uhid: build sample program for target architecture samples: hidraw: build sample program for target architecture samples: connector: build sample program for target architecture samples: vfs: build sample programs for target architecture samples: pidfd: build sample program for target architecture samples: mei: build sample program for target architecture samples: auxdisplay: use 'userprogs' syntax samples: timers: use 'userprogs' syntax samples: watchdog: use 'userprogs' syntax Sam Ravnborg (1): samples: uhid: fix warnings in uhid-example Documentation/kbuild/makefiles.rst | 183 + Makefile | 13 +- init/Kconfig | 4 +- net/bpfilter/Makefile | 11 +- samples/Kconfig| 26 +++- samples/Makefile | 4 + samples/auxdisplay/Makefile| 11 +- samples/connector/Makefile | 12 +- samples/hidraw/Makefile| 9 +- samples/mei/Makefile | 9 +- samples/pidfd/Makefile | 8 +- samples/seccomp/Makefile | 42 +-- samples/timers/Makefile| 17 +-- samples/uhid/.gitignore| 2 + samples/uhid/Makefile | 9 +- samples/uhid/uhid-example.c| 4 +- samples/vfs/Makefile | 11 +- samples/watchdog/Makefile | 10 +-
[PATCH v2 14/15] samples: timers: use 'userprogs' syntax
Kbuild now supports the 'userprogs' syntax to compile userspace programs for the same architecture as the kernel. Add the entry to samples/Makefile to put this into the build bot coverage. I also added the CONFIG option guarded by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig | 4 samples/Makefile| 1 + samples/timers/Makefile | 17 +++-- 3 files changed, 8 insertions(+), 14 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index 2322e11e8b80..a8629a0d4f96 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -135,6 +135,10 @@ config SAMPLE_SECCOMP Build samples of seccomp filters using various methods of BPF filter construction. +config SAMPLE_TIMER + bool "Timer sample" + depends on CC_CAN_LINK && HEADERS_INSTALL + config SAMPLE_UHID bool "UHID sample" depends on CC_CAN_LINK && HEADERS_INSTALL diff --git a/samples/Makefile b/samples/Makefile index 0c43b5d34b15..042208326689 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -16,6 +16,7 @@ subdir-$(CONFIG_SAMPLE_PIDFD) += pidfd obj-$(CONFIG_SAMPLE_QMI_CLIENT)+= qmi/ obj-$(CONFIG_SAMPLE_RPMSG_CLIENT) += rpmsg/ subdir-$(CONFIG_SAMPLE_SECCOMP)+= seccomp +subdir-$(CONFIG_SAMPLE_TIMER) += timers obj-$(CONFIG_SAMPLE_TRACE_EVENTS) += trace_events/ obj-$(CONFIG_SAMPLE_TRACE_PRINTK) += trace_printk/ obj-$(CONFIG_SAMPLE_FTRACE_DIRECT) += ftrace/ diff --git a/samples/timers/Makefile b/samples/timers/Makefile index f9fa07460802..15c7ddbc8c51 100644 --- a/samples/timers/Makefile +++ b/samples/timers/Makefile @@ -1,16 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -ifndef CROSS_COMPILE -uname_M := $(shell uname -m 2>/dev/null || echo not) -ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/) +userprogs := hpet_example +always-y := $(userprogs) -ifeq ($(ARCH),x86) -CC := $(CROSS_COMPILE)gcc -PROGS := hpet_example - -all: $(PROGS) - -clean: - rm -fr $(PROGS) - -endif -endif +userccflags += -I usr/include -- 2.25.1
[PATCH v2 04/15] samples: seccomp: build sample programs for target architecture
These userspace programs include UAPI headers exported to usr/include/.
'make headers' always works for the target architecture (i.e. the same
architecture as the kernel), so the sample programs should be built for
the target as well. Kbuild now supports 'userprogs' for that.
I also guarded the CONFIG option by 'depends on CC_CAN_LINK' because
$(CC) may not provide libc.
The 'ifndef CROSS_COMPILE' is no longer needed.
BTW, the -m31 for s390 is left-over code. Commit 5a79859ae0f3 ("s390:
remove 31 bit support") killed it.
Signed-off-by: Masahiro Yamada
Acked-by: Sam Ravnborg
---
Changes in v2: None
samples/Kconfig | 2 +-
samples/seccomp/Makefile | 42 +++-
2 files changed, 4 insertions(+), 40 deletions(-)
diff --git a/samples/Kconfig b/samples/Kconfig
index 9d236c346de5..8949e9646125 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -126,7 +126,7 @@ config SAMPLE_PIDFD
config SAMPLE_SECCOMP
bool "Build seccomp sample code"
- depends on SECCOMP_FILTER && HEADERS_INSTALL
+ depends on SECCOMP_FILTER && CC_CAN_LINK && HEADERS_INSTALL
help
Build samples of seccomp filters using various methods of
BPF filter construction.
diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
index 89279e8b87df..75916c23e416 100644
--- a/samples/seccomp/Makefile
+++ b/samples/seccomp/Makefile
@@ -1,44 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
-ifndef CROSS_COMPILE
-hostprogs := bpf-fancy dropper bpf-direct user-trap
+userprogs := bpf-fancy dropper bpf-direct user-trap
-HOSTCFLAGS_bpf-fancy.o += -I$(objtree)/usr/include
-HOSTCFLAGS_bpf-fancy.o += -idirafter $(objtree)/include
-HOSTCFLAGS_bpf-helper.o += -I$(objtree)/usr/include
-HOSTCFLAGS_bpf-helper.o += -idirafter $(objtree)/include
bpf-fancy-objs := bpf-fancy.o bpf-helper.o
-HOSTCFLAGS_dropper.o += -I$(objtree)/usr/include
-HOSTCFLAGS_dropper.o += -idirafter $(objtree)/include
-dropper-objs := dropper.o
+userccflags += -I usr/include
-HOSTCFLAGS_bpf-direct.o += -I$(objtree)/usr/include
-HOSTCFLAGS_bpf-direct.o += -idirafter $(objtree)/include
-bpf-direct-objs := bpf-direct.o
-
-HOSTCFLAGS_user-trap.o += -I$(objtree)/usr/include
-HOSTCFLAGS_user-trap.o += -idirafter $(objtree)/include
-user-trap-objs := user-trap.o
-
-# Try to match the kernel target.
-ifndef CONFIG_64BIT
-
-# s390 has -m31 flag to build 31 bit binaries
-ifndef CONFIG_S390
-MFLAG = -m32
-else
-MFLAG = -m31
-endif
-
-HOSTCFLAGS_bpf-direct.o += $(MFLAG)
-HOSTCFLAGS_dropper.o += $(MFLAG)
-HOSTCFLAGS_bpf-helper.o += $(MFLAG)
-HOSTCFLAGS_bpf-fancy.o += $(MFLAG)
-HOSTCFLAGS_user-trap.o += $(MFLAG)
-HOSTLDLIBS_bpf-direct += $(MFLAG)
-HOSTLDLIBS_bpf-fancy += $(MFLAG)
-HOSTLDLIBS_dropper += $(MFLAG)
-HOSTLDLIBS_user-trap += $(MFLAG)
-endif
-always-y := $(hostprogs)
-endif
+always-y := $(userprogs)
--
2.25.1
[PATCH v2 07/15] samples: uhid: build sample program for target architecture
This userspace program includes UAPI headers exported to usr/include/. 'make headers' always works for the target architecture (i.e. the same architecture as the kernel), so the sample program should be built for the target as well. Kbuild now supports 'userprogs' for that. Add the entry to samples/Makefile to put this into the build bot coverage. I also added the CONFIG option guarded by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig | 6 ++ samples/Makefile| 1 + samples/uhid/.gitignore | 2 ++ samples/uhid/Makefile | 9 +++-- 4 files changed, 12 insertions(+), 6 deletions(-) create mode 100644 samples/uhid/.gitignore diff --git a/samples/Kconfig b/samples/Kconfig index 8949e9646125..2560e87c9cae 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -131,6 +131,12 @@ config SAMPLE_SECCOMP Build samples of seccomp filters using various methods of BPF filter construction. +config SAMPLE_UHID + bool "UHID sample" + depends on CC_CAN_LINK && HEADERS_INSTALL + help + Build UHID sample program. + config SAMPLE_VFIO_MDEV_MTTY tristate "Build VFIO mtty example mediated device sample code -- loadable modules only" depends on VFIO_MDEV_DEVICE && m diff --git a/samples/Makefile b/samples/Makefile index 5ce50ef0f2b2..bdc168405452 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_SAMPLE_TRACE_EVENTS) += trace_events/ obj-$(CONFIG_SAMPLE_TRACE_PRINTK) += trace_printk/ obj-$(CONFIG_SAMPLE_FTRACE_DIRECT) += ftrace/ obj-$(CONFIG_SAMPLE_TRACE_ARRAY) += ftrace/ +subdir-$(CONFIG_SAMPLE_UHID) += uhid obj-$(CONFIG_VIDEO_PCI_SKELETON) += v4l/ obj-y += vfio-mdev/ subdir-$(CONFIG_SAMPLE_VFS)+= vfs diff --git a/samples/uhid/.gitignore b/samples/uhid/.gitignore new file mode 100644 index ..0e0a5a929f5d --- /dev/null +++ b/samples/uhid/.gitignore @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +/uhid-example diff --git a/samples/uhid/Makefile b/samples/uhid/Makefile index 5f44ea40d6d5..9e652fc34103 100644 --- a/samples/uhid/Makefile +++ b/samples/uhid/Makefile @@ -1,8 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only -# List of programs to build -hostprogs := uhid-example +userprogs := uhid-example +always-y := $(userprogs) -# Tell kbuild to always build the programs -always-y := $(hostprogs) - -HOSTCFLAGS_uhid-example.o += -I$(objtree)/usr/include +userccflags += -I usr/include -- 2.25.1
[PATCH v2 02/15] kbuild: add infrastructure to build userspace programs
Kbuild supports the infrastructure to build host programs, but there was no support to build userspace programs for the target architecture (i.e. the same architecture as the kernel). Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154), but it was not merged. One problem at that time was, there was no good way to know whether $(CC) can link standalone programs. In fact, pre-built kernel.org toolchains [1] are often used for building the kernel, but they do not provide libc. Now, we can handle this cleanly because the compiler capability is evaluated at the Kconfig time. If $(CC) cannot link standalone programs, the relevant options are hidden by 'depends on CC_CAN_LINK'. The implementation just mimics scripts/Makefile.host The userspace programs are compiled with the same flags as the host programs. In addition, it uses -m32 or -m64 if it is found in $(KBUILD_CFLAGS). This new syntax has two usecases. - Sample programs Several userspace programs under samples/ include UAPI headers installed in usr/include. Most of them were previously built for the host architecture just to use the 'hostprogs' syntax. However, 'make headers' always works for the target architecture. This caused the arch mismatch in cross-compiling. To fix this distortion, sample code should be built for the target architecture. - Bpfilter net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper, and embeds it into the kernel. Currently, it overrides HOSTCC with CC to use the 'hostprogs' syntax. This hack should go away. [1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/ Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: - Rename 'user-ccflags' to 'userccflags' We use '-ccflags' for the per-file flag. 'user-ccflags' would have a Makefile | 13 --- scripts/Makefile.build | 6 + scripts/Makefile.clean | 2 +- scripts/Makefile.userprogs | 45 ++ 4 files changed, 62 insertions(+), 4 deletions(-) create mode 100644 scripts/Makefile.userprogs diff --git a/Makefile b/Makefile index ee7773d5f4c9..9ff00bfe0575 100644 --- a/Makefile +++ b/Makefile @@ -406,9 +406,12 @@ else HOSTCC = gcc HOSTCXX= g++ endif -KBUILD_HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ - -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) \ - $(HOSTCFLAGS) + +export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \ + -O2 -fomit-frame-pointer -std=gnu89 +export KBUILD_USERLDFLAGS := + +KBUILD_HOSTCFLAGS := $(KBUILD_USERCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS) KBUILD_HOSTCXXFLAGS := -Wall -O2 $(HOST_LFS_CFLAGS) $(HOSTCXXFLAGS) KBUILD_HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS) KBUILD_HOSTLDLIBS := $(HOST_LFS_LIBS) $(HOSTLDLIBS) @@ -937,6 +940,10 @@ ifeq ($(CONFIG_RELR),y) LDFLAGS_vmlinux+= --pack-dyn-relocs=relr endif +# Align the bit size of userspace programs with the kernel +KBUILD_USERCFLAGS += $(filter -m32 -m64, $(KBUILD_CFLAGS)) +KBUILD_USERLDFLAGS += $(filter -m32 -m64, $(KBUILD_CFLAGS)) + # make the checker run with the right architecture CHECKFLAGS += --arch=$(ARCH) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 9fcbfac15d1d..3665b1a0bc8e 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -50,6 +50,12 @@ ifneq ($(hostprogs)$(hostcxxlibs-y)$(hostcxxlibs-m),) include scripts/Makefile.host endif +# Do not include userprogs rules unless needed. +userprogs := $(sort $(userprogs)) +ifneq ($(userprogs),) +include scripts/Makefile.userprogs +endif + ifndef obj $(warning kbuild: Makefile.build is included improperly) endif diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean index 075f0cc2d8d7..e2c76122319d 100644 --- a/scripts/Makefile.clean +++ b/scripts/Makefile.clean @@ -29,7 +29,7 @@ subdir-ymn:= $(addprefix $(obj)/,$(subdir-ymn)) __clean-files := $(extra-y) $(extra-m) $(extra-) \ $(always) $(always-y) $(always-m) $(always-) $(targets) $(clean-files) \ - $(hostprogs) $(hostprogs-y) $(hostprogs-m) $(hostprogs-) \ + $(hostprogs) $(hostprogs-y) $(hostprogs-m) $(hostprogs-) $(userprogs) \ $(hostcxxlibs-y) $(hostcxxlibs-m) __clean-files := $(filter-out $(no-clean-files), $(__clean-files)) diff --git a/scripts/Makefile.userprogs b/scripts/Makefile.userprogs new file mode 100644 index ..ebde030e7dd0 --- /dev/null +++ b/scripts/Makefile.userprogs @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Build userspace programs for the target system +# + +# Executables compiled from a single .c file +user-csingle := $(foreach m, $(userprogs), $(if $($(m)-objs),,$(m))) + +# Executables linked based on several .o files +user-cmulti:= $(foreach m, $(userprogs), $(if $($(m)-objs),$(m))) + +# Objects
[PATCH v2 13/15] samples: auxdisplay: use 'userprogs' syntax
Kbuild now supports the 'userprogs' syntax to compile userspace programs for the same architecture as the kernel. Add the entry to samples/Makefile to put this into the build bot coverage. I also added the CONFIG option guarded by 'depends on CC_CAN_LINK' because $(CC) may not provide libc. Signed-off-by: Masahiro Yamada Acked-by: Miguel Ojeda Acked-by: Sam Ravnborg --- Changes in v2: None samples/Kconfig | 4 samples/Makefile| 1 + samples/auxdisplay/Makefile | 11 ++- 3 files changed, 7 insertions(+), 9 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index 69699db49675..2322e11e8b80 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -6,6 +6,10 @@ menuconfig SAMPLES if SAMPLES +config SAMPLE_AUXDISPLAY + bool "auxdisplay sample" + depends on CC_CAN_LINK + config SAMPLE_TRACE_EVENTS tristate "Build trace_events examples -- loadable modules only" depends on EVENT_TRACING && m diff --git a/samples/Makefile b/samples/Makefile index bdc168405452..0c43b5d34b15 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 # Makefile for Linux samples code +subdir-$(CONFIG_SAMPLE_AUXDISPLAY) += auxdisplay obj-$(CONFIG_SAMPLE_ANDROID_BINDERFS) += binderfs/ obj-$(CONFIG_SAMPLE_CONFIGFS) += configfs/ obj-$(CONFIG_SAMPLE_CONNECTOR) += connector/ diff --git a/samples/auxdisplay/Makefile b/samples/auxdisplay/Makefile index 0273bab27233..dbdf939af94a 100644 --- a/samples/auxdisplay/Makefile +++ b/samples/auxdisplay/Makefile @@ -1,10 +1,3 @@ # SPDX-License-Identifier: GPL-2.0 -CC := $(CROSS_COMPILE)gcc -CFLAGS := -I../../usr/include - -PROGS := cfag12864b-example - -all: $(PROGS) - -clean: - rm -fr $(PROGS) +userprogs := cfag12864b-example +always-y := $(userprogs) -- 2.25.1
[PATCH v2 03/15] bpfilter: use 'userprogs' syntax to build bpfilter_umh
The user mode helper should be compiled for the same architecture as the kernel. This Makefile reused the 'hostprogs' syntax by overriding HOSTCC with CC. Use the new syntax 'userprogs' to fix the Makefile mess. Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: None net/bpfilter/Makefile | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile index f6209e4827b9..f23b53294fba 100644 --- a/net/bpfilter/Makefile +++ b/net/bpfilter/Makefile @@ -3,18 +3,14 @@ # Makefile for the Linux BPFILTER layer. # -hostprogs := bpfilter_umh +userprogs := bpfilter_umh bpfilter_umh-objs := main.o -KBUILD_HOSTCFLAGS += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi \ - $(filter -m32 -m64, $(KBUILD_CFLAGS)) -HOSTCC := $(CC) +userccflags += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi -ifeq ($(CONFIG_BPFILTER_UMH), y) -# builtin bpfilter_umh should be compiled with -static +# builtin bpfilter_umh should be linked with -static # since rootfs isn't mounted at the time of __init # function is called and do_execv won't find elf interpreter -KBUILD_HOSTLDFLAGS += -static $(filter -m32 -m64, $(KBUILD_CFLAGS)) -endif +userldflags += -static $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh -- 2.25.1
Re: [PATCH] ARM64: dts: freescale: imx8mm: correct VDDARM@1.6GHz
On Sun, Apr 26, 2020 at 06:06:48AM +0800, Robin Gong wrote:
> Correct VDDARM to 0.95V@1.6Ghz with datasheet.
Please add more details about the data sheet like version, download
address, etc.
>
> Signed-off-by: Robin Gong
I know it might be hard to follow, but for historic reason, we use
subject prefix 'ARM: dts: ...' for arm32 and 'arm64: dts: ...' for arm64
dts patches on IMX platform.
Shawn
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index cc7152e..a226030 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -129,7 +129,7 @@
>
> opp-16 {
> opp-hz = /bits/ 64 <16>;
> - opp-microvolt = <90>;
> + opp-microvolt = <95>;
> opp-supported-hw = <0xc>, <0x7>;
> clock-latency-ns = <15>;
> opp-suspend;
> --
> 2.7.4
>
Re: [PATCH] arm64: dts: imx8mn: Update VDD_ARM 1.2GHz setpoint voltage
On Sat, Apr 25, 2020 at 08:29:50PM +0800, Anson Huang wrote: > The latest datasheet Rev. 0.1, 03/2020 removes below constrain: > > "If VDD_SOC/GPU/DDR = 0.95V, then VDD_ARM must be >= 0.95V." > > So, for 1.2GHz setpoint VDD_ARM can use its typical voltage > directly. > > The datasheet can be downloaded from below link: > https://www.nxp.com/docs/en/data-sheet/IMX8MNCEC.pdf > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH] ARM: dts: gw552x: add USB OTG support
On Fri, Apr 24, 2020 at 10:10:15AM -0700, Tim Harvey wrote:
> The GW552x-B board revision adds USB OTG support.
>
> Enable the device-tree node and configure the OTG_ID pin.
>
> Signed-off-by: Tim Harvey
> ---
> arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> index dc646b7..133a1e3 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> @@ -12,8 +12,6 @@
> led1 =
> led2 =
> nand =
> - usb0 =
> - usb1 =
Have some comments about this change in the commit log?
Shawn
> };
>
> chosen {
> @@ -258,6 +256,14 @@
> status = "okay";
> };
>
> + {
> + vbus-supply = <_5p0v>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_usbotg>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_wdog>;
> @@ -359,6 +365,12 @@
> >;
> };
>
> + pinctrl_usbotg: usbotggrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x13059
> + >;
> + };
> +
> pinctrl_wdog: wdoggrp {
> fsl,pins = <
> MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
> --
> 2.7.4
>
Re: [PATCH 5/5] virtio: Add bounce DMA ops
* Michael S. Tsirkin [2020-04-28 16:41:04]:
> > Won't we still need some changes to virtio to make use of its own pool (to
> > bounce buffers)? Something similar to its own DMA ops proposed in this
> > patch?
>
> If you are doing this for all devices, you need to either find a way
> to do this without chaning DMA ops, or by doing some automatic change
> to all drivers.
Ok thanks for this input. I will see how we can obfuscate this in DMA APIs
itself.
Can you also comment on the virtio transport problem I cited? The hypervisor we
are dealing with does not support MMIO transport. It supports message queue
send/recv and also doorbell, which I think can be used if we can make some
change like this to virtio_mmio.c:
+static inline u32
+virtio_readl(struct virtio_mmio_device *vm_dev, u32 reg_offset)
+{
+return vm_dev->mmio_ops->readl(vm_dev, reg_offset);
+}
+
+static inline void
+virtio_writel(struct virtio_mmio_device *vm_dev, u32 reg_offset, u32 data)
+{
+vm_dev->mmio_ops->writel(vm_dev, reg_offset, data);
+}
/* Check magic value */
-magic = readl(vm_dev->base + VIRTIO_MMIO_MAGIC_VALUE);
+magic = vrito_readl(vm_dev, VIRTIO_MMIO_MAGIC_VALUE);
mmio_ops->readl on most platforms can default to readl itself, while on a
platform like us, it can boil down to message_queue send/recv. Would such a
change be acceptable?
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v3 3/4] iommu/vt-d: Add page request draining support
On Wed, 22 Apr 2020 16:06:10 +0800
Lu Baolu wrote:
> When a PASID is stopped or terminated, there can be pending PRQs
> (requests that haven't received responses) in remapping hardware.
> This adds the interface to drain page requests and call it when a
> PASID is terminated.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Liu Yi L
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-svm.c | 103
> ++-- include/linux/intel-iommu.h |
> 4 ++ 2 files changed, 102 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
> index 83dc4319f661..2534641ef707 100644
> --- a/drivers/iommu/intel-svm.c
> +++ b/drivers/iommu/intel-svm.c
> @@ -23,6 +23,7 @@
> #include "intel-pasid.h"
>
> static irqreturn_t prq_event_thread(int irq, void *d);
> +static void intel_svm_drain_prq(struct device *dev, int pasid);
>
> #define PRQ_ORDER 0
>
> @@ -66,6 +67,8 @@ int intel_svm_enable_prq(struct intel_iommu *iommu)
> dmar_writeq(iommu->reg + DMAR_PQT_REG, 0ULL);
> dmar_writeq(iommu->reg + DMAR_PQA_REG,
> virt_to_phys(iommu->prq) | PRQ_ORDER);
> + init_completion(>prq_complete);
> +
> return 0;
> }
>
> @@ -208,6 +211,7 @@ static void intel_mm_release(struct mmu_notifier
> *mn, struct mm_struct *mm) rcu_read_lock();
> list_for_each_entry_rcu(sdev, >devs, list) {
> intel_pasid_tear_down_entry(svm->iommu, sdev->dev,
> svm->pasid);
> + intel_svm_drain_prq(sdev->dev, svm->pasid);
mmu_notifier release is called in atomic context, drain_prq needs to
wait for completion. I tested exit path when a process crashes. I got
[ +0.696214] BUG: sleeping function called from invalid context at
kernel/sched/completion.c:101
[ +0.68] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3235,
name: dsatest
[ +0.46] INFO: lockdep is turned off.
[ +0.02] CPU: 1 PID: 3235 Comm: dsatest Not tainted 5.7.0-rc1-z-svmtest+
#1637
[ +0.00] Hardware name: Intel Corporation Kabylake Client platform/Skylake
Halo DDR4 RVP11, BIOS
04.1709050855 09/05/2017
[ +0.01] Call Trace:
[ +0.04] dump_stack+0x68/0x9b
[ +0.03] ___might_sleep+0x229/0x250
[ +0.03] wait_for_completion_timeout+0x3c/0x110
[ +0.03] intel_svm_drain_prq+0x12f/0x210
[ +0.03] intel_mm_release+0x73/0x110
[ +0.03] __mmu_notifier_release+0x94/0x220
[ +0.02] ? do_munmap+0x10/0x10
[ +0.02] ? prepare_ftrace_return+0x5c/0x80
[ +0.03] exit_mmap+0x156/0x1a0
[ +0.02] ? mmput+0x44/0x120
[ +0.03] ? exit_mmap+0x5/0x1a0
[ +0.02] ? ftrace_graph_caller+0xa0/0xa0
[ +0.01] mmput+0x5e/0x120
> intel_flush_svm_range_dev(svm, sdev, 0, -1, 0);
> }
> rcu_read_unlock();
> @@ -401,12 +405,8 @@ int intel_svm_unbind_gpasid(struct device *dev,
> int pasid) if (!sdev->users) {
> list_del_rcu(>list);
> intel_pasid_tear_down_entry(iommu, dev,
> svm->pasid);
> + intel_svm_drain_prq(dev, svm->pasid);
> intel_flush_svm_range_dev(svm, sdev, 0, -1,
> 0);
> - /* TODO: Drain in flight PRQ for the PASID
> since it
> - * may get reused soon, we don't want to
> - * confuse with its previous life.
> - * intel_svm_drain_prq(dev, pasid);
> - */
> kfree_rcu(sdev, rcu);
>
> if (list_empty(>devs)) {
> @@ -644,6 +644,7 @@ int intel_svm_unbind_mm(struct device *dev, int
> pasid)
>* large and has to be physically
> contiguous. So it's
>* hard to be as defensive as we might like.
> */ intel_pasid_tear_down_entry(iommu, dev, svm->pasid);
> + intel_svm_drain_prq(dev, svm->pasid);
> intel_flush_svm_range_dev(svm, sdev, 0, -1,
> 0); kfree_rcu(sdev, rcu);
>
> @@ -722,6 +723,92 @@ static bool is_canonical_address(u64 addr)
> return (((saddr << shift) >> shift) == saddr);
> }
>
> +/**
> + * intel_svm_drain_prq:
> + *
> + * Drain all pending page requests and responses related to a
> specific
> + * pasid in both software and hardware.
> + */
> +static void intel_svm_drain_prq(struct device *dev, int pasid)
> +{
> + struct device_domain_info *info;
> + struct dmar_domain *domain;
> + struct intel_iommu *iommu;
> + struct qi_desc desc[3];
> + struct pci_dev *pdev;
> + int head, tail;
> + u16 sid, did;
> + int qdep;
> +
> + info = get_domain_info(dev);
> + if (WARN_ON(!info || !dev_is_pci(dev)))
> + return;
> +
> + if (!info->ats_enabled)
> + return;
> +
> + iommu = info->iommu;
> + domain = info->domain;
> + pdev = to_pci_dev(dev);
> + sid = PCI_DEVID(info->bus, info->devfn);
> + did = domain->iommu_did[iommu->seq_id];
> + qdep = pci_ats_queue_depth(pdev);
> +
Re: [PATCH] epoll: Fix UAF dentry name access in wakeup source setup
On Wed, Apr 29, 2020 at 4:46 AM Al Viro wrote:
> On Wed, Apr 29, 2020 at 04:31:04AM +0200, Jann Horn wrote:
> > I'm guessing this will go through akpm's tree?
> >
> > fs/eventpoll.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> > index 8c596641a72b0..5052a41670479 100644
> > --- a/fs/eventpoll.c
> > +++ b/fs/eventpoll.c
> > @@ -1450,7 +1450,7 @@ static int reverse_path_check(void)
> >
> > static int ep_create_wakeup_source(struct epitem *epi)
> > {
> > - const char *name;
> > + struct name_snapshot name;
> > struct wakeup_source *ws;
> >
> > if (!epi->ep->ws) {
> > @@ -1459,8 +1459,9 @@ static int ep_create_wakeup_source(struct epitem *epi)
> > return -ENOMEM;
> > }
> >
> > - name = epi->ffd.file->f_path.dentry->d_name.name;
> > - ws = wakeup_source_register(NULL, name);
> > + take_dentry_name_snapshot(, epi->ffd.file->f_path.dentry);
> > + ws = wakeup_source_register(NULL, name.name.name);
> > + release_dentry_name_snapshot();
>
> I'm not sure I like it. Sure, it won't get freed under you that way; it still
> can go absolutely stale by the time you return from wakeup_source_register().
> What is it being used for?
The one user I'm aware of is Android; they use EPOLLWAKEUP in the
following places:
https://cs.android.com/search?q=EPOLLWAKEUP%20-file:strace%20-file:uapi%2F%20-file:syscall%2Fzerrors%20-file:sys%2Funix%2Fzerrors%20-file:prebuilts%2F%20-file:mod.rs%20-file:libcap-ng%2F%20-file:tests%2F=
I see timerfds, /dev/input/event*, some other stuff with input devices
and video devices, binder, netlink socket, and some other stuff like
that - nothing that's actually likely to be renamed.
Searching on cs.android.com for places that parse this stuff, there
seems to be some code that uploads it as part of bug reports or
something (?), and some parser whose precise purpose I can't figure
out right now:
(Arve might know what this is actually good for.)
Anyway, I don't think that name is actually particularly critical to
the correct functioning of the system; and the bug is a memory
corruption issue, so we should fix it somehow. And adding
infrastructure to power management so that it can invoke a callback to
figure out the (potentially, under rare circumstances, changing) name
of a wakeup source seems like a bit of overkill to me.
Re: [PATCH] arm64: dts: freescale: imx8mp: update input_val for AUDIOMIX_BIT_STREAM
On Fri, Apr 24, 2020 at 05:05:15PM +0800, Shengjiu Wang wrote:
> Update input_val for AUDIOMIX_BIT_STREAM according to latest RM.
>
> Fixes: 6d9b8d20431f ("arm64: dts: freescale: Add i.MX8MP dtsi support")
> Signed-off-by: Shengjiu Wang
Applied, thanks.
[PATCH -next] hinic: Use kmemdup instead of kzalloc and memcpy
Fixes coccicheck warnings: drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:452:17-24: WARNING opportunity for kmemdup drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:458:23-30: WARNING opportunity for kmemdup Reported-by: Hulk Robot Signed-off-by: Zou Wei --- drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c index f8626df..a39cc16 100644 --- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c @@ -449,18 +449,15 @@ static void recv_mbox_handler(struct hinic_mbox_func_to_func *func_to_func, return; } - rcv_mbox_temp = kzalloc(sizeof(*rcv_mbox_temp), GFP_KERNEL); + rcv_mbox_temp = kmemdup(recv_mbox, sizeof(*rcv_mbox_temp), GFP_KERNEL); if (!rcv_mbox_temp) return; - memcpy(rcv_mbox_temp, recv_mbox, sizeof(*rcv_mbox_temp)); - - rcv_mbox_temp->mbox = kzalloc(MBOX_MAX_BUF_SZ, GFP_KERNEL); + rcv_mbox_temp->mbox = kmemdup(recv_mbox->mbox, MBOX_MAX_BUF_SZ, + GFP_KERNEL); if (!rcv_mbox_temp->mbox) goto err_alloc_rcv_mbox_msg; - memcpy(rcv_mbox_temp->mbox, recv_mbox->mbox, MBOX_MAX_BUF_SZ); - rcv_mbox_temp->buf_out = kzalloc(MBOX_MAX_BUF_SZ, GFP_KERNEL); if (!rcv_mbox_temp->buf_out) goto err_alloc_rcv_mbox_buf; -- 2.6.2
Re: [mm/debug] fa6726c1e7: kernel_BUG_at_include/linux/mm.h
On 04/28/2020 02:51 PM, Catalin Marinas wrote: > On Tue, Apr 28, 2020 at 04:41:11AM -0400, Qian Cai wrote: >> On Apr 28, 2020, at 1:54 AM, Anshuman Khandual >> wrote: >>> That is true. There is a slight change in the rules, making it explicit yes >>> only when both ARCH_HAS_DEBUG_VM_PGTABLE and DEBUG_VM are enabled. >>> >>> +config DEBUG_VM_PGTABLE >>> +bool "Debug arch page table for semantics compliance" >>> +depends on MMU >>> +depends on !IA64 && !ARM >>> +depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT >>> +default y if ARCH_HAS_DEBUG_VM_PGTABLE && DEBUG_VM >>> +help >>> >>> The default is really irrelevant as the config option can be set explicitly. >> >> That could also explain. Since not long time ago, it was only “default >> y if DEBUG_VM”, that caused the robot saved a .config with >> DEBUG_VM_PGTABLE=y by default. >> >> Even though you changed the rule recently, it has no effect as the >> robot could “make oldconfig” from the saved config for each linux-next >> tree execution and the breakage will go on. > > I'm not entirely sure that's the case. This report still points at the > old commit fa6726c1e7 which has: > > + depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT > + default n if !ARCH_HAS_DEBUG_VM_PGTABLE > + default y if DEBUG_VM > > In -next we now have commit 647d9a0de34c and subsequently modified by > commit 0a8646638865. So hopefully with the latest -next tree we won't > see this report. Could some one from LKP test framework, please confirm if this still causes above problem on the latest linux-next by default ?
[PATCH v2 05/10] mm/gup: separate PageHighMem() and PageHighMemZone() use case
From: Joonsoo Kim Until now, PageHighMem() is used for two different cases. One is to check if there is a direct mapping for this page or not. The other is to check the zone of this page, that is, weather it is the highmem type zone or not. Now, we have separate functions, PageHighMem() and PageHighMemZone() for each cases. Use appropriate one. Note that there are some rules to determine the proper macro. 1. If PageHighMem() is called for checking if the direct mapping exists or not, use PageHighMem(). 2. If PageHighMem() is used to predict the previous gfp_flags for this page, use PageHighMemZone(). The zone of the page is related to the gfp_flags. 3. If purpose of calling PageHighMem() is to count highmem page and to interact with the system by using this count, use PageHighMemZone(). This counter is usually used to calculate the available memory for an kernel allocation and pages on the highmem zone cannot be available for an kernel allocation. 4. Otherwise, use PageHighMemZone(). It's safe since it's implementation is just copy of the previous PageHighMem() implementation and won't be changed. I apply the rule #2 for this patch. Acked-by: Roman Gushchin Signed-off-by: Joonsoo Kim --- mm/gup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/gup.c b/mm/gup.c index 11fda53..9652eed 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1608,7 +1608,7 @@ static struct page *new_non_cma_page(struct page *page, unsigned long private) */ gfp_t gfp_mask = GFP_USER | __GFP_NOWARN; - if (PageHighMem(page)) + if (PageHighMemZone(page)) gfp_mask |= __GFP_HIGHMEM; #ifdef CONFIG_HUGETLB_PAGE -- 2.7.4
[PATCH v2 06/10] mm/hugetlb: separate PageHighMem() and PageHighMemZone() use case
From: Joonsoo Kim
Until now, PageHighMem() is used for two different cases. One is to check
if there is a direct mapping for this page or not. The other is to check
the zone of this page, that is, weather it is the highmem type zone or not.
Now, we have separate functions, PageHighMem() and PageHighMemZone() for
each cases. Use appropriate one.
Note that there are some rules to determine the proper macro.
1. If PageHighMem() is called for checking if the direct mapping exists
or not, use PageHighMem().
2. If PageHighMem() is used to predict the previous gfp_flags for
this page, use PageHighMemZone(). The zone of the page is related to
the gfp_flags.
3. If purpose of calling PageHighMem() is to count highmem page and
to interact with the system by using this count, use PageHighMemZone().
This counter is usually used to calculate the available memory for an
kernel allocation and pages on the highmem zone cannot be available
for an kernel allocation.
4. Otherwise, use PageHighMemZone(). It's safe since it's implementation
is just copy of the previous PageHighMem() implementation and won't
be changed.
I apply the rule #3 for this patch.
Acked-by: Roman Gushchin
Signed-off-by: Joonsoo Kim
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5548e88..56c9143 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2639,7 +2639,7 @@ static void try_to_free_low(struct hstate *h, unsigned
long count,
list_for_each_entry_safe(page, next, freel, lru) {
if (count >= h->nr_huge_pages)
return;
- if (PageHighMem(page))
+ if (PageHighMemZone(page))
continue;
list_del(>lru);
update_and_free_page(h, page);
--
2.7.4
[PATCH v2 04/10] power: separate PageHighMem() and PageHighMemZone() use case
From: Joonsoo Kim
Until now, PageHighMem() is used for two different cases. One is to check
if there is a direct mapping for this page or not. The other is to check
the zone of this page, that is, weather it is the highmem type zone or not.
Now, we have separate functions, PageHighMem() and PageHighMemZone() for
each cases. Use appropriate one.
Note that there are some rules to determine the proper macro.
1. If PageHighMem() is called for checking if the direct mapping exists
or not, use PageHighMem().
2. If PageHighMem() is used to predict the previous gfp_flags for
this page, use PageHighMemZone(). The zone of the page is related to
the gfp_flags.
3. If purpose of calling PageHighMem() is to count highmem page and
to interact with the system by using this count, use PageHighMemZone().
This counter is usually used to calculate the available memory for an
kernel allocation and pages on the highmem zone cannot be available
for an kernel allocation.
4. Otherwise, use PageHighMemZone(). It's safe since it's implementation
is just copy of the previous PageHighMem() implementation and won't
be changed.
I apply the rule #3 for this patch.
Acked-by: Roman Gushchin
Signed-off-by: Joonsoo Kim
---
kernel/power/snapshot.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 6598001..be759a6 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1227,7 +1227,7 @@ static struct page *saveable_highmem_page(struct zone
*zone, unsigned long pfn)
if (!page || page_zone(page) != zone)
return NULL;
- BUG_ON(!PageHighMem(page));
+ BUG_ON(!PageHighMemZone(page));
if (swsusp_page_is_forbidden(page) || swsusp_page_is_free(page))
return NULL;
@@ -1291,7 +1291,7 @@ static struct page *saveable_page(struct zone *zone,
unsigned long pfn)
if (!page || page_zone(page) != zone)
return NULL;
- BUG_ON(PageHighMem(page));
+ BUG_ON(PageHighMemZone(page));
if (swsusp_page_is_forbidden(page) || swsusp_page_is_free(page))
return NULL;
@@ -1529,7 +1529,7 @@ static unsigned long preallocate_image_pages(unsigned
long nr_pages, gfp_t mask)
if (!page)
break;
memory_bm_set_bit(_bm, page_to_pfn(page));
- if (PageHighMem(page))
+ if (PageHighMemZone(page))
alloc_highmem++;
else
alloc_normal++;
@@ -1625,7 +1625,7 @@ static unsigned long free_unnecessary_pages(void)
unsigned long pfn = memory_bm_next_pfn(_bm);
struct page *page = pfn_to_page(pfn);
- if (PageHighMem(page)) {
+ if (PageHighMemZone(page)) {
if (!to_free_highmem)
continue;
to_free_highmem--;
@@ -2264,7 +2264,7 @@ static unsigned int count_highmem_image_pages(struct
memory_bitmap *bm)
memory_bm_position_reset(bm);
pfn = memory_bm_next_pfn(bm);
while (pfn != BM_END_OF_MAP) {
- if (PageHighMem(pfn_to_page(pfn)))
+ if (PageHighMemZone(pfn_to_page(pfn)))
cnt++;
pfn = memory_bm_next_pfn(bm);
@@ -2541,7 +2541,7 @@ static void *get_buffer(struct memory_bitmap *bm, struct
chain_allocator *ca)
return ERR_PTR(-EFAULT);
page = pfn_to_page(pfn);
- if (PageHighMem(page))
+ if (PageHighMemZone(page))
return get_highmem_page_buffer(page, ca);
if (swsusp_page_is_forbidden(page) && swsusp_page_is_free(page))
--
2.7.4
[PATCH v2 08/10] mm/page_alloc: correct the use of is_highmem_idx()
From: Joonsoo Kim What we'd like to check here is whether page has direct mapping or not. Use PageHighMem() since it is perfectly matched for this purpose. Acked-by: Roman Gushchin Signed-off-by: Joonsoo Kim --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7fe5115..da473c7 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1399,7 +1399,7 @@ static void __meminit __init_single_page(struct page *page, unsigned long pfn, INIT_LIST_HEAD(>lru); #ifdef WANT_PAGE_VIRTUAL /* The shift won't overflow because ZONE_NORMAL is below 4G. */ - if (!is_highmem_idx(zone)) + if (!PageHighMem(page)) set_page_address(page, __va(pfn << PAGE_SHIFT)); #endif } -- 2.7.4
[PATCH v2 10/10] mm/page-flags: change the implementation of the PageHighMem()
From: Joonsoo Kim Until now, PageHighMem() is used for two different cases. One is to check if there is a direct mapping for this page or not. The other is to check the zone of this page, that is, weather it is the highmem type zone or not. Previous patches introduce PageHighMemZone() macro and separates both cases strictly. So, now, PageHighMem() is used just for checking if there is a direct mapping for this page or not. In the following patchset, ZONE_MOVABLE which could be considered as the highmem type zone in some configuration could have both types of pages, direct mapped pages and unmapped pages. So, current implementation of PageHighMem() that checks the zone rather than checks the page in order to check if a direct mapping exists will be invalid. This patch prepares that case by implementing PageHighMem() with the max_low_pfn. Acked-by: Roman Gushchin Signed-off-by: Joonsoo Kim --- include/linux/page-flags.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index fca0cce..7ac5fc8 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -375,6 +375,8 @@ PAGEFLAG(Readahead, reclaim, PF_NO_COMPOUND) TESTCLEARFLAG(Readahead, reclaim, PF_NO_COMPOUND) #ifdef CONFIG_HIGHMEM +extern unsigned long max_low_pfn; + /* * Must use a macro here due to header dependency issues. page_zone() is not * available at this point. @@ -383,7 +385,7 @@ PAGEFLAG(Readahead, reclaim, PF_NO_COMPOUND) * in order to predict previous gfp_flags or to count something for system * memory management. */ -#define PageHighMem(__p) is_highmem_idx(page_zonenum(__p)) +#define PageHighMem(__p) (page_to_pfn(__p) >= max_low_pfn) #define PageHighMemZone(__p) is_highmem_idx(page_zonenum(__p)) #else PAGEFLAG_FALSE(HighMem) -- 2.7.4
[PATCH v2 09/10] mm/migrate: replace PageHighMem() with open-code
From: Joonsoo Kim Implementation of PageHighMem() will be changed in following patches. Before that, use open-code to avoid the side effect of implementation change on PageHighMem(). Acked-by: Roman Gushchin Signed-off-by: Joonsoo Kim --- include/linux/migrate.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/migrate.h b/include/linux/migrate.h index 3e546cb..a9cfd8e 100644 --- a/include/linux/migrate.h +++ b/include/linux/migrate.h @@ -37,6 +37,7 @@ static inline struct page *new_page_nodemask(struct page *page, gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL; unsigned int order = 0; struct page *new_page = NULL; + int zidx; if (PageHuge(page)) return alloc_huge_page_nodemask(page_hstate(compound_head(page)), @@ -47,7 +48,8 @@ static inline struct page *new_page_nodemask(struct page *page, order = HPAGE_PMD_ORDER; } - if (PageHighMem(page) || (zone_idx(page_zone(page)) == ZONE_MOVABLE)) + zidx = zone_idx(page_zone(page)); + if (is_highmem_idx(zidx) || zidx == ZONE_MOVABLE) gfp_mask |= __GFP_HIGHMEM; new_page = __alloc_pages_nodemask(gfp_mask, order, -- 2.7.4
[PATCH v2 07/10] mm: separate PageHighMem() and PageHighMemZone() use case
From: Joonsoo Kim Until now, PageHighMem() is used for two different cases. One is to check if there is a direct mapping for this page or not. The other is to check the zone of this page, that is, weather it is the highmem type zone or not. Now, we have separate functions, PageHighMem() and PageHighMemZone() for each cases. Use appropriate one. Note that there are some rules to determine the proper macro. 1. If PageHighMem() is called for checking if the direct mapping exists or not, use PageHighMem(). 2. If PageHighMem() is used to predict the previous gfp_flags for this page, use PageHighMemZone(). The zone of the page is related to the gfp_flags. 3. If purpose of calling PageHighMem() is to count highmem page and to interact with the system by using this count, use PageHighMemZone(). This counter is usually used to calculate the available memory for an kernel allocation and pages on the highmem zone cannot be available for an kernel allocation. 4. Otherwise, use PageHighMemZone(). It's safe since it's implementation is just copy of the previous PageHighMem() implementation and won't be changed. I apply the rule #3 for this patch. Acked-by: Roman Gushchin Signed-off-by: Joonsoo Kim --- mm/memory_hotplug.c | 2 +- mm/page_alloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 555137b..891c214 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -593,7 +593,7 @@ void generic_online_page(struct page *page, unsigned int order) __free_pages_core(page, order); totalram_pages_add(1UL << order); #ifdef CONFIG_HIGHMEM - if (PageHighMem(page)) + if (PageHighMemZone(page)) totalhigh_pages_add(1UL << order); #endif } diff --git a/mm/page_alloc.c b/mm/page_alloc.c index fc5919e..7fe5115 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7444,7 +7444,7 @@ void adjust_managed_page_count(struct page *page, long count) atomic_long_add(count, _zone(page)->managed_pages); totalram_pages_add(count); #ifdef CONFIG_HIGHMEM - if (PageHighMem(page)) + if (PageHighMemZone(page)) totalhigh_pages_add(count); #endif } -- 2.7.4
[PATCH v2 03/10] kexec: separate PageHighMem() and PageHighMemZone() use case
From: Joonsoo Kim
Until now, PageHighMem() is used for two different cases. One is to check
if there is a direct mapping for this page or not. The other is to check
the zone of this page, that is, weather it is the highmem type zone or not.
Now, we have separate functions, PageHighMem() and PageHighMemZone() for
each cases. Use appropriate one.
Note that there are some rules to determine the proper macro.
1. If PageHighMem() is called for checking if the direct mapping exists
or not, use PageHighMem().
2. If PageHighMem() is used to predict the previous gfp_flags for
this page, use PageHighMemZone(). The zone of the page is related to
the gfp_flags.
3. If purpose of calling PageHighMem() is to count highmem page and
to interact with the system by using this count, use PageHighMemZone().
This counter is usually used to calculate the available memory for an
kernel allocation and pages on the highmem zone cannot be available
for an kernel allocation.
4. Otherwise, use PageHighMemZone(). It's safe since it's implementation
is just copy of the previous PageHighMem() implementation and won't
be changed.
I apply the rule #2 for this patch.
Acked-by: Roman Gushchin
Signed-off-by: Joonsoo Kim
---
kernel/kexec_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index ba1d91e..33097b7 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -766,7 +766,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
* gfp_flags honor the ones passed in.
*/
if (!(gfp_mask & __GFP_HIGHMEM) &&
- PageHighMem(old_page)) {
+ PageHighMemZone(old_page)) {
kimage_free_pages(old_page);
continue;
}
--
2.7.4
[PATCH v2 02/10] drm/ttm: separate PageHighMem() and PageHighMemZone() use case
From: Joonsoo Kim
Until now, PageHighMem() is used for two different cases. One is to check
if there is a direct mapping for this page or not. The other is to check
the zone of this page, that is, weather it is the highmem type zone or not.
Now, we have separate functions, PageHighMem() and PageHighMemZone() for
each cases. Use appropriate one.
Note that there are some rules to determine the proper macro.
1. If PageHighMem() is called for checking if the direct mapping exists
or not, use PageHighMem().
2. If PageHighMem() is used to predict the previous gfp_flags for
this page, use PageHighMemZone(). The zone of the page is related to
the gfp_flags.
3. If purpose of calling PageHighMem() is to count highmem page and
to interact with the system by using this count, use PageHighMemZone().
This counter is usually used to calculate the available memory for an
kernel allocation and pages on the highmem zone cannot be available
for an kernel allocation.
4. Otherwise, use PageHighMemZone(). It's safe since it's implementation
is just copy of the previous PageHighMem() implementation and won't
be changed.
I apply the rule #4 for this patch.
Acked-by: Roman Gushchin
Reviewed-by: Christian König
Signed-off-by: Joonsoo Kim
---
drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index acd63b7..d071b71 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -641,7 +641,7 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
*/
#ifdef CONFIG_HIGHMEM
- if (PageHighMem(page) && glob->zone_highmem != NULL)
+ if (PageHighMemZone(page) && glob->zone_highmem != NULL)
zone = glob->zone_highmem;
#else
if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
@@ -656,7 +656,7 @@ void ttm_mem_global_free_page(struct ttm_mem_global *glob,
struct page *page,
struct ttm_mem_zone *zone = NULL;
#ifdef CONFIG_HIGHMEM
- if (PageHighMem(page) && glob->zone_highmem != NULL)
+ if (PageHighMemZone(page) && glob->zone_highmem != NULL)
zone = glob->zone_highmem;
#else
if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b40a467..847fabe 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -530,7 +530,7 @@ static int ttm_alloc_new_pages(struct list_head *pages,
gfp_t gfp_flags,
/* gfp flags of highmem page should never be dma32 so we
* we should be fine in such case
*/
- if (PageHighMem(p))
+ if (PageHighMemZone(p))
continue;
#endif
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index faefaae..338b2a2 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -747,7 +747,7 @@ static int ttm_dma_pool_alloc_new_pages(struct dma_pool
*pool,
/* gfp flags of highmem page should never be dma32 so we
* we should be fine in such case
*/
- if (PageHighMem(p))
+ if (PageHighMemZone(p))
continue;
#endif
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2ec448e..6e094dd 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -119,7 +119,7 @@ static int ttm_tt_set_page_caching(struct page *p,
{
int ret = 0;
- if (PageHighMem(p))
+ if (PageHighMemZone(p))
return 0;
if (c_old != tt_cached) {
--
2.7.4
[PATCH v2 00/10] change the implementation of the PageHighMem()
From: Joonsoo Kim Changes on v2 - add "acked-by", "reviewed-by" tags - replace PageHighMem() with use open-code, instead of using new PageHighMemZone() macro. Related file is "include/linux/migrate.h" Hello, This patchset separates two use cases of PageHighMem() by introducing PageHighMemZone() macro. And, it changes the implementation of PageHighMem() to reflect the actual meaning of this macro. This patchset is a preparation step for the patchset, "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE" [1]. PageHighMem() is used for two different cases. One is to check if there is a direct mapping for this page or not. The other is to check the zone of this page, that is, weather it is the highmem type zone or not. Until now, both the cases are the perfectly same thing. So, implementation of the PageHighMem() uses the one case that checks if the zone of the page is the highmem type zone or not. "#define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))" ZONE_MOVABLE is special. It is considered as normal type zone on !CONFIG_HIGHMEM, but, it is considered as highmem type zone on CONFIG_HIGHMEM. Let's focus on later case. In later case, all pages on the ZONE_MOVABLE has no direct mapping until now. However, following patchset "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE" , which is once merged and reverted, will be tried again and will break this assumption that all pages on the ZONE_MOVABLE has no direct mapping. Hence, the ZONE_MOVABLE which is considered as highmem type zone could have the both types of pages, direct mapped and not. Since the ZONE_MOVABLE could have both type of pages, __GFP_HIGHMEM is still required to allocate the memory from it. And, we conservatively need to consider the ZONE_MOVABLE as highmem type zone. Even in this situation, PageHighMem() for the pages on the ZONE_MOVABLE when it is called for checking the direct mapping should return correct result. Current implementation of PageHighMem() just returns TRUE if the zone of the page is on a highmem type zone. So, it could be wrong if the page on the MOVABLE_ZONE is actually direct mapped. To solve this potential problem, this patch introduces a new PageHighMemZone() macro. In following patches, two use cases of PageHighMem() are separated by calling proper macro, PageHighMem() and PageHighMemZone(). Then, implementation of PageHighMem() will be changed as just checking if the direct mapping exists or not, regardless of the zone of the page. Note that there are some rules to determine the proper macro. 1. If PageHighMem() is called for checking if the direct mapping exists or not, use PageHighMem(). 2. If PageHighMem() is used to predict the previous gfp_flags for this page, use PageHighMemZone(). The zone of the page is related to the gfp_flags. 3. If purpose of calling PageHighMem() is to count highmem page and to interact with the system by using this count, use PageHighMemZone(). This counter is usually used to calculate the available memory for an kernel allocation and pages on the highmem zone cannot be available for an kernel allocation. 4. Otherwise, use PageHighMemZone(). It's safe since it's implementation is just copy of the previous PageHighMem() implementation and won't be changed. My final plan is to change the name, PageHighMem() to PageNoDirectMapped() or something else in order to represent proper meaning. This patchset is based on next-20200428 and you can find the full patchset on the following link. https://github.com/JoonsooKim/linux/tree/page_highmem-cleanup-v2.00-next-20200428 Thanks. [1]: https://lore.kernel.org/linux-mm/1512114786-5085-1-git-send-email-iamjoonsoo@lge.com Joonsoo Kim (10): mm/page-flags: introduce PageHighMemZone() drm/ttm: separate PageHighMem() and PageHighMemZone() use case kexec: separate PageHighMem() and PageHighMemZone() use case power: separate PageHighMem() and PageHighMemZone() use case mm/gup: separate PageHighMem() and PageHighMemZone() use case mm/hugetlb: separate PageHighMem() and PageHighMemZone() use case mm: separate PageHighMem() and PageHighMemZone() use case mm/page_alloc: correct the use of is_highmem_idx() mm/migrate: replace PageHighMem() with open-code mm/page-flags: change the implementation of the PageHighMem() drivers/gpu/drm/ttm/ttm_memory.c | 4 ++-- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 +- drivers/gpu/drm/ttm/ttm_tt.c | 2 +- include/linux/migrate.h | 4 +++- include/linux/page-flags.h | 10 +- kernel/kexec_core.c | 2 +- kernel/power/snapshot.c | 12 ++-- mm/gup.c | 2 +- mm/hugetlb.c | 2 +- mm/memory_hotplug.c | 2 +- mm/page_alloc.c
[PATCH v2 01/10] mm/page-flags: introduce PageHighMemZone()
From: Joonsoo Kim PageHighMem() is used for two different cases. One is to check if there is a direct mapping for this page or not. The other is to check the zone of this page, that is, weather it is the highmem type zone or not. Until now, both the cases are the perfectly same thing. So, implementation of the PageHighMem() uses the one case that checks if the zone of the page is the highmem type zone or not. "#define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))" ZONE_MOVABLE is special. It is considered as normal type zone on !CONFIG_HIGHMEM, but, it is considered as highmem type zone on CONFIG_HIGHMEM. Let's focus on later case. In later case, all pages on the ZONE_MOVABLE has no direct mapping until now. However, following patchset "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE" , which is once merged and reverted, will be tried again and will break this assumption that all pages on the ZONE_MOVABLE has no direct mapping. Hence, the ZONE_MOVABLE which is considered as highmem type zone could have the both types of pages, direct mapped and not. Since the ZONE_MOVABLE could have both type of pages, __GFP_HIGHMEM is still required to allocate the memory from it. And, we conservatively need to consider the ZONE_MOVABLE as highmem type zone. Even in this situation, PageHighMem() for the pages on the ZONE_MOVABLE when it is called for checking the direct mapping should return correct result. Current implementation of PageHighMem() just returns TRUE if the zone of the page is on a highmem type zone. So, it could be wrong if the page on the MOVABLE_ZONE is actually direct mapped. To solve this potential problem, this patch introduces a new PageHighMemZone() macro. In following patches, two use cases of PageHighMem() are separated by calling proper macro, PageHighMem() and PageHighMemZone(). Then, implementation of PageHighMem() will be changed as just checking if the direct mapping exists or not, regardless of the zone of the page. Note that there are some rules to determine the proper macro. 1. If PageHighMem() is called for checking if the direct mapping exists or not, use PageHighMem(). 2. If PageHighMem() is used to predict the previous gfp_flags for this page, use PageHighMemZone(). The zone of the page is related to the gfp_flags. 3. If purpose of calling PageHighMem() is to count highmem page and to interact with the system by using this count, use PageHighMemZone(). This counter is usually used to calculate the available memory for an kernel allocation and pages on the highmem zone cannot be available for an kernel allocation. 4. Otherwise, use PageHighMemZone(). It's safe since it's implementation is just copy of the previous PageHighMem() implementation and won't be changed. My final plan is to change the name, PageHighMem() to PageNoDirectMapped() or something else in order to represent proper meaning. Acked-by: Roman Gushchin Signed-off-by: Joonsoo Kim --- include/linux/page-flags.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 222f6f7..fca0cce 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -378,10 +378,16 @@ PAGEFLAG(Readahead, reclaim, PF_NO_COMPOUND) /* * Must use a macro here due to header dependency issues. page_zone() is not * available at this point. + * PageHighMem() is for checking if the direct mapping exists or not. + * PageHighMemZone() is for checking the zone, where the page is belong to, + * in order to predict previous gfp_flags or to count something for system + * memory management. */ #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p)) +#define PageHighMemZone(__p) is_highmem_idx(page_zonenum(__p)) #else PAGEFLAG_FALSE(HighMem) +PAGEFLAG_FALSE(HighMemZone) #endif #ifdef CONFIG_SWAP -- 2.7.4
Re: [PATCH -next] hinic: Use ARRAY_SIZE for nic_vf_cmd_msg_handler
On Wed, 2020-04-29 at 11:15 +0800, Zou Wei wrote:
> fix coccinelle warning, use ARRAY_SIZE
>
> drivers/net/ethernet/huawei/hinic/hinic_sriov.c:713:43-44: WARNING: Use
> ARRAY_SIZE
>
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
> b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
> index b24788e..ac12725 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
> @@ -710,8 +710,7 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
> void *buf_in,
> if (!hwdev)
> return -EFAULT;
>
> - cmd_number = sizeof(nic_vf_cmd_msg_handler) /
> - sizeof(struct vf_cmd_msg_handle);
> + cmd_number = ARRAY_SIZE(nic_vf_cmd_msg_handler);
> pfhwdev = container_of(dev, struct hinic_pfhwdev, hwdev);
> nic_io = >func_to_io;
> for (i = 0; i < cmd_number; i++) {
Probably better to remove cmd_number altogether
---
drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
index b24788..af70cc 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
@@ -704,17 +704,15 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
struct hinic_hwdev *dev = hwdev;
struct hinic_func_to_io *nic_io;
struct hinic_pfhwdev *pfhwdev;
- u32 i, cmd_number;
+ u32 i;
int err = 0;
if (!hwdev)
return -EFAULT;
- cmd_number = sizeof(nic_vf_cmd_msg_handler) /
- sizeof(struct vf_cmd_msg_handle);
pfhwdev = container_of(dev, struct hinic_pfhwdev, hwdev);
nic_io = >func_to_io;
- for (i = 0; i < cmd_number; i++) {
+ for (i = 0; i < ARRAY_SIZE(nic_vf_cmd_msg_handler); i++) {
vf_msg_handle = _vf_cmd_msg_handler[i];
if (cmd == vf_msg_handle->cmd &&
vf_msg_handle->cmd_msg_handler) {
@@ -725,7 +723,7 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
break;
}
}
- if (i == cmd_number)
+ if (i == ARRAY_SIZE(nic_vf_cmd_msg_handler))
err = hinic_msg_to_mgmt(>pf_to_mgmt, HINIC_MOD_L2NIC,
cmd, buf_in, in_size, buf_out,
out_size, HINIC_MGMT_MSG_SYNC);
Re: [PATCH v5 3/5] drivers/soc/litex: add LiteX SoC Controller driver
On Mon, 2020-04-27 at 11:13 +0200, Mateusz Holenko wrote: > As Gabriel Somlo suggested to me, I could still use > readl/writel/ioread/iowrite() standard functions providing memory > barriers *and* have values in CPU native endianness by using the > following constructs: > > `le32_to_cpu(readl(addr))` > > and > > `writel(cpu_to_le32(value), addr)` > > as le32_to_cpu/cpu_to_le32(): > - does nothing on LE CPUs and > - reorders bytes on BE CPUs which in turn reverts swapping made by > readl() resulting in returning the original value. It's a bit sad... I don't understand why you need this. The HW has a fied endian has you have mentioned earlier (and that is a good design). The fact that you are trying to shove things into a "smaller pipe" than the actual register shouldn't affect at what address the MSB and LSB reside. And readl/writel (or ioread32/iowrite32) will always be LE as well, so will match the HW layout. Thus I don't see why you need to play swapping games here. This however would be avoided completely if the HW was a tiny bit smarter and would do the multi-beat access for you which shouldn't be terribly hard to implement. That said, it would be even clearer if you just open coded the 2 or 3 useful cases: 32/8, 32/16 and 32/32. The loop with calculated shifts (and no masks) makes the code hard to understand. Cheers, Ben.
[PATCH] clk/meson: fixes memleak issue in init err branch
In common init function, when run into err branch, we didn`t
use kfree to release kzmalloc area, this may bring in memleak
Signed-off-by: Bernard Zhao
---
drivers/clk/meson/meson8b.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 34a70c4b4899..0f07d5a4cd16 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -3687,6 +3687,7 @@ static void __init meson8b_clkc_init_common(struct
device_node *np,
if (ret) {
pr_err("%s: Failed to register clkc reset controller: %d\n",
__func__, ret);
+ kfree(rstc);
return;
}
@@ -3710,8 +3711,10 @@ static void __init meson8b_clkc_init_common(struct
device_node *np,
continue;
ret = of_clk_hw_register(np, clk_hw_onecell_data->hws[i]);
- if (ret)
+ if (ret) {
+ kfree(rstc);
return;
+ }
}
meson8b_cpu_nb_data.cpu_clk = clk_hw_onecell_data->hws[CLKID_CPUCLK];
@@ -3727,13 +3730,16 @@ static void __init meson8b_clkc_init_common(struct
device_node *np,
if (ret) {
pr_err("%s: failed to register the CPU clock notifier\n",
__func__);
+ kfree(rstc);
return;
}
ret = of_clk_add_hw_provider(np, of_clk_hw_onecell_get,
clk_hw_onecell_data);
- if (ret)
+ if (ret) {
pr_err("%s: failed to register clock provider\n", __func__);
+ kfree(rstc);
+ }
}
static void __init meson8_clkc_init(struct device_node *np)
--
2.26.2
Re: [PATCH v5 3/5] drivers/soc/litex: add LiteX SoC Controller driver
On Sat, 2020-04-25 at 13:42 +0200, Mateusz Holenko wrote:
> From: Pawel Czarnecki
>
> This commit adds driver for the FPGA-based LiteX SoC
> Controller from LiteX SoC builder.
Sorry for jumping in late, Joel only just pointed me to this :)
> + * The purpose of `litex_set_reg`/`litex_get_reg` is to implement
> + * the logic of writing to/reading from the LiteX CSR in a single
> + * place that can be then reused by all LiteX drivers.
> + */
> +void litex_set_reg(void __iomem *reg, unsigned long reg_size,
> + unsigned long val)
> +{
> + unsigned long shifted_data, shift, i;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_lock, flags);
> +
> + for (i = 0; i < reg_size; ++i) {
> + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
> + shifted_data = val >> shift;
> +
> + __raw_writel(shifted_data, reg + (LITEX_REG_SIZE * i));
> + }
> +
> + spin_unlock_irqrestore(_lock, flags);
> +}
> +
> +unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_size)
> +{
> + unsigned long shifted_data, shift, i;
> + unsigned long result = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_lock, flags);
> +
> + for (i = 0; i < reg_size; ++i) {
> + shifted_data = __raw_readl(reg + (LITEX_REG_SIZE * i));
> +
> + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
> + result |= (shifted_data << shift);
> + }
> +
> + spin_unlock_irqrestore(_lock, flags);
> +
> + return result;
> +}
I really don't like the fact that the register sizes & sub sizes are
#defined. As your comment explains, this makes it harder to support
other configurations. This geometry should come from the device-tree
instead.
Also this while thing is rather gross (and the lock will not help
performance). Why can't CSRs be normally memory mapped always instead ?
Even when transporting them on a HW bus that's smaller, the HW bus
conversion should be able to do the break-down into a multi-breat
transfer rather than doing that in SW.
Or at least have a fast-path if the register size is no larger than the
sub size, so you can use a normal ioread32/iowrite32.
Also I wonder ... last I played with LiteX, it would re-generate the
register layout (including the bit layout inside registers potentially)
rather enthousiastically, making it pretty hard to have a fixed
register layout for use by a kernel driver. Was this addressed ?
Cheers,
Ben.
Re: [PATCH] HID: mcp2221: add gpiolib dependency
Thanks Arnd, How about one liner:
depends on USB_HID && I2C && GPIOLIB
Reviewed-by: Rishi Gupta
On Wed, Apr 29, 2020 at 3:00 AM Arnd Bergmann wrote:
>
> Without gpiolib, this driver fails to link:
>
> arm-linux-gnueabi-ld: drivers/hid/hid-mcp2221.o: in function `mcp2221_probe':
> hid-mcp2221.c:(.text+0x1b0): undefined reference to `devm_gpiochip_add_data'
> arm-linux-gnueabi-ld: drivers/hid/hid-mcp2221.o: in function `mcp_gpio_get':
> hid-mcp2221.c:(.text+0x30c): undefined reference to `gpiochip_get_data'
>
> Fixes: 328de1c519c5 ("HID: mcp2221: add GPIO functionality support")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/hid/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 008bf44bc2c3..d54e7ae80de5 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1155,6 +1155,7 @@ config HID_ALPS
> config HID_MCP2221
> tristate "Microchip MCP2221 HID USB-to-I2C/SMbus host support"
> depends on USB_HID && I2C
> + depends on GPIOLIB
> ---help---
> Provides I2C and SMBUS host adapter functionality over USB-HID
> through MCP2221 device.
> --
> 2.26.0
>
[PATCH -next] hinic: Use ARRAY_SIZE for nic_vf_cmd_msg_handler
fix coccinelle warning, use ARRAY_SIZE
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:713:43-44: WARNING: Use
ARRAY_SIZE
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
index b24788e..ac12725 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_sriov.c
@@ -710,8 +710,7 @@ int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd,
void *buf_in,
if (!hwdev)
return -EFAULT;
- cmd_number = sizeof(nic_vf_cmd_msg_handler) /
- sizeof(struct vf_cmd_msg_handle);
+ cmd_number = ARRAY_SIZE(nic_vf_cmd_msg_handler);
pfhwdev = container_of(dev, struct hinic_pfhwdev, hwdev);
nic_io = >func_to_io;
for (i = 0; i < cmd_number; i++) {
--
2.6.2
Re: general protection fault in tcf_action_destroy (2)
syzbot suspects this bug was fixed by commit: commit 0d1c3530e1bd38382edef72591b78e877e0edcd3 Author: Cong Wang Date: Thu Mar 12 05:42:28 2020 + net_sched: keep alloc_hash updated after hash allocation bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e7415410 start commit: 67d584e3 Merge tag 'for-5.6-rc6-tag' of git://git.kernel.o.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=9f894bd92023de02 dashboard link: https://syzkaller.appspot.com/bug?extid=92a80fff3b3af6c4464e syz repro: https://syzkaller.appspot.com/x/repro.syz?x=160c3223e0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14f790ade0 If the result looks correct, please mark the bug fixed by replying with: #syz fix: net_sched: keep alloc_hash updated after hash allocation For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH] drm/i915/gt: Avoid uninitialized use of rpcurupei in frequency_show
When building with clang + -Wuninitialized:
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c:407:7: warning: variable
'rpcurupei' is uninitialized when used here [-Wuninitialized]
rpcurupei,
^
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c:304:16: note: initialize the
variable 'rpcurupei' to silence this warning
u32 rpcurupei, rpcurup, rpprevup;
^
= 0
1 warning generated.
rpupei is assigned twice; based on the second argument to
intel_uncore_read, it seems this one should have been assigned to
rpcurupei.
Fixes: 9c878557b1eb ("drm/i915/gt: Use the RPM config register to determine clk
frequencies")
Link: https://github.com/ClangBuiltLinux/linux/issues/1016
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 3d3ef62ed89f..f6ba66206273 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -336,7 +336,7 @@ static int frequency_show(struct seq_file *m, void *unused)
rpdeclimit = intel_uncore_read(uncore, GEN6_RP_DOWN_THRESHOLD);
rpstat = intel_uncore_read(uncore, GEN6_RPSTAT1);
- rpupei = intel_uncore_read(uncore, GEN6_RP_CUR_UP_EI) &
GEN6_CURICONT_MASK;
+ rpcurupei = intel_uncore_read(uncore, GEN6_RP_CUR_UP_EI) &
GEN6_CURICONT_MASK;
rpcurup = intel_uncore_read(uncore, GEN6_RP_CUR_UP) &
GEN6_CURBSYTAVG_MASK;
rpprevup = intel_uncore_read(uncore, GEN6_RP_PREV_UP) &
GEN6_CURBSYTAVG_MASK;
rpcurdownei = intel_uncore_read(uncore, GEN6_RP_CUR_DOWN_EI) &
GEN6_CURIAVG_MASK;
base-commit: 0fd02a5d3eb7020a7e1801f8d7f01891071c85e4
--
2.26.2
Re: linux-next: build warning after merge of the scsi-fixes tree
Tyrel, > Do you want me to resend, or can you fixup your tree? I fixed it up. -- Martin K. Petersen Oracle Linux Engineering
[PATCH V3] thermal: imx: Add missing of_node_put()
After finishing using cpu node got from of_get_cpu_node(), of_node_put()
needs to be called, the cpufreq policy also needs to be put unconditionally.
Signed-off-by: Anson Huang
---
Changes since V2:
- call cpufreq_cpu_put() unconditionally after cooling register done.
---
drivers/thermal/imx_thermal.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index e761c9b..8764cb5 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -649,7 +649,7 @@ MODULE_DEVICE_TABLE(of, of_imx_thermal_match);
static int imx_thermal_register_legacy_cooling(struct imx_thermal_data *data)
{
struct device_node *np;
- int ret;
+ int ret = 0;
data->policy = cpufreq_cpu_get(0);
if (!data->policy) {
@@ -661,20 +661,19 @@ static int imx_thermal_register_legacy_cooling(struct
imx_thermal_data *data)
if (!np || !of_find_property(np, "#cooling-cells", NULL)) {
data->cdev = cpufreq_cooling_register(data->policy);
- if (IS_ERR(data->cdev)) {
+ if (IS_ERR(data->cdev))
ret = PTR_ERR(data->cdev);
- cpufreq_cpu_put(data->policy);
- return ret;
- }
}
- return 0;
+ cpufreq_cpu_put(data->policy);
+ of_node_put(np);
+
+ return ret;
}
static void imx_thermal_unregister_legacy_cooling(struct imx_thermal_data
*data)
{
cpufreq_cooling_unregister(data->cdev);
- cpufreq_cpu_put(data->policy);
}
#else
--
2.7.4
Re: [PATCH 1/2] arm64: dts: imx8qxp-mek: Sort labels alphabetically
On Fri, Apr 17, 2020 at 01:39:05PM +0800, Anson Huang wrote: > Sort the labels alphabetically for consistency. > > Signed-off-by: Anson Huang Applied both, thanks.
Re: [PATCH v2 4/4] mm/slub: Fix sysfs shrink circular locking dependency
> On Apr 28, 2020, at 10:06 AM, Waiman Long wrote:
>
> On 4/27/20 10:11 PM, Qian Cai wrote:
>>
>>> On Apr 27, 2020, at 9:39 PM, Waiman Long wrote:
>>>
>>> The sequence that was prevented by this patch is "kn->count -->
>>> mem_hotplug_lock.rwsem". This sequence isn't directly in the splat. Once
>>> this link is broken, the 3-lock circular loop cannot be formed. Maybe I
>>> should modify the commit log to make this point more clear.
>> I don’t know what you are talking about. Once trylock succeed once, you will
>> have kn->count —> cpu/memory_hotplug_lock.
>>
> Trylock is handled differently from lockdep's perspective as trylock can
> failed. When trylock succeeds, the critical section is executed. As long as
> it doesn't try to acquire another lock in the circular chain, the execution
> will finish at some point and release the lock. On the other hand, if another
> task has already held all those locks, the trylock will fail and held locks
> should be released. Again, no deadlock will happen.
So once,
CPU0 (trylock succeed):
kn->count —> cpu/memory_hotplug_lock.
Did you mean that lockdep will not record this existing chain?
If it did. Then later, are you still sure that CPU1 (via memcg path below) will
still be impossible to trigger a splat just because lockdep will be able to
tell that those arennon-exclusive (cpu/memory_hotplug_lock) locks instead?
cpu/memory_hotplug_lock -> kn->count
[ 290.805818] -> #3 (kn->count#86){}-{0:0}:
[ 290.811954]__kernfs_remove+0x455/0x4c0
[ 290.816428]kernfs_remove+0x23/0x40
[ 290.820554]sysfs_remove_dir+0x74/0x80
[ 290.824947]kobject_del+0x57/0xa0
[ 290.828905]sysfs_slab_unlink+0x1c/0x20
[ 290.833377]shutdown_cache+0x15d/0x1c0
[ 290.837964]kmemcg_cache_shutdown_fn+0xe/0x20
[ 290.842963]kmemcg_workfn+0x35/0x50 <—— cpu/memory_hotplug_lock
[ 290.847095]process_one_work+0x57e/0xb90
[ 290.851658]worker_thread+0x63/0x5b0
[ 290.855872]kthread+0x1f7/0x220
[ 290.859653]ret_from_fork+0x27/0x50
Re: [PATCH] arm64: dts: imx8mm: specify #sound-dai-cells for SAI nodes
On Wed, Apr 15, 2020 at 02:59:41PM -0400, Matt Porter wrote: > Add #sound-dai-cells properties to SAI nodes. > > Signed-off-by: Matt Porter Applied, thanks.
Re: [PATCH] epoll: Fix UAF dentry name access in wakeup source setup
On Wed, Apr 29, 2020 at 04:31:04AM +0200, Jann Horn wrote:
> I'm guessing this will go through akpm's tree?
>
> fs/eventpoll.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index 8c596641a72b0..5052a41670479 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -1450,7 +1450,7 @@ static int reverse_path_check(void)
>
> static int ep_create_wakeup_source(struct epitem *epi)
> {
> - const char *name;
> + struct name_snapshot name;
> struct wakeup_source *ws;
>
> if (!epi->ep->ws) {
> @@ -1459,8 +1459,9 @@ static int ep_create_wakeup_source(struct epitem *epi)
> return -ENOMEM;
> }
>
> - name = epi->ffd.file->f_path.dentry->d_name.name;
> - ws = wakeup_source_register(NULL, name);
> + take_dentry_name_snapshot(, epi->ffd.file->f_path.dentry);
> + ws = wakeup_source_register(NULL, name.name.name);
> + release_dentry_name_snapshot();
I'm not sure I like it. Sure, it won't get freed under you that way; it still
can go absolutely stale by the time you return from wakeup_source_register().
What is it being used for?
[PATCH v2] soc: imx8m: Make imx8m_dsp_ops static
Fix the following warning:
sound/soc/sof/imx/imx8m.c:95:20: warning:
symbol 'imx8m_dsp_ops' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: ChenTao
Acked-by: Kai Vehmanen
Reviewed-by: Daniel Baluta
---
v1->v2:
- add recipient broo...@kernel.org alsa-de...@alsa-project.org
sound/soc/sof/imx/imx8m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/imx/imx8m.c b/sound/soc/sof/imx/imx8m.c
index 07451ba4efae..1a5b0f9ebac1 100644
--- a/sound/soc/sof/imx/imx8m.c
+++ b/sound/soc/sof/imx/imx8m.c
@@ -92,7 +92,7 @@ static void imx8m_dsp_handle_request(struct imx_dsp_ipc *ipc)
snd_sof_ipc_msgs_rx(priv->sdev);
}
-struct imx_dsp_ops imx8m_dsp_ops = {
+static struct imx_dsp_ops imx8m_dsp_ops = {
.handle_reply = imx8m_dsp_handle_reply,
.handle_request = imx8m_dsp_handle_request,
};
--
2.22.0
Re: [PATCH 02/16] Revert "objtool: Skip samples subdirectory"
On Sat, Apr 25, 2020 at 5:32 AM Josh Poimboeuf wrote: > > On Thu, Apr 23, 2020 at 04:39:15PM +0900, Masahiro Yamada wrote: > > This reverts commit 8728497895794d1f207a836e02dae762ad175d56. > > > > This directory contains no object. > > > > Cc: Josh Poimboeuf > > Signed-off-by: Masahiro Yamada > > --- > > > > samples/Makefile | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/samples/Makefile b/samples/Makefile > > index f8f847b4f61f..5ce50ef0f2b2 100644 > > --- a/samples/Makefile > > +++ b/samples/Makefile > > @@ -1,6 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > # Makefile for Linux samples code > > -OBJECT_FILES_NON_STANDARD := y > > > > obj-$(CONFIG_SAMPLE_ANDROID_BINDERFS)+= binderfs/ > > obj-$(CONFIG_SAMPLE_CONFIGFS)+= configfs/ > > -- > > 2.25.1 > > Hm, somehow I was thinking this would work recursively for > subdirectories. Anyway, you're right: > > Acked-by: Josh Poimboeuf > > -- > Josh > Applied to linux-kbuild. -- Best Regards Masahiro Yamada
[PATCH] epoll: Move helper functions from UAPI header into eventpoll.c
ep_take_care_of_epollwakeup() is a kernel-internal function (it calls
capable()) and therefore does not belong in a UAPI header.
Since nothing outside fs/eventpoll.c uses it, move it over there.
Signed-off-by: Jann Horn
---
fs/eventpoll.c | 13 +
include/uapi/linux/eventpoll.h | 12
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 8c596641a72b0..7365ccba90973 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -2102,6 +2102,19 @@ static inline int epoll_mutex_lock(struct mutex *mutex,
int depth,
return -EAGAIN;
}
+#ifdef CONFIG_PM_SLEEP
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ if ((epev->events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
+ epev->events &= ~EPOLLWAKEUP;
+}
+#else
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ epev->events &= ~EPOLLWAKEUP;
+}
+#endif
+
int do_epoll_ctl(int epfd, int op, int fd, struct epoll_event *epds,
bool nonblock)
{
diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
index 8a3432d0f0dcb..39dfc29f0f529 100644
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -79,16 +79,4 @@ struct epoll_event {
__u64 data;
} EPOLL_PACKED;
-#ifdef CONFIG_PM_SLEEP
-static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
-{
- if ((epev->events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
- epev->events &= ~EPOLLWAKEUP;
-}
-#else
-static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
-{
- epev->events &= ~EPOLLWAKEUP;
-}
-#endif
#endif /* _UAPI_LINUX_EVENTPOLL_H */
base-commit: 96c9a7802af7d500a582d89a8b864584fe878c1b
--
2.26.2.303.gf8c07b1a785-goog
Re: [PATCH 00/16] kbuild: support 'userprogs' syntax
Hi Sam, On Sat, Apr 25, 2020 at 8:53 PM Sam Ravnborg wrote: > > Hi Masahiro > > On Thu, Apr 23, 2020 at 04:39:13PM +0900, Masahiro Yamada wrote: > > > > Several Makefiles use 'hostprogs' for building the code for > > the host architecture is not appropriate. > > > > This is just because Kbuild does not provide the syntax to do it. > > > > This series introduce 'userprogs' syntax and use it from > > sample and bpf Makefiles. > > > > Sam worked on this in 2014. > > https://lkml.org/lkml/2014/7/13/154 > > I wonder how you managed to dig that up, but thanks for the reference. I just remembered your work back in 2014. I did not remember the patch title exactly, but I searched for 'From: Sam Ravnborg' and 'To: linux-kbu...@vger.kernel.org' in my mail box. -- Best Regards Masahiro Yamada
Re: [PATCH 2/2] gpio: Make "offset" and "unsigned int", not just "unsigned"
On Tue, 2020-04-28 at 18:04 -0700, Doug Anderson wrote: > Hi, > On Tue, Apr 28, 2020 at 5:57 PM Joe Perches wrote: > > On Tue, 2020-04-28 at 17:50 -0700, Doug Anderson wrote: > > > $ git grep -P -n '\bunsigned\s+(?!int|long)' include/linux/gpio/driver.h > > include/linux/gpio/driver.h:352: > > unsigned offset); > > include/linux/gpio/driver.h:354: > > unsigned offset); > > include/linux/gpio/driver.h:356: > > unsigned offset); > > include/linux/gpio/driver.h:358: > > unsigned offset); > > include/linux/gpio/driver.h:360: > > unsigned offset, int value); > > include/linux/gpio/driver.h:362: > > unsigned offset); > > include/linux/gpio/driver.h:367: > > unsigned offset, int value); > > include/linux/gpio/driver.h:372: > > unsigned offset, > > include/linux/gpio/driver.h:375: > > unsigned offset); > > include/linux/gpio/driver.h:462:unsigned offset); > > include/linux/gpio/driver.h:660:int gpiochip_generic_request(struct > > gpio_chip *gc, unsigned offset); > > include/linux/gpio/driver.h:661:void gpiochip_generic_free(struct gpio_chip > > *gc, unsigned offset); > > include/linux/gpio/driver.h:662:int gpiochip_generic_config(struct > > gpio_chip *gc, unsigned offset, > > ...riggght. ...and now I run your sed script _after_ my patch > and I get no hits. ...so I'm still confused about what you want me to > do that's not already done in my patch. So you did say it's the g It seems I only looked at the first diff block. cheers, , Joe
Re: [PATCH V1 2/4] ARM: imx: cpu: drop dead code
On Thu, Mar 12, 2020 at 05:17:23PM +0800, peng@nxp.com wrote:
> From: Peng Fan
>
> imx_soc_device_init is only called by i.MX6Q/SL/SX/UL/7D/7ULP.
> So we could drop the switch case for i.MX1/2/3/5 which are dead code
> that never be executed.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/mach-imx/cpu.c | 24
> 1 file changed, 24 deletions(-)
>
> diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
> index 2df649a84697..0302cb66134b 100644
> --- a/arch/arm/mach-imx/cpu.c
> +++ b/arch/arm/mach-imx/cpu.c
> @@ -108,30 +108,6 @@ static int __init imx_soc_device_init(void)
> goto free_soc;
>
> switch (__mxc_cpu_type) {
> - case MXC_CPU_MX1:
> - soc_id = "i.MX1";
> - break;
> - case MXC_CPU_MX21:
> - soc_id = "i.MX21";
> - break;
> - case MXC_CPU_MX25:
> - soc_id = "i.MX25";
> - break;
> - case MXC_CPU_MX27:
> - soc_id = "i.MX27";
> - break;
> - case MXC_CPU_MX31:
> - soc_id = "i.MX31";
> - break;
> - case MXC_CPU_MX35:
> - soc_id = "i.MX35";
> - break;
> - case MXC_CPU_MX51:
> - soc_id = "i.MX51";
> - break;
> - case MXC_CPU_MX53:
> - soc_id = "i.MX53";
> - break;
The code is here to completeness. If it doesn't get in your way, let's
just keep it.
Shawn
> case MXC_CPU_IMX6SL:
> ocotp_compat = "fsl,imx6sl-ocotp";
> soc_id = "i.MX6SL";
> --
> 2.16.4
>
[PATCH] epoll: Fix UAF dentry name access in wakeup source setup
In ep_create_wakeup_source(), epi->ffd.file is some random file we're
watching with epoll, so it might well be renamed concurrently. And when a
file gets renamed, the buffer containing its name may be freed.
This can be reproduced by racing a task that keeps adding and removing
EPOLLWAKEUP epoll entries for a fifo with another task that keeps renaming
the fifo between two long names if you add an mdelay(200) call directly
before wakeup_source_register(); KASAN then complains:
BUG: KASAN: use-after-free in strlen+0xa/0x40
Read of size 1 at addr 888065fda990 by task wakemeup/2375
[...]
Call Trace:
[...]
strlen+0xa/0x40
kstrdup+0x1a/0x60
wakeup_source_create+0x43/0xb0
wakeup_source_register+0x13/0x60
ep_create_wakeup_source+0x7f/0xf0
do_epoll_ctl+0x13d0/0x1880
[...]
__x64_sys_epoll_ctl+0xc3/0x110
[...]
Allocated by task 2376:
[...]
__d_alloc+0x323/0x3c0
d_alloc+0x30/0xf0
__lookup_hash+0x61/0xc0
do_renameat2+0x3fa/0x6d0
__x64_sys_rename+0x3a/0x40
[...]
Freed by task 2379:
[...]
kfree_rcu_work+0x9b/0x5d0
[...]
Backporting note: This patch depends on commit 49d31c2f389a ("dentry name
snapshots"). Maybe that one should also be backported as a dependency for
pre-v4.13? (Sorry, I wasn't sure how to properly express this as a "Fixes:"
tag.)
Cc: sta...@vger.kernel.org
Fixes: 4d7e30d98939 ("epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while
epoll events are ready")
Signed-off-by: Jann Horn
---
I'm guessing this will go through akpm's tree?
fs/eventpoll.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 8c596641a72b0..5052a41670479 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1450,7 +1450,7 @@ static int reverse_path_check(void)
static int ep_create_wakeup_source(struct epitem *epi)
{
- const char *name;
+ struct name_snapshot name;
struct wakeup_source *ws;
if (!epi->ep->ws) {
@@ -1459,8 +1459,9 @@ static int ep_create_wakeup_source(struct epitem *epi)
return -ENOMEM;
}
- name = epi->ffd.file->f_path.dentry->d_name.name;
- ws = wakeup_source_register(NULL, name);
+ take_dentry_name_snapshot(, epi->ffd.file->f_path.dentry);
+ ws = wakeup_source_register(NULL, name.name.name);
+ release_dentry_name_snapshot();
if (!ws)
return -ENOMEM;
base-commit: 96c9a7802af7d500a582d89a8b864584fe878c1b
--
2.26.2.303.gf8c07b1a785-goog
