Re: [PATCH v2 11/14] PCI/P2PDMA: Store mapping method in an xarray
On Tue, Jul 30, 2019 at 10:35:42AM -0600, Logan Gunthorpe wrote:
> When upstream_bridge_distance() is called store the method required
> to map the DMA transfers in an xarray so that it can be looked up
> efficiently on the hot path in pci_p2pdma_map_sg().
>
> Signed-off-by: Logan Gunthorpe
> ---
> drivers/pci/p2pdma.c | 40 +++-
> 1 file changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index fe647bd8f947..010aa8742bec 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -19,10 +19,19 @@
> #include
> #include
> #include
> +#include
> +
> +enum pci_p2pdma_map_type {
> + PCI_P2PDMA_MAP_UNKNOWN = 0,
> + PCI_P2PDMA_MAP_NOT_SUPPORTED,
> + PCI_P2PDMA_MAP_BUS_ADDR,
> + PCI_P2PDMA_MAP_THRU_IOMMU,
> +};
So here we add a new enum for the map type, but for the internal code
the previousloading of the distance is kept, which seems a little
strange.
> + if (!(dist & P2PDMA_THRU_HOST_BRIDGE)) {
> + map_type = PCI_P2PDMA_MAP_BUS_ADDR;
> + goto store_map_type_and_return;
> + }
> +
> + if (host_bridge_whitelist(provider, client)) {
> + map_type = PCI_P2PDMA_MAP_THRU_IOMMU;
> + } else {
> + dist |= P2PDMA_NOT_SUPPORTED;
> + map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
> + }
>
> +store_map_type_and_return:
Why not:
if (dist & P2PDMA_THRU_HOST_BRIDGE) {
if (host_bridge_whitelist(provider, client)) {
map_type = PCI_P2PDMA_MAP_THRU_IOMMU;
} else {
dist |= P2PDMA_NOT_SUPPORTED;
map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
}
}
Re: [PATCH v8 13/14] KVM/x86/vPMU: check the lbr feature before entering guest
On 08/06/2019 03:16 PM, Wei Wang wrote:
The guest can access the lbr related msrs only when the vcpu's lbr event
has been assigned the lbr feature. A cpu pinned lbr event (though no such
event usages in the current upstream kernel) could reclaim the lbr feature
from the vcpu's lbr event (task pinned) via ipi calls. If the cpu is
running in the non-root mode, this will cause the cpu to vm-exit to handle
the host ipi and then vm-entry back to the guest. So on vm-entry (where
interrupt has been disabled), we double confirm that the vcpu's lbr event
is still assigned the lbr feature via checking event->oncpu.
The pass-through of the lbr related msrs will be cancelled if the lbr is
reclaimed, and the following guest accesses to the lbr related msrs will
vm-exit to the related msr emulation handler in kvm, which will prevent
the accesses.
Signed-off-by: Wei Wang
---
arch/x86/kvm/pmu.c | 6 ++
arch/x86/kvm/pmu.h | 3 +++
arch/x86/kvm/vmx/pmu_intel.c | 35 +++
arch/x86/kvm/x86.c | 13 +
4 files changed, 57 insertions(+)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index afad092..ed10a57 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -339,6 +339,12 @@ bool kvm_pmu_lbr_enable(struct kvm_vcpu *vcpu)
return false;
}
+void kvm_pmu_enabled_feature_confirm(struct kvm_vcpu *vcpu)
+{
+ if (kvm_x86_ops->pmu_ops->enabled_feature_confirm)
+ kvm_x86_ops->pmu_ops->enabled_feature_confirm(vcpu);
+}
+
void kvm_pmu_deliver_pmi(struct kvm_vcpu *vcpu)
{
if (lapic_in_kernel(vcpu))
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index f875721..7467907 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -30,6 +30,7 @@ struct kvm_pmu_ops {
int (*is_valid_msr_idx)(struct kvm_vcpu *vcpu, unsigned idx);
bool (*is_valid_msr)(struct kvm_vcpu *vcpu, u32 msr);
bool (*lbr_enable)(struct kvm_vcpu *vcpu);
+ void (*enabled_feature_confirm)(struct kvm_vcpu *vcpu);
int (*get_msr)(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
int (*set_msr)(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
void (*sched_in)(struct kvm_vcpu *vcpu, int cpu);
@@ -126,6 +127,8 @@ int kvm_vm_ioctl_set_pmu_event_filter(struct kvm *kvm, void
__user *argp);
bool is_vmware_backdoor_pmc(u32 pmc_idx);
+void kvm_pmu_enabled_feature_confirm(struct kvm_vcpu *vcpu);
+
extern struct kvm_pmu_ops intel_pmu_ops;
extern struct kvm_pmu_ops amd_pmu_ops;
#endif /* __KVM_X86_PMU_H */
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 5580f1a..421051aa 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -781,6 +781,40 @@ static void intel_pmu_reset(struct kvm_vcpu *vcpu)
intel_pmu_free_lbr_event(vcpu);
}
+void intel_pmu_lbr_confirm(struct kvm_vcpu *vcpu)
+{
+ struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
+
+ /*
+* Either lbr_event being NULL or lbr_used being false indicates that
+* the lbr msrs haven't been passed through to the guest, so no need
+* to cancel passthrough.
+*/
+ if (!pmu->lbr_event || !pmu->lbr_used)
+ return;
+
+ /*
+* The lbr feature gets reclaimed via IPI calls, so checking of
+* lbr_event->oncpu needs to be in an atomic context. Just confirm
+* that irq has been disabled already.
+*/
+ lockdep_assert_irqs_disabled();
+
+ /*
+* Cancel the pass-through of the lbr msrs if lbr has been reclaimed
+* by the host perf.
+*/
+ if (pmu->lbr_event->oncpu != -1) {
A mistake here, should be "pmu->lbr_event->oncpu == -1".
(It didn't seem to affect the profiling result, but generated
more vm-exits due to mistakenly cancelling the passthrough)
Best,
Wei
Re: [PATCH v2 03/14] PCI/P2PDMA: Add constants for not-supported result upstream_bridge_distance()
On Tue, Jul 30, 2019 at 10:35:34AM -0600, Logan Gunthorpe wrote: > Add constant flags to indicate two devices are not supported or whether > the data path goes through the host bridge instead of using the negative > values -1 and -2. > > This helps annotate the code better, but the main reason is so we > can use the information to store the required mapping method in an > xarray. > > Signed-off-by: Logan Gunthorpe > Reviewed-by: Christian König Is there really no way to keep the distance separate from the type of the connection as I requested? I think that would avoid a lot of confusion down the road.
Re: [PATCH v5 0/3] Merge m25p80 into spi-nor
On 08/06/2019 08:10 AM, Vignesh Raghavendra wrote:
> External E-Mail
>
>
> This is repost of patch 6 and 7 split from from Boris Brezillon's X-X-X
> mode support series[1]
>
> Background from cover letter for RFC[1]:
> m25p80 is just a simple SPI NOR controller driver (a wrapper around the
> SPI mem API). Not only it shouldn't be named after a specific SPI NOR
> chip, but it also doesn't deserve a specific driver IMO, especially if
> the end goal is to get rid of SPI NOR controller drivers found in
> drivers/mtd/spi-nor/ and replace them by SPI mem drivers (which would
> be placed in drivers/spi/). With this solution, we declare the SPI NOR
> driver as a spi_mem_driver, just like the SPI NAND layer is declared as
> a spi_mem driver (patch 1/2).
> This solution also allows us to check at a fined-grain level (thanks to
> the spi_mem_supports_op() function) which operations are supported and
> which ones are not, while the original m25p80 logic was basing this
> decision on the SPI_{RX,TX}_{DUAL,QUAD,OCTO} flags only (patch 2/2).
>
> [1] https://patchwork.ozlabs.org/cover/982926/
>
> Tested on TI' DRA7xx EVM with TI QSPI controller (a spi-mem driver) with
> DMA (s25fl256 and mx66l51235l) flash. I don't see any performance
> regression due to bounce buffer copy introduced by this series
> Also tested with cadence-quadspi (a spi-nor driver) driver
>
> Boris Brezillon (2):
> mtd: spi-nor: Move m25p80 code in spi-nor.c
> mtd: spi-nor: Rework hwcaps selection for the spi-mem case
>
> Vignesh Raghavendra (1):
> mtd: spi-nor: always use bounce buffer for register read/writes
>
> drivers/mtd/devices/Kconfig | 18 -
> drivers/mtd/devices/Makefile | 1 -
> drivers/mtd/devices/m25p80.c | 347 ---
> drivers/mtd/spi-nor/Kconfig | 2 +
> drivers/mtd/spi-nor/spi-nor.c | 814 +++---
> include/linux/mtd/spi-nor.h | 24 +-
> 6 files changed, 777 insertions(+), 429 deletions(-)
> delete mode 100644 drivers/mtd/devices/m25p80.c
>
The patches are looking good. I'll be out of office starting today and will
return on Monday. I'll let the 0day bot run its tests and then I will do some
tests on a flash or two. I intend to apply your patches on Monday.
Thanks, Vignesh!
ta
Re: [PATCH v5 3/3] mtd: spi-nor: Rework hwcaps selection for the spi-mem case
On 08/06/2019 08:10 AM, Vignesh Raghavendra wrote:
> +static int spi_nor_spimem_check_op(struct spi_nor *nor,
> +struct spi_mem_op *op)
> +{
> + /*
> + * First test with 4 address bytes. The opcode itself might
> + * be a 3B addressing opcode but we don't care, because
> + * SPI controller implementation should not check the opcode,
> + * but just the sequence.
> + */
> + op->addr.nbytes = 4;
> + if (!spi_mem_supports_op(nor->spimem, op)) {
> + /* If flash size <16MB, 3 address bytes are sufficient */
> + if (nor->mtd.size <= SZ_16M) {
> + op->addr.nbytes = 3;
> + if (!spi_mem_supports_op(nor->spimem, op))
> + return -ENOTSUPP;
> + return 0;
> + }
> + return -ENOTSUPP;
> + }
> +
> + return 0;
> +}
We can get rid of a level of indentation by writing it as:
static int spi_nor_spimem_check_op(struct spi_nor *nor,
struct spi_mem_op *op)
{
op->addr.nbytes = 4;
if (!spi_mem_supports_op(nor->spimem, op)) {
if (nor->mtd.size > SZ_16M)
return -ENOTSUPP;
/* If flash size <16MB, 3 address bytes are sufficient */
op->addr.nbytes = 3;
if (!spi_mem_supports_op(nor->spimem, op))
return -ENOTSUPP;
}
return 0;
}
I'll do this by myself when applying, no need to resubmit.
Thanks, Vignesh!
ta
Re: [PATCH 5.2 073/131] dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device
On Tue, Aug 06, 2019 at 06:04:48PM -0400, Sasha Levin wrote:
> On Tue, Aug 06, 2019 at 01:57:56PM +0100, Robin Murphy wrote:
>> Given that the two commits touch entirely separate files I'm not sure what
>> the imagined dependency could be :/
>
>> From the commit message of 3de433c5b38a ("drm/msm: Use the correct
> dma_sync calls in msm_gem"):
>
>Fixes the combination of two patches:
>
>Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
>Fixes: 449fa54d6815 (dma-direct: correct the physical addr in
> dma_direct_sync_sg_for_cpu/device)
>
>> 0036bc73ccbe is indeed not a fix (frankly I'm not convinced it's even a
>> valid change at all) but even conceptually it bears no relation whatsoever
>> to the genuine bug fixed by 449fa54d6815.
>
> Given that Rob Clark asked me to drop 0036bc73ccbe not because it's
> irrelevant but because it's potentially dangerous, I did not feel
> confident enough ignoring the statement in the commit message and
> dropped this patch instead.
449fa54d6815 fixes swiotlb misbehaving vs the API spec for the call,
something that real users on x86 cought. Robs fix works around the
fact that msm is badly abusing dma API. So even if both are genuine
bugs it is pretty clear we need to decide the match for the proper
users of the API and not the single abuser.
Re: [PATCH] riscv: kbuild: add virtual memory system selection
On Tue, Aug 06, 2019 at 05:02:03PM -0700, Paul Walmsley wrote: > The rationale is to encourage others to start laying the groundwork for > future Sv48 support. The immediate trigger for it was Alex's mmap > randomization support patch series, which needs to set some Kconfig > options differently depending on the selection of Sv32/39/48. Writing a formal todo list is much better encouragement than adding dead code. Th latter has a tendency of lingering around forever and actually hurting people. > > > but actively harmful, which is even worse. > > Reflecting on this assertion, the only case that I could come up with is > that randconfig or allyesconfig build testing could fail. Is this the > case that you're thinking of, or is there a different one? If that's the > one, I do agree that it would be best to avoid this case, and it looks > like there's no obvious way to work around that issue. randconfig or just a user thinking bigger is better and picking it. > > Even if we assume we want to implement Sv48 eventually (which seems > > to be a bit off), we need to make this a runtime choice and not a > > compile time one to not balloon the number of configs that distributions > > (and kernel developers) need to support. > > The expectation is that kernels that support multiple virtual memory > system modes at runtime will probably incur either a performance or a > memory layout penalty for doing so. So performance-sensitive embedded > applications will select only the model that they use, while distribution > kernels will likely take the performance hit for broader single-kernel > support. Even if we want to support Sv39 only or Sv39+Sv39 the choice in the patch doesn't make any sense. So better do the whole thing when its ready than doing false "groundwork".
[PATCH 3/9] remoteproc: qcom: pas: Update IMEM PIL info on load
Use the sysmon_name as identifier and store the relocated base address
and size of the memory region in the PIL reloation info structure in
IMEM.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_pas.c | 15 ---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index b88d74632d39..2aa0743fc05b 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -136,6 +136,7 @@ config QCOM_Q6V5_PAS
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
+ select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index db4b3c4bacd7..bfb622d36cb3 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -23,6 +23,7 @@
#include
#include "qcom_common.h"
+#include "qcom_pil_info.h"
#include "qcom_q6v5.h"
#include "remoteproc_internal.h"
@@ -52,6 +53,7 @@ struct qcom_adsp {
int pas_id;
int crash_reason_smem;
bool has_aggre2_clk;
+ const char *info_name;
struct completion start_done;
struct completion stop_done;
@@ -70,11 +72,17 @@ struct qcom_adsp {
static int adsp_load(struct rproc *rproc, const struct firmware *fw)
{
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
+ int ret;
- return qcom_mdt_load(adsp->dev, fw, rproc->firmware, adsp->pas_id,
-adsp->mem_region, adsp->mem_phys, adsp->mem_size,
->mem_reloc);
+ ret = qcom_mdt_load(adsp->dev, fw, rproc->firmware, adsp->pas_id,
+ adsp->mem_region, adsp->mem_phys, adsp->mem_size,
+ >mem_reloc);
+ if (ret)
+ return ret;
+ qcom_pil_info_store(adsp->info_name, adsp->mem_reloc, adsp->mem_size);
+
+ return 0;
}
static int adsp_start(struct rproc *rproc)
@@ -278,6 +286,7 @@ static int adsp_probe(struct platform_device *pdev)
adsp->rproc = rproc;
adsp->pas_id = desc->pas_id;
adsp->has_aggre2_clk = desc->has_aggre2_clk;
+ adsp->info_name = desc->sysmon_name;
platform_set_drvdata(pdev, adsp);
ret = adsp_alloc_memory_region(adsp);
--
2.18.0
[PATCH 9/9] remoteproc: qcom: Introduce panic handler for PAS and ADSP
Make the PAS and ADSP/CDSP remoteproc drivers implement the panic
handler that will invoke a stop to prepare the remoteprocs for post
mortem debugging.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/qcom_q6v5_adsp.c | 8
drivers/remoteproc/qcom_q6v5_pas.c | 8
2 files changed, 16 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index e953886b2eb7..3de1683903db 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -282,12 +282,20 @@ static void *adsp_da_to_va(struct rproc *rproc, u64 da,
int len)
return adsp->mem_region + offset;
}
+static void adsp_panic(struct rproc *rproc)
+{
+ struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
+
+ qcom_q6v5_panic(>q6v5);
+}
+
static const struct rproc_ops adsp_ops = {
.start = adsp_start,
.stop = adsp_stop,
.da_to_va = adsp_da_to_va,
.parse_fw = qcom_register_dump_segments,
.load = adsp_load,
+ .panic = adsp_panic,
};
static int adsp_init_clock(struct qcom_adsp *adsp, const char **clk_ids)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index bfb622d36cb3..31ff09bcd3ee 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -179,12 +179,20 @@ static void *adsp_da_to_va(struct rproc *rproc, u64 da,
int len)
return adsp->mem_region + offset;
}
+static void adsp_panic(struct rproc *rproc)
+{
+ struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
+
+ qcom_q6v5_panic(>q6v5);
+}
+
static const struct rproc_ops adsp_ops = {
.start = adsp_start,
.stop = adsp_stop,
.da_to_va = adsp_da_to_va,
.parse_fw = qcom_register_dump_segments,
.load = adsp_load,
+ .panic = adsp_panic,
};
static int adsp_init_clock(struct qcom_adsp *adsp)
--
2.18.0
[PATCH 5/9] arm64: dts: qcom: qcs404: Add IMEM and PIL info region
Add a simple-mfd representing IMEM on QCS404 and define the PIL
relocation info region, so that post mortem tools will be able to locate
the loaded remoteprocs.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index 3d0789775009..1604a9697832 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -845,6 +845,16 @@
status = "disabled";
};
+ imem@860 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x0860 0x1000>;
+
+ pil-reloc {
+ compatible ="qcom,pil-reloc-info";
+ offset = <0x94c>;
+ };
+ };
+
intc: interrupt-controller@b00 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
--
2.18.0
[PATCH 7/9] remoteproc: Introduce "panic" callback in ops
Introduce a "panic" function in the remoteproc ops table, to allow
remoteproc instances to perform operations needed in order to aid in
post mortem system debugging, such as flushing caches etc, when the
kernel panics.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/remoteproc_core.c | 16
include/linux/remoteproc.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3c5fbbbfb0f1..cc47797c6496 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1833,6 +1833,16 @@ void rproc_shutdown(struct rproc *rproc)
}
EXPORT_SYMBOL(rproc_shutdown);
+static int rproc_panic_handler(struct notifier_block *nb, unsigned long event,
+ void *ptr)
+{
+ struct rproc *rproc = container_of(nb, struct rproc, panic_nb);
+
+ rproc->ops->panic(rproc);
+
+ return NOTIFY_DONE;
+}
+
/**
* rproc_get_by_phandle() - find a remote processor by phandle
* @phandle: phandle to the rproc
@@ -2058,6 +2068,12 @@ struct rproc *rproc_alloc(struct device *dev, const char
*name,
rproc->ops->get_boot_addr = rproc_elf_get_boot_addr;
}
+ /* Register panic notifier for remoteprocs with "panic" callback */
+ if (rproc->ops->panic) {
+ rproc->panic_nb.notifier_call = rproc_panic_handler;
+ atomic_notifier_chain_register(_notifier_list,
>panic_nb);
+ }
+
mutex_init(>lock);
idr_init(>notifyids);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 16ad66683ad0..33553f6d8ff0 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -383,6 +383,7 @@ struct rproc_ops {
int (*load)(struct rproc *rproc, const struct firmware *fw);
int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
u32 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
+ void (*panic)(struct rproc *rproc);
};
/**
@@ -481,6 +482,7 @@ struct rproc_dump_segment {
* @auto_boot: flag to indicate if remote processor should be auto-started
* @dump_segments: list of segments in the firmware
* @nb_vdev: number of vdev currently handled by rproc
+ * @panic_nb: notifier_block for remoteproc's panic handler
*/
struct rproc {
struct list_head node;
@@ -514,6 +516,7 @@ struct rproc {
bool auto_boot;
struct list_head dump_segments;
int nb_vdev;
+ struct notifier_block panic_nb;
};
/**
--
2.18.0
[PATCH 1/9] remoteproc: qcom: Introduce driver to store pil info in IMEM
A region in IMEM is used to communicate load addresses of remoteproc to
post mortem debug tools. Implement a driver that can be used to store
this information in order to enable these tools to process collected
ramdumps.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/Kconfig | 3 +
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/qcom_pil_info.c | 139 +
drivers/remoteproc/qcom_pil_info.h | 6 ++
4 files changed, 149 insertions(+)
create mode 100644 drivers/remoteproc/qcom_pil_info.c
create mode 100644 drivers/remoteproc/qcom_pil_info.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28ed306982f7..3984bd16e670 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -85,6 +85,9 @@ config KEYSTONE_REMOTEPROC
It's safe to say N here if you're not interested in the Keystone
DSPs or just want to use a bare minimum kernel.
+config QCOM_PIL_INFO
+ tristate
+
config QCOM_RPROC_COMMON
tristate
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 00f09e658cb3..c1b46e9033cb 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
+obj-$(CONFIG_QCOM_PIL_INFO)+= qcom_pil_info.o
obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
obj-$(CONFIG_QCOM_Q6V5_ADSP) += qcom_q6v5_adsp.o
diff --git a/drivers/remoteproc/qcom_pil_info.c
b/drivers/remoteproc/qcom_pil_info.c
new file mode 100644
index ..aa42732016f3
--- /dev/null
+++ b/drivers/remoteproc/qcom_pil_info.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019 Linaro Ltd.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct pil_reloc_entry {
+ char name[8];
+ __le64 base;
+ __le32 size;
+} __packed;
+
+#define PIL_INFO_SIZE 200
+#define PIL_INFO_ENTRIES (PIL_INFO_SIZE / sizeof(struct pil_reloc_entry))
+
+struct pil_reloc {
+ struct device *dev;
+ struct regmap *map;
+ u32 offset;
+ int val_bytes;
+
+ struct pil_reloc_entry entries[PIL_INFO_ENTRIES];
+};
+
+static struct pil_reloc *_reloc;
+static DEFINE_MUTEX(reloc_mutex);
+
+/**
+ * qcom_pil_info_store() - store PIL information of image in IMEM
+ * @image: name of the image
+ * @base: base address of the loaded image
+ * @size: size of the loaded image
+ */
+void qcom_pil_info_store(const char *image, phys_addr_t base, size_t size)
+{
+ struct pil_reloc_entry *entry;
+ int idx = -1;
+ int i;
+
+ mutex_lock(_mutex);
+ if (!_reloc)
+ goto unlock;
+
+ for (i = 0; i < PIL_INFO_ENTRIES; i++) {
+ if (!_reloc->entries[i].name[0]) {
+ if (idx == -1)
+ idx = i;
+ continue;
+ }
+
+ if (!strncmp(_reloc->entries[i].name, image, 8)) {
+ idx = i;
+ goto found;
+ }
+ }
+
+ if (idx) {
+ dev_warn(_reloc->dev, "insufficient PIL info slots\n");
+ goto unlock;
+ }
+
+found:
+ entry = &_reloc->entries[idx];
+ stracpy(entry->name, image);
+ entry->base = base;
+ entry->size = size;
+
+ regmap_bulk_write(_reloc->map, _reloc->offset + idx * sizeof(*entry),
+ entry, sizeof(*entry) / _reloc->val_bytes);
+
+unlock:
+ mutex_unlock(_mutex);
+}
+EXPORT_SYMBOL_GPL(qcom_pil_info_store);
+
+static int pil_reloc_probe(struct platform_device *pdev)
+{
+ struct pil_reloc *reloc;
+
+ reloc = devm_kzalloc(>dev, sizeof(*reloc), GFP_KERNEL);
+ if (!reloc)
+ return -ENOMEM;
+
+ reloc->dev = >dev;
+ reloc->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
+ if (IS_ERR(reloc->map))
+ return PTR_ERR(reloc->map);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", >offset))
+ return -EINVAL;
+
+ reloc->val_bytes = regmap_get_val_bytes(reloc->map);
+ if (reloc->val_bytes < 0)
+ return -EINVAL;
+
+ regmap_bulk_write(reloc->map, reloc->offset, reloc->entries,
+ sizeof(reloc->entries) / reloc->val_bytes);
+
+ mutex_lock(_mutex);
+ _reloc = reloc;
+ mutex_unlock(_mutex);
+
+ return 0;
+}
+
+static int pil_reloc_remove(struct platform_device *pdev)
+{
+ mutex_lock(_mutex);
+ _reloc = NULL;
+ mutex_unlock(_mutex);
+
+ return 0;
+}
+
+static const struct
[PATCH 8/9] remoteproc: qcom: q6v5: Add common panic handler
Add a common panic handler that invokes a stop request and sleep enough
to let the remoteproc flush it's caches etc in order to aid post mortem
debugging.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/qcom_q6v5.c | 19 +++
drivers/remoteproc/qcom_q6v5.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 0d33e3079f0d..0aebae893362 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -6,6 +6,7 @@
* Copyright (C) 2014 Sony Mobile Communications AB
* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include
#include
@@ -15,6 +16,8 @@
#include
#include "qcom_q6v5.h"
+#define Q6V5_PANIC_DELAY_MS200
+
/**
* qcom_q6v5_prepare() - reinitialize the qcom_q6v5 context before start
* @q6v5: reference to qcom_q6v5 context to be reinitialized
@@ -162,6 +165,22 @@ int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5)
}
EXPORT_SYMBOL_GPL(qcom_q6v5_request_stop);
+/**
+ * qcom_q6v5_panic() - panic handler to invoke a stop on the remote
+ * @q6v5: reference to qcom_q6v5 context
+ *
+ * Set the stop bit and sleep in order to allow the remote processor to flush
+ * its caches etc for post mortem debugging.
+ */
+void qcom_q6v5_panic(struct qcom_q6v5 *q6v5)
+{
+ qcom_smem_state_update_bits(q6v5->state,
+ BIT(q6v5->stop_bit), BIT(q6v5->stop_bit));
+
+ mdelay(Q6V5_PANIC_DELAY_MS);
+}
+EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
+
/**
* qcom_q6v5_init() - initializer of the q6v5 common struct
* @q6v5: handle to be initialized
diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
index 7ac92c1e0f49..c37e6fd063e4 100644
--- a/drivers/remoteproc/qcom_q6v5.h
+++ b/drivers/remoteproc/qcom_q6v5.h
@@ -42,5 +42,6 @@ int qcom_q6v5_prepare(struct qcom_q6v5 *q6v5);
int qcom_q6v5_unprepare(struct qcom_q6v5 *q6v5);
int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5);
int qcom_q6v5_wait_for_start(struct qcom_q6v5 *q6v5, int timeout);
+void qcom_q6v5_panic(struct qcom_q6v5 *q6v5);
#endif
--
2.18.0
[PATCH 4/9] remoteproc: qcom: wcnss: Update IMEM PIL info on load
Store the relocated base address and size in the PIL relocation info
structure in IMEM.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_wcnss.c | 14 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 2aa0743fc05b..3f976ce3df3c 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -185,6 +185,7 @@ config QCOM_WCNSS_PIL
depends on QCOM_SMEM
depends on QCOM_SYSMON || QCOM_SYSMON=n
select QCOM_MDT_LOADER
+ select QCOM_PIL_INFO
select QCOM_RPROC_COMMON
select QCOM_SCM
help
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index dc135754bb9c..9db9a3d25af4 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -27,6 +27,7 @@
#include "qcom_common.h"
#include "remoteproc_internal.h"
+#include "qcom_pil_info.h"
#include "qcom_wcnss.h"
#define WCNSS_CRASH_REASON_SMEM422
@@ -145,10 +146,17 @@ void qcom_wcnss_assign_iris(struct qcom_wcnss *wcnss,
static int wcnss_load(struct rproc *rproc, const struct firmware *fw)
{
struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
+ int ret;
+
+ ret = qcom_mdt_load(wcnss->dev, fw, rproc->firmware, WCNSS_PAS_ID,
+ wcnss->mem_region, wcnss->mem_phys,
+ wcnss->mem_size, >mem_reloc);
+ if (ret)
+ return ret;
+
+ qcom_pil_info_store("wcnss", wcnss->mem_reloc, wcnss->mem_size);
- return qcom_mdt_load(wcnss->dev, fw, rproc->firmware, WCNSS_PAS_ID,
-wcnss->mem_region, wcnss->mem_phys,
-wcnss->mem_size, >mem_reloc);
+ return 0;
}
static void wcnss_indicate_nv_download(struct qcom_wcnss *wcnss)
--
2.18.0
[PATCH 6/9] arm64: dts: qcom: sdm845: Add IMEM and PIL info region
Add a simple-mfd representing IMEM on SDM845 and define the PIL
relocation info region, so that post mortem tools will be able to locate
the loaded remoteprocs.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c8ebe21f7673..38a6b304dba3 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2456,6 +2456,16 @@
cell-index = <0>;
};
+ imem@146bf000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0 0x146bf000 0 0x1000>;
+
+ pil-reloc {
+ compatible ="qcom,pil-reloc-info";
+ offset = <0x94c>;
+ };
+ };
+
apps_smmu: iommu@1500 {
compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
reg = <0 0x1500 0 0x8>;
--
2.18.0
[PATCH 0/9] remoteproc: qcom: post mortem debug support
The following series introduces two components that aids in post mortem debugging of Qualcomm systems. The first part is used to store information about loaded images in IMEM, for post mortem tools to know where the kernel loaded the remoteproc firmware. The second part invokes a stop operation on the remoteprocs during a kernel panic, in order to trigger them to flush caches etc. Bjorn Andersson (9): remoteproc: qcom: Introduce driver to store pil info in IMEM remoteproc: qcom: mss: Update IMEM PIL info on load remoteproc: qcom: pas: Update IMEM PIL info on load remoteproc: qcom: wcnss: Update IMEM PIL info on load arm64: dts: qcom: qcs404: Add IMEM and PIL info region arm64: dts: qcom: sdm845: Add IMEM and PIL info region remoteproc: Introduce "panic" callback in ops remoteproc: qcom: q6v5: Add common panic handler remoteproc: qcom: Introduce panic handler for PAS and ADSP arch/arm64/boot/dts/qcom/qcs404.dtsi | 10 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++ drivers/remoteproc/Kconfig | 6 ++ drivers/remoteproc/Makefile | 1 + drivers/remoteproc/qcom_pil_info.c | 139 +++ drivers/remoteproc/qcom_pil_info.h | 6 ++ drivers/remoteproc/qcom_q6v5.c | 19 drivers/remoteproc/qcom_q6v5.h | 1 + drivers/remoteproc/qcom_q6v5_adsp.c | 8 ++ drivers/remoteproc/qcom_q6v5_mss.c | 3 + drivers/remoteproc/qcom_q6v5_pas.c | 23 - drivers/remoteproc/qcom_wcnss.c | 14 ++- drivers/remoteproc/remoteproc_core.c | 16 +++ include/linux/remoteproc.h | 3 + 14 files changed, 253 insertions(+), 6 deletions(-) create mode 100644 drivers/remoteproc/qcom_pil_info.c create mode 100644 drivers/remoteproc/qcom_pil_info.h -- 2.18.0
[PATCH 2/9] remoteproc: qcom: mss: Update IMEM PIL info on load
As the MPSS address is calculated during load store it, and the size, in
the PIL info region structure in IMEM.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_mss.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 3984bd16e670..b88d74632d39 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -119,6 +119,7 @@ config QCOM_Q6V5_MSS
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
+ select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 8fcf9d28dd73..d9192fa40e05 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -28,6 +28,7 @@
#include "remoteproc_internal.h"
#include "qcom_common.h"
+#include "qcom_pil_info.h"
#include "qcom_q6v5.h"
#include
@@ -1040,6 +1041,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
else if (ret < 0)
dev_err(qproc->dev, "MPSS authentication failed: %d\n", ret);
+ qcom_pil_info_store("modem", mpss_reloc, qproc->mpss_size);
+
release_firmware:
release_firmware(fw);
out:
--
2.18.0
Re: [PATCH] ALSA: usb-midi: fix a memory leak bug
On Wed, Aug 7, 2019 at 1:31 AM Takashi Iwai wrote: > > On Wed, 07 Aug 2019 05:22:09 +0200, > Wenwen Wang wrote: > > > > In __snd_usbmidi_create(), a MIDI streaming interface structure is > > allocated through kzalloc() and the pointer is saved to 'umidi'. Later on, > > the endpoint structures are created by invoking > > snd_usbmidi_create_endpoints_midiman() or snd_usbmidi_create_endpoints(), > > depending on the type of the audio quirk type. However, if the creation > > fails, the allocated 'umidi' is not deallocated, leading to a memory leak > > bug. > > > > To fix the above issue, free 'umidi' before returning the error. > > > > Signed-off-by: Wenwen Wang > > It's again a false-positive report. The object is released > automatically by the destructor of its base snd_rawmidi object. Thanks for your response! Sorry for the false positives. :( Wenwen
Re: [PATCH] ALSA: usb-midi: fix a memory leak bug
On Wed, 07 Aug 2019 05:22:09 +0200, Wenwen Wang wrote: > > In __snd_usbmidi_create(), a MIDI streaming interface structure is > allocated through kzalloc() and the pointer is saved to 'umidi'. Later on, > the endpoint structures are created by invoking > snd_usbmidi_create_endpoints_midiman() or snd_usbmidi_create_endpoints(), > depending on the type of the audio quirk type. However, if the creation > fails, the allocated 'umidi' is not deallocated, leading to a memory leak > bug. > > To fix the above issue, free 'umidi' before returning the error. > > Signed-off-by: Wenwen Wang It's again a false-positive report. The object is released automatically by the destructor of its base snd_rawmidi object. thanks, Takashi
Re: [PATCH 1/3] mm/migrate: clean up useless code in migrate_vma_collect_pmd()
On Tue, Aug 06, 2019 at 06:35:03AM -0700, Matthew Wilcox wrote: > > This needs something beyond the subject line. Maybe ... > > After these assignments, we either restart the loop with a fresh variable, > or we assign to the variable again without using the value we've assigned. > > Reviewed-by: Matthew Wilcox (Oracle) > > > goto next; > > } > > - pfn = page_to_pfn(page); > > After you've done all this, as far as I can tell, the 'pfn' variable is > only used in one arm of the conditions, so it can be moved there. > > ie something like: > > - unsigned long mpfn, pfn; > + unsigned long mpfn; > ... > - pfn = pte_pfn(pte); > ... > + unsigned long pfn = pte_pfn(pte); > + > This makes code better. Thank you for the suggestion. Will send v2 for this patch. Regards, Pingfan
Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
On Tue, 2019-08-06 at 22:15 -0700, Nathan Chancellor wrote:
> On Tue, Aug 06, 2019 at 03:37:42PM -0700, Nick Desaulniers wrote:
> > On Thu, Aug 1, 2019 at 12:11 AM Johannes Berg
> > wrote:
> > >
> > > > Luca, you said this was already fixed in your internal tree, and the fix
> > > > would appear soon in next, but I don't see anything in linux-next?
> > >
> > > Luca is still on vacation, but I just sent out a version of the patch we
> > > had applied internally.
> > >
> > > Also turns out it wasn't actually _fixed_, just _moved_, so those
> > > internal patches wouldn't have helped anyway.
> >
> > Thanks for the report. Do you have a link?
> > I'll rebase my patch then.
> > --
> > Thanks,
> > ~Nick Desaulniers
>
> Just for everyone else (since I commented on our issue tracker), this is
> now fixed in Linus's tree as of commit 1f6607250331 ("iwlwifi: dbg_ini:
> fix compile time assert build errors").
Yes, thanks Nathan! I was just digging for this patch to reply to you,
I'm still catching up with what happened during my vacations.
--
Cheers,
Luca.
Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
On Tue, Aug 06, 2019 at 03:37:42PM -0700, Nick Desaulniers wrote:
> On Thu, Aug 1, 2019 at 12:11 AM Johannes Berg
> wrote:
> >
> >
> > > Luca, you said this was already fixed in your internal tree, and the fix
> > > would appear soon in next, but I don't see anything in linux-next?
> >
> > Luca is still on vacation, but I just sent out a version of the patch we
> > had applied internally.
> >
> > Also turns out it wasn't actually _fixed_, just _moved_, so those
> > internal patches wouldn't have helped anyway.
>
> Thanks for the report. Do you have a link?
> I'll rebase my patch then.
> --
> Thanks,
> ~Nick Desaulniers
Just for everyone else (since I commented on our issue tracker), this is
now fixed in Linus's tree as of commit 1f6607250331 ("iwlwifi: dbg_ini:
fix compile time assert build errors").
Cheers,
Nathan
[PATCH] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
Without this patch, the MAP_SYNC test case will cause a print_bad_pte
warning on arm64 as follows:
[ 25.542693] BUG: Bad page map in process mapdax333
pte:2e8000448800f53 pmd:41ff5f003
[ 25.546360] page:7e001022 refcount:1 mapcount:-1
mapping:8003e29c7440 index:0x0
[ 25.550281] ext4_dax_aops
[ 25.550282] name:"__aaabbbcccddd__"
[ 25.551553] flags: 0x3001002(referenced|reserved)
[ 25.555802] raw: 03001002 8003dfffa908
8003e29c7440
[ 25.559446] raw: 0001fffe
[ 25.563075] page dumped because: bad pte
[ 25.564938] addr:be05b000 vm_flags:208000fb
anon_vma: mapping:8003e29c7440 index:0
[ 25.574272] file:__aaabbbcccddd__ fault:ext4_dax_fault
ap:ext4_file_mmap readpage:0x0
[ 25.578799] CPU: 1 PID: 1180 Comm: mapdax333 Not tainted 5.2.0+ #21
[ 25.581702] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
02/06/2015
[ 25.585624] Call trace:
[ 25.587008] dump_backtrace+0x0/0x178
[ 25.588799] show_stack+0x24/0x30
[ 25.590328] dump_stack+0xa8/0xcc
[ 25.591901] print_bad_pte+0x18c/0x218
[ 25.593628] unmap_page_range+0x778/0xc00
[ 25.595506] unmap_single_vma+0x94/0xe8
[ 25.597304] unmap_vmas+0x90/0x108
[ 25.598901] unmap_region+0xc0/0x128
[ 25.600566] __do_munmap+0x284/0x3f0
[ 25.602245] __vm_munmap+0x78/0xe0
[ 25.603820] __arm64_sys_munmap+0x34/0x48
[ 25.605709] el0_svc_common.constprop.0+0x78/0x168
[ 25.607956] el0_svc_handler+0x34/0x90
[ 25.609698] el0_svc+0x8/0xc
[ 25.611103] Disabling lock debugging due to kernel taint
[ 25.613573] BUG: Bad page state in process mapdax333 pfn:448800
[ 25.616359] page:7e001022 refcount:0 mapcount:-1
mapping:8003e29c7440 index:0x1
[ 25.620236] ext4_dax_aops
[ 25.620237] name:"__aaabbbcccddd__"
[ 25.621495] flags: 0x300()
[ 25.624912] raw: 0300 dead0100 dead0200
8003e29c7440
[ 25.628502] raw: 0001 fffe
[ 25.632097] page dumped because: non-NULL mapping
[...]
[ 25.656567] CPU: 1 PID: 1180 Comm: mapdax333 Tainted: GB
5.2.0+ #21
[ 25.660131] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
02/06/2015
[ 25.663324] Call trace:
[ 25.664466] dump_backtrace+0x0/0x178
[ 25.666163] show_stack+0x24/0x30
[ 25.667721] dump_stack+0xa8/0xcc
[ 25.669270] bad_page+0xf0/0x150
[ 25.670772] free_pages_check_bad+0x84/0xa0
[ 25.672724] free_pcppages_bulk+0x45c/0x708
[ 25.674675] free_unref_page_commit+0xcc/0x100
[ 25.676751] free_unref_page_list+0x13c/0x200
[ 25.678801] release_pages+0x350/0x420
[ 25.680539] free_pages_and_swap_cache+0xf8/0x128
[ 25.682738] tlb_flush_mmu+0x164/0x2b0
[ 25.684485] unmap_page_range+0x648/0xc00
[ 25.686349] unmap_single_vma+0x94/0xe8
[ 25.688131] unmap_vmas+0x90/0x108
[ 25.689739] unmap_region+0xc0/0x128
[ 25.691392] __do_munmap+0x284/0x3f0
[ 25.693079] __vm_munmap+0x78/0xe0
[ 25.694658] __arm64_sys_munmap+0x34/0x48
[ 25.696530] el0_svc_common.constprop.0+0x78/0x168
[ 25.698772] el0_svc_handler+0x34/0x90
[ 25.700512] el0_svc+0x8/0xc
The root cause is in _vm_normal_page, without the PTE_SPECIAL bit,
the return value will be incorrectly set to pfn_to_page(pfn) instead
of NULL. Besides, this patch also rewrite the pmd_mkdevmap to avoid
setting PTE_SPECIAL for pmd
The MAP_SYNC test case is as follows(Provided by Yibo Cai)
$#include
$#include
$#include
$#include
$#include
$#ifndef MAP_SYNC
$#define MAP_SYNC 0x8
$#endif
/* mount -o dax /dev/pmem0 /mnt */
$#define F "/mnt/__aaabbbcccddd__"
int main(void)
{
int fd;
char buf[4096];
void *addr;
if ((fd = open(F, O_CREAT|O_TRUNC|O_RDWR, 0644)) < 0) {
perror("open1");
return 1;
}
if (write(fd, buf, 4096) != 4096) {
perror("lseek");
return 1;
}
addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_SYNC,
fd, 0);
if (addr == MAP_FAILED) {
perror("mmap");
printf("did you mount with '-o dax'?\n");
return 1;
}
memset(addr, 0x55, 4096);
if (munmap(addr, 4096) == -1) {
perror("munmap");
return 1;
}
close(fd);
return 0;
}
Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support")
Reported-by: Yibo Cai
Signed-off-by: Jia He
Acked-by: Robin Murphy
---
arch/arm64/include/asm/pgtable.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 5fdcfe237338..e09760ece844 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -209,7 +209,7 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
static inline pte_t pte_mkdevmap(pte_t pte)
{
- return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
+ return set_pte_bit(pte, __pgprot(PTE_DEVMAP |
[PATCH] tipc: set addr_trail_end when using explicit node addresses
When tipc uses auto-generated node addresses it goes through a duplicate
address detection phase to ensure the address is unique.
When using explicitly configured node names the DAD phase is skipped.
However addr_trail_end was being left set to 0 which causes parts of the
tipc state machine to assume that the address is not yet valid and
unnecessarily delays the discovery phase. By setting addr_trail_end to
jiffies when using explicit addresses we ensure that we move straight to
discovery.
Signed-off-by: Chris Packham
---
net/tipc/discover.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index c138d68e8a69..f83bfe8c9443 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -361,6 +361,8 @@ int tipc_disc_create(struct net *net, struct tipc_bearer *b,
if (!tipc_own_addr(net)) {
tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
+ } else {
+ tn->addr_trial_end = jiffies;
}
memcpy(>dest, dest, sizeof(*dest));
d->net = net;
--
2.22.0
Re: [PATCH net v2] net: dsa: Check existence of .port_mdb_add callback before calling it
Hi Chen-Yu,
On Wed, 7 Aug 2019 11:18:28 +0800, Chen-Yu Tsai wrote:
> On Wed, Aug 7, 2019 at 4:34 AM Vivien Didelot
> wrote:
> >
> > Hi Chen-Yu,
> >
> > On Wed, 7 Aug 2019 01:49:37 +0800, Chen-Yu Tsai wrote:
> > > On Wed, Aug 7, 2019 at 1:15 AM Vivien Didelot
> > > wrote:
> > > >
> > > > Hi Chen-Yu,
> > > >
> > > > On Tue, 6 Aug 2019 15:53:25 +0800, Chen-Yu Tsai
> > > > wrote:
> > > > > From: Chen-Yu Tsai
> > > > >
> > > > > With the recent addition of commit 75dad2520fc3 ("net: dsa: b53:
> > > > > Disable
> > > > > all ports on setup"), users of b53 (BCM53125 on Lamobo R1 in my case)
> > > > > are forced to use the dsa subsystem to enable the switch, instead of
> > > > > having it in the default transparent "forward-to-all" mode.
> > > > >
> > > > > The b53 driver does not support mdb bitmap functions. However the dsa
> > > > > layer does not check for the existence of the .port_mdb_add callback
> > > > > before actually using it. This results in a NULL pointer dereference,
> > > > > as shown in the kernel oops below.
> > > > >
> > > > > The other functions seem to be properly guarded. Do the same for
> > > > > .port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
> > > > >
> > > > > b53 is not the only driver that doesn't support mdb bitmap functions.
> > > > > Others include bcm_sf2, dsa_loop, lantiq_gswip, mt7530, mv88e6060,
> > > > > qca8k, realtek-smi, and vitesse-vsc73xx.
> > > >
> > > > I don't know what you mean by that, there's no "mdb bitmap function"
> > > > support for drivers, only the port_mdb_{prepare,add,del} callbacks...
> > >
> > > The term was coined from commit e6db98db8a95 ("net: dsa: add switch mdb
> > > bitmap functions"). But yeah, .port_mdb_* ops/callbacks would be more
> > > appropriate.
> > >
> > > > > 8<--- cut here ---
> > > > > Unable to handle kernel NULL pointer dereference at virtual
> > > > > address
> > > > > pgd = (ptrval)
> > > > > [] *pgd=
> > > > > Internal error: Oops: 8005 [#1] SMP ARM
> > > > > Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common
> > > > > rtlwifi mac80211 cfg80211
> > > > > CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted
> > > > > 5.3.0-rc1-00247-gd3519030752a #1
> > > > > Hardware name: Allwinner sun7i (A20) Family
> > > > > Workqueue: events switchdev_deferred_process_work
> > > > > PC is at 0x0
> > > > > LR is at dsa_switch_event+0x570/0x620
> > > > > pc : [<>]lr : []psr: 80070013
> > > > > sp : ee871db8 ip : fp : ee98d0a4
> > > > > r10: 000c r9 : 0008 r8 : ee89f710
> > > > > r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
> > > > > r3 : r2 : ee89f710 r1 : 0008 r0 : ee98d040
> > > > > Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > > > > Control: 10c5387d Table: 6deb406a DAC: 0051
> > > > > Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
> > > > > Stack: (0xee871db8 to 0xee872000)
> > > > > 1da0:
> > > > > ee871e14 103ace2d
> > > > > 1dc0: ee871e14 0005
> > > > > c08524a0
> > > > > 1de0: e000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000
> > > > > c0851120 c014bef0
> > > > > 1e00: b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710
> > > > > ee871ecb
> > > > > 1e20: 0008 103ace2d c087e248 ee29c868 103ace2d
> > > > > 0001
> > > > > 1e40: ee871e98 0006 c0fb2a50 c087e2d0
> > > > > c08523c4
> > > > > 1e60: c014bdfc 0006 c0fad2d0 ee871e98 ee89f710
> > > > > c014c500
> > > > > 1e80: ee89f3c0 c0f04c48 ee9e5000 c087dfb4
> > > > > ee9e5000
> > > > > 1ea0: ee89f710 ee871ecb 0001 103ace2d c0f04c48
> > > > > c087e0a8
> > > > > 1ec0: efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710
> > > > > ee9e5000 0122
> > > > > 1ee0: 0100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c
> > > > > 2e928000 c0fad2ec
> > > > > 1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 c087def8
> > > > > c0fad2ec c01447dc
> > > > > 1f20: ef315640 ef7a62c0 0008 ee839580 ee839594 ef7a62c0
> > > > > 0008 c0f03d00
> > > > > 1f40: ef7a62d8 ef7a62c0 e000 c0145b84 e000 c0fb2420
> > > > > c0bfaa8c
> > > > > 1f60: e000 ee84b600 ee84b5c0 ee87 ee839580
> > > > > c0145b40 ef0e5ea4
> > > > > 1f80: ee84b61c c014a6f8 0001 ee84b5c0 c014a5b0
> > > > >
> > > > > 1fa0: c01010e8
> > > > >
> > > > > 1fc0:
> > > > >
> > > > > 1fe0: 0013
> > > > >
> > > > > []
Re: [PATCH v2] soc: qcom: socinfo: Annotate switch cases with fall through
On Wed, 7 Aug 2019 at 07:54, Bjorn Andersson wrote:
>
> Introduce fall through annotations in the switch statements of
> socinfo_debugfs_init() to silence compiler warnings.
Oops, I missed this. Thanks for fixing it!
> Fixes: 9c84c1e78634 ("soc: qcom: socinfo: Expose custom attributes")
> Reported-by: Stephen Rothwell
> Signed-off-by: Bjorn Andersson
Acked-by: Vaishali Thakkar
> ---
> drivers/soc/qcom/socinfo.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> index 855353bed19e..a39ea5061dc5 100644
> --- a/drivers/soc/qcom/socinfo.c
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -323,6 +323,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo
> *qcom_socinfo,
> debugfs_create_x32("raw_device_number", 0400,
>qcom_socinfo->dbg_root,
>_socinfo->info.raw_device_num);
> + /* Fall through */
> case SOCINFO_VERSION(0, 11):
> case SOCINFO_VERSION(0, 10):
> case SOCINFO_VERSION(0, 9):
> @@ -330,10 +331,12 @@ static void socinfo_debugfs_init(struct qcom_socinfo
> *qcom_socinfo,
>
> debugfs_create_u32("foundry_id", 0400, qcom_socinfo->dbg_root,
>_socinfo->info.foundry_id);
> + /* Fall through */
> case SOCINFO_VERSION(0, 8):
> case SOCINFO_VERSION(0, 7):
> DEBUGFS_ADD(info, pmic_model);
> DEBUGFS_ADD(info, pmic_die_rev);
> + /* Fall through */
> case SOCINFO_VERSION(0, 6):
> qcom_socinfo->info.hw_plat_subtype =
> __le32_to_cpu(info->hw_plat_subtype);
> @@ -341,6 +344,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo
> *qcom_socinfo,
> debugfs_create_u32("hardware_platform_subtype", 0400,
>qcom_socinfo->dbg_root,
>_socinfo->info.hw_plat_subtype);
> + /* Fall through */
> case SOCINFO_VERSION(0, 5):
> qcom_socinfo->info.accessory_chip =
> __le32_to_cpu(info->accessory_chip);
> @@ -348,23 +352,27 @@ static void socinfo_debugfs_init(struct qcom_socinfo
> *qcom_socinfo,
> debugfs_create_u32("accessory_chip", 0400,
>qcom_socinfo->dbg_root,
>_socinfo->info.accessory_chip);
> + /* Fall through */
> case SOCINFO_VERSION(0, 4):
> qcom_socinfo->info.plat_ver = __le32_to_cpu(info->plat_ver);
>
> debugfs_create_u32("platform_version", 0400,
>qcom_socinfo->dbg_root,
>_socinfo->info.plat_ver);
> + /* Fall through */
> case SOCINFO_VERSION(0, 3):
> qcom_socinfo->info.hw_plat = __le32_to_cpu(info->hw_plat);
>
> debugfs_create_u32("hardware_platform", 0400,
>qcom_socinfo->dbg_root,
>_socinfo->info.hw_plat);
> + /* Fall through */
> case SOCINFO_VERSION(0, 2):
> qcom_socinfo->info.raw_ver = __le32_to_cpu(info->raw_ver);
>
> debugfs_create_u32("raw_version", 0400,
> qcom_socinfo->dbg_root,
>_socinfo->info.raw_ver);
> + /* Fall through */
> case SOCINFO_VERSION(0, 1):
> DEBUGFS_ADD(info, build_id);
> break;
> --
> 2.18.0
>
[PATCH nvmem v2 0/2] nvmem: imx: add i.MX8QM platform support
From: Fugang Duan The patch set is to add i.MX8QM platform support for i.MX8 SCU OCOTP driver due to i.MX8QM efuse table has some difference with i.MX8QXP platform. V2: - Add dt-bindings for the new compatible string support. Fugang Duan (2): nvmem: imx: add i.MX8QM platform support dt-bindings: fsl: scu: add new compatible string for ocotp Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++- drivers/nvmem/imx-ocotp-scu.c | 7 +++ 2 files changed, 10 insertions(+), 1 deletion(-) -- 2.7.4
Re: [PATCH v4 2/4] RISC-V: Add riscv_isa reprensenting ISA features common across CPUs
On Wed, Aug 7, 2019 at 3:24 AM Paul Walmsley wrote: > > Hi Anup, Atish, > > On Fri, 2 Aug 2019, Atish Patra wrote: > > > From: Anup Patel > > > > This patch adds riscv_isa integer to represent ISA features common > > across all CPUs. The riscv_isa is not same as elf_hwcap because > > elf_hwcap will only have ISA features relevant for user-space apps > > whereas riscv_isa will have ISA features relevant to both kernel > > and user-space apps. > > > > One of the use case is KVM hypervisor where riscv_isa will be used > > to do following operations: > > > > 1. Check whether hypervisor extension is available > > 2. Find ISA features that need to be virtualized (e.g. floating > >point support, vector extension, etc.) > > > > Signed-off-by: Anup Patel > > Signed-off-by: Atish Patra > > Do you have any opinions on how this patch might change for the Z-prefix > extensions? This bitfield approach probably won't scale, and with the > EXPORT_SYMBOL(), it might be worth trying to put together a approach that > would work over the long term? Our plan is to use bitmap instead of bitfield and all Zxyz extensions will be assigned bit positions "27 + i" where "i" will be based on order in-which they are defined in RISC-V spec. In general, "i" is just a unique relative index (starting from 0). To summarize, the existing bitfield approach can be naturally extended using bitmap. We will update this patch accordingly. Regards, Anup
[PATCH v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Lori Hikichi
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of msgs
in a transfer is limited to two, and must be a write
followed by a read.
Signed-off-by: Lori Hikichi
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Icarus Chau
Signed-off-by: Ray Jui
Signed-off-by: Shivaraj Shetty
---
drivers/i2c/busses/i2c-bcm-iproc.c | 70 +++---
1 file changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..15fedcf 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -81,6 +81,7 @@
#define M_CMD_PROTOCOL_MASK 0xf
#define M_CMD_PROTOCOL_BLK_WR0x7
#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PROTOCOL_PROCESS 0xa
#define M_CMD_PEC_SHIFT 8
#define M_CMD_RD_CNT_SHIFT 0
#define M_CMD_RD_CNT_MASK0xff
@@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct
bcm_iproc_i2c_dev *iproc_i2c,
return 0;
}
-static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
-struct i2c_msg *msg)
+/*
+ * If 'process_call' is true, then this is a multi-msg transfer that requires
+ * a repeated start between the messages.
+ * More specifically, it must be a write (reg) followed by a read (data).
+ * The i2c quirks are set to enforce this rule.
+ */
+static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
+ struct i2c_msg *msgs, bool process_call)
{
int i;
u8 addr;
u32 val, tmp, val_intr_en;
unsigned int tx_bytes;
+ struct i2c_msg *msg = [0];
/* check if bus is busy */
if (!!(iproc_i2c_rd_reg(iproc_i2c,
@@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
val = msg->buf[i];
/* mark the last byte */
- if (i == msg->len - 1)
- val |= BIT(M_TX_WR_STATUS_SHIFT);
+ if (!process_call && (i == msg->len - 1))
+ val |= 1 << M_TX_WR_STATUS_SHIFT;
iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
}
iproc_i2c->tx_bytes = tx_bytes;
}
+ /* Process the read message if this is process call */
+ if (process_call) {
+ msg++;
+ iproc_i2c->msg = msg; /* point to second msg */
+
+ /*
+* The last byte to be sent out should be a slave
+* address with read operation
+*/
+ addr = msg->addr << 1 | 1;
+ /* mark it the last byte out */
+ val = addr | (1 << M_TX_WR_STATUS_SHIFT);
+ iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
+ }
+
/* mark as incomplete before starting the transaction */
if (iproc_i2c->irq)
reinit_completion(_i2c->done);
@@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
* underrun interrupt, which will be triggerred when the TX FIFO is
* empty. When that happens we can then pump more data into the FIFO
*/
- if (!(msg->flags & I2C_M_RD) &&
+ if (!process_call && !(msg->flags & I2C_M_RD) &&
msg->len > iproc_i2c->tx_bytes)
val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
@@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
*/
val = BIT(M_CMD_START_BUSY_SHIFT);
if (msg->flags & I2C_M_RD) {
+ u32 protocol;
+
iproc_i2c->rx_bytes = 0;
if (msg->len > M_RX_FIFO_MAX_THLD_VALUE)
iproc_i2c->thld_bytes = M_RX_FIFO_THLD_VALUE;
@@ -758,7 +783,10 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
/* enable the RX threshold interrupt */
val_intr_en |= BIT(IE_M_RX_THLD_SHIFT);
- val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
+ protocol = process_call ?
+ M_CMD_PROTOCOL_PROCESS : M_CMD_PROTOCOL_BLK_RD;
+
+ val |= (protocol << M_CMD_PROTOCOL_SHIFT) |
(msg->len << M_CMD_RD_CNT_SHIFT);
} else {
val |= (M_CMD_PROTOCOL_BLK_WR << M_CMD_PROTOCOL_SHIFT);
@@ -774,17 +802,31 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg msgs[], int num)
{
struct bcm_iproc_i2c_dev *iproc_i2c = i2c_get_adapdata(adapter);
- int ret, i;
+
[PATCH nvmem v2 1/2] nvmem: imx: add i.MX8QM platform support
From: Fugang Duan
i.MX8QM efuse table has some difference with i.MX8QXP platform,
so add i.MX8QM platform support.
Signed-off-by: Fugang Duan
---
drivers/nvmem/imx-ocotp-scu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
index be2f5f0..0d78ab4 100644
--- a/drivers/nvmem/imx-ocotp-scu.c
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -16,6 +16,7 @@
enum ocotp_devtype {
IMX8QXP,
+ IMX8QM,
};
struct ocotp_devtype_data {
@@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
.nregs = 800,
};
+static struct ocotp_devtype_data imx8qm_data = {
+ .devtype = IMX8QM,
+ .nregs = 800,
+};
+
static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
u32 *val)
{
@@ -118,6 +124,7 @@ static struct nvmem_config imx_scu_ocotp_nvmem_config = {
static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx8qxp-scu-ocotp", (void *)_data },
+ { .compatible = "fsl,imx8qm-scu-ocotp", (void *)_data },
{ },
};
MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
--
2.7.4
[PATCH nvmem v2 2/2] dt-bindings: fsl: scu: add new compatible string for ocotp
From: Fugang Duan Add new compatible string "fsl,imx8qm-scu-ocotp" into binding doc for i.MX8 SCU OCOTP driver. Signed-off-by: Fugang Duan --- Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index a575e42..c149fad 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -136,7 +136,9 @@ Required properties: OCOTP bindings based on SCU Message Protocol Required properties: -- compatible: Should be "fsl,imx8qxp-scu-ocotp" +- compatible: Should be one of: + "fsl,imx8qm-scu-ocotp", + "fsl,imx8qxp-scu-ocotp". - #address-cells: Must be 1. Contains byte index - #size-cells: Must be 1. Contains byte length -- 2.7.4
RE: [PATCH 1/3] perf: Add capability-related utilities
On Wed, July 17 at 2019 7:47 PM Arnaldo Carvalho de Melo wrote: > Em Wed, Jul 17, 2019 at 06:05:51PM -0300, Arnaldo Carvalho de Melo > escreveu: > > Em Tue, Jul 16, 2019 at 10:46:43AM +0200, Jiri Olsa escreveu: > > > On Tue, Jul 02, 2019 at 08:10:03PM -0400, Igor Lubashev wrote: > > > > Add utilities to help checking capabilities of the running process. > > > > Make perf link with libcap. > > > > > > > > Signed-off-by: Igor Lubashev > > > > --- > > > > tools/perf/Makefile.config | 2 +- > > > > tools/perf/util/Build | 1 + > > > > tools/perf/util/cap.c | 24 > > > > tools/perf/util/cap.h | 10 ++ > > > > tools/perf/util/event.h| 1 + > > > > tools/perf/util/python-ext-sources | 1 + > > > > tools/perf/util/util.c | 9 + > > > > 7 files changed, 47 insertions(+), 1 deletion(-) create mode > > > > 100644 tools/perf/util/cap.c create mode 100644 > > > > tools/perf/util/cap.h > > > > > > > > diff --git a/tools/perf/Makefile.config > > > > b/tools/perf/Makefile.config index 85fbcd265351..21470a50ed39 > > > > 100644 > > > > --- a/tools/perf/Makefile.config > > > > +++ b/tools/perf/Makefile.config > > > > @@ -259,7 +259,7 @@ CXXFLAGS += -Wno-strict-aliasing # adding > > > > assembler files missing the .GNU-stack linker note. > > > > LDFLAGS += -Wl,-z,noexecstack > > > > > > > > -EXTLIBS = -lpthread -lrt -lm -ldl > > > > +EXTLIBS = -lpthread -lrt -lm -ldl -lcap > > > > > > I wonder we should detect libcap or it's everywhere.. Arnaldo's > > > compile test suite might tell > > > > I'll add this tentatively and try to build it in my test suite. > > So, not even in my notebook this worked straight away: > > CC /tmp/build/perf/util/cap.o > CC /tmp/build/perf/util/config.o > In file included from util/cap.c:5: > util/cap.h:6:10: fatal error: sys/capability.h: No such file or directory > 6 | #include > | ^~ > compilation terminated. > mv: cannot stat '/tmp/build/perf/util/.cap.o.tmp': No such file or directory > > > I had to first do: > > dnf install libcap-devel > > So we need to have a feature test and fail if that is not installed, i.e. > libcap > becomes a hard req for building perf, which I think is reasonable, one more > shouldn't hurt, right? > > With all the features enabled: > > [acme@quaco perf]$ ldd ~/bin/perf > linux-vdso.so.1 (0x7ffe7278a000) > libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 > (0x7f7be52f1000) > libunwind.so.8 => /lib64/libunwind.so.8 (0x7f7be52d7000) > liblzma.so.5 => /lib64/liblzma.so.5 (0x7f7be52ae000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7be528d000) > librt.so.1 => /lib64/librt.so.1 (0x7f7be5283000) > libm.so.6 => /lib64/libm.so.6 (0x7f7be513d000) > libdl.so.2 => /lib64/libdl.so.2 (0x7f7be5135000) > libcap.so.2 => /lib64/libcap.so.2 (0x7f7be512e000) > libelf.so.1 => /lib64/libelf.so.1 (0x7f7be5113000) > libdw.so.1 => /lib64/libdw.so.1 (0x7f7be50c) > libslang.so.2 => /lib64/libslang.so.2 (0x7f7be4de8000) > libperl.so.5.28 => /lib64/libperl.so.5.28 (0x7f7be4ac2000) > libc.so.6 => /lib64/libc.so.6 (0x7f7be48fa000) > libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 > (0x7f7be469) > libz.so.1 => /lib64/libz.so.1 (0x7f7be4676000) > libzstd.so.1 => /lib64/libzstd.so.1 (0x7f7be45d1000) > libnuma.so.1 => /lib64/libnuma.so.1 (0x7f7be45c3000) > libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1 > (0x7f7be456d000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f7be4551000) > /lib64/ld-linux-x86-64.so.2 (0x7f7be5331000) > libbz2.so.1 => /lib64/libbz2.so.1 (0x7f7be453d000) > libcrypt.so.2 => /lib64/libcrypt.so.2 (0x7f7be4502000) > libutil.so.1 => /lib64/libutil.so.1 (0x7f7be44fd000) > libbabeltrace.so.1 => /lib64/libbabeltrace.so.1 > (0x7f7be44ed000) > libpopt.so.0 => /lib64/libpopt.so.0 (0x7f7be44dd000) > libuuid.so.1 => /lib64/libuuid.so.1 (0x7f7be44d3000) > libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 > (0x7f7be44cd000) > libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x7f7be43a9000) > libpcre.so.1 => /lib64/libpcre.so.1 (0x7f7be4335000) > [acme@quaco perf]$ > > ;-) > > So, please check tools/build/feature/ and check how this is done and add a > test and the warning in tools/perf/Makefile.config so that we get an error > message stating that libcap-dev or libcap-devel should be installed. I have just posted v2 of the series (https://lkml.kernel.org/lkml/cover.1565146171.git.iluba...@akamai.com). Instead of making libcap is "hard req", I made it as "soft" one. We can still build a useful tool w/o libcap. It will just have to assume that perf is running with no capabilities, since we
RE: [EXT] Re: [PATCH nvmem 1/1] nvmem: imx: add i.MX8QM platform support
From: Srinivas Kandagatla Sent: Tuesday,
August 6, 2019 6:04 PM
> On 04/07/2019 15:20, fugang.d...@nxp.com wrote:
> > From: Fugang Duan
> >
> > i.MX8QM efuse table has some difference with i.MX8QXP platform, so add
> > i.MX8QM platform support.
> >
> > Signed-off-by: Fugang Duan
> > ---
> > drivers/nvmem/imx-ocotp-scu.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c index be2f5f0..0d78ab4 100644
> > --- a/drivers/nvmem/imx-ocotp-scu.c
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -16,6 +16,7 @@
> >
> > enum ocotp_devtype {
> > IMX8QXP,
> > + IMX8QM,
> > };
> >
> > struct ocotp_devtype_data {
> > @@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
> > .nregs = 800,
> > };
> >
> > +static struct ocotp_devtype_data imx8qm_data = {
> > + .devtype = IMX8QM,
> > + .nregs = 800,
> > +};
> > +
> > static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> >u32 *val)
> > {
> > @@ -118,6 +124,7 @@ static struct nvmem_config
> > imx_scu_ocotp_nvmem_config = {
> >
> > static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> > { .compatible = "fsl,imx8qxp-scu-ocotp", (void *)_data
> > },
> > + { .compatible = "fsl,imx8qm-scu-ocotp", (void *)_data },
> > { },
>
> Looks like you forgot to add this new compatible to device tree bindings
> at ./Documentation/devicetree/bindings/nvmem/imx-ocotp.txt or forgot to
> add me to CC.
>
> Please resend the patch with it, I can not apply this as it is.
>
> Thanks,
> srini
There have no separated binding documentation for imx-ocotp-scu.c driver.
It is reasonable to add the new compatible string on below binding file
"fsl,scu.txt":
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>
> > };
> > MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
> >
Re: [PATCH RFC tip/core/rcu 02/14] rcu/nocb: Add bypass callback queueing
On Tue, Aug 06, 2019 at 09:24:15PM -0400, Steven Rostedt wrote: > On Tue, 6 Aug 2019 18:17:07 -0700 > "Paul E. McKenney" wrote: > > > On Tue, Aug 06, 2019 at 08:40:55PM -0400, Steven Rostedt wrote: > > > On Tue, 6 Aug 2019 17:35:01 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > > > + // Don't use ->nocb_bypass during early boot. > > > > > > > > > > Very minor nit: comment style should be /* */ > > > > > > > > I thought that Linus said that "//" was now OK. Am I confused? > > > > > > Have a link? > > > > https://lkml.org/lkml/2016/7/8/625 > > The (c) form is particularly good for things like enum or structure > member comments at the end of code, where you might want to align > things up, but the ending comment marker ends up being visually pretty > distracting (and lining _that_ up is too much make-believe work). > > I think it's still for special occasions, and the above example doesn't > look like one of them ;-) It does say "particularly good for", not "only good for. ;-) > I basically avoid the '//' comment, as it just adds inconstancy. It saves me two whacks on the shift key and three whacks on other keys. ;-) Thanx, Paul
Re: Slowness forming TIPC cluster with explicit node addresses
Hi Jon, On Wed, 2019-08-07 at 02:55 +, Jon Maloy wrote: > > > > > -Original Message- > > From: Chris Packham > > Sent: 4-Aug-19 19:05 > > To: Jon Maloy ; tipc- > > discuss...@lists.sourceforge.net > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: Slowness forming TIPC cluster with explicit node > > addresses > > > > On Sun, 2019-08-04 at 21:53 +, Jon Maloy wrote: > > > > > > > > > > > > > > > > > > -Original Message- > > > > From: netdev-ow...@vger.kernel.org > > > g> > > On > > > > > > > > > > > Behalf Of Chris Packham > > > > Sent: 2-Aug-19 01:11 > > > > To: Jon Maloy ; tipc- > > > > discuss...@lists.sourceforge.net > > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Subject: Re: Slowness forming TIPC cluster with explicit node > > > > addresses > > > > > > > > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote: > > > > > > > > > > > > > > > On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: netdev-ow...@vger.kernel.org > > > ow...@vger.kernel.org> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Behalf Of Chris Packham > > > > > > > Sent: 25-Jul-19 19:37 > > > > > > > To: tipc-discuss...@lists.sourceforge.net > > > > > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > > > Subject: Slowness forming TIPC cluster with explicit node > > > > > > > addresses > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm having problems forming a TIPC cluster between 2 > > > > > > > nodes. > > > > > > > > > > > > > > This is the basic steps I'm going through on each node. > > > > > > > > > > > > > > modprobe tipc > > > > > > > ip link set eth2 up > > > > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable > > > > > > > media > > > > > > > eth dev eth0 > > > > > > eth2, I assume... > > > > > > > > > > > Yes sorry I keep switching between between Ethernet ports for > > > > > testing > > > > > so I hand edited the email. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then to confirm if the cluster is formed I use tipc link > > > > > > > list > > > > > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > > > broadcast-link: up > > > > > > > ... > > > > > > > > > > > > > > Looking at tcpdump the two nodes are sending packets > > > > > > > > > > > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 > > > > > > > bytes, > > > > > > > MessageSize > > > > > > > 76 bytes, Neighbor Detection Protocol internal, > > > > > > > messageType > > > > > > > Link > > > > > > > request > > > > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 > > > > > > > bytes, > > > > > > > MessageSize > > > > > > > 76 bytes, Neighbor Detection Protocol internal, > > > > > > > messageType > > > > > > > Link > > > > > > > request > > > > > > > > > > > > > > Eventually (after a few minutes) the link does come up > > > > > > > > > > > > > > [root@node-6 ~]# tipc link list > > > > > > > broadcast-link: up > > > > > > > 1001006:eth2-1001005:eth2: up > > > > > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > > > broadcast-link: up > > > > > > > 1001005:eth2-1001006:eth2: up > > > > > > > > > > > > > > When I remove the "tipc node set addr" things seem to > > > > > > > kick > > > > > > > into > > > > > > > life straight away > > > > > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > > > broadcast-link: up > > > > > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up > > > > > > > > > > > > > > So there appears to be some difference in behaviour > > > > > > > between > > > > > > > having > > > > > > > an explicit node address and using the default. > > > > > > > Unfortunately > > > > > > > our > > > > > > > application relies on setting the node addresses. > > > > > > I do this many times a day, without any problems. If there > > > > > > would be > > > > > > any time difference, I would expect the 'auto configurable' > > > > > > version > > > > > > to be slower, because it involves a DAD step. > > > > > > Are you sure you don't have any other nodes running in your > > > > > > system? > > > > > > > > > > > > ///jon > > > > > > > > > > > Nope the two nodes are connected back to back. Does the > > > > > number of > > > > > Ethernet interfaces make a difference? As you can see I've > > > > > got 3 > > > > > on > > > > > each node. One is completely disconnected, one is for booting > > > > > over > > > > > TFTP > > > > > (only used by U-boot) and the other is the USB Ethernet I'm > > > > > using for > > > > > testing. > > > > > > > > > So I can still reproduce this on nodes that only have one > > > > network > > > > interface and > > > > are the only things
Re: [PATCH v7 01/20] pinctrl: tegra: Add suspend and resume support
On 8/6/19 2:51 PM, Sowjanya Komatineni wrote: On 8/5/19 2:20 AM, Linus Walleij wrote: On Wed, Jul 31, 2019 at 11:11 PM Sowjanya Komatineni wrote: This patch adds support for Tegra pinctrl driver suspend and resume. During suspend, context of all pinctrl registers are stored and on resume they are all restored to have all the pinmux and pad configuration for normal operation. Acked-by: Thierry Reding Reviewed-by: Dmitry Osipenko Signed-off-by: Sowjanya Komatineni Patch applied to the pinctrl tree. This patch seems finished. Also if the rest don't get merged for v5.4 then at least this is so your patch stack gets more shallow. I hope it's fine to merge this separately, else tell me and I'll pull it out. Yours, Linus Walleij Yes, this patch can be merged separately. But, there's latest feedback from Dmitry to add barrier after writes to make sure pinmux register writes happen. So will update this patch to add barrier in v8. So, need to wait for v8. Thanks Sowjanya I see it merged. So will exclude suspend/resume patch and will add patch for necessary write barrier fix in v8 version. Thanks Sowjanya
[PATCH v2 4/4] perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
Kernel requires CAP_SYS_ADMIN instead of euid==0 to mount debugfs for ftrace.
Make perf do the same.
Signed-off-by: Igor Lubashev
---
tools/perf/builtin-ftrace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
index ae1466aa3b26..d09eac8a6d57 100644
--- a/tools/perf/builtin-ftrace.c
+++ b/tools/perf/builtin-ftrace.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "debug.h"
#include
@@ -21,6 +22,7 @@
#include "target.h"
#include "cpumap.h"
#include "thread_map.h"
+#include "util/cap.h"
#include "util/config.h"
@@ -281,7 +283,7 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int
argc, const char **argv)
.events = POLLIN,
};
- if (geteuid() != 0) {
+ if (!perf_cap__capable(CAP_SYS_ADMIN)) {
pr_err("ftrace only works for root!\n");
return -1;
}
--
2.7.4
[PATCH v2 0/4] perf: Use capabilities instead of uid and euid
Series v1: https://lkml.kernel.org/lkml/1562112605-6235-1-git-send-email-iluba...@akamai.com Kernel is using capabilities instead of uid and euid to restrict access to kernel pointers and tracing facilities. This patch series updates the perf to better match the security model used by the kernel. This series enables instructions in Documentation/admin-guide/perf-security.rst to actually work, even when kernel.perf_event_paranoid=2 and kernel.kptr_restrict=1. The series consists of four patches: 01: perf: Add capability-related utilities Add utility functions to check capabilities and perf_event_paranoid checks, if libcap-dev[el] is available. (Otherwise, assume no capabilities.) 02: perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever perf_event_paranoid level is verified. 03: perf: Use CAP_SYSLOG with kptr_restrict checks Replace the use of uid and euid with a check for CAP_SYSLOG when kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c). Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c). 04: perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace Replace the use of euid==0 with a check for CAP_SYS_ADMIN before mounting debugfs for ftrace. I tested this by following Documentation/admin-guide/perf-security.rst guidelines and setting sysctls: kernel.perf_event_paranoid=2 kernel.kptr_restrict=1 As an unpriviledged user who is in perf_users group (setup via instructions above), I executed: perf record -a -- sleep 1 Without the patch, perf record did not capture any kernel functions. With the patch, perf included all kernel funcitons. Changelog: v2: * Added a build feature check for libcap-dev[el] as suggested by Arnaldo Igor Lubashev (4): perf: Add capability-related utilities perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks perf: Use CAP_SYSLOG with kptr_restrict checks perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace tools/build/Makefile.feature | 2 ++ tools/build/feature/Makefile | 4 tools/build/feature/test-libcap.c| 20 tools/perf/Makefile.config | 11 +++ tools/perf/Makefile.perf | 2 ++ tools/perf/arch/arm/util/cs-etm.c| 3 ++- tools/perf/arch/arm64/util/arm-spe.c | 4 ++-- tools/perf/arch/x86/util/intel-bts.c | 3 ++- tools/perf/arch/x86/util/intel-pt.c | 2 +- tools/perf/builtin-ftrace.c | 4 +++- tools/perf/util/Build| 2 ++ tools/perf/util/cap.c| 29 + tools/perf/util/cap.h| 24 tools/perf/util/event.h | 1 + tools/perf/util/evsel.c | 2 +- tools/perf/util/python-ext-sources | 1 + tools/perf/util/symbol.c | 15 +++ tools/perf/util/util.c | 9 + 18 files changed, 127 insertions(+), 11 deletions(-) create mode 100644 tools/build/feature/test-libcap.c create mode 100644 tools/perf/util/cap.c create mode 100644 tools/perf/util/cap.h -- 2.7.4
[PATCH v2 2/4] perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
The kernel is using CAP_SYS_ADMIN instead of euid==0 to override
perf_event_paranoid check. Make perf do the same.
Signed-off-by: Igor Lubashev
---
tools/perf/arch/arm/util/cs-etm.c| 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 4 ++--
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/util/evsel.c | 2 +-
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/perf/arch/arm/util/cs-etm.c
b/tools/perf/arch/arm/util/cs-etm.c
index 5cb07e8cb296..b87a1ca2968f 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -18,6 +18,7 @@
#include "../../perf.h"
#include "../../util/auxtrace.h"
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evlist.h"
#include "../../util/evsel.h"
#include "../../util/pmu.h"
@@ -254,7 +255,7 @@ static int cs_etm_recording_options(struct auxtrace_record
*itr,
struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
struct evsel *evsel, *cs_etm_evsel = NULL;
struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = (geteuid() == 0 || perf_event_paranoid() < 0);
+ bool privileged = perf_event_paranoid_check(-1);
int err = 0;
ptr->evlist = evlist;
diff --git a/tools/perf/arch/arm64/util/arm-spe.c
b/tools/perf/arch/arm64/util/arm-spe.c
index 00915b8fd05b..200bc973371b 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -12,6 +12,7 @@
#include
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -65,8 +66,7 @@ static int arm_spe_recording_options(struct auxtrace_record
*itr,
struct arm_spe_recording *sper =
container_of(itr, struct arm_spe_recording, itr);
struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
- struct evsel *evsel, *arm_spe_evsel = NULL;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
struct evsel *tracking_evsel;
int err;
diff --git a/tools/perf/arch/x86/util/intel-bts.c
b/tools/perf/arch/x86/util/intel-bts.c
index 7b23318ebd7b..56a76142e9fd 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -12,6 +12,7 @@
#include
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -107,7 +108,7 @@ static int intel_bts_recording_options(struct
auxtrace_record *itr,
struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
struct evsel *evsel, *intel_bts_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
btsr->evlist = evlist;
btsr->snapshot_mode = opts->auxtrace_snapshot_mode;
diff --git a/tools/perf/arch/x86/util/intel-pt.c
b/tools/perf/arch/x86/util/intel-pt.c
index 218a4e694618..43d5088ee824 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -558,7 +558,7 @@ static int intel_pt_recording_options(struct
auxtrace_record *itr,
bool have_timing_info, need_immediate = false;
struct evsel *evsel, *intel_pt_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
u64 tsc_bit;
int err;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 64bc32ed6dfa..eafc134bf17c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr
*attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return geteuid() == 0 || perf_event_paranoid() == -1;
+ return perf_event_paranoid_check(-1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
[PATCH v2 1/4] perf: Add capability-related utilities
Add utilities to help checking capabilities of the running procss.
Make perf link with libcap, if it is available. If no libcap-dev[el],
assume no capabilities.
Signed-off-by: Igor Lubashev
---
tools/build/Makefile.feature | 2 ++
tools/build/feature/Makefile | 4
tools/build/feature/test-libcap.c | 20
tools/perf/Makefile.config | 11 +++
tools/perf/Makefile.perf | 2 ++
tools/perf/util/Build | 2 ++
tools/perf/util/cap.c | 29 +
tools/perf/util/cap.h | 24
tools/perf/util/event.h| 1 +
tools/perf/util/python-ext-sources | 1 +
tools/perf/util/util.c | 9 +
11 files changed, 105 insertions(+)
create mode 100644 tools/build/feature/test-libcap.c
create mode 100644 tools/perf/util/cap.c
create mode 100644 tools/perf/util/cap.h
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 86b793dffbc4..8a19753cc26a 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -42,6 +42,7 @@ FEATURE_TESTS_BASIC := \
gtk2-infobar\
libaudit\
libbfd \
+libcap \
libelf \
libelf-getphdrnum \
libelf-gelf_getnote \
@@ -110,6 +111,7 @@ FEATURE_DISPLAY ?= \
gtk2 \
libaudit \
libbfd \
+ libcap \
libelf \
libnuma\
numa_num_possible_cpus \
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 0658b8cd0e53..8499385365c0 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -20,6 +20,7 @@ FILES= \
test-libbfd-liberty.bin\
test-libbfd-liberty-z.bin \
test-cplus-demangle.bin\
+ test-libcap.bin \
test-libelf.bin\
test-libelf-getphdrnum.bin \
test-libelf-gelf_getnote.bin \
@@ -105,6 +106,9 @@ $(OUTPUT)test-fortify-source.bin:
$(OUTPUT)test-bionic.bin:
$(BUILD)
+$(OUTPUT)test-libcap.bin:
+ $(BUILD) -lcap
+
$(OUTPUT)test-libelf.bin:
$(BUILD) -lelf
diff --git a/tools/build/feature/test-libcap.c
b/tools/build/feature/test-libcap.c
new file mode 100644
index ..d2a2e152195f
--- /dev/null
+++ b/tools/build/feature/test-libcap.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+
+int main(void)
+{
+ cap_flag_value_t val;
+ cap_t caps = cap_get_proc();
+
+ if (!caps)
+ return 1;
+
+ if (cap_get_flag(caps, CAP_SYS_ADMIN, CAP_EFFECTIVE, ) != 0)
+ return 1;
+
+ if (cap_free(caps) != 0)
+ return 1;
+
+ return 0;
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index e4988f49ea79..9a06787fedc6 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -824,6 +824,17 @@ ifndef NO_LIBZSTD
endif
endif
+ifndef NO_LIBCAP
+ ifeq ($(feature-libcap), 1)
+CFLAGS += -DHAVE_LIBCAP_SUPPORT
+EXTLIBS += -lcap
+$(call detected,CONFIG_LIBCAP)
+ else
+msg := $(warning No libcap found, disables capability support, please
install libcap-devel/libcap-dev);
+NO_LIBCAP := 1
+ endif
+endif
+
ifndef NO_BACKTRACE
ifeq ($(feature-backtrace), 1)
CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 67512a12276b..f9807d8c005b 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -88,6 +88,8 @@ include ../scripts/utilities.mak
#
# Define NO_LIBBPF if you do not want BPF support
#
+# Define NO_LIBCAP if you do not want process capabilities considered by perf
+#
# Define NO_SDT if you do not want to define SDT event in perf tools,
# note that it doesn't disable SDT scanning support.
#
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 7abf05131889..7cda749059a9 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -148,6 +148,8 @@ perf-$(CONFIG_ZLIB) += zlib.o
perf-$(CONFIG_LZMA) += lzma.o
perf-$(CONFIG_ZSTD) += zstd.o
+perf-$(CONFIG_LIBCAP) += cap.o
+
perf-y += demangle-java.o
perf-y += demangle-rust.o
diff --git a/tools/perf/util/cap.c b/tools/perf/util/cap.c
new file mode 100644
index ..c3ba841bbf37
--- /dev/null
+++ b/tools/perf/util/cap.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Capability utilities
+ */
+
+#ifdef HAVE_LIBCAP_SUPPORT
+
+#include "cap.h"
+#include
+#include
+
+bool
[PATCH v2 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
Kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0 when
checking kptr_restrict. Make perf do the same.
Also, the kernel is a more restrictive than "no restrictions" in case of
kptr_restrict==0, so add the same logic to perf.
Signed-off-by: Igor Lubashev
---
tools/perf/util/symbol.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 173f3378aaa0..046271103499 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -15,8 +16,10 @@
#include
#include "annotate.h"
#include "build-id.h"
+#include "cap.h"
#include "util.h"
#include "debug.h"
+#include "event.h"
#include "machine.h"
#include "map.h"
#include "symbol.h"
@@ -890,7 +893,11 @@ bool symbol__restricted_filename(const char *filename,
{
bool restricted = false;
- if (symbol_conf.kptr_restrict) {
+ /* Per kernel/kallsyms.c:
+* we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
+*/
+ if (symbol_conf.kptr_restrict ||
+ (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))) {
char *r = realpath(filename, NULL);
if (r != NULL) {
@@ -2190,9 +2197,9 @@ static bool symbol__read_kptr_restrict(void)
char line[8];
if (fgets(line, sizeof(line), fp) != NULL)
- value = ((geteuid() != 0) || (getuid() != 0)) ?
- (atoi(line) != 0) :
- (atoi(line) == 2);
+ value = perf_cap__capable(CAP_SYSLOG) ?
+ (atoi(line) >= 2) :
+ (atoi(line) != 0);
fclose(fp);
}
--
2.7.4
[PATCH] RDMA/hns: remove obsolete Kconfig comment
Since commit a07fc0bb483e ("RDMA/hns: Fix build error")
these kconfig comment is obsolete, so just remove it.
Signed-off-by: YueHaibing
---
drivers/infiniband/hw/hns/Kconfig | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/infiniband/hw/hns/Kconfig
b/drivers/infiniband/hw/hns/Kconfig
index 5478219..d602b69 100644
--- a/drivers/infiniband/hw/hns/Kconfig
+++ b/drivers/infiniband/hw/hns/Kconfig
@@ -8,8 +8,6 @@ config INFINIBAND_HNS
is used in Hisilicon Hip06 and more further ICT SoC based on
platform device.
- To compile HIP06 or HIP08 driver as module, choose M here.
-
config INFINIBAND_HNS_HIP06
tristate "Hisilicon Hip06 Family RoCE support"
depends on INFINIBAND_HNS && HNS && HNS_DSAF && HNS_ENET
@@ -17,15 +15,9 @@ config INFINIBAND_HNS_HIP06
RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip06 and
Hip07 SoC. These RoCE engines are platform devices.
- To compile this driver, choose Y here: if INFINIBAND_HNS is m, this
- module will be called hns-roce-hw-v1
-
config INFINIBAND_HNS_HIP08
tristate "Hisilicon Hip08 Family RoCE support"
depends on INFINIBAND_HNS && PCI && HNS3
---help---
RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip08 SoC.
The RoCE engine is a PCI device.
-
- To compile this driver, choose Y here: if INFINIBAND_HNS is m, this
- module will be called hns-roce-hw-v2.
--
2.7.4
[PATCH] ALSA: usb-midi: fix a memory leak bug
In __snd_usbmidi_create(), a MIDI streaming interface structure is allocated through kzalloc() and the pointer is saved to 'umidi'. Later on, the endpoint structures are created by invoking snd_usbmidi_create_endpoints_midiman() or snd_usbmidi_create_endpoints(), depending on the type of the audio quirk type. However, if the creation fails, the allocated 'umidi' is not deallocated, leading to a memory leak bug. To fix the above issue, free 'umidi' before returning the error. Signed-off-by: Wenwen Wang --- sound/usb/midi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/midi.c b/sound/usb/midi.c index b737f0e..22db37f 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -2476,7 +2476,7 @@ int __snd_usbmidi_create(struct snd_card *card, else err = snd_usbmidi_create_endpoints(umidi, endpoints); if (err < 0) - goto exit; + goto free_midi; usb_autopm_get_interface_no_resume(umidi->iface); -- 2.7.4
Re: [PATCH v4 09/10] powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter
On 2019/8/6 15:59, Christophe Leroy wrote:
Le 05/08/2019 à 08:43, Jason Yan a écrit :
One may want to disable kaslr when boot, so provide a cmdline parameter
'nokaslr' to support this.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by: Diana Craciun
Tested-by: Diana Craciun
Reviewed-by: Christophe Leroy
Tiny comment below.
---
arch/powerpc/kernel/kaslr_booke.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/kernel/kaslr_booke.c
b/arch/powerpc/kernel/kaslr_booke.c
index 4b3f19a663fc..7c3cb41e7122 100644
--- a/arch/powerpc/kernel/kaslr_booke.c
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -361,6 +361,18 @@ static unsigned long __init
kaslr_choose_location(void *dt_ptr, phys_addr_t size
return kaslr_offset;
}
+static inline __init bool kaslr_disabled(void)
+{
+ char *str;
+
+ str = strstr(boot_command_line, "nokaslr");
+ if ((str == boot_command_line) ||
+ (str > boot_command_line && *(str - 1) == ' '))
+ return true;
I don't think additional () are needed for the left part 'str ==
boot_command_line'
Agree.
+
+ return false;
+}
+
/*
* To see if we need to relocate the kernel to a random offset
* void *dt_ptr - address of the device tree
@@ -376,6 +388,8 @@ notrace void __init kaslr_early_init(void *dt_ptr,
phys_addr_t size)
kernel_sz = (unsigned long)_end - KERNELBASE;
kaslr_get_cmdline(dt_ptr);
+ if (kaslr_disabled())
+ return;
offset = kaslr_choose_location(dt_ptr, size, kernel_sz);
.
Re: [PATCH] arch/microblaze: add support for get_user() of size 8 bytes
On Tue, Aug 06, 2019 at 03:36:37PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> arch/microblaze/ is missing support for get_user() of size 8 bytes,
> so add it by using __copy_from_user().
>
> Fixes these build errors:
>drivers/infiniband/core/uverbs_main.o: In function `ib_uverbs_write':
>drivers/infiniband/core/.tmp_gl_uverbs_main.o:(.text+0x13a4): undefined
> reference to `__user_bad'
>drivers/android/binder.o: In function `binder_thread_write':
>drivers/android/.tmp_gl_binder.o:(.text+0xda6c): undefined reference to
> `__user_bad'
>drivers/android/.tmp_gl_binder.o:(.text+0xda98): undefined reference to
> `__user_bad'
>drivers/android/.tmp_gl_binder.o:(.text+0xdf10): undefined reference to
> `__user_bad'
>drivers/android/.tmp_gl_binder.o:(.text+0xe498): undefined reference to
> `__user_bad'
>drivers/android/binder.o:drivers/android/.tmp_gl_binder.o:(.text+0xea78):
> more undefined references to `__user_bad' follow
>
> 'make allmodconfig' now builds successfully for arch/microblaze/.
>
> Fixes: 538722ca3b76 ("microblaze: fix get_user/put_user side-effects")
> Reported-by: kbuild test robot
> Signed-off-by: Randy Dunlap
> Cc: Al Viro
> Cc: Steven J. Magnani
> Cc: Michal Simek
> Cc: Jason Gunthorpe
> Cc: Leon Romanovsky
> Cc: Andrew Morton
> ---
> arch/microblaze/include/asm/uaccess.h |6 ++
> 1 file changed, 6 insertions(+)
>
Thanks, it works for us.
Reviewed-by: Leon Romanovsky
Re: [PATCH net v2] net: dsa: Check existence of .port_mdb_add callback before calling it
On Wed, Aug 7, 2019 at 4:34 AM Vivien Didelot wrote:
>
> Hi Chen-Yu,
>
> On Wed, 7 Aug 2019 01:49:37 +0800, Chen-Yu Tsai wrote:
> > On Wed, Aug 7, 2019 at 1:15 AM Vivien Didelot
> > wrote:
> > >
> > > Hi Chen-Yu,
> > >
> > > On Tue, 6 Aug 2019 15:53:25 +0800, Chen-Yu Tsai wrote:
> > > > From: Chen-Yu Tsai
> > > >
> > > > With the recent addition of commit 75dad2520fc3 ("net: dsa: b53: Disable
> > > > all ports on setup"), users of b53 (BCM53125 on Lamobo R1 in my case)
> > > > are forced to use the dsa subsystem to enable the switch, instead of
> > > > having it in the default transparent "forward-to-all" mode.
> > > >
> > > > The b53 driver does not support mdb bitmap functions. However the dsa
> > > > layer does not check for the existence of the .port_mdb_add callback
> > > > before actually using it. This results in a NULL pointer dereference,
> > > > as shown in the kernel oops below.
> > > >
> > > > The other functions seem to be properly guarded. Do the same for
> > > > .port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
> > > >
> > > > b53 is not the only driver that doesn't support mdb bitmap functions.
> > > > Others include bcm_sf2, dsa_loop, lantiq_gswip, mt7530, mv88e6060,
> > > > qca8k, realtek-smi, and vitesse-vsc73xx.
> > >
> > > I don't know what you mean by that, there's no "mdb bitmap function"
> > > support for drivers, only the port_mdb_{prepare,add,del} callbacks...
> >
> > The term was coined from commit e6db98db8a95 ("net: dsa: add switch mdb
> > bitmap functions"). But yeah, .port_mdb_* ops/callbacks would be more
> > appropriate.
> >
> > > > 8<--- cut here ---
> > > > Unable to handle kernel NULL pointer dereference at virtual address
> > > >
> > > > pgd = (ptrval)
> > > > [] *pgd=
> > > > Internal error: Oops: 8005 [#1] SMP ARM
> > > > Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common
> > > > rtlwifi mac80211 cfg80211
> > > > CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted
> > > > 5.3.0-rc1-00247-gd3519030752a #1
> > > > Hardware name: Allwinner sun7i (A20) Family
> > > > Workqueue: events switchdev_deferred_process_work
> > > > PC is at 0x0
> > > > LR is at dsa_switch_event+0x570/0x620
> > > > pc : [<>]lr : []psr: 80070013
> > > > sp : ee871db8 ip : fp : ee98d0a4
> > > > r10: 000c r9 : 0008 r8 : ee89f710
> > > > r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
> > > > r3 : r2 : ee89f710 r1 : 0008 r0 : ee98d040
> > > > Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > > > Control: 10c5387d Table: 6deb406a DAC: 0051
> > > > Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
> > > > Stack: (0xee871db8 to 0xee872000)
> > > > 1da0:
> > > > ee871e14 103ace2d
> > > > 1dc0: ee871e14 0005
> > > > c08524a0
> > > > 1de0: e000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000
> > > > c0851120 c014bef0
> > > > 1e00: b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710
> > > > ee871ecb
> > > > 1e20: 0008 103ace2d c087e248 ee29c868 103ace2d
> > > > 0001
> > > > 1e40: ee871e98 0006 c0fb2a50 c087e2d0
> > > > c08523c4
> > > > 1e60: c014bdfc 0006 c0fad2d0 ee871e98 ee89f710
> > > > c014c500
> > > > 1e80: ee89f3c0 c0f04c48 ee9e5000 c087dfb4
> > > > ee9e5000
> > > > 1ea0: ee89f710 ee871ecb 0001 103ace2d c0f04c48
> > > > c087e0a8
> > > > 1ec0: efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710
> > > > ee9e5000 0122
> > > > 1ee0: 0100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c
> > > > 2e928000 c0fad2ec
> > > > 1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 c087def8
> > > > c0fad2ec c01447dc
> > > > 1f20: ef315640 ef7a62c0 0008 ee839580 ee839594 ef7a62c0
> > > > 0008 c0f03d00
> > > > 1f40: ef7a62d8 ef7a62c0 e000 c0145b84 e000 c0fb2420
> > > > c0bfaa8c
> > > > 1f60: e000 ee84b600 ee84b5c0 ee87 ee839580
> > > > c0145b40 ef0e5ea4
> > > > 1f80: ee84b61c c014a6f8 0001 ee84b5c0 c014a5b0
> > > >
> > > > 1fa0: c01010e8
> > > >
> > > > 1fc0:
> > > >
> > > > 1fe0: 0013
> > > >
> > > > [] (dsa_switch_event) from []
> > > > (notifier_call_chain+0x48/0x84)
> > > > [] (notifier_call_chain) from []
> > > > (raw_notifier_call_chain+0x18/0x20)
> > > > [] (raw_notifier_call_chain) from []
> > > > (dsa_port_mdb_add+0x48/0x74)
> > > > [] (dsa_port_mdb_add) from []
>
WARNING in cgroup_rstat_updated
Hello,
syzbot found the following crash on:
HEAD commit:31cc088a Merge tag 'drm-next-2019-07-19' of git://anongit...
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=102db48c60
kernel config: https://syzkaller.appspot.com/x/.config?x=4dba67bf8b8c9ad7
dashboard link: https://syzkaller.appspot.com/bug?extid=370e4739fa489334a4ef
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16dd57dc60
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+370e4739fa489334a...@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device batadv0
WARNING: CPU: 1 PID: 9095 at mm/page_counter.c:62 page_counter_cancel
mm/page_counter.c:62 [inline]
WARNING: CPU: 1 PID: 9095 at mm/page_counter.c:62
page_counter_cancel+0x5a/0x70 mm/page_counter.c:55
Kernel panic - not syncing: panic_on_warn set ...
Shutting down cpus with NMI
Kernel Offset: disabled
==
WARNING: possible circular locking dependency detected
5.2.0+ #67 Not tainted
--
syz-executor.2/9306 is trying to acquire lock:
e4252251 ((console_sem).lock){-.-.}, at: down_trylock+0x13/0x70
kernel/locking/semaphore.c:135
but task is already holding lock:
0fdb8781 (per_cpu_ptr(_rstat_cpu_lock, cpu)){-...}, at:
cgroup_rstat_updated+0x115/0x2f0 kernel/cgroup/rstat.c:49
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (per_cpu_ptr(_rstat_cpu_lock, cpu)){-...}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
cgroup_rstat_updated+0x115/0x2f0 kernel/cgroup/rstat.c:49
cgroup_base_stat_cputime_account_end.isra.0+0x1d/0x60
kernel/cgroup/rstat.c:361
__cgroup_account_cputime+0x9e/0xd0 kernel/cgroup/rstat.c:371
cgroup_account_cputime include/linux/cgroup.h:782 [inline]
update_curr+0x3c8/0x8d0 kernel/sched/fair.c:862
dequeue_entity+0x1e/0x1100 kernel/sched/fair.c:4014
dequeue_task_fair+0x65/0x870 kernel/sched/fair.c:5306
dequeue_task+0x77/0x2e0 kernel/sched/core.c:1195
sched_move_task+0x1fb/0x350 kernel/sched/core.c:6847
cpu_cgroup_attach+0x6d/0xb0 kernel/sched/core.c:6970
cgroup_migrate_execute+0xc56/0x1350 kernel/cgroup/cgroup.c:2524
cgroup_migrate+0x14f/0x1f0 kernel/cgroup/cgroup.c:2780
cgroup_attach_task+0x57f/0x860 kernel/cgroup/cgroup.c:2817
cgroup_procs_write+0x340/0x400 kernel/cgroup/cgroup.c:4777
cgroup_file_write+0x241/0x790 kernel/cgroup/cgroup.c:3754
kernfs_fop_write+0x2b8/0x480 fs/kernfs/file.c:315
__vfs_write+0x8a/0x110 fs/read_write.c:494
vfs_write+0x268/0x5d0 fs/read_write.c:558
ksys_write+0x14f/0x290 fs/read_write.c:611
__do_sys_write fs/read_write.c:623 [inline]
__se_sys_write fs/read_write.c:620 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:620
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #2 (>lock){-.-.}:
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
rq_lock kernel/sched/sched.h:1207 [inline]
task_fork_fair+0x6a/0x520 kernel/sched/fair.c:9940
sched_fork+0x3af/0x900 kernel/sched/core.c:2783
copy_process+0x1b04/0x6b00 kernel/fork.c:1987
_do_fork+0x146/0xfa0 kernel/fork.c:2369
kernel_thread+0xbb/0xf0 kernel/fork.c:2456
rest_init+0x28/0x37b init/main.c:417
arch_call_rest_init+0xe/0x1b
start_kernel+0x912/0x951 init/main.c:785
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:472
x86_64_start_kernel+0x77/0x7b arch/x86/kernel/head64.c:453
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
-> #1 (>pi_lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
try_to_wake_up+0xb0/0x1aa0 kernel/sched/core.c:2432
wake_up_process+0x10/0x20 kernel/sched/core.c:2548
__up.isra.0+0x136/0x1a0 kernel/locking/semaphore.c:261
up+0x9c/0xe0 kernel/locking/semaphore.c:186
__up_console_sem+0xb7/0x1c0 kernel/printk/printk.c:244
console_unlock+0x695/0xf10 kernel/printk/printk.c:2481
vprintk_emit+0x2a0/0x700 kernel/printk/printk.c:1986
vprintk_default+0x28/0x30 kernel/printk/printk.c:2013
vprintk_func+0x7e/0x189 kernel/printk/printk_safe.c:386
printk+0xba/0xed kernel/printk/printk.c:2046
check_stack_usage kernel/exit.c:765 [inline]
do_exit.cold+0x18b/0x314 kernel/exit.c:927
do_group_exit+0x135/0x360 kernel/exit.c:981
__do_sys_exit_group
Re: [PATCH v3] mlx5: Use refcount_t for refcount
On Tue, Aug 06, 2019 at 08:40:11PM +, Saeed Mahameed wrote: > On Tue, 2019-08-06 at 09:59 +0800, Chuhong Yuan wrote: > > Reference counters are preferred to use refcount_t instead of > > atomic_t. > > This is because the implementation of refcount_t can prevent > > overflows and detect possible use-after-free. > > So convert atomic_t ref counters to refcount_t. > > > > Signed-off-by: Chuhong Yuan > > --- > > Changes in v3: > > - Merge v2 patches together. > > > > drivers/infiniband/hw/mlx5/srq_cmd.c | 6 +++--- > > drivers/net/ethernet/mellanox/mlx5/core/qp.c | 6 +++--- > > include/linux/mlx5/driver.h | 3 ++- > > 3 files changed, 8 insertions(+), 7 deletions(-) > > > > LGTM, Leon, let me know if you are happy with this version, > this should go to mlx5-next. Thanks, Acked-by: Leon Romanovsky
Re: [PATCH v4 07/10] powerpc/fsl_booke/32: randomize the kernel image offset
On 2019/8/6 15:56, Christophe Leroy wrote:
Le 05/08/2019 à 08:43, Jason Yan a écrit :
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally the bootloader may
pass entropy via the /chosen/kaslr-seed node in device tree.
We will use the first 512M of the low memory to randomize the kernel
image. The memory will be split in 64M zones. We will use the lower 8
bit of the entropy to decide the index of the 64M zone. Then we chose a
16K aligned offset inside the 64M zone to put the kernel in.
KERNELBASE
|--> 64M <--|
| |
+---+ ++---+
| || |kernel| | |
+---+ ++---+
| |
|-> offset <-|
kimage_vaddr
We also check if we will overlap with some areas like the dtb area, the
initrd area or the crashkernel area. If we cannot find a proper area,
kaslr will be disabled and boot from the original kernel.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by: Diana Craciun
Tested-by: Diana Craciun
Reviewed-by: Christophe Leroy
Thanks for your help,
One small comment below
---
arch/powerpc/kernel/kaslr_booke.c | 322 +-
1 file changed, 320 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/kaslr_booke.c
b/arch/powerpc/kernel/kaslr_booke.c
index 30f84c0321b2..97250cad71de 100644
--- a/arch/powerpc/kernel/kaslr_booke.c
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -34,15 +36,329 @@
#include
#include
#include
+#include
#include
+#include
+#include
+
+#ifdef DEBUG
+#define DBG(fmt...) printk(KERN_ERR fmt)
+#else
+#define DBG(fmt...)
+#endif
+
+struct regions {
+ unsigned long pa_start;
+ unsigned long pa_end;
+ unsigned long kernel_size;
+ unsigned long dtb_start;
+ unsigned long dtb_end;
+ unsigned long initrd_start;
+ unsigned long initrd_end;
+ unsigned long crash_start;
+ unsigned long crash_end;
+ int reserved_mem;
+ int reserved_mem_addr_cells;
+ int reserved_mem_size_cells;
+};
extern int is_second_reloc;
+/* Simplified build-specific string for starting entropy. */
+static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+ LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+
+static __init void kaslr_get_cmdline(void *fdt)
+{
+ int node = fdt_path_offset(fdt, "/chosen");
+
+ early_init_dt_scan_chosen(node, "chosen", 1, boot_command_line);
+}
+
+static unsigned long __init rotate_xor(unsigned long hash, const void
*area,
+ size_t size)
+{
+ size_t i;
+ unsigned long *ptr = (unsigned long *)area;
As area is a void *, this cast shouldn't be necessary. Or maybe it is
necessary because it discards the const ?
It's true the cast is not necessary. The ptr can be made const and then
remove the cast.
Christophe
[PATCH] team: Add vlan tx offload to hw_enc_features
We should also enable bonding's vlan tx offload in hw_enc_features,
pass the vlan packets to the slave devices with vlan tci, let them
to handle vlan tunneling offload implementation.
Fixes: 3268e5cb494d ("team: Advertise tunneling offload features")
Signed-off-by: YueHaibing
---
drivers/net/team/team.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index abfa0da..e8089de 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1004,6 +1004,8 @@ static void __team_compute_features(struct team *team)
team->dev->vlan_features = vlan_features;
team->dev->hw_enc_features = enc_features | NETIF_F_GSO_ENCAP_ALL |
+NETIF_F_HW_VLAN_CTAG_TX |
+NETIF_F_HW_VLAN_STAG_TX |
NETIF_F_GSO_UDP_L4;
team->dev->hard_header_len = max_hard_header_len;
--
2.7.4
Re: [PATCH 1/2] KEYS: Replace uid/gid/perm permissions checking with an ACL
On Tue, Jul 30, 2019 at 06:16:14PM -0700, Eric Biggers wrote:
> On Mon, Jul 29, 2019 at 08:49:56PM -0700, Eric Biggers wrote:
> > Hi David,
> >
> > On Tue, Jul 09, 2019 at 06:16:01PM -0700, Eric Biggers wrote:
> > > On Thu, May 23, 2019 at 04:58:27PM +0100, David Howells wrote:
> > > > Replace the uid/gid/perm permissions checking on a key with an ACL to
> > > > allow
> > > > the SETATTR and SEARCH permissions to be split. This will also allow a
> > > > greater range of subjects to represented.
> > > >
> > >
> > > This patch broke 'keyctl new_session', and hence broke all the fscrypt
> > > tests:
> > >
> > > $ keyctl new_session
> > > keyctl_session_to_parent: Permission denied
> > >
> > > Output of 'keyctl show' is
> > >
> > > $ keyctl show
> > > Session Keyring
> > > 605894913 --alswrv 0 0 keyring: _ses
> > > 189223103 s-rv 0 0 \_ user: invocation_id
> > >
> > > - Eric
> >
> > This bug is still present in next-20190729.
> >
> > - Eric
>
> This fixes it:
>
> diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
> index aa3bfcadbc660..519c94f1cc3c2 100644
> --- a/security/keys/process_keys.c
> +++ b/security/keys/process_keys.c
> @@ -58,7 +58,7 @@ static struct key_acl session_keyring_acl = {
> .possessor_viewable = true,
> .nr_ace = 2,
> .aces = {
> - KEY_POSSESSOR_ACE(KEY_ACE__PERMS & ~KEY_ACE_JOIN),
> + KEY_POSSESSOR_ACE(KEY_ACE__PERMS),
> KEY_OWNER_ACE(KEY_ACE_VIEW | KEY_ACE_READ),
> }
> };
>
>
> The old permissions were KEY_POS_ALL | KEY_USR_VIEW | KEY_USR_READ, so
> I'm not sure why JOIN permission was removed?
>
> - Eric
Ping. This is still broken in linux-next.
- Eric
RE: Slowness forming TIPC cluster with explicit node addresses
> -Original Message-
> From: Chris Packham
> Sent: 4-Aug-19 19:05
> To: Jon Maloy ; tipc-
> discuss...@lists.sourceforge.net
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Slowness forming TIPC cluster with explicit node addresses
>
> On Sun, 2019-08-04 at 21:53 +, Jon Maloy wrote:
> >
> > >
> > > -Original Message-
> > > From: netdev-ow...@vger.kernel.org
> On
> > > Behalf Of Chris Packham
> > > Sent: 2-Aug-19 01:11
> > > To: Jon Maloy ; tipc-
> > > discuss...@lists.sourceforge.net
> > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: Slowness forming TIPC cluster with explicit node
> > > addresses
> > >
> > > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> > > >
> > > > On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote:
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: netdev-ow...@vger.kernel.org > > ow...@vger.kernel.org>
> > > >
> > > > >
> > > > > >
> > > > > > On Behalf Of Chris Packham
> > > > > > Sent: 25-Jul-19 19:37
> > > > > > To: tipc-discuss...@lists.sourceforge.net
> > > > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > > Subject: Slowness forming TIPC cluster with explicit node
> > > > > > addresses
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm having problems forming a TIPC cluster between 2 nodes.
> > > > > >
> > > > > > This is the basic steps I'm going through on each node.
> > > > > >
> > > > > > modprobe tipc
> > > > > > ip link set eth2 up
> > > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable media
> > > > > > eth dev eth0
> > > > > eth2, I assume...
> > > > >
> > > > Yes sorry I keep switching between between Ethernet ports for
> > > > testing
> > > > so I hand edited the email.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Then to confirm if the cluster is formed I use tipc link list
> > > > > >
> > > > > > [root@node-5 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > ...
> > > > > >
> > > > > > Looking at tcpdump the two nodes are sending packets
> > > > > >
> > > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60
> > > > > > bytes,
> > > > > > MessageSize
> > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType
> > > > > > Link
> > > > > > request
> > > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60
> > > > > > bytes,
> > > > > > MessageSize
> > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType
> > > > > > Link
> > > > > > request
> > > > > >
> > > > > > Eventually (after a few minutes) the link does come up
> > > > > >
> > > > > > [root@node-6 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > 1001006:eth2-1001005:eth2: up
> > > > > >
> > > > > > [root@node-5 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > 1001005:eth2-1001006:eth2: up
> > > > > >
> > > > > > When I remove the "tipc node set addr" things seem to kick
> > > > > > into
> > > > > > life straight away
> > > > > >
> > > > > > [root@node-5 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > > > > >
> > > > > > So there appears to be some difference in behaviour between
> > > > > > having
> > > > > > an explicit node address and using the default. Unfortunately
> > > > > > our
> > > > > > application relies on setting the node addresses.
> > > > > I do this many times a day, without any problems. If there
> > > > > would be
> > > > > any time difference, I would expect the 'auto configurable'
> > > > > version
> > > > > to be slower, because it involves a DAD step.
> > > > > Are you sure you don't have any other nodes running in your
> > > > > system?
> > > > >
> > > > > ///jon
> > > > >
> > > > Nope the two nodes are connected back to back. Does the number of
> > > > Ethernet interfaces make a difference? As you can see I've got 3
> > > > on
> > > > each node. One is completely disconnected, one is for booting
> > > > over
> > > > TFTP
> > > > (only used by U-boot) and the other is the USB Ethernet I'm
> > > > using for
> > > > testing.
> > > >
> > > So I can still reproduce this on nodes that only have one network
> > > interface and
> > > are the only things connected.
> > >
> > > I did find one thing that helps
> > >
> > > diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
> > > c138d68e8a69..49921dad404a 100644
> > > --- a/net/tipc/discover.c
> > > +++ b/net/tipc/discover.c
> > > @@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
> > > tipc_bearer *b,
> > > tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
> > >
> > > /* Do we need an address trial period first ? */
> > > - if (!tipc_own_addr(net)) {
> > > +// if (!tipc_own_addr(net)) {
> > > tn->addr_trial_end = jiffies +
> > > msecs_to_jiffies(1000);
> > >
[PATCH] xilinx_sdfec: Convert to IDA
From: "Matthew Wilcox (Oracle)"
This driver does not use the lookup abilities of the IDR, so convert it
to the more space-efficient IDA.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/misc/xilinx_sdfec.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index f257d3812110..071b26a8c6a9 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -22,8 +22,7 @@
#define DEV_NAME_LEN 12
-static struct idr dev_idr;
-static struct mutex dev_idr_lock;
+static DEFINE_IDA(dev_nrs);
/**
* struct xsdfec_clks - For managing SD-FEC clocks
@@ -227,13 +226,6 @@ static void xsdfec_disable_all_clks(struct xsdfec_clks
*clks)
clk_disable_unprepare(clks->axi_clk);
}
-static void xsdfec_idr_remove(struct xsdfec_dev *xsdfec)
-{
- mutex_lock(_idr_lock);
- idr_remove(_idr, xsdfec->dev_id);
- mutex_unlock(_idr_lock);
-}
-
static int xsdfec_probe(struct platform_device *pdev)
{
struct xsdfec_dev *xsdfec;
@@ -263,9 +255,7 @@ static int xsdfec_probe(struct platform_device *pdev)
/* Save driver private data */
platform_set_drvdata(pdev, xsdfec);
- mutex_lock(_idr_lock);
- err = idr_alloc(_idr, xsdfec->dev_name, 0, 0, GFP_KERNEL);
- mutex_unlock(_idr_lock);
+ err = ida_alloc(_nrs, GFP_KERNEL);
if (err < 0)
goto err_xsdfec_dev;
xsdfec->dev_id = err;
@@ -278,12 +268,12 @@ static int xsdfec_probe(struct platform_device *pdev)
err = misc_register(>miscdev);
if (err) {
dev_err(dev, "error:%d. Unable to register device", err);
- goto err_xsdfec_idr;
+ goto err_xsdfec_ida;
}
return 0;
-err_xsdfec_idr:
- xsdfec_idr_remove(xsdfec);
+err_xsdfec_ida:
+ ida_free(_nrs, xsdfec->dev_id);
err_xsdfec_dev:
xsdfec_disable_all_clks(>clks);
return err;
@@ -295,7 +285,7 @@ static int xsdfec_remove(struct platform_device *pdev)
xsdfec = platform_get_drvdata(pdev);
misc_deregister(>miscdev);
- xsdfec_idr_remove(xsdfec);
+ ida_free(_nrs, xsdfec->dev_id);
xsdfec_disable_all_clks(>clks);
return 0;
}
@@ -321,8 +311,6 @@ static int __init xsdfec_init(void)
{
int err;
- mutex_init(_idr_lock);
- idr_init(_idr);
err = platform_driver_register(_driver);
if (err < 0) {
pr_err("%s Unabled to register SDFEC driver", __func__);
@@ -334,7 +322,6 @@ static int __init xsdfec_init(void)
static void __exit xsdfec_exit(void)
{
platform_driver_unregister(_driver);
- idr_destroy(_idr);
}
module_init(xsdfec_init);
--
2.20.1
[PATCH v2 1/1] ixgbe: sync the first fragment unconditionally
In Xen environment, if Xen-swiotlb is enabled, ixgbe driver
could possibly allocate a page, DMA memory buffer, for the first
fragment which is not suitable for Xen-swiotlb to do DMA operations.
Xen-swiotlb have to internally allocate another page for doing DMA
operations. It requires syncing between those two pages. However,
since commit f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path"), the unmap operation is performed with
DMA_ATTR_SKIP_CPU_SYNC. As a result, the sync is not performed.
To fix this problem, always sync before possibly performing a page
unmap operation.
Fixes: f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path")
Reviewed-by: Alexander Duyck
Signed-off-by: Firo Yang
---
Changes from v1:
* Imporved the patch description.
* Added Reviewed-by: and Fixes: as suggested by Alexander Duyck
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712d6529..200de9838096 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1825,13 +1825,7 @@ static void ixgbe_pull_tail(struct ixgbe_ring *rx_ring,
static void ixgbe_dma_sync_frag(struct ixgbe_ring *rx_ring,
struct sk_buff *skb)
{
- /* if the page was released unmap it, else just sync our portion */
- if (unlikely(IXGBE_CB(skb)->page_released)) {
- dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
-ixgbe_rx_pg_size(rx_ring),
-DMA_FROM_DEVICE,
-IXGBE_RX_DMA_ATTR);
- } else if (ring_uses_build_skb(rx_ring)) {
+ if (ring_uses_build_skb(rx_ring)) {
unsigned long offset = (unsigned long)(skb->data) & ~PAGE_MASK;
dma_sync_single_range_for_cpu(rx_ring->dev,
@@ -1848,6 +1842,14 @@ static void ixgbe_dma_sync_frag(struct ixgbe_ring
*rx_ring,
skb_frag_size(frag),
DMA_FROM_DEVICE);
}
+
+ /* If the page was released, just unmap it. */
+ if (unlikely(IXGBE_CB(skb)->page_released)) {
+ dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
+ixgbe_rx_pg_size(rx_ring),
+DMA_FROM_DEVICE,
+IXGBE_RX_DMA_ATTR);
+ }
}
/**
--
2.16.4
[PATCH] libata-sff: use spin_lock_irqsave instead of spin_lock_irq in IRQ context.
Function ata_sff_flush_pio_task use spin_lock_irq/spin_unlock_irq
to protect shared data.
spin_unlock_irq will enable interrupts.
In the interrupt handler nv_swncq_interrupt (./drivers/ata/sata_nv.c),
when ap->link.sactive is true, nv_swncq_host_interrupt was called.
nv_swncq_hotplug is called when NV_SWNCQ_IRQ_HOTPLUG is set.
Then it will follow this chain:
nv_swncq_hotplug -> sata_scr_read (./dirvers/ata/libata-core.c)
-> sata_pmp_scr_read (./drivers/ata/libata-pmp.c)
-> sata_pmp_read -> ata_exec_internal
-> ata_exec_internal_sg -> ata_sff_flush_pio_task
Interrupts are enabled in interrupt handler.
Use spin_lock_irqsave instead of spin_lock_irq to avoid this.
Signed-off-by: Fuqian Huang
---
drivers/ata/libata-sff.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 10aa27882142..d3143e7e6ec0 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1241,6 +1241,7 @@ EXPORT_SYMBOL_GPL(ata_sff_queue_pio_task);
void ata_sff_flush_pio_task(struct ata_port *ap)
{
+ unsigned long flags;
DPRINTK("ENTER\n");
cancel_delayed_work_sync(>sff_pio_task);
@@ -1253,9 +1254,9 @@ void ata_sff_flush_pio_task(struct ata_port *ap)
* __ata_sff_port_intr() checks for HSM_ST_IDLE and before it calls
* ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().
*/
- spin_lock_irq(ap->lock);
+ spin_lock_irqsave(ap->lock, flags);
ap->hsm_task_state = HSM_ST_IDLE;
- spin_unlock_irq(ap->lock);
+ spin_unlock_irqrestore(ap->lock, flags);
ap->sff_pio_task_link = NULL;
--
2.11.0
Re: [PATCH 5.2 03/20] ALSA: usb-audio: Sanity checks for each pipe and EP types
On Fri, Aug 02, 2019 at 05:51:54PM +0200, Greg Kroah-Hartman wrote:
On Fri, Aug 02, 2019 at 09:48:28AM -0400, Sasha Levin wrote:
On Fri, Aug 02, 2019 at 11:39:57AM +0200, Greg Kroah-Hartman wrote:
> From: Takashi Iwai
>
> commit 801ebf1043ae7b182588554cc9b9ad3c14bc2ab5 upstream.
>
> The recent USB core code performs sanity checks for the given pipe and
> EP types, and it can be hit by manipulated USB descriptors by syzbot.
> For making syzbot happier, this patch introduces a local helper for a
> sanity check in the driver side and calls it at each place before the
> message handling, so that we can avoid the WARNING splats.
>
> Reported-by: syzbot+d952e5e28f5fb7718...@syzkaller.appspotmail.com
> Signed-off-by: Takashi Iwai
> Signed-off-by: Greg Kroah-Hartman
This commit has a fix: 5d78e1c2b7f4b ("ALSA: usb-audio: Fix gpf in
snd_usb_pipe_sanity_check") which was not pulled by Linus yet.
I'm going to drop this commit and re-queue it together with it's fix
once it makes it upstream.
Ah, thanks for doing that.
Now queued these two commits for 5.2.
--
Thanks,
Sasha
Re: [PATCH v4 06/12] fpga: dfl: afu: export __port_enable/disable function.
On Mon, Aug 05, 2019 at 05:52:40PM +0200, Greg KH wrote: > On Sun, Aug 04, 2019 at 06:20:16PM +0800, Wu Hao wrote: > > As these two functions are used by other private features. e.g. > > in error reporting private feature, it requires to check port status > > and reset port for error clearing. > > > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > > Acked-by: Moritz Fischer > > Acked-by: Alan Tull > > Signed-off-by: Moritz Fischer > > --- > > v2: rebased > > --- > > drivers/fpga/dfl-afu-main.c | 25 ++--- > > drivers/fpga/dfl-afu.h | 3 +++ > > 2 files changed, 17 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c > > index e013afb..e312179 100644 > > --- a/drivers/fpga/dfl-afu-main.c > > +++ b/drivers/fpga/dfl-afu-main.c > > @@ -22,14 +22,16 @@ > > #include "dfl-afu.h" > > > > /** > > - * port_enable - enable a port > > + * __port_enable - enable a port > > * @pdev: port platform device. > > * > > * Enable Port by clear the port soft reset bit, which is set by default. > > * The AFU is unable to respond to any MMIO access while in reset. > > - * port_enable function should only be used after port_disable function. > > + * __port_enable function should only be used after __port_disable > > function. > > + * > > + * The caller needs to hold lock for protection. > > */ > > -static void port_enable(struct platform_device *pdev) > > +void __port_enable(struct platform_device *pdev) > > worst global function name ever. > > Don't polute the global namespace like this for a single driver. If you > REALLY need it, then use a prefix that shows it is your individual > dfl_special_sauce_platform_device_only type thing. Oh.. Sure.. Let me fix the naming in the next version. Thanks Hao > > thanks, > > greg k-h
Re: linux-next: build failure after merge of the arm64 tree
On Tue, Aug 6, 2019 at 4:50 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the arm64 tree, today's linux-next build (powerpc
> ppc64_defconfig) was just spinning in make - it executing some scripts,
> but it was hard to catch just what.
>
> Apparently caused by commit
>
> 5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR
> relocations")
>
> I have not idea why, but reverting the above commit allows to build
> to finish.
Okay, I can reproduce with:
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- defconfig
*** Default configuration is based on 'ppc64_defconfig'
#
# No change to .config
#
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j72
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
[...]
And confirmed that backing out my patch fixes it.
The problem seems to come from the use of $(NM) in the Kconfig file.
If I apply this diff:
diff --git a/init/Kconfig b/init/Kconfig
index d96127ebc44e0..177a95b323230 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -31,7 +31,7 @@ config CC_HAS_ASM_GOTO
def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
config TOOLS_SUPPORT_RELR
- def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)"
"OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
+ def_bool $(success,$(NM))
config CC_HAS_WARN_MAYBE_UNINITIALIZED
def_bool $(cc-option,-Wmaybe-uninitialized)
I still see the hang. Replacing $(NM) with something else makes it go away.
That leads me to ask what is special about $(NM) + powerpc? It turns
out to be this fragment of arch/powerpc/Makefile:
ifdef CONFIG_PPC64
new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' >
/dev/null; then echo y; else echo n; fi)
ifeq ($(new_nm),y)
NM := $(NM) --synthetic
endif
endif
We're setting NM to something else based on a config option, which I
presume sets up some sort of circular dependency that confuses
Kconfig. Removing this fragment of the makefile (or appending
--synthetic unconditionally) also makes the problem go away.
We should at least able to remove the test for a new-enough binutils.
According to changes.rst we require binutils 2.21 which was released
in 2011, and support for --synthetic was added to binutils in 2004:
https://github.com/bminor/binutils-gdb/commit/0873df2aec48685715d2c5041c1f6f4ed43976c1
But why are we passing --synthetic at all on ppc64? This behaviour
seems to come from this commit from 2004:
https://github.com/mpe/linux-fullhistory/commit/0e32679a4ea48a634d94e97355d47512ef14d71f
which states: "On new toolchains we need to use nm --synthetic or we
miss code symbols."
But I only see a couple of missing symbols if I compare the output of
nm with and without --synthetic on a powerpc64 kernel:
$ diff -u <(powerpc-linux-gnu-nm --synthetic vmlinux)
<(powerpc-linux-gnu-nm vmlinux)
--- /dev/fd/63 2019-08-06 18:48:56.127020621 -0700
+++ /dev/fd/62 2019-08-06 18:48:56.131020636 -0700
@@ -74840,7 +74840,6 @@
c1901b10 D LZ4_decompress_fast
c07819a0 T .LZ4_decompress_fast_continue
c1901b70 D LZ4_decompress_fast_continue
-c07811e0 t .LZ4_decompress_fast_extDict
c1901b40 d LZ4_decompress_fast_extDict
c0781960 T .LZ4_decompress_fast_usingDict
c1901b58 D LZ4_decompress_fast_usingDict
@@ -74856,7 +74855,6 @@
c1901bd0 D LZ4_decompress_safe_usingDict
c07822b0 T .LZ4_decompress_safe_withPrefix64k
c1901b88 D LZ4_decompress_safe_withPrefix64k
-c0780c60 t .LZ4_decompress_safe_withSmallPrefix
c1901b28 d LZ4_decompress_safe_withSmallPrefix
c077fbe0 T .LZ4_setStreamDecode
c1901ac8 D LZ4_setStreamDecode
I guess the problem was worse back in 2004. It almost certainly didn't
involve these particular symbols because they were added in commit
2209fda323e2fd2a2d0885595fd5097717f8d2aa from 2018. So I guess we have
a couple of possible quick fixes (assuming that the Kconfig issue
can't be solved somehow): either stop passing --synthetic on powerpc
and lose a couple of symbols in 64-bit kernels, or start passing it
unconditionally on powerpc (it doesn't seem to make a difference to
the nm output on a ppc64_defconfig kernel with CONFIG_PPC64=n). I'm
cc'ing the powerpc maintainers for their opinion on what to do. While
this is being resolved we should probably back out my patch from
-next.
Peter
Re: [PATCH 2/2] s390/build: use size command to perform empty .bss check
On Tue, Aug 6, 2019 at 7:56 PM Vasily Gorbik wrote:
>
> Currently empty .bss checks performed do not pay attention to "common
> objects" in object files which end up in .bss section eventually.
>
> The "size" tool is a part of binutils and since version 2.18 provides
> "--common" command line option, which allows to account "common objects"
> sizes in .bss section size. Utilize "size --common" to perform accurate
> check that .bss section is unused. Besides that the size tool handles
> object files without .bss section gracefully and doesn't require
> additional objdump run.
>
> The linux kernel requires binutils 2.20 since 4.13.
>
> Kbuild exports OBJSIZE to reference the right size tool.
>
> Signed-off-by: Vasily Gorbik
> ---
> arch/s390/scripts/Makefile.chkbss | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/s390/scripts/Makefile.chkbss
> b/arch/s390/scripts/Makefile.chkbss
> index 884a9caff5fb..ba1d7a8a242f 100644
> --- a/arch/s390/scripts/Makefile.chkbss
> +++ b/arch/s390/scripts/Makefile.chkbss
> @@ -11,8 +11,7 @@ chkbss: $(addprefix $(obj)/, $(chkbss-files))
>
> quiet_cmd_chkbss = CHKBSS $<
>cmd_chkbss = \
> - if $(OBJDUMP) -h $< | grep -q "\.bss" && \
> - ! $(OBJDUMP) -j .bss -w -h $< | awk 'END { if ($$3) exit 1 }';
> then \
> + if ! $(OBJSIZE) --common $< | awk 'END { if ($$3) exit 1 }'; then \
While you are touching this line,
you may also want to replace 'awk' with $(AWK),
which is defined in the top-level Makefile.
> echo "error: $< .bss section is not empty" >&2; exit 1; \
> fi; \
> touch $@;
> --
> 2.21.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 1/2] kbuild: add OBJSIZE variable for the size tool
Hi. On Tue, Aug 6, 2019 at 7:56 PM Vasily Gorbik wrote: > > Define and export OBJSIZE variable for "size" tool from binutils to be > used in architecture specific Makefiles (naming the variable just "SIZE" > would be too risky). In particular this tool is useful to perform checks > that early boot code is not using bss section (which might have not been > zeroed yet or intersects with initrd or other files boot loader might > have put right after the linux kernel). > > Signed-off-by: Vasily Gorbik I think you want to apply both to the s390 tree. If so, Acked-by: Masahiro Yamada Thanks. > --- > Makefile | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index fa0fbe7851ea..ff4cff29fe46 100644 > --- a/Makefile > +++ b/Makefile > @@ -419,6 +419,7 @@ NM = $(CROSS_COMPILE)nm > STRIP = $(CROSS_COMPILE)strip > OBJCOPY= $(CROSS_COMPILE)objcopy > OBJDUMP= $(CROSS_COMPILE)objdump > +OBJSIZE= $(CROSS_COMPILE)size > PAHOLE = pahole > LEX= flex > YACC = bison > @@ -474,9 +475,9 @@ KBUILD_LDFLAGS := > GCC_PLUGINS_CFLAGS := > > export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS > LD CC > -export CPP AR NM STRIP OBJCOPY OBJDUMP PAHOLE KBUILD_HOSTLDFLAGS > KBUILD_HOSTLDLIBS > -export MAKE LEX YACC AWK INSTALLKERNEL PERL PYTHON PYTHON2 PYTHON3 > UTS_MACHINE > -export HOSTCXX KBUILD_HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS > +export CPP AR NM STRIP OBJCOPY OBJDUMP OBJSIZE PAHOLE LEX YACC AWK > INSTALLKERNEL > +export PERL PYTHON PYTHON2 PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX > +export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS > LDFLAGS_MODULE > > export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS > KBUILD_LDFLAGS > export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE > -- > 2.21.0 > -- Best Regards Masahiro Yamada
RE: Realtek r8822be wireless card fails to work with new rtw88 kernel module
> + yhchuang > > On Tue, Aug 6, 2019 at 7:32 AM 고준 wrote: > > > > Hello, > > > > I recently reported a bug to Ubuntu regarding a regression in wireless > > driver support for the Realtek r8822be wireless chipset. The issue > > link on launchpad is: > > > > https://bugs.launchpad.net/bugs/1838133 > > > > After Canonical developers triaged the bug they determined that the > > problem lies upstream, and instructed me to send mails to the relevant > > kernel module maintainers at Realtek and to the general kernel.org > > mailing list. > > > > I built kernel 5.3.0-rc1+ with the latest realtek drivers from > > wireless-drivers-next but my Realtek r8822be doesn't work with > > rtw88/rtwpci kernel modules. > > > > Please let me know if there is any additional information I can > > provide that would help in debugging this issue. > > Any chance this would help you? > > https://patchwork.kernel.org/patch/11065631/ > > Somebody else was complaining about 8822be regressions that were fixed > with that. > I hope it could fix it. And as "r8822be" was dropped, it is preferred to use "rtw88" instead. I have received two kinds of failures that cause driver stop working. One is the MSI interrupt should be enabled on certain platforms. Another is the RFE type of the card, could you send more dmesg to me? Yan-Hsuan
[PATCH] riscv: kbuild: drop CONFIG_RISCV_ISA_C
The baseline ISA support requirement for the RISC-V Linux kernel mandates compressed instructions, so it doesn't make sense for compressed instruction support to be configurable. Signed-off-by: Paul Walmsley Cc: Atish Patra --- arch/riscv/Kconfig | 10 -- arch/riscv/Makefile | 2 +- 2 files changed, 1 insertion(+), 11 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 59a4727ecd6c..8c5b9329ec46 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -197,16 +197,6 @@ config TUNE_GENERIC endchoice -config RISCV_ISA_C - bool "Emit compressed instructions when building Linux" - default y - help - Adds "C" to the ISA subsets that the toolchain is allowed to emit - when building Linux, which results in compressed instructions in the - Linux binary. - - If you don't know what to do here, say Y. - menu "supported PMU type" depends on PERF_EVENTS diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 7a117be8297c..e23e066c55e2 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -38,7 +38,7 @@ endif riscv-march-$(CONFIG_ARCH_RV32I) := rv32ima riscv-march-$(CONFIG_ARCH_RV64I) := rv64ima riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd -riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c +riscv-march-y := $(riscv-march-y)c KBUILD_CFLAGS += -march=$(subst fd,,$(riscv-march-y)) KBUILD_AFLAGS += -march=$(riscv-march-y) -- 2.22.0
Re: [PATCH 4.19 02/74] ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200
On Mon, Aug 05, 2019 at 04:41:12PM +0200, Pavel Machek wrote:
Hi!
[ Upstream commit 1c0479023412ab7834f2e98b796eb0d8c627cd62 ]
As some point hs200 was failing on rk3288-veyron-minnie. See commit
984926781122 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed
from rk3288 minnie"). Although I didn't track down exactly when it
started working, it seems to work OK now, so let's turn it back on.
To test this, I booted from SD card and then used this script to
stress the enumeration process after fixing a memory leak [1]:
cd /sys/bus/platform/drivers/dwmmc_rockchip
for i in $(seq 1 3000); do
echo "" $i
echo ff0f.dwmmc > unbind
sleep .5
echo ff0f.dwmmc > bind
while true; do
if [ -e /dev/mmcblk2 ]; then
break;
fi
sleep .1
done
done
It worked fine.
This may not be suitable for stable. So... hs200 started working in
mainline sometime. That does not mean it was fixed in all the various
stable trees, too.
How was this tested in respective -stable releases?
If you know of any other patches required on older stable kernels to
make this work I'll be more than happy to take them...
--
Thanks,
Sasha
[PATCH v2] soc: qcom: socinfo: Annotate switch cases with fall through
Introduce fall through annotations in the switch statements of
socinfo_debugfs_init() to silence compiler warnings.
Fixes: 9c84c1e78634 ("soc: qcom: socinfo: Expose custom attributes")
Reported-by: Stephen Rothwell
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/socinfo.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 855353bed19e..a39ea5061dc5 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -323,6 +323,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_x32("raw_device_number", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.raw_device_num);
+ /* Fall through */
case SOCINFO_VERSION(0, 11):
case SOCINFO_VERSION(0, 10):
case SOCINFO_VERSION(0, 9):
@@ -330,10 +331,12 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_u32("foundry_id", 0400, qcom_socinfo->dbg_root,
_socinfo->info.foundry_id);
+ /* Fall through */
case SOCINFO_VERSION(0, 8):
case SOCINFO_VERSION(0, 7):
DEBUGFS_ADD(info, pmic_model);
DEBUGFS_ADD(info, pmic_die_rev);
+ /* Fall through */
case SOCINFO_VERSION(0, 6):
qcom_socinfo->info.hw_plat_subtype =
__le32_to_cpu(info->hw_plat_subtype);
@@ -341,6 +344,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_u32("hardware_platform_subtype", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.hw_plat_subtype);
+ /* Fall through */
case SOCINFO_VERSION(0, 5):
qcom_socinfo->info.accessory_chip =
__le32_to_cpu(info->accessory_chip);
@@ -348,23 +352,27 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_u32("accessory_chip", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.accessory_chip);
+ /* Fall through */
case SOCINFO_VERSION(0, 4):
qcom_socinfo->info.plat_ver = __le32_to_cpu(info->plat_ver);
debugfs_create_u32("platform_version", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.plat_ver);
+ /* Fall through */
case SOCINFO_VERSION(0, 3):
qcom_socinfo->info.hw_plat = __le32_to_cpu(info->hw_plat);
debugfs_create_u32("hardware_platform", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.hw_plat);
+ /* Fall through */
case SOCINFO_VERSION(0, 2):
qcom_socinfo->info.raw_ver = __le32_to_cpu(info->raw_ver);
debugfs_create_u32("raw_version", 0400, qcom_socinfo->dbg_root,
_socinfo->info.raw_ver);
+ /* Fall through */
case SOCINFO_VERSION(0, 1):
DEBUGFS_ADD(info, build_id);
break;
--
2.18.0
[PATCH v3] gpio: mpc8xxx: Add new platforms GPIO DT node description
From: Song Hui
Update the NXP GPIO node dt-binding file for QorIQ and
Layerscape platforms, and add one more example with
ls1028a GPIO node.
Signed-off-by: Song Hui
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index 69d4616..baf95d9 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : Should be "fsl,-gpio"
The following s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
- ls1021a, ls1043a, ls2080a.
+ ls1021a, ls1043a, ls2080a, ls1028a.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
@@ -37,3 +37,17 @@ gpio0: gpio@230 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+
+Example of gpio-controller node for a ls1028a SoC:
+
+gpio1: gpio@230 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x230 0x0 0x1>;
+ interrupts = ;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+};
--
2.9.5
[PATCH v2] bonding: Add vlan tx offload to hw_enc_features
As commit 30d8177e8ac7 ("bonding: Always enable vlan tx offload")
said, we should always enable bonding's vlan tx offload, pass the
vlan packets to the slave devices with vlan tci, let them to handle
vlan implementation.
Now if encapsulation protocols like VXLAN is used, skb->encapsulation
may be set, then the packet is passed to vlan device which based on
bonding device. However in netif_skb_features(), the check of
hw_enc_features:
if (skb->encapsulation)
features &= dev->hw_enc_features;
clears NETIF_F_HW_VLAN_CTAG_TX/NETIF_F_HW_VLAN_STAG_TX. This results
in same issue in commit 30d8177e8ac7 like this:
vlan_dev_hard_start_xmit
-->dev_queue_xmit
-->validate_xmit_skb
-->netif_skb_features //NETIF_F_HW_VLAN_CTAG_TX is cleared
-->validate_xmit_vlan
-->__vlan_hwaccel_push_inside //skb->tci is cleared
...
--> bond_start_xmit
--> bond_xmit_hash //BOND_XMIT_POLICY_ENCAP34
--> __skb_flow_dissect // nhoff point to IP header
--> case htons(ETH_P_8021Q)
// skb_vlan_tag_present is false, so
vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
//vlan point to ip header wrongly
Fixes: b2a103e6d0af ("bonding: convert to ndo_fix_features")
Signed-off-by: YueHaibing
Acked-by: Jay Vosburgh
---
v2: fix a log typo, add Fixes tag
---
drivers/net/bonding/bond_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 02fd782..931d9d9 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1126,6 +1126,8 @@ static void bond_compute_features(struct bonding *bond)
done:
bond_dev->vlan_features = vlan_features;
bond_dev->hw_enc_features = enc_features | NETIF_F_GSO_ENCAP_ALL |
+ NETIF_F_HW_VLAN_CTAG_TX |
+ NETIF_F_HW_VLAN_STAG_TX |
NETIF_F_GSO_UDP_L4;
bond_dev->mpls_features = mpls_features;
bond_dev->gso_max_segs = gso_max_segs;
--
2.7.4
Re: [PATCH] soc: qcom: socinfo: Annotate switch cases with fall through
On Tue 06 Aug 18:50 PDT 2019, Stephen Rothwell wrote: > Hi Bjorn, > > On Tue, 6 Aug 2019 18:24:57 -0700 Bjorn Andersson > wrote: > > > >qcom_socinfo->dbg_root, > >_socinfo->info.raw_device_num); > > + /* Fall through */ > > case SOCINFO_VERSION(0, 11): > > + /* Fall through */ > > case SOCINFO_VERSION(0, 10): > > + /* Fall through */ > > case SOCINFO_VERSION(0, 9): > > I don't think you need the comment between consecutive "case"s - just > where there is actual code. > You're right, will respin the patch. Thanks, Bjorn
[v5 PATCH 3/4] mm: shrinker: make shrinker not depend on memcg kmem
Currently shrinker is just allocated and can work when memcg kmem is
enabled. But, THP deferred split shrinker is not slab shrinker, it
doesn't make too much sense to have such shrinker depend on memcg kmem.
It should be able to reclaim THP even though memcg kmem is disabled.
Introduce a new shrinker flag, SHRINKER_NONSLAB, for non-slab shrinker.
When memcg kmem is disabled, just such shrinkers can be called in
shrinking memcg slab.
Cc: Kirill Tkhai
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: David Rientjes
Cc: Qian Cai
Acked-by: Kirill A. Shutemov
Signed-off-by: Yang Shi
---
include/linux/memcontrol.h | 19 ---
include/linux/shrinker.h | 3 ++-
mm/memcontrol.c| 9 +--
mm/vmscan.c| 60 --
4 files changed, 45 insertions(+), 46 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 44c4146..5771816 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -128,9 +128,8 @@ struct mem_cgroup_per_node {
struct mem_cgroup_reclaim_iter iter[DEF_PRIORITY + 1];
-#ifdef CONFIG_MEMCG_KMEM
struct memcg_shrinker_map __rcu *shrinker_map;
-#endif
+
struct rb_node tree_node; /* RB tree node */
unsigned long usage_in_excess;/* Set to the value by which */
/* the soft limit is exceeded*/
@@ -1253,6 +1252,11 @@ static inline bool
mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg)
} while ((memcg = parent_mem_cgroup(memcg)));
return false;
}
+
+extern int memcg_expand_shrinker_maps(int new_id);
+
+extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
+ int nid, int shrinker_id);
#else
#define mem_cgroup_sockets_enabled 0
static inline void mem_cgroup_sk_alloc(struct sock *sk) { };
@@ -1261,6 +1265,11 @@ static inline bool
mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg)
{
return false;
}
+
+static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
+ int nid, int shrinker_id)
+{
+}
#endif
struct kmem_cache *memcg_kmem_get_cache(struct kmem_cache *cachep);
@@ -1332,10 +1341,6 @@ static inline int memcg_cache_id(struct mem_cgroup
*memcg)
return memcg ? memcg->kmemcg_id : -1;
}
-extern int memcg_expand_shrinker_maps(int new_id);
-
-extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
- int nid, int shrinker_id);
#else
static inline int memcg_kmem_charge(struct page *page, gfp_t gfp, int order)
@@ -1377,8 +1382,6 @@ static inline void memcg_put_cache_ids(void)
{
}
-static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
- int nid, int shrinker_id) { }
#endif /* CONFIG_MEMCG_KMEM */
#endif /* _LINUX_MEMCONTROL_H */
diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 9443caf..9e112d6 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -69,7 +69,7 @@ struct shrinker {
/* These are for internal use */
struct list_head list;
-#ifdef CONFIG_MEMCG_KMEM
+#ifdef CONFIG_MEMCG
/* ID in shrinker_idr */
int id;
#endif
@@ -81,6 +81,7 @@ struct shrinker {
/* Flags */
#define SHRINKER_NUMA_AWARE(1 << 0)
#define SHRINKER_MEMCG_AWARE (1 << 1)
+#define SHRINKER_NONSLAB (1 << 2)
extern int prealloc_shrinker(struct shrinker *shrinker);
extern void register_shrinker_prepared(struct shrinker *shrinker);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cdbb7a8..d90ded1 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -313,6 +313,7 @@ void memcg_put_cache_ids(void)
EXPORT_SYMBOL(memcg_kmem_enabled_key);
struct workqueue_struct *memcg_kmem_cache_wq;
+#endif
static int memcg_shrinker_map_size;
static DEFINE_MUTEX(memcg_shrinker_map_mutex);
@@ -436,14 +437,6 @@ void memcg_set_shrinker_bit(struct mem_cgroup *memcg, int
nid, int shrinker_id)
}
}
-#else /* CONFIG_MEMCG_KMEM */
-static int memcg_alloc_shrinker_maps(struct mem_cgroup *memcg)
-{
- return 0;
-}
-static void memcg_free_shrinker_maps(struct mem_cgroup *memcg) { }
-#endif /* CONFIG_MEMCG_KMEM */
-
/**
* mem_cgroup_css_from_page - css of the memcg associated with a page
* @page: page of interest
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b1b5e5f..093b76d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -174,11 +174,22 @@ struct scan_control {
*/
unsigned long vm_total_pages;
+static void set_task_reclaim_state(struct task_struct *task,
+ struct reclaim_state *rs)
+{
+ /* Check for an overwrite */
+ WARN_ON_ONCE(rs && task->reclaim_state);
+
+ /* Check for the nulling of an already-nulled member */
+ WARN_ON_ONCE(!rs &&
[v5 PATCH 4/4] mm: thp: make deferred split shrinker memcg aware
Currently THP deferred split shrinker is not memcg aware, this may cause
premature OOM with some configuration. For example the below test would
run into premature OOM easily:
$ cgcreate -g memory:thp
$ echo 4G > /sys/fs/cgroup/memory/thp/memory/limit_in_bytes
$ cgexec -g memory:thp transhuge-stress 4000
transhuge-stress comes from kernel selftest.
It is easy to hit OOM, but there are still a lot THP on the deferred
split queue, memcg direct reclaim can't touch them since the deferred
split shrinker is not memcg aware.
Convert deferred split shrinker memcg aware by introducing per memcg
deferred split queue. The THP should be on either per node or per memcg
deferred split queue if it belongs to a memcg. When the page is
immigrated to the other memcg, it will be immigrated to the target
memcg's deferred split queue too.
Reuse the second tail page's deferred_list for per memcg list since the
same THP can't be on multiple deferred split queues.
Cc: Kirill Tkhai
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: David Rientjes
Cc: Qian Cai
Acked-by: Kirill A. Shutemov
Signed-off-by: Yang Shi
---
include/linux/huge_mm.h| 9 ++
include/linux/memcontrol.h | 4 +++
include/linux/mm_types.h | 1 +
mm/huge_memory.c | 76 +++---
mm/memcontrol.c| 24 +++
5 files changed, 103 insertions(+), 11 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 45ede62..61c9ffd 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -267,6 +267,15 @@ static inline bool thp_migration_supported(void)
return IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION);
}
+static inline struct list_head *page_deferred_list(struct page *page)
+{
+ /*
+* Global or memcg deferred list in the second tail pages is
+* occupied by compound_head.
+*/
+ return [2].deferred_list;
+}
+
#else /* CONFIG_TRANSPARENT_HUGEPAGE */
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
#define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 5771816..cace365 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -312,6 +312,10 @@ struct mem_cgroup {
struct list_head event_list;
spinlock_t event_list_lock;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ struct deferred_split deferred_split_queue;
+#endif
+
struct mem_cgroup_per_node *nodeinfo[0];
/* WARNING: nodeinfo must be the last member here */
};
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 3a37a89..156640c 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -139,6 +139,7 @@ struct page {
struct {/* Second tail page of compound page */
unsigned long _compound_pad_1; /* compound_head */
unsigned long _compound_pad_2;
+ /* For both global and memcg */
struct list_head deferred_list;
};
struct {/* Page table pages */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index e0d8e08..c9a596e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -495,11 +495,25 @@ pmd_t maybe_pmd_mkwrite(pmd_t pmd, struct vm_area_struct
*vma)
return pmd;
}
-static inline struct list_head *page_deferred_list(struct page *page)
+#ifdef CONFIG_MEMCG
+static inline struct deferred_split *get_deferred_split_queue(struct page
*page)
{
- /* ->lru in the tail pages is occupied by compound_head. */
- return [2].deferred_list;
+ struct mem_cgroup *memcg = compound_head(page)->mem_cgroup;
+ struct pglist_data *pgdat = NODE_DATA(page_to_nid(page));
+
+ if (memcg)
+ return >deferred_split_queue;
+ else
+ return >deferred_split_queue;
+}
+#else
+static inline struct deferred_split *get_deferred_split_queue(struct page
*page)
+{
+ struct pglist_data *pgdat = NODE_DATA(page_to_nid(page));
+
+ return >deferred_split_queue;
}
+#endif
void prep_transhuge_page(struct page *page)
{
@@ -2658,7 +2672,7 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
{
struct page *head = compound_head(page);
struct pglist_data *pgdata = NODE_DATA(page_to_nid(head));
- struct deferred_split *ds_queue = >deferred_split_queue;
+ struct deferred_split *ds_queue = get_deferred_split_queue(page);
struct anon_vma *anon_vma = NULL;
struct address_space *mapping = NULL;
int count, mapcount, extra_pins, ret;
@@ -2794,8 +2808,7 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
void free_transhuge_page(struct page *page)
{
- struct pglist_data *pgdata = NODE_DATA(page_to_nid(page));
- struct deferred_split *ds_queue =
[v5 PATCH 2/4] mm: move mem_cgroup_uncharge out of __page_cache_release()
The later patch would make THP deferred split shrinker memcg aware, but
it needs page->mem_cgroup information in THP destructor, which is called
after mem_cgroup_uncharge() now.
So, move mem_cgroup_uncharge() from __page_cache_release() to compound
page destructor, which is called by both THP and other compound pages
except HugeTLB. And call it in __put_single_page() for single order
page.
Suggested-by: "Kirill A . Shutemov"
Cc: Kirill Tkhai
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: David Rientjes
Cc: Qian Cai
Acked-by: Kirill A. Shutemov
Signed-off-by: Yang Shi
---
mm/page_alloc.c | 1 +
mm/swap.c | 2 +-
mm/vmscan.c | 6 ++
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index df02a88..1d1c5d3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -670,6 +670,7 @@ static void bad_page(struct page *page, const char *reason,
void free_compound_page(struct page *page)
{
+ mem_cgroup_uncharge(page);
__free_pages_ok(page, compound_order(page));
}
diff --git a/mm/swap.c b/mm/swap.c
index ae30039..d4242c8 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -71,12 +71,12 @@ static void __page_cache_release(struct page *page)
spin_unlock_irqrestore(>lru_lock, flags);
}
__ClearPageWaiters(page);
- mem_cgroup_uncharge(page);
}
static void __put_single_page(struct page *page)
{
__page_cache_release(page);
+ mem_cgroup_uncharge(page);
free_unref_page(page);
}
diff --git a/mm/vmscan.c b/mm/vmscan.c
index dbdc46a..b1b5e5f 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1490,10 +1490,9 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
* Is there need to periodically free_page_list? It would
* appear not as the counts should be low
*/
- if (unlikely(PageTransHuge(page))) {
- mem_cgroup_uncharge(page);
+ if (unlikely(PageTransHuge(page)))
(*get_compound_page_dtor(page))(page);
- } else
+ else
list_add(>lru, _pages);
continue;
@@ -1914,7 +1913,6 @@ static unsigned noinline_for_stack
move_pages_to_lru(struct lruvec *lruvec,
if (unlikely(PageCompound(page))) {
spin_unlock_irq(>lru_lock);
- mem_cgroup_uncharge(page);
(*get_compound_page_dtor(page))(page);
spin_lock_irq(>lru_lock);
} else
--
1.8.3.1
[v5 PATCH 0/4] Make deferred split shrinker memcg aware
Currently THP deferred split shrinker is not memcg aware, this may cause premature OOM with some configuration. For example the below test would run into premature OOM easily: $ cgcreate -g memory:thp $ echo 4G > /sys/fs/cgroup/memory/thp/memory/limit_in_bytes $ cgexec -g memory:thp transhuge-stress 4000 transhuge-stress comes from kernel selftest. It is easy to hit OOM, but there are still a lot THP on the deferred split queue, memcg direct reclaim can't touch them since the deferred split shrinker is not memcg aware. Convert deferred split shrinker memcg aware by introducing per memcg deferred split queue. The THP should be on either per node or per memcg deferred split queue if it belongs to a memcg. When the page is immigrated to the other memcg, it will be immigrated to the target memcg's deferred split queue too. Reuse the second tail page's deferred_list for per memcg list since the same THP can't be on multiple deferred split queues. Make deferred split shrinker not depend on memcg kmem since it is not slab. It doesn’t make sense to not shrink THP even though memcg kmem is disabled. With the above change the test demonstrated above doesn’t trigger OOM even though with cgroup.memory=nokmem. Changelog: v5: * Fixed the issue reported by Qian Cai, folded the fix in. * Squashed build fix patches in. v4: * Replace list_del() to list_del_init() per Andrew. * Fixed the build failure for different kconfig combo and tested the below combo: MEMCG + TRANSPARENT_HUGEPAGE !MEMCG + TRANSPARENT_HUGEPAGE MEMCG + !TRANSPARENT_HUGEPAGE !MEMCG + !TRANSPARENT_HUGEPAGE * Added Acked-by from Kirill Shutemov. v3: * Adopted the suggestion from Kirill Shutemov to move mem_cgroup_uncharge() out of __page_cache_release() in order to handle THP free properly. * Adjusted the sequence of the patches per Kirill Shutemov. Dropped the patch 3/4 in v2. * Moved enqueuing THP onto "to" memcg deferred split queue after page->mem_cgroup is changed in memcg account move per Kirill Tkhai. v2: * Adopted the suggestion from Krill Shutemov to extract deferred split fields into a struct to reduce code duplication (patch 1/4). With this change, the lines of change is shrunk down to 198 from 278. * Removed memcg_deferred_list. Use deferred_list for both global and memcg. With the code deduplication, it doesn't make too much sense to keep it. Kirill Tkhai also suggested so. * Fixed typo for SHRINKER_NONSLAB. Yang Shi (4): mm: thp: extract split_queue_* into a struct mm: move mem_cgroup_uncharge out of __page_cache_release() mm: shrinker: make shrinker not depend on memcg kmem mm: thp: make deferred split shrinker memcg aware include/linux/huge_mm.h| 9 ++ include/linux/memcontrol.h | 23 +- include/linux/mm_types.h | 1 + include/linux/mmzone.h | 12 ++-- include/linux/shrinker.h | 3 +- mm/huge_memory.c | 111 ++ mm/memcontrol.c| 33 +++- mm/page_alloc.c| 9 -- mm/swap.c | 2 +- mm/vmscan.c| 66 +++ 10 files changed, 186 insertions(+), 83 deletions(-)
[v5 PATCH 1/4] mm: thp: extract split_queue_* into a struct
Put split_queue, split_queue_lock and split_queue_len into a struct in
order to reduce code duplication when we convert deferred_split to memcg
aware in the later patches.
Suggested-by: "Kirill A . Shutemov"
Cc: Kirill Tkhai
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: David Rientjes
Cc: Qian Cai
Acked-by: Kirill A. Shutemov
Signed-off-by: Yang Shi
---
include/linux/mmzone.h | 12 +---
mm/huge_memory.c | 45 +
mm/page_alloc.c| 8 +---
3 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d77d717..d8ec773 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -676,6 +676,14 @@ struct zonelist {
extern struct page *mem_map;
#endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+struct deferred_split {
+ spinlock_t split_queue_lock;
+ struct list_head split_queue;
+ unsigned long split_queue_len;
+};
+#endif
+
/*
* On NUMA machines, each NUMA node would have a pg_data_t to describe
* it's memory layout. On UMA machines there is a single pglist_data which
@@ -755,9 +763,7 @@ struct zonelist {
#endif /* CONFIG_DEFERRED_STRUCT_PAGE_INIT */
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- spinlock_t split_queue_lock;
- struct list_head split_queue;
- unsigned long split_queue_len;
+ struct deferred_split deferred_split_queue;
#endif
/* Fields commonly accessed by the page reclaim scanner */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 1334ede..e0d8e08 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2658,6 +2658,7 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
{
struct page *head = compound_head(page);
struct pglist_data *pgdata = NODE_DATA(page_to_nid(head));
+ struct deferred_split *ds_queue = >deferred_split_queue;
struct anon_vma *anon_vma = NULL;
struct address_space *mapping = NULL;
int count, mapcount, extra_pins, ret;
@@ -2744,17 +2745,17 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
}
/* Prevent deferred_split_scan() touching ->_refcount */
- spin_lock(>split_queue_lock);
+ spin_lock(_queue->split_queue_lock);
count = page_count(head);
mapcount = total_mapcount(head);
if (!mapcount && page_ref_freeze(head, 1 + extra_pins)) {
if (!list_empty(page_deferred_list(head))) {
- pgdata->split_queue_len--;
+ ds_queue->split_queue_len--;
list_del(page_deferred_list(head));
}
if (mapping)
__dec_node_page_state(page, NR_SHMEM_THPS);
- spin_unlock(>split_queue_lock);
+ spin_unlock(_queue->split_queue_lock);
__split_huge_page(page, list, end, flags);
if (PageSwapCache(head)) {
swp_entry_t entry = { .val = page_private(head) };
@@ -2771,7 +2772,7 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
dump_page(page, "total_mapcount(head) > 0");
BUG();
}
- spin_unlock(>split_queue_lock);
+ spin_unlock(_queue->split_queue_lock);
fail: if (mapping)
xa_unlock(>i_pages);
spin_unlock_irqrestore(>lru_lock, flags);
@@ -2794,52 +2795,56 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
void free_transhuge_page(struct page *page)
{
struct pglist_data *pgdata = NODE_DATA(page_to_nid(page));
+ struct deferred_split *ds_queue = >deferred_split_queue;
unsigned long flags;
- spin_lock_irqsave(>split_queue_lock, flags);
+ spin_lock_irqsave(_queue->split_queue_lock, flags);
if (!list_empty(page_deferred_list(page))) {
- pgdata->split_queue_len--;
+ ds_queue->split_queue_len--;
list_del(page_deferred_list(page));
}
- spin_unlock_irqrestore(>split_queue_lock, flags);
+ spin_unlock_irqrestore(_queue->split_queue_lock, flags);
free_compound_page(page);
}
void deferred_split_huge_page(struct page *page)
{
struct pglist_data *pgdata = NODE_DATA(page_to_nid(page));
+ struct deferred_split *ds_queue = >deferred_split_queue;
unsigned long flags;
VM_BUG_ON_PAGE(!PageTransHuge(page), page);
- spin_lock_irqsave(>split_queue_lock, flags);
+ spin_lock_irqsave(_queue->split_queue_lock, flags);
if (list_empty(page_deferred_list(page))) {
count_vm_event(THP_DEFERRED_SPLIT_PAGE);
- list_add_tail(page_deferred_list(page), >split_queue);
- pgdata->split_queue_len++;
+ list_add_tail(page_deferred_list(page),
[PATCH] riscv: delay: use do_div() instead of __udivdi3()
In preparation for removing __udivdi3() from the RISC-V
architecture-specific files, convert its one user to use do_div().
This avoids breaking the RV32 build after __udivdi3() is removed.
Signed-off-by: Paul Walmsley
---
arch/riscv/lib/delay.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/delay.c b/arch/riscv/lib/delay.c
index 87ff89e88f2c..8c686934e0f6 100644
--- a/arch/riscv/lib/delay.c
+++ b/arch/riscv/lib/delay.c
@@ -81,9 +81,14 @@ EXPORT_SYMBOL(__delay);
void udelay(unsigned long usecs)
{
u64 ucycles = (u64)usecs * lpj_fine * UDELAY_MULT;
+ u64 n;
+ u32 rem;
if (unlikely(usecs > MAX_UDELAY_US)) {
- __delay((u64)usecs * riscv_timebase / 100ULL);
+ n = (u64)usecs * riscv_timebase;
+ rem = do_div(n, 100);
+
+ __delay(n);
return;
}
--
2.22.0
[PATCH] of/platform: Fix device_links_supplier_sync_state_resume() warning
In platforms/devices which have CONFIG_OF turned on but don't have a
populated DT, the calls to device_links_supplier_sync_state_pause() and
device_links_supplier_sync_state_resume() can get mismatched. This will
cause a warning during boot. Fix the warning by making sure the calls are
matched even in that case.
Reported-by: Qian Cai
Signed-off-by: Saravana Kannan
---
drivers/of/platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index a2a4e4b79d43..e5f7e40df439 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -723,7 +723,8 @@ arch_initcall_sync(of_platform_default_populate_init);
static int __init of_platform_sync_state_init(void)
{
- device_links_supplier_sync_state_resume();
+ if (of_have_populated_dt())
+ device_links_supplier_sync_state_resume();
return 0;
}
late_initcall_sync(of_platform_sync_state_init);
--
2.23.0.rc1.153.gdeed80330f-goog
PARTNERSHIP REQUEST,
Dear Friend, I need you to please let me know if there are fast growing investments in your country in which i can invest money in. I have access to a huge amount of money, which i want to invest in your country, i want to know if you can be an agent/partner to me and i will give you a commission of 30% only If you agree to assist me, i will like to know if the commission is ok for you, also i would love to know more about you too. Get Back to me without delay if you are interested Yours Faithfully Simon Beron.
Re: linux-next: Signed-off-by missing for commit in the net-next tree
Hi Stephen, Sure, thanks! Yifeng On Tue, Aug 6, 2019 at 6:54 PM Stephen Rothwell wrote: > > Hi Yifeng, > > On Tue, 6 Aug 2019 16:37:26 -0700 Yifeng Sun wrote: > > > > My apologies, thanks for the email. Please add the signed-off if you can. > > Dave does not rebase his trees, so that is not possible. Just remember > for next time, thanks :-) > > -- > Cheers, > Stephen Rothwell
Re: [PATCH] rtl8712: rtl871x_ioctl_linux.c: fix unnecessary typecast
Sorry folks, I haven't properly tested this before sending the patch
After I've removed the cast, I got this error:
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:668:13: error: SSE
register return with SSE disabled
(fwrq->m >= 2.412e8) &&
~^~~
But I think it's strange since you said that this compiled fine in
your environments.
I think we need to take a deeper look into this.
Kind regards
Em ter, 6 de ago de 2019 às 10:10, David Laight
escreveu:
>
> From: Dan Carpenter
> > Sent: 06 August 2019 12:53
> > On Mon, Aug 05, 2019 at 10:33:29PM -0300, Jose Carlos Cazarin Filho wrote:
> > > Fix checkpath warning:
> > > WARNING: Unnecessary typecast of c90 int constant
> > >
> > > Signed-off-by: Jose Carlos Cazarin Filho
> > > ---
> > > Hello all!
> > > This is my first commit to the Linux Kernel, I'm doing this to learn and
> > > be able
> > > to contribute more in the future
> > > Peace all!
> > > drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > index 944336e0d..da371072e 100644
> > > --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > @@ -665,8 +665,8 @@ static int r8711_wx_set_freq(struct net_device *dev,
> > >
> > > /* If setting by frequency, convert to a channel */
> > > if ((fwrq->e == 1) &&
> > > - (fwrq->m >= (int) 2.412e8) &&
> > > - (fwrq->m <= (int) 2.487e8)) {
> > > + (fwrq->m >= 2.412e8) &&
> > > + (fwrq->m <= 2.487e8)) {
> >
> > I don't think we can do this. You're not allowed to use floats in the
> > kernel (because they make context switching slow). I could have sworn
> > that we use the -nofp to stop the compile when people use floats but
> > this compiles fine for me.
>
> My guess is the 'c90 int constant' text.
>
> It rather implies that '2.412e8' has become the same as '214120'.
> Which is rather worrying because suddenly 'int_var * 2.4e8' might
> be an integer multiply rather than a double one and overflow.
> Have the standard people broken code again?
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
Re: "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
> On Aug 6, 2019, at 9:50 PM, Saravana Kannan wrote: > > Thanks for confirming. I didn't think ARM64 could even boot without > DT. I'll send a fix right away. > > Any chance you can let us know what device this was tested on? It is a HPE Apollo 70 arm64 server. https://h20195.www2.hpe.com/v2/gethtml.aspx?docname=a00039978enw > > -Saravana > > > > -Saravana > > On Tue, Aug 6, 2019 at 6:46 PM Qian Cai wrote: >> >> >> >>> On Aug 6, 2019, at 9:22 PM, Saravana Kannan wrote: >>> >>> On Tue, Aug 6, 2019 at 5:46 PM Qian Cai wrote: >>>> >>>> It looks like the linux-next commit “of/platform: Pause/resume sync state >>>> during init and of_platform_populate()” [1] >>>> Introduced a warning while booting arm64. >>>> >>>> [1] >>>> https://lore.kernel.org/lkml/20190731221721.187713-6-sarava...@google.com/ >>>> >>>> [ 93.449300][T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas >>>> 44-bit (features 0x170d) >>>> [ 93.464873][T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 >>>> entries for cmdq >>>> [ 93.485481][T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 >>>> entries for evtq >>>> [ 93.496320][T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2 >>>> [ 93.502917][T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas >>>> 44-bit (features 0x170d) >>>> [ 93.621818][T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 >>>> entries for cmdq >>>> [ 93.643000][T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 >>>> entries for evtq >>>> [ 94.519445][T1] libphy: Fixed MDIO Bus: probed >>>> [ 94.524649][T1] EFI Variables Facility v0.08 2004-May-17 >>>> [ 94.601166][T1] NET: Registered protocol family 17 >>>> [ 94.766008][T1] zswap: loaded using pool lzo/zbud >>>> [ 94.774745][T1] kmemleak: Kernel memory leak detector initialized >>>> (mempool size: 16384) >>>> [ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started >>>> [ 94.812338][ T1368] pcieport :0f:00.0: Adding to iommu group 0 >>>> [ 94.984466][T1] [ cut here ] >>>> [ 94.989827][T1] Unmatched sync_state pause/resume! >>>> [ 94.989894][T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 >>>> device_links_supplier_sync_state_resume+0x100/0x128 >>>> [ 95.006062][T1] Modules linked in: >>>> [ 95.009815][T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted >>>> 5.3.0-rc3-next-20190806+ #11 >>>> [ 95.018161][T1] Hardware name: HPE Apollo 70 >>>> /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019 >>>> [ 95.028593][T1] pstate: 6049 (nZCv daif +PAN -UAO) >>>> [ 95.034077][T1] pc : >>>> device_links_supplier_sync_state_resume+0x100/0x128 >>>> [ 95.041124][T1] lr : >>>> device_links_supplier_sync_state_resume+0x100/0x128 >>>> [ 95.048167][T1] sp : 34ff800806e6fbc0 >>>> [ 95.052172][T1] x29: 34ff800806e6fc00 x28: >>>> [ 95.058177][T1] x27: x26: >>>> [ 95.064181][T1] x25: 0038 x24: >>>> [ 95.070185][T1] x23: x22: 0019 >>>> [ 95.076189][T1] x21: x20: f9ff808b804e6c50 >>>> [ 95.082193][T1] x19: 100014a6e600 x18: 0040 >>>> [ 95.088197][T1] x17: x16: 86ff80099d581b50 >>>> [ 95.094201][T1] x15: x14: 100010086d1c >>>> [ 95.100205][T1] x13: 1000109d8688 x12: >>>> [ 95.106209][T1] x11: 00f9 x10: 0808b804e6c6 >>>> [ 95.112213][T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00 >>>> [ 95.118217][T1] x7 : 6170206574617473 x6 : 100014076972 >>>> [ 95.124221][T1] x5 : 34ff800806e6f8f0 x4 : 000f >>>> [ 95.130225][T1] x3 : 1000101bfa5c x2 : 0001 >>>> [ 95.136229][T1] x1 : 0001 x0 : 0022 >>>> [ 95.142233][T1] Call trace: >>>> [ 95.145374][T1] device_links_supplier_sync_state_resume+0x100/0x128 >>>> [ 95.152074][T1] of_platform_sync_state_init+0x10/0x1c >>
Re: linux-next: Signed-off-by missing for commit in the net-next tree
Hi Yifeng, On Tue, 6 Aug 2019 16:37:26 -0700 Yifeng Sun wrote: > > My apologies, thanks for the email. Please add the signed-off if you can. Dave does not rebase his trees, so that is not possible. Just remember for next time, thanks :-) -- Cheers, Stephen Rothwell pgpsJqsY4ng0g.pgp Description: OpenPGP digital signature
Re: [PATCH AUTOSEL 5.2 57/59] coredump: split pipe command whitespace before expanding template
On Tue, 2019-08-06 at 17:33 -0400, Sasha Levin wrote: > From: Paul Wise > > [ Upstream commit 315c69261dd3fa12dbc830d4fa00d1fad98d3b03 ] The patch changes the behaviour of the interface between the Linux kernel and userspace core dump handlers. The previous behaviour was unlikely to be depended on by any core dump handler but it is still a behaviour change, so I think it would be best to keep it out of the stable branches and would prefer to have folks encounter the change as Linux distros etc roll out 5.3 and later into their dev releases. We discussed this on #kernelnewbies a while ago and gregkh agreed that it should stew a while longer before reaching any stable releases. In addition if it gets backported to stable releases, my patch for core(5) from man-pages will have to get more complicated :) -- bye, pabs https://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
Re: "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
Thanks for confirming. I didn't think ARM64 could even boot without DT. I'll send a fix right away. Any chance you can let us know what device this was tested on? -Saravana -Saravana On Tue, Aug 6, 2019 at 6:46 PM Qian Cai wrote: > > > > > On Aug 6, 2019, at 9:22 PM, Saravana Kannan wrote: > > > > On Tue, Aug 6, 2019 at 5:46 PM Qian Cai wrote: > >> > >> It looks like the linux-next commit “of/platform: Pause/resume sync state > >> during init and of_platform_populate()” [1] > >> Introduced a warning while booting arm64. > >> > >> [1] > >> https://lore.kernel.org/lkml/20190731221721.187713-6-sarava...@google.com/ > >> > >> [ 93.449300][T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas > >> 44-bit (features 0x170d) > >> [ 93.464873][T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 > >> entries for cmdq > >> [ 93.485481][T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 > >> entries for evtq > >> [ 93.496320][T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2 > >> [ 93.502917][T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas > >> 44-bit (features 0x170d) > >> [ 93.621818][T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 > >> entries for cmdq > >> [ 93.643000][T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 > >> entries for evtq > >> [ 94.519445][T1] libphy: Fixed MDIO Bus: probed > >> [ 94.524649][T1] EFI Variables Facility v0.08 2004-May-17 > >> [ 94.601166][T1] NET: Registered protocol family 17 > >> [ 94.766008][T1] zswap: loaded using pool lzo/zbud > >> [ 94.774745][T1] kmemleak: Kernel memory leak detector initialized > >> (mempool size: 16384) > >> [ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started > >> [ 94.812338][ T1368] pcieport :0f:00.0: Adding to iommu group 0 > >> [ 94.984466][T1] [ cut here ] > >> [ 94.989827][T1] Unmatched sync_state pause/resume! > >> [ 94.989894][T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 > >> device_links_supplier_sync_state_resume+0x100/0x128 > >> [ 95.006062][T1] Modules linked in: > >> [ 95.009815][T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted > >> 5.3.0-rc3-next-20190806+ #11 > >> [ 95.018161][T1] Hardware name: HPE Apollo 70 > >> /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019 > >> [ 95.028593][T1] pstate: 6049 (nZCv daif +PAN -UAO) > >> [ 95.034077][T1] pc : > >> device_links_supplier_sync_state_resume+0x100/0x128 > >> [ 95.041124][T1] lr : > >> device_links_supplier_sync_state_resume+0x100/0x128 > >> [ 95.048167][T1] sp : 34ff800806e6fbc0 > >> [ 95.052172][T1] x29: 34ff800806e6fc00 x28: > >> [ 95.058177][T1] x27: x26: > >> [ 95.064181][T1] x25: 0038 x24: > >> [ 95.070185][T1] x23: x22: 0019 > >> [ 95.076189][T1] x21: x20: f9ff808b804e6c50 > >> [ 95.082193][T1] x19: 100014a6e600 x18: 0040 > >> [ 95.088197][T1] x17: x16: 86ff80099d581b50 > >> [ 95.094201][T1] x15: x14: 100010086d1c > >> [ 95.100205][T1] x13: 1000109d8688 x12: > >> [ 95.106209][T1] x11: 00f9 x10: 0808b804e6c6 > >> [ 95.112213][T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00 > >> [ 95.118217][T1] x7 : 6170206574617473 x6 : 100014076972 > >> [ 95.124221][T1] x5 : 34ff800806e6f8f0 x4 : 000f > >> [ 95.130225][T1] x3 : 1000101bfa5c x2 : 0001 > >> [ 95.136229][T1] x1 : 0001 x0 : 0022 > >> [ 95.142233][T1] Call trace: > >> [ 95.145374][T1] device_links_supplier_sync_state_resume+0x100/0x128 > >> [ 95.152074][T1] of_platform_sync_state_init+0x10/0x1c > >> [ 95.157557][T1] do_one_initcall+0x2f8/0x600 > >> [ 95.162172][T1] do_initcall_level+0x37c/0x3fc > >> [ 95.166959][T1] do_basic_setup+0x34/0x4c > >> [ 95.171313][T1] kernel_init_freeable+0x188/0x24c > >> [ 95.176363][T1] kernel_init+0x18/0x334 > >> [ 95.180543][T1] ret_from_fork+0x10/0x18 > >> [ 95.184809][T1] ---[ end trace a9e
RE: [EXT] Re: [PATCH nvmem 1/1] nvmem: imx: add i.MX8QM platform support
From: Srinivas Kandagatla Sent: Tuesday,
August 6, 2019 6:04 PM
> On 04/07/2019 15:20, fugang.d...@nxp.com wrote:
> > From: Fugang Duan
> >
> > i.MX8QM efuse table has some difference with i.MX8QXP platform, so add
> > i.MX8QM platform support.
> >
> > Signed-off-by: Fugang Duan
> > ---
> > drivers/nvmem/imx-ocotp-scu.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c index be2f5f0..0d78ab4 100644
> > --- a/drivers/nvmem/imx-ocotp-scu.c
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -16,6 +16,7 @@
> >
> > enum ocotp_devtype {
> > IMX8QXP,
> > + IMX8QM,
> > };
> >
> > struct ocotp_devtype_data {
> > @@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
> > .nregs = 800,
> > };
> >
> > +static struct ocotp_devtype_data imx8qm_data = {
> > + .devtype = IMX8QM,
> > + .nregs = 800,
> > +};
> > +
> > static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> >u32 *val)
> > {
> > @@ -118,6 +124,7 @@ static struct nvmem_config
> > imx_scu_ocotp_nvmem_config = {
> >
> > static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> > { .compatible = "fsl,imx8qxp-scu-ocotp", (void *)_data
> > },
> > + { .compatible = "fsl,imx8qm-scu-ocotp", (void *)_data },
> > { },
>
> Looks like you forgot to add this new compatible to device tree bindings
> at ./Documentation/devicetree/bindings/nvmem/imx-ocotp.txt or forgot to
> add me to CC.
>
> Please resend the patch with it, I can not apply this as it is.
>
> Thanks,
> srini
Thanks for your review.
I will send the V2 version including the separated device tree bindings patch.
>
> > };
> > MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
> >
Re: [PATCH] soc: qcom: socinfo: Annotate switch cases with fall through
Hi Bjorn, On Tue, 6 Aug 2019 18:24:57 -0700 Bjorn Andersson wrote: > > qcom_socinfo->dbg_root, > _socinfo->info.raw_device_num); > + /* Fall through */ > case SOCINFO_VERSION(0, 11): > + /* Fall through */ > case SOCINFO_VERSION(0, 10): > + /* Fall through */ > case SOCINFO_VERSION(0, 9): I don't think you need the comment between consecutive "case"s - just where there is actual code. -- Cheers, Stephen Rothwell pgpFORk1OlLDa.pgp Description: OpenPGP digital signature
[PATCH v8 1/3] PM / wakeup: Drop wakeup_source_init(), wakeup_source_prepare()
wakeup_source_init() has no users. Remove it.
As a result, wakeup_source_prepare() is only called from
wakeup_source_create(). Merge wakeup_source_prepare() into
wakeup_source_create() and remove it.
Change wakeup_source_create() behavior so that assigning NULL to wakeup
source's name throws an error.
Signed-off-by: Tri Vo
---
drivers/base/power/wakeup.c | 33 +
include/linux/pm_wakeup.h | 11 ---
2 files changed, 13 insertions(+), 31 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index ee31d4f8d856..3938892c8903 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -72,23 +72,6 @@ static struct wakeup_source deleted_ws = {
.lock = __SPIN_LOCK_UNLOCKED(deleted_ws.lock),
};
-/**
- * wakeup_source_prepare - Prepare a new wakeup source for initialization.
- * @ws: Wakeup source to prepare.
- * @name: Pointer to the name of the new wakeup source.
- *
- * Callers must ensure that the @name string won't be freed when @ws is still
in
- * use.
- */
-void wakeup_source_prepare(struct wakeup_source *ws, const char *name)
-{
- if (ws) {
- memset(ws, 0, sizeof(*ws));
- ws->name = name;
- }
-}
-EXPORT_SYMBOL_GPL(wakeup_source_prepare);
-
/**
* wakeup_source_create - Create a struct wakeup_source object.
* @name: Name of the new wakeup source.
@@ -96,13 +79,23 @@ EXPORT_SYMBOL_GPL(wakeup_source_prepare);
struct wakeup_source *wakeup_source_create(const char *name)
{
struct wakeup_source *ws;
+ const char *ws_name;
- ws = kmalloc(sizeof(*ws), GFP_KERNEL);
+ ws = kzalloc(sizeof(*ws), GFP_KERNEL);
if (!ws)
- return NULL;
+ goto err_ws;
+
+ ws_name = kstrdup_const(name, GFP_KERNEL);
+ if (!ws_name)
+ goto err_name;
+ ws->name = ws_name;
- wakeup_source_prepare(ws, name ? kstrdup_const(name, GFP_KERNEL) :
NULL);
return ws;
+
+err_name:
+ kfree(ws);
+err_ws:
+ return NULL;
}
EXPORT_SYMBOL_GPL(wakeup_source_create);
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 91027602d137..c0cad2d8f800 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -81,7 +81,6 @@ static inline void device_set_wakeup_path(struct device *dev)
}
/* drivers/base/power/wakeup.c */
-extern void wakeup_source_prepare(struct wakeup_source *ws, const char *name);
extern struct wakeup_source *wakeup_source_create(const char *name);
extern void wakeup_source_destroy(struct wakeup_source *ws);
extern void wakeup_source_add(struct wakeup_source *ws);
@@ -112,9 +111,6 @@ static inline bool device_can_wakeup(struct device *dev)
return dev->power.can_wakeup;
}
-static inline void wakeup_source_prepare(struct wakeup_source *ws,
-const char *name) {}
-
static inline struct wakeup_source *wakeup_source_create(const char *name)
{
return NULL;
@@ -181,13 +177,6 @@ static inline void pm_wakeup_dev_event(struct device *dev,
unsigned int msec,
#endif /* !CONFIG_PM_SLEEP */
-static inline void wakeup_source_init(struct wakeup_source *ws,
- const char *name)
-{
- wakeup_source_prepare(ws, name);
- wakeup_source_add(ws);
-}
-
static inline void __pm_wakeup_event(struct wakeup_source *ws, unsigned int
msec)
{
return pm_wakeup_ws_event(ws, msec, false);
--
2.22.0.770.g0f2c4a37fd-goog
[PATCH v8 3/3] PM / wakeup: Show wakeup sources stats in sysfs
Add an ID and a device pointer to 'struct wakeup_source'. Use them to to expose wakeup sources statistics in sysfs under /sys/class/wakeup/wakeup/*. Co-developed-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Co-developed-by: Stephen Boyd Signed-off-by: Stephen Boyd Signed-off-by: Tri Vo Tested-by: Tri Vo Tested-by: Kalesh Singh --- Documentation/ABI/testing/sysfs-class-wakeup | 76 +++ drivers/acpi/device_pm.c | 3 +- drivers/base/power/Makefile | 2 +- drivers/base/power/power.h | 9 + drivers/base/power/wakeup.c | 28 ++- drivers/base/power/wakeup_stats.c| 203 +++ fs/eventpoll.c | 4 +- include/linux/pm_wakeup.h| 10 +- kernel/power/autosleep.c | 2 +- kernel/power/wakelock.c | 2 +- kernel/time/alarmtimer.c | 2 +- 11 files changed, 328 insertions(+), 13 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-wakeup create mode 100644 drivers/base/power/wakeup_stats.c diff --git a/Documentation/ABI/testing/sysfs-class-wakeup b/Documentation/ABI/testing/sysfs-class-wakeup new file mode 100644 index ..754aab8b6dcd --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-wakeup @@ -0,0 +1,76 @@ +What: /sys/class/wakeup/ +Date: June 2019 +Contact: Tri Vo +Description: + The /sys/class/wakeup/ directory contains pointers to all + wakeup sources in the kernel at that moment in time. + +What: /sys/class/wakeup/.../name +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the name of the wakeup source. + +What: /sys/class/wakeup/.../active_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source was + activated. + +What: /sys/class/wakeup/.../event_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of signaled wakeup events + associated with the wakeup source. + +What: /sys/class/wakeup/.../wakeup_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source might + abort suspend. + +What: /sys/class/wakeup/.../expire_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source's + timeout has expired. + +What: /sys/class/wakeup/.../active_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the amount of time the wakeup source has + been continuously active, in milliseconds. If the wakeup + source is not active, this file contains '0'. + +What: /sys/class/wakeup/.../total_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the total amount of time this wakeup source + has been active, in milliseconds. + +What: /sys/class/wakeup/.../max_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the maximum amount of time this wakeup + source has been continuously active, in milliseconds. + +What: /sys/class/wakeup/.../last_change_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the monotonic clock time when the wakeup + source was touched last time, in milliseconds. + +What: /sys/class/wakeup/.../prevent_suspend_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + The file contains the total amount of time this wakeup source + has been preventing autosleep, in milliseconds. diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index 28cffaaf9d82..91634e2dba8a 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -495,7 +495,8 @@ acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev, goto out; mutex_lock(_pm_notifier_lock); - adev->wakeup.ws = wakeup_source_register(dev_name(>dev)); + adev->wakeup.ws = wakeup_source_register(>dev, +dev_name(>dev)); adev->wakeup.context.dev = dev; adev->wakeup.context.func = func; adev->wakeup.flags.notifier_present = true; diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile index e1bb691cf8f1..ec5bb190b9d0 100644 --- a/drivers/base/power/Makefile +++ b/drivers/base/power/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_PM)
[PATCH v8 2/3] PM / wakeup: Use wakeup_source_register() in wakelock.c
kernel/power/wakelock.c duplicates wakeup source creation and
registration code from drivers/base/power/wakeup.c.
Change struct wakelock's wakeup source to a pointer and use
wakeup_source_register() function to create and register said wakeup
source. Use wakeup_source_unregister() on cleanup path.
Signed-off-by: Tri Vo
Reviewed-by: Stephen Boyd
---
kernel/power/wakelock.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/kernel/power/wakelock.c b/kernel/power/wakelock.c
index 4210152e56f0..d1eb7fd98b64 100644
--- a/kernel/power/wakelock.c
+++ b/kernel/power/wakelock.c
@@ -27,7 +27,7 @@ static DEFINE_MUTEX(wakelocks_lock);
struct wakelock {
char*name;
struct rb_node node;
- struct wakeup_sourcews;
+ struct wakeup_source*ws;
#ifdef CONFIG_PM_WAKELOCKS_GC
struct list_headlru;
#endif
@@ -46,7 +46,7 @@ ssize_t pm_show_wakelocks(char *buf, bool show_active)
for (node = rb_first(_tree); node; node = rb_next(node)) {
wl = rb_entry(node, struct wakelock, node);
- if (wl->ws.active == show_active)
+ if (wl->ws->active == show_active)
str += scnprintf(str, end - str, "%s ", wl->name);
}
if (str > buf)
@@ -112,16 +112,16 @@ static void __wakelocks_gc(struct work_struct *work)
u64 idle_time_ns;
bool active;
- spin_lock_irq(>ws.lock);
- idle_time_ns = ktime_to_ns(ktime_sub(now, wl->ws.last_time));
- active = wl->ws.active;
- spin_unlock_irq(>ws.lock);
+ spin_lock_irq(>ws->lock);
+ idle_time_ns = ktime_to_ns(ktime_sub(now, wl->ws->last_time));
+ active = wl->ws->active;
+ spin_unlock_irq(>ws->lock);
if (idle_time_ns < ((u64)WL_GC_TIME_SEC * NSEC_PER_SEC))
break;
if (!active) {
- wakeup_source_remove(>ws);
+ wakeup_source_unregister(wl->ws);
rb_erase(>node, _tree);
list_del(>lru);
kfree(wl->name);
@@ -187,9 +187,15 @@ static struct wakelock *wakelock_lookup_add(const char
*name, size_t len,
kfree(wl);
return ERR_PTR(-ENOMEM);
}
- wl->ws.name = wl->name;
- wl->ws.last_time = ktime_get();
- wakeup_source_add(>ws);
+
+ wl->ws = wakeup_source_register(wl->name);
+ if (!wl->ws) {
+ kfree(wl->name);
+ kfree(wl);
+ return ERR_PTR(-ENOMEM);
+ }
+ wl->ws->last_time = ktime_get();
+
rb_link_node(>node, parent, node);
rb_insert_color(>node, _tree);
wakelocks_lru_add(wl);
@@ -233,9 +239,9 @@ int pm_wake_lock(const char *buf)
u64 timeout_ms = timeout_ns + NSEC_PER_MSEC - 1;
do_div(timeout_ms, NSEC_PER_MSEC);
- __pm_wakeup_event(>ws, timeout_ms);
+ __pm_wakeup_event(wl->ws, timeout_ms);
} else {
- __pm_stay_awake(>ws);
+ __pm_stay_awake(wl->ws);
}
wakelocks_lru_most_recent(wl);
@@ -271,7 +277,7 @@ int pm_wake_unlock(const char *buf)
ret = PTR_ERR(wl);
goto out;
}
- __pm_relax(>ws);
+ __pm_relax(wl->ws);
wakelocks_lru_most_recent(wl);
wakelocks_gc();
--
2.22.0.770.g0f2c4a37fd-goog
[PATCH v8 0/3] PM / wakeup: Show wakeup sources stats in sysfs
Userspace can use wakeup_sources debugfs node to plot history of suspend blocking wakeup sources over device's boot cycle. This information can then be used (1) for power-specific bug reporting and (2) towards attributing battery consumption to specific processes over a period of time. However, debugfs doesn't have stable ABI. For this reason, create a 'struct device' to expose wakeup sources statistics in sysfs under /sys/class/wakeup/wakeup/*. Patch 1 and 2 do some cleanup to simplify our changes to how wakeup sources are created. Patch 3 implements wakeup sources stats in sysfs. Tri Vo (3): PM / wakeup: Drop wakeup_source_init(), wakeup_source_prepare() PM / wakeup: Use wakeup_source_register() in wakelock.c PM / wakeup: Show wakeup sources stats in sysfs Documentation/ABI/testing/sysfs-class-wakeup | 76 +++ drivers/acpi/device_pm.c | 3 +- drivers/base/power/Makefile | 2 +- drivers/base/power/power.h | 9 + drivers/base/power/wakeup.c | 59 +++--- drivers/base/power/wakeup_stats.c| 203 +++ fs/eventpoll.c | 4 +- include/linux/pm_wakeup.h| 21 +- kernel/power/autosleep.c | 2 +- kernel/power/wakelock.c | 32 +-- kernel/time/alarmtimer.c | 2 +- 11 files changed, 358 insertions(+), 55 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-wakeup create mode 100644 drivers/base/power/wakeup_stats.c v2: - Updated Documentation/ABI/, as per Greg. - Removed locks in attribute functions, as per Greg. - Lifetimes of struct wakelock and struck wakeup_source are now different due to the latter embedding a refcounted kobject. Changed it so that struct wakelock only has a pointer to struct wakeup_source, instead of embedding it. - Added CONFIG_PM_SLEEP_STATS that enables/disables wakeup source statistics in sysfs. v3: Changes by Greg: - Reworked code to use 'struct device' instead of raw kobjects. - Updated documentation file. - Only link wakeup_stats.o when CONFIG_PM_SLEEP_STATS is enabled. Changes by Tri: - Reverted changes to kernel/power/wakelock.c. 'struct device' hides kobject operations. So no need to handle lifetimes in wakelock.c v4: - Added 'Co-developed-by:' and 'Tested-by:' fields to commit message. - Moved new documentation to a separate file Documentation/ABI/testing/sysfs-class-wakeup, as per Greg. - Fixed copyright header in drivers/base/power/wakeup_stats.c, as per Greg. v5: - Removed CONFIG_PM_SLEEP_STATS - Used PTR_ERR_OR_ZERO instead of if(IS_ERR(...)) + PTR_ERR, reported by kbuild test robot - Stephen reported that a call to device_init_wakeup() and writing 'enabled' to that device's power/wakeup file results in multiple wakeup source being allocated for that device. Changed device_wakeup_enable() to check if device wakeup was previously enabled. Changes by Stephen: - Changed stats location from /sys/class/wakeup//* to /sys/class/wakeup/wakeup/*, where ID is an IDA-allocated integer. This avoids name collisions in /sys/class/wakeup/ directory. - Added a "name" attribute to wakeup sources, and updated documentation. - Device registering the wakeup source is now the parent of the wakeup source. Updated wakeup_source_register()'s signature and its callers accordingly. v6: - Changed stats location to /sys/class/wakeup/ws/* - Replaced ida_simple_get()/ida_simple_remove() with ida_alloc()/ida_free() as the former is deprecated. - Reverted changes to device_init_wakeup(). Rafael is preparing a patch to deal with extra wakeup source allocation in a separate patch. v7: - Removed wakeup_source_init(), wakeup_source_prepare(). - Removed duplicate wakeup source creation code from kernel/power/wakelock. - Moved ID allocation to wakeup source object creation time. - Changed stats location back to /sys/class/wakeup/wakeup/* - Remove wakeup source device's "power" attributes. v8: - Updated commit message on patch 1 to indicate change of behavior of wakeup_source_create(), as per Stephen. - Included headers for used symbols, as per Stephen. - Added a function to create wakeup source devices to use device_set_pm_not_required() to skip power management for such devices, as per Stephen. -- 2.22.0.770.g0f2c4a37fd-goog
Re: "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
> On Aug 6, 2019, at 9:22 PM, Saravana Kannan wrote: > > On Tue, Aug 6, 2019 at 5:46 PM Qian Cai wrote: >> >> It looks like the linux-next commit “of/platform: Pause/resume sync state >> during init and of_platform_populate()” [1] >> Introduced a warning while booting arm64. >> >> [1] >> https://lore.kernel.org/lkml/20190731221721.187713-6-sarava...@google.com/ >> >> [ 93.449300][T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas >> 44-bit (features 0x170d) >> [ 93.464873][T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 >> entries for cmdq >> [ 93.485481][T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 >> entries for evtq >> [ 93.496320][T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2 >> [ 93.502917][T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas >> 44-bit (features 0x170d) >> [ 93.621818][T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 >> entries for cmdq >> [ 93.643000][T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 >> entries for evtq >> [ 94.519445][T1] libphy: Fixed MDIO Bus: probed >> [ 94.524649][T1] EFI Variables Facility v0.08 2004-May-17 >> [ 94.601166][T1] NET: Registered protocol family 17 >> [ 94.766008][T1] zswap: loaded using pool lzo/zbud >> [ 94.774745][T1] kmemleak: Kernel memory leak detector initialized >> (mempool size: 16384) >> [ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started >> [ 94.812338][ T1368] pcieport :0f:00.0: Adding to iommu group 0 >> [ 94.984466][T1] [ cut here ] >> [ 94.989827][T1] Unmatched sync_state pause/resume! >> [ 94.989894][T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 >> device_links_supplier_sync_state_resume+0x100/0x128 >> [ 95.006062][T1] Modules linked in: >> [ 95.009815][T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted >> 5.3.0-rc3-next-20190806+ #11 >> [ 95.018161][T1] Hardware name: HPE Apollo 70 >> /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019 >> [ 95.028593][T1] pstate: 6049 (nZCv daif +PAN -UAO) >> [ 95.034077][T1] pc : >> device_links_supplier_sync_state_resume+0x100/0x128 >> [ 95.041124][T1] lr : >> device_links_supplier_sync_state_resume+0x100/0x128 >> [ 95.048167][T1] sp : 34ff800806e6fbc0 >> [ 95.052172][T1] x29: 34ff800806e6fc00 x28: >> [ 95.058177][T1] x27: x26: >> [ 95.064181][T1] x25: 0038 x24: >> [ 95.070185][T1] x23: x22: 0019 >> [ 95.076189][T1] x21: x20: f9ff808b804e6c50 >> [ 95.082193][T1] x19: 100014a6e600 x18: 0040 >> [ 95.088197][T1] x17: x16: 86ff80099d581b50 >> [ 95.094201][T1] x15: x14: 100010086d1c >> [ 95.100205][T1] x13: 1000109d8688 x12: >> [ 95.106209][T1] x11: 00f9 x10: 0808b804e6c6 >> [ 95.112213][T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00 >> [ 95.118217][T1] x7 : 6170206574617473 x6 : 100014076972 >> [ 95.124221][T1] x5 : 34ff800806e6f8f0 x4 : 000f >> [ 95.130225][T1] x3 : 1000101bfa5c x2 : 0001 >> [ 95.136229][T1] x1 : 0001 x0 : 0022 >> [ 95.142233][T1] Call trace: >> [ 95.145374][T1] device_links_supplier_sync_state_resume+0x100/0x128 >> [ 95.152074][T1] of_platform_sync_state_init+0x10/0x1c >> [ 95.157557][T1] do_one_initcall+0x2f8/0x600 >> [ 95.162172][T1] do_initcall_level+0x37c/0x3fc >> [ 95.166959][T1] do_basic_setup+0x34/0x4c >> [ 95.171313][T1] kernel_init_freeable+0x188/0x24c >> [ 95.176363][T1] kernel_init+0x18/0x334 >> [ 95.180543][T1] ret_from_fork+0x10/0x18 >> [ 95.184809][T1] ---[ end trace a9ea68c902540fe5 ]--- >> [ 95.269085][T1] Freeing unused kernel memory: 28672K >> [ 101.069860][T1] Checked W+X mappings: passed, no W+X pages found >> [ 101.076265][T1] Run /init as init process >> [ 101.186359][T1] systemd[1]: System time before build time, advancing >> clock. > > > I tested it again on my device (on an older kernel) and I don't see > this warning. Is this on an ARM64 target without a populated DT? Probably, /sys/firmware/devicetree is all empty. > That's the only thing I can see that could cause this
Re: [PATCH] bonding: Add vlan tx offload to hw_enc_features
On 2019/8/6 21:41, Jay Vosburgh wrote:
> YueHaibing wrote:
>
>> As commit 30d8177e8ac7 ("bonding: Always enable vlan tx offload")
>> said, we should always enable bonding's vlan tx offload, pass the
>> vlan packets to the slave devices with vlan tci, let them to handle
>> vlan implementation.
>>
>> Now if encapsulation protocols like VXLAN is used, skb->encapsulation
>> may be set, then the packet is passed to vlan devicec which based on
>
> Typo: "devicec"
oh, yes, thanks!
>
>> bonding device. However in netif_skb_features(), the check of
>> hw_enc_features:
>>
>> if (skb->encapsulation)
>> features &= dev->hw_enc_features;
>>
>> clears NETIF_F_HW_VLAN_CTAG_TX/NETIF_F_HW_VLAN_STAG_TX. This results
>> in same issue in commit 30d8177e8ac7 like this:
>>
>> vlan_dev_hard_start_xmit
>> -->dev_queue_xmit
>>-->validate_xmit_skb
>> -->netif_skb_features //NETIF_F_HW_VLAN_CTAG_TX is cleared
>> -->validate_xmit_vlan
>>-->__vlan_hwaccel_push_inside //skb->tci is cleared
>> ...
>> --> bond_start_xmit
>> --> bond_xmit_hash //BOND_XMIT_POLICY_ENCAP34
>> --> __skb_flow_dissect // nhoff point to IP header
>>--> case htons(ETH_P_8021Q)
>> // skb_vlan_tag_present is false, so
>> vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
>> //vlan point to ip header wrongly
>>
>> Signed-off-by: YueHaibing
>
> Looks good to me; should this be tagged with
>
> Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
>
> as 30d8177e8ac7 was? If not, is there an appropriate commit id?
It seems the commit was:
Fixes: b2a103e6d0af ("bonding: convert to ndo_fix_features")
>
> Acked-by: Jay Vosburgh
Thanks, will send v2.
>
> -J
>
>> ---
>> drivers/net/bonding/bond_main.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/bonding/bond_main.c
>> b/drivers/net/bonding/bond_main.c
>> index 02fd782..931d9d9 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -1126,6 +1126,8 @@ static void bond_compute_features(struct bonding *bond)
>> done:
>> bond_dev->vlan_features = vlan_features;
>> bond_dev->hw_enc_features = enc_features | NETIF_F_GSO_ENCAP_ALL |
>> +NETIF_F_HW_VLAN_CTAG_TX |
>> +NETIF_F_HW_VLAN_STAG_TX |
>> NETIF_F_GSO_UDP_L4;
>> bond_dev->mpls_features = mpls_features;
>> bond_dev->gso_max_segs = gso_max_segs;
>> --
>> 2.7.4
>
> ---
> -Jay Vosburgh, jay.vosbu...@canonical.com
>
> .
>
[PATCH] kernel/watchdog: Fix watchdog_allowed_mask not used warning
Define watchdog_allowed_mask only when SOFTLOCKUP_DETECTOR is enabled. Signed-off-by: Santosh Sivaraj --- kernel/watchdog.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 7f9e7b9306fe..d365616f9ed3 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -44,8 +44,6 @@ int __read_mostly soft_watchdog_user_enabled = 1; int __read_mostly watchdog_thresh = 10; static int __read_mostly nmi_watchdog_available; -static struct cpumask watchdog_allowed_mask __read_mostly; - struct cpumask watchdog_cpumask __read_mostly; unsigned long *watchdog_cpumask_bits = cpumask_bits(_cpumask); @@ -160,6 +158,7 @@ static void lockup_detector_update_enable(void) } #ifdef CONFIG_SOFTLOCKUP_DETECTOR +static struct cpumask watchdog_allowed_mask __read_mostly; /* Global variables, exported for sysctl */ unsigned int __read_mostly softlockup_panic = -- 2.20.1
Re: [PATCH v3 5/5] ASoC: dt-bindings: Introduce compatible strings for 7ULP and 8MQ
On Tue, Aug 06, 2019 at 06:12:14PM +0300, Daniel Baluta wrote: > For i.MX7ULP and i.MX8MQ register map is changed. Add two new compatbile > strings to differentiate this. > > Signed-off-by: Daniel Baluta Looks good to me. As long as one of DT maintainers acks, Acked-by: Nicolin Chen Thanks > --- > Documentation/devicetree/bindings/sound/fsl-sai.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt > b/Documentation/devicetree/bindings/sound/fsl-sai.txt > index 2e726b983845..e61c0dc1fc0b 100644 > --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt > +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt > @@ -8,7 +8,8 @@ codec/DSP interfaces. > Required properties: > >- compatible : Compatible list, contains "fsl,vf610-sai", > - "fsl,imx6sx-sai" or "fsl,imx6ul-sai" > + "fsl,imx6sx-sai", "fsl,imx6ul-sai", > + "fsl,imx7ulp-sai" or "fsl,imx8mq-sai". > >- reg : Offset and length of the register set for the > device. > > -- > 2.17.1 >
Re: [PATCH] soc: qcom: socinfo: Annotate switch cases with fall through
Hi,
On 8/6/19 8:24 PM, Bjorn Andersson wrote:
> Introduce fall through annotations in the switch statements of
> socinfo_debugfs_init() to silence compiler warnings.
>
This is enough to silence all the warnings:
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 855353bed19e..a39ea5061dc5 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -323,6 +323,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_x32("raw_device_number", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.raw_device_num);
+ /* Fall through */
case SOCINFO_VERSION(0, 11):
case SOCINFO_VERSION(0, 10):
case SOCINFO_VERSION(0, 9):
@@ -330,10 +331,12 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_u32("foundry_id", 0400, qcom_socinfo->dbg_root,
_socinfo->info.foundry_id);
+ /* Fall through */
case SOCINFO_VERSION(0, 8):
case SOCINFO_VERSION(0, 7):
DEBUGFS_ADD(info, pmic_model);
DEBUGFS_ADD(info, pmic_die_rev);
+ /* Fall through */
case SOCINFO_VERSION(0, 6):
qcom_socinfo->info.hw_plat_subtype =
__le32_to_cpu(info->hw_plat_subtype);
@@ -341,6 +344,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_u32("hardware_platform_subtype", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.hw_plat_subtype);
+ /* Fall through */
case SOCINFO_VERSION(0, 5):
qcom_socinfo->info.accessory_chip =
__le32_to_cpu(info->accessory_chip);
@@ -348,23 +352,27 @@ static void socinfo_debugfs_init(struct qcom_socinfo
*qcom_socinfo,
debugfs_create_u32("accessory_chip", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.accessory_chip);
+ /* Fall through */
case SOCINFO_VERSION(0, 4):
qcom_socinfo->info.plat_ver = __le32_to_cpu(info->plat_ver);
debugfs_create_u32("platform_version", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.plat_ver);
+ /* Fall through */
case SOCINFO_VERSION(0, 3):
qcom_socinfo->info.hw_plat = __le32_to_cpu(info->hw_plat);
debugfs_create_u32("hardware_platform", 0400,
qcom_socinfo->dbg_root,
_socinfo->info.hw_plat);
+ /* Fall through */
case SOCINFO_VERSION(0, 2):
qcom_socinfo->info.raw_ver = __le32_to_cpu(info->raw_ver);
debugfs_create_u32("raw_version", 0400, qcom_socinfo->dbg_root,
_socinfo->info.raw_ver);
+ /* Fall through */
case SOCINFO_VERSION(0, 1):
DEBUGFS_ADD(info, build_id);
break;
--
Gustavo
> Fixes: 9c84c1e78634 ("soc: qcom: socinfo: Expose custom attributes")
> Reported-by: Stephen Rothwell
> Signed-off-by: Bjorn Andersson
> ---
> drivers/soc/qcom/socinfo.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> index 855353bed19e..f0ca9d7c7966 100644
> --- a/drivers/soc/qcom/socinfo.c
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -323,17 +323,23 @@ static void socinfo_debugfs_init(struct qcom_socinfo
> *qcom_socinfo,
> debugfs_create_x32("raw_device_number", 0400,
> qcom_socinfo->dbg_root,
> _socinfo->info.raw_device_num);
> + /* Fall through */
> case SOCINFO_VERSION(0, 11):
> + /* Fall through */
> case SOCINFO_VERSION(0, 10):
> + /* Fall through */
> case SOCINFO_VERSION(0, 9):
> qcom_socinfo->info.foundry_id = __le32_to_cpu(info->foundry_id);
>
> debugfs_create_u32("foundry_id", 0400, qcom_socinfo->dbg_root,
> _socinfo->info.foundry_id);
> + /* Fall through */
> case SOCINFO_VERSION(0, 8):
> + /* Fall through */
> case SOCINFO_VERSION(0, 7):
> DEBUGFS_ADD(info, pmic_model);
> DEBUGFS_ADD(info, pmic_die_rev);
> + /* Fall through */
> case SOCINFO_VERSION(0, 6):
> qcom_socinfo->info.hw_plat_subtype =
> __le32_to_cpu(info->hw_plat_subtype);
> @@ -341,6 +347,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo
> *qcom_socinfo,
>
[PATCH v3 14/41] vmci: convert put_page() to put_user_page*()
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Note that this effectively changes the code's behavior in
qp_release_pages(): it now ultimately calls set_page_dirty_lock(),
instead of set_page_dirty(). This is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Cc: Arnd Bergmann
Cc: Al Viro
Cc: Gustavo A. R. Silva
Cc: Kees Cook
Signed-off-by: John Hubbard
---
drivers/misc/vmw_vmci/vmci_context.c| 2 +-
drivers/misc/vmw_vmci/vmci_queue_pair.c | 11 ++-
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_context.c
b/drivers/misc/vmw_vmci/vmci_context.c
index 16695366ec92..9daa52ee63b7 100644
--- a/drivers/misc/vmw_vmci/vmci_context.c
+++ b/drivers/misc/vmw_vmci/vmci_context.c
@@ -587,7 +587,7 @@ void vmci_ctx_unset_notify(struct vmci_ctx *context)
if (notify_page) {
kunmap(notify_page);
- put_page(notify_page);
+ put_user_page(notify_page);
}
}
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 8531ae781195..e5434551d0ef 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -626,15 +626,8 @@ static void qp_release_queue_mutex(struct vmci_queue
*queue)
static void qp_release_pages(struct page **pages,
u64 num_pages, bool dirty)
{
- int i;
-
- for (i = 0; i < num_pages; i++) {
- if (dirty)
- set_page_dirty(pages[i]);
-
- put_page(pages[i]);
- pages[i] = NULL;
- }
+ put_user_pages_dirty_lock(pages, num_pages, dirty);
+ memset(pages, 0, num_pages * sizeof(struct page *));
}
/*
--
2.22.0
Re: [PATCH v3 3/5] ASoC: fsl_sai: Add support for SAI new version
On Tue, Aug 06, 2019 at 06:12:12PM +0300, Daniel Baluta wrote:
> New IP version introduces Version ID and Parameter registers
> and optionally added Timestamp feature.
>
> VERID and PARAM registers are placed at the top of registers
> address space and some registers are shifted according to
> the following table:
>
> Tx/Rx data registers and Tx/Rx FIFO registers keep their
> addresses, all other registers are shifted by 8.
>
> SAI Memory map is described in chapter 13.10.4.1.1 I2S Memory map
> of the Reference Manual [1].
>
> In order to make as less changes as possible we attach an offset
> to each register offset to each changed register definition. The
> offset is read from each board private data.
>
> [1]https://cache.nxp.com/secured/assets/documents/en/reference-manual/IMX8MDQLQRM.pdf?__gda__=1563728701_38bea7f0f726472cc675cb141b91bec7=.pdf
>
> Signed-off-by: Mihai Serban
> [initial coding in the NXP internal tree]
> Signed-off-by: Shengjiu Wang
> [bugfixing and cleanups]
> Signed-off-by: Daniel Baluta
> [adapted to linux-next]
Acked-by: Nicolin Chen
One small request that we can do with a separate patch later:
> struct fsl_sai_soc_data {
> bool use_imx_pcm;
> unsigned int fifo_depth;
> + unsigned int reg_offset;
> };
I think we need a list of comments for the structure defines.
It might be okay for the old two entries but reg_offset isn't
that explicit any more.
Re: [PATCH v2] lpfc: Mitigate high memory pre-allocation by SCSI-MQ
On Wed, Aug 7, 2019 at 1:13 AM James Smart wrote: > > On 8/5/2019 6:09 PM, Ming Lei wrote: > > > > I am wondering why you use 2 * num_possible_nodes() as the limit instead of > > num_possible_nodes(), could you explain it a bit? > > The number comes from most systems being dual socket systems, thus a > numa node count of 2. Some of these dual socket systems can be high cpu > counts per socket. We did see a difference, on different architectures > and where cpu counts were high per socket, that more hwqs per socket did > help. So if there can be more than 1 hwq per socket then I think that is > goodness. I guess it isn't related with CPU cores per socket, what matters is number of sockets, given each CPU core in same socket is in same position wrt. RW preformance on same shared memory, so looks the following way is what we need: shost->nr_hw_queues = max_t(int, num_possible_nodes(), nr_processor_sockets); However, I don't know how to retrieve 'nr_processor_sockets' in kernel. Maybe topology_max_packages() can be used for x86, not see how to read it for other ARCHs. Cc Thomas and linux-kernel list. Thanks, Ming Lei
[PATCH v3 18/41] drivers/tee: convert put_page() to put_user_page*()
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Acked-by: Jens Wiklander
Signed-off-by: John Hubbard
---
drivers/tee/tee_shm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 2da026fd12c9..c967d0420b67 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -31,16 +31,13 @@ static void tee_shm_release(struct tee_shm *shm)
poolm->ops->free(poolm, shm);
} else if (shm->flags & TEE_SHM_REGISTER) {
- size_t n;
int rc = teedev->desc->ops->shm_unregister(shm->ctx, shm);
if (rc)
dev_err(teedev->dev.parent,
"unregister shm %p failed: %d", shm, rc);
- for (n = 0; n < shm->num_pages; n++)
- put_page(shm->pages[n]);
-
+ put_user_pages(shm->pages, shm->num_pages);
kfree(shm->pages);
}
@@ -313,16 +310,13 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx,
unsigned long addr,
return shm;
err:
if (shm) {
- size_t n;
-
if (shm->id >= 0) {
mutex_lock(>mutex);
idr_remove(>idr, shm->id);
mutex_unlock(>mutex);
}
if (shm->pages) {
- for (n = 0; n < shm->num_pages; n++)
- put_page(shm->pages[n]);
+ put_user_pages(shm->pages, shm->num_pages);
kfree(shm->pages);
}
}
--
2.22.0
[PATCH v3 26/41] futex: convert put_page() to put_user_page*()
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Darren Hart
Signed-off-by: John Hubbard
---
kernel/futex.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 6d50728ef2e7..4b4cae58ec57 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -623,7 +623,7 @@ get_futex_key(u32 __user *uaddr, int fshared, union
futex_key *key, enum futex_a
lock_page(page);
shmem_swizzled = PageSwapCache(page) || page->mapping;
unlock_page(page);
- put_page(page);
+ put_user_page(page);
if (shmem_swizzled)
goto again;
@@ -675,7 +675,7 @@ get_futex_key(u32 __user *uaddr, int fshared, union
futex_key *key, enum futex_a
if (READ_ONCE(page->mapping) != mapping) {
rcu_read_unlock();
- put_page(page);
+ put_user_page(page);
goto again;
}
@@ -683,7 +683,7 @@ get_futex_key(u32 __user *uaddr, int fshared, union
futex_key *key, enum futex_a
inode = READ_ONCE(mapping->host);
if (!inode) {
rcu_read_unlock();
- put_page(page);
+ put_user_page(page);
goto again;
}
@@ -702,7 +702,7 @@ get_futex_key(u32 __user *uaddr, int fshared, union
futex_key *key, enum futex_a
*/
if (!atomic_inc_not_zero(>i_count)) {
rcu_read_unlock();
- put_page(page);
+ put_user_page(page);
goto again;
}
@@ -723,7 +723,7 @@ get_futex_key(u32 __user *uaddr, int fshared, union
futex_key *key, enum futex_a
}
out:
- put_page(page);
+ put_user_page(page);
return err;
}
--
2.22.0
Re: [PATCH v3 13/16] powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests
Hello Christoph, Thanks for your review. Christoph Hellwig writes: > On Tue, Aug 06, 2019 at 02:22:34AM -0300, Thiago Jung Bauermann wrote: >> @@ -1318,7 +1319,10 @@ void iommu_init_early_pSeries(void) >> of_reconfig_notifier_register(_reconfig_nb); >> register_memory_notifier(_mem_nb); >> >> -set_pci_dma_ops(_iommu_ops); >> +if (is_secure_guest()) >> +set_pci_dma_ops(NULL); >> +else >> +set_pci_dma_ops(_iommu_ops); > > Shoudn't: > > if (!is_secure_guest()) > set_pci_dma_ops(_iommu_ops); > > be enough here, given that NULL is the default? Indeed, it is enough. > Also either way I think this conditional needs a comment explaining > why it is there. Good point. I added the commit message as a comment in the code. New version of this patch below. >From 5dc3914efa4765eef2869d554d4ea1c676bb1e75 Mon Sep 17 00:00:00 2001 From: Thiago Jung Bauermann Date: Thu, 24 Jan 2019 22:40:16 -0200 Subject: [PATCH] powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests Secure guest memory is inacessible to devices so regular DMA isn't possible. In that case set devices' dma_map_ops to NULL so that the generic DMA code path will use SWIOTLB to bounce buffers for DMA. Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/platforms/pseries/iommu.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c index 889dc2e44b89..8d9c2b17ad54 100644 --- a/arch/powerpc/platforms/pseries/iommu.c +++ b/arch/powerpc/platforms/pseries/iommu.c @@ -36,6 +36,7 @@ #include #include #include +#include #include "pseries.h" @@ -1318,7 +1319,15 @@ void iommu_init_early_pSeries(void) of_reconfig_notifier_register(_reconfig_nb); register_memory_notifier(_mem_nb); - set_pci_dma_ops(_iommu_ops); + /* +* Secure guest memory is inacessible to devices so regular DMA isn't +* possible. +* +* In that case keep devices' dma_map_ops as NULL so that the generic +* DMA code path will use SWIOTLB to bounce buffers for DMA. +*/ + if (!is_secure_guest()) + set_pci_dma_ops(_iommu_ops); } static int __init disable_multitce(char *str)
Re: [PATCH v2 0/3] arm/arm64: Add support for function error injection
On Wed, Aug 07, 2019 at 09:08:11AM +0900, Masami Hiramatsu wrote: > On Tue, 6 Aug 2019 18:00:12 +0800 > Leo Yan wrote: > > > This small patch set is to add support for function error injection; > > this can be used to eanble more advanced debugging feature, e.g. > > CONFIG_BPF_KPROBE_OVERRIDE. > > > > The patch 01/03 is to consolidate the function definition which can be > > suared cross architectures, patches 02,03/03 are used for enabling > > function error injection on arm64 and arm architecture respectively. > > > > I tested on arm64 platform Juno-r2 and one of my laptop with x86 > > architecture with below steps; I don't test for Arm architecture so > > only pass compilation. > > > > - Enable kernel configuration: > > CONFIG_BPF_KPROBE_OVERRIDE > > CONFIG_BTRFS_FS > > CONFIG_BPF_EVENTS=y > > CONFIG_KPROBES=y > > CONFIG_KPROBE_EVENTS=y > > CONFIG_BPF_KPROBE_OVERRIDE=y > > > > - Build samples/bpf on with Debian rootFS: > > # cd $kernel > > # make headers_install > > # make samples/bpf/ LLC=llc-7 CLANG=clang-7 > > > > - Run the sample tracex7: > > # dd if=/dev/zero of=testfile.img bs=1M seek=1000 count=1 > > # DEVICE=$(losetup --show -f testfile.img) > > # mkfs.btrfs -f $DEVICE > > # ./tracex7 testfile.img > > [ 1975.211781] BTRFS error (device (efault)): open_ctree failed > > mount: /mnt/linux-kernel/linux-cs-dev/samples/bpf/tmpmnt: mount(2) system > > call failed: Cannot allocate memory. > > > > Changes from v1: > > * Consolidated the function definition into asm-generic header (Will); > > * Used APIs to access pt_regs elements (Will); > > * Fixed typos in the comments (Will). > > This looks good to me. > > Reviewed-by: Masami Hiramatsu > > Thank you! Thanks a lot for reviewing, Masami. Leo.
Re: [PATCH v3 3/5] RISC-V: Fix unsupported isa string info.
On Wed, 7 Aug 2019, Atish Patra wrote: > On Tue, 2019-08-06 at 16:27 -0700, Paul Walmsley wrote: > > > Seems like the "su" should be dropped from mandatory_ext. What do you > > think? > > > > Yup. As DT binding only mention imafdc, mandatory extensions should > contain only that and just consider "su" extensions are considered as > implicit as we are running Linux. Discussing this with Andrew and Palmer, it looks like "su" is currently non-compliant. Section 22.6 of the user-level specification states that the "s" character indicates that a longer standard supervisor extension name will follow. So far I don't think any of these have been defined. > Do you think QEMU DT should be updated to reflect that ? Yes. > > There's no Kconfig option by this name, and we're requiring > > compressed > > Sorry. This was a typo. It should have been CONFIG_RISCV_ISA_C. > > > instruction support as part of the RISC-V Linux baseline. Could you > > share the rationale behind this? > > I think I added this check at the config file. Looking at the Kconfig, > RISCV_ISA_C is always enabled. So we can drop this. OK great. Do you want to resend an updated patch, or would you like me to fix it up here? I'll also send a patch to drop CONFIG_RISCV_ISA_C. - Paul
