RE: [PATCH v3 3/4] iommu: Add iommu_aux_get_domain_for_dev()
> From: Alex Williamson
> Sent: Thursday, July 30, 2020 4:25 AM
>
> On Tue, 14 Jul 2020 13:57:02 +0800
> Lu Baolu wrote:
>
> > The device driver needs an API to get its aux-domain. A typical usage
> > scenario is:
> >
> > unsigned long pasid;
> > struct iommu_domain *domain;
> > struct device *dev = mdev_dev(mdev);
> > struct device *iommu_device = vfio_mdev_get_iommu_device(dev);
> >
> > domain = iommu_aux_get_domain_for_dev(dev);
> > if (!domain)
> > return -ENODEV;
> >
> > pasid = iommu_aux_get_pasid(domain, iommu_device);
> > if (pasid <= 0)
> > return -EINVAL;
> >
> > /* Program the device context */
> >
> >
> > This adds an API for such use case.
> >
> > Suggested-by: Alex Williamson
> > Signed-off-by: Lu Baolu
> > ---
> > drivers/iommu/iommu.c | 18 ++
> > include/linux/iommu.h | 7 +++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index cad5a19ebf22..434bf42b6b9b 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -2817,6 +2817,24 @@ void iommu_aux_detach_group(struct
> iommu_domain *domain,
> > }
> > EXPORT_SYMBOL_GPL(iommu_aux_detach_group);
> >
> > +struct iommu_domain *iommu_aux_get_domain_for_dev(struct device
> *dev)
> > +{
> > + struct iommu_domain *domain = NULL;
> > + struct iommu_group *group;
> > +
> > + group = iommu_group_get(dev);
> > + if (!group)
> > + return NULL;
> > +
> > + if (group->aux_domain_attached)
> > + domain = group->domain;
>
> Why wouldn't the aux domain flag be on the domain itself rather than
> the group? Then if we wanted sanity checking in patch 1/ we'd only
> need to test the flag on the object we're provided.
>
> If we had such a flag, we could create an iommu_domain_is_aux()
> function and then simply use iommu_get_domain_for_dev() and test that
> it's an aux domain in the example use case. It seems like that would
IOMMU layer manages domains per parent device. Here given a
dev (of mdev), we need a way to find its associated domain under its
parent device. And we cannot simply use iommu_get_domain_for_dev
on the parent device of the mdev, as it will give us the primary domain
of parent device.
Thanks
Kevin
> resolve the jump from a domain to an aux-domain just as well as adding
> this separate iommu_aux_get_domain_for_dev() interface. The is_aux
> test might also be useful in other cases too. Thanks,
>
> Alex
>
> > +
> > + iommu_group_put(group);
> > +
> > + return domain;
> > +}
> > +EXPORT_SYMBOL_GPL(iommu_aux_get_domain_for_dev);
> > +
> > /**
> > * iommu_sva_bind_device() - Bind a process address space to a device
> > * @dev: the device
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index 9506551139ab..cda6cef7579e 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -639,6 +639,7 @@ int iommu_aux_attach_group(struct
> iommu_domain *domain,
> >struct iommu_group *group, struct device *dev);
> > void iommu_aux_detach_group(struct iommu_domain *domain,
> >struct iommu_group *group, struct device *dev);
> > +struct iommu_domain *iommu_aux_get_domain_for_dev(struct device
> *dev);
> >
> > struct iommu_sva *iommu_sva_bind_device(struct device *dev,
> > struct mm_struct *mm,
> > @@ -1040,6 +1041,12 @@ iommu_aux_detach_group(struct
> iommu_domain *domain,
> > {
> > }
> >
> > +static inline struct iommu_domain *
> > +iommu_aux_get_domain_for_dev(struct device *dev)
> > +{
> > + return NULL;
> > +}
> > +
> > static inline struct iommu_sva *
> > iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void
> *drvdata)
> > {
Re: [RFC PATCH v5 12/14] gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done
On 7/29/20 4:42 PM, Dmitry Osipenko wrote:
29.07.2020 20:55, Sowjanya Komatineni пишет:
On 7/29/20 10:08 AM, Dmitry Osipenko wrote:
28.07.2020 19:04, Sowjanya Komatineni пишет:
...
+void tegra_mipi_cancel_calibration(struct tegra_mipi_device *device)
+{
Doesn't MIPI_CAL need to be reset here?
No need to reset MIPI CAL
Could you please explain why. There is a calibration state-machine that
apparently needs to be returned into initial state, does it return by
itself?
TRM says that MIPI block needs to be reset before of starting
calibration process. The reset is completely missing in the driver, I
assume it needs to be corrected with another patch.
TRM documented incorrectly. There is no need to reset MIPI_CAL.
MIPI CAL is FSM and it does not hang and done bit is to indicate if
results are applied to pads or not.
If we don't see done bit set meaning, MIPI CAL did not see LP-11 and
results are not applied to pads.
But how to stop calibration from triggering on LP-11 once it has been
enabled? The reset should be needed since there is no other way to reset
the calibration state.
Its a finite state machine that goes thru fixed steps of sequence codes
internally and holds results in registers.
When it sees LP-11 results are applied to pads.
If it does not see LP-11, next start will again trigger calibrating with
finite sequence codes.
As per HW designers, we don't have to do any reverts when done bit is
not set.
Also while multiple streams can happen in parallel and we can't reset
MIPI CAL as other CSI channel streams (using other pads) may also be
going thru calibration process in parallel depending and also DSI pads
also are calibrated thru same MIPI CAL controller.
Perhaps this should be the case for a shared reset control API usage.
Re: [PATCH -next] tools build: Check return value of fwrite_unlocked in jvmti_agent.c
On Fri, Jul 24, 2020 at 3:07 AM Wang ShaoBo wrote:
>
> Function jvmti_write_code called by compiled_method_load_cb may return
> error in using fwrite_unlocked, this failure should be captured and
> warned.
>
> Signed-off-by: Wang ShaoBo
> ---
> tools/perf/jvmti/jvmti_agent.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/jvmti/jvmti_agent.c b/tools/perf/jvmti/jvmti_agent.c
> index 88108598d6e9..a1fe6aa16b6d 100644
> --- a/tools/perf/jvmti/jvmti_agent.c
> +++ b/tools/perf/jvmti/jvmti_agent.c
> @@ -363,7 +363,7 @@ jvmti_write_code(void *agent, char const *sym,
> struct jr_code_load rec;
> size_t sym_len;
> FILE *fp = agent;
> - int ret = -1;
> + int ret;
>
> /* don't care about 0 length function, no samples */
> if (size == 0)
> @@ -401,16 +401,23 @@ jvmti_write_code(void *agent, char const *sym,
> rec.code_index = code_generation++;
>
> ret = fwrite_unlocked(, sizeof(rec), 1, fp);
> - fwrite_unlocked(sym, sym_len, 1, fp);
> + if (ret)
> + goto error;
Sorry, it seems I lost a reply to this. Won't ret here be the number
of items written and not an error code? Consequently all writes will
immediately goto error?
Thanks,
Ian
> + ret = fwrite_unlocked(sym, sym_len, 1, fp);
> + if (ret)
> + goto error;
>
> - if (code)
> - fwrite_unlocked(code, size, 1, fp);
> + if (code) {
> + ret = fwrite_unlocked(code, size, 1, fp);
> + if (ret)
> + goto error;
> + }
>
> funlockfile(fp);
> -
> - ret = 0;
> -
> - return ret;
> + return 0;
> +error:
> + funlockfile(fp);
> + return -1;
> }
>
> int
> --
> 2.17.1
>
Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache
On 7/29/20 9:16 AM, Mike Snitzer wrote: On Wed, Jul 29 2020 at 7:55am -0400, Greg KH wrote: On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote: On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: This mail needs to be saent to sta...@vger.kernel.org (now cc'd). Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9 Now backported, thanks. Nope, it broke the build, I need something that actually works :) OK, I'll defer to John Donnelly to get back with you (and rest of stable@). He is more invested due to SUSE also having this issue. I can put focus to it if John cannot sort this out. Mike Hi. Thank you for reaching out. What specifically is broken? . If it that applying 2df3bae9a6543e90042291707b8db0cbfbae9ee9 to 4.14.y is failing? JD.
[PATCH] power: supply: add "Wireless" to power_supply_type and power_supply_type_text
In android platform(BatteryMonitor.cpp), SysfsStringEnumMap
supplyTypeMap[] is declred for communication with kernel(sysfs)
and there is "Wireless". But, no type for "Wireless" in kernel.
So, we suggest to add "Wireless" to power_supply_type and
power_supply_type_text.
I hope this will not only synchronize the text values with
android platform, but also help other platforms.
Signed-off-by: Jeehong Kim
---
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index bc79560229b5..35582b67eff5 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -56,6 +56,7 @@ static const char * const POWER_SUPPLY_TYPE_TEXT[] = {
[POWER_SUPPLY_TYPE_USB_PD] = "USB_PD",
[POWER_SUPPLY_TYPE_USB_PD_DRP] = "USB_PD_DRP",
[POWER_SUPPLY_TYPE_APPLE_BRICK_ID] = "BrickID",
+ [POWER_SUPPLY_TYPE_WIRELESS]= "Wireless",
};
static const char * const POWER_SUPPLY_USB_TYPE_TEXT[] = {
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index ac1345a48ad0..c8bad17a9483 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -182,6 +182,7 @@ enum power_supply_type {
POWER_SUPPLY_TYPE_USB_PD, /* Power Delivery Port */
POWER_SUPPLY_TYPE_USB_PD_DRP, /* PD Dual Role Port */
POWER_SUPPLY_TYPE_APPLE_BRICK_ID, /* Apple Charging Method */
+ POWER_SUPPLY_TYPE_WIRELESS, /* Wireless */
};
enum power_supply_usb_type {
--
2.17.1
Re: linux-next: build failure after merge of the origin tree
On Wed, Jul 29, 2020 at 4:08 PM Stephen Rothwell wrote:
>
> include/linux/random.h:123:24: error: variable 'net_rand_state' with
> 'latent_entropy' attribute must not be local
> 123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
Hmm.
Ok, this shows a limitation of my allmodconfig testing (and all my
normal builds) - no plugins. So that problem wasn't as obvious as it
should have been.
That error isn't very helpful, in that I think it actually is very
wrong. The variable really isn't local at all.
I think what the plugin *means* by "local" is "automatic", and I think
it uses the wrong test for it. IOW, looking at the plugin, it does
if (!TREE_STATIC(*node)) {
*no_add_attrs = true;
error("variable %qD with %qE attribute must
not be local",
*node, name);
and what I think it really wants is that it has a static address - so
a global variable is fine - as opposed to being an actual static
declaration.
Also looking at the plugin, I suspect it is going to be very unhappy
about the fact that the attribute is there both on a declaration and
on the actual definition. The code later seems to really only want to
work on the definition, since it's creating an initializer..
IOW, I get the feeling that the plugin is confused, and it so happened
that the only variables we'd marked for latent entropy were static
ones. But I haven't done gcc plugins, so...
Adding the gcc plugin people. Otherwise the only option seems to be to
just remove that __latent_entropy marker.
Linus
Re: [RFC PATCH v5 12/14] gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done
29.07.2020 20:55, Sowjanya Komatineni пишет:
>
> On 7/29/20 10:08 AM, Dmitry Osipenko wrote:
>> 28.07.2020 19:04, Sowjanya Komatineni пишет:
>> ...
> +void tegra_mipi_cancel_calibration(struct tegra_mipi_device *device)
> +{
Doesn't MIPI_CAL need to be reset here?
>>> No need to reset MIPI CAL
>> Could you please explain why. There is a calibration state-machine that
>> apparently needs to be returned into initial state, does it return by
>> itself?
>>
>> TRM says that MIPI block needs to be reset before of starting
>> calibration process. The reset is completely missing in the driver, I
>> assume it needs to be corrected with another patch.
>
> TRM documented incorrectly. There is no need to reset MIPI_CAL.
>
> MIPI CAL is FSM and it does not hang and done bit is to indicate if
> results are applied to pads or not.
>
> If we don't see done bit set meaning, MIPI CAL did not see LP-11 and
> results are not applied to pads.
But how to stop calibration from triggering on LP-11 once it has been
enabled? The reset should be needed since there is no other way to reset
the calibration state.
> Also while multiple streams can happen in parallel and we can't reset
> MIPI CAL as other CSI channel streams (using other pads) may also be
> going thru calibration process in parallel depending and also DSI pads
> also are calibrated thru same MIPI CAL controller.
Perhaps this should be the case for a shared reset control API usage.
Re: [PATCH] PCI: Disallow ASPM on ASMedia ASM1083/1085 PCIe-PCI bridge
On Tue, Jul 21, 2020 at 08:18:03PM -0600, Robert Hancock wrote:
> Recently ASPM handling was changed to no longer disable ASPM on all
> PCIe to PCI bridges. Unfortunately these ASMedia PCIe to PCI bridge
> devices don't seem to function properly with ASPM enabled, as they
> cause the parent PCIe root port to cause repeated AER timeout errors.
> In addition to flooding the kernel log, this also causes the machine
> to wake up immediately after suspend is initiated.
>
> Fixes: 66ff14e59e8a ("PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X
> Bridges")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Robert Hancock
I applied this to for-linus for v5.8, since 66ff14e59e8a was merged
for v5.8. Thanks very much for finding, debugging, and fixing this!
66ff14e59e8a wasn't marked for stable, so if it *was* backported to
stable kernels, I assume whatever process backported it will also
catch this because of the Fixes: tag.
> ---
> drivers/pci/quirks.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 812bfc32ecb8..e5713114f2ab 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2330,6 +2330,19 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10f1,
> quirk_disable_aspm_l0s);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10f4, quirk_disable_aspm_l0s);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1508, quirk_disable_aspm_l0s);
>
> +static void quirk_disable_aspm_l0s_l1(struct pci_dev *dev)
> +{
> + pci_info(dev, "Disabling ASPM L0s/L1\n");
> + pci_disable_link_state(dev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1);
> +}
> +
> +/*
> + * ASM1083/1085 PCIe-PCI bridge devices cause AER timeout errors on the
> + * upstream PCIe root port when ASPM is enabled. At least L0s mode is
> affected,
> + * disable both L0s and L1 for now to be safe.
> + */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ASMEDIA, 0x1080,
> quirk_disable_aspm_l0s_l1);
> +
> /*
> * Some Pericom PCIe-to-PCI bridges in reverse mode need the PCIe Retrain
> * Link bit cleared after starting the link retrain process to allow this
> --
> 2.26.2
>
[PATCH] mmc: sdhci_am654: Add workaround for card detect debounce timer
There is a one time delay because of a card detect debounce timer in the
controller IP. This timer runs as soon as power is applied to the module
regardless of whether a card is present or not and any writes to
SDHCI_POWER_ON will return 0 before it expires. This timeout has been
measured to be about 1 second in am654x and j721e.
Write-and-read-back in a loop on SDHCI_POWER_ON for a maximum of
1.5 seconds to make sure that the controller actually powers on.
Signed-off-by: Faiz Abbas
---
drivers/mmc/host/sdhci_am654.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index 1718b9e8af63..55cff9de2f3e 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -272,6 +272,7 @@ static void sdhci_j721e_4bit_set_clock(struct sdhci_host
*host,
sdhci_set_clock(host, clock);
}
+#define MAX_POWER_ON_TIMEOUT 1500 /* ms */
static void sdhci_am654_write_b(struct sdhci_host *host, u8 val, int reg)
{
unsigned char timing = host->mmc->ios.timing;
@@ -291,6 +292,26 @@ static void sdhci_am654_write_b(struct sdhci_host *host,
u8 val, int reg)
}
writeb(val, host->ioaddr + reg);
+ if (reg == SDHCI_POWER_CONTROL && (val & SDHCI_POWER_ON)) {
+ /*
+* Power on will not happen until the card detect debounce
+* timer expires. Wait at least 1.5 seconds for the power on
+* bit to be set
+*/
+ ktime_t timeout = ktime_add_ms(ktime_get(),
+ MAX_POWER_ON_TIMEOUT);
+ do {
+ if (ktime_compare(ktime_get(), timeout) > 0) {
+ dev_warn(mmc_dev(host->mmc),
+"Power on failed\n");
+
+ return;
+ }
+
+ writeb(val, host->ioaddr + reg);
+ usleep_range(1000, 1);
+ } while (!(readb(host->ioaddr + reg) & SDHCI_POWER_ON));
+ }
}
static int sdhci_am654_execute_tuning(struct mmc_host *mmc, u32 opcode)
--
2.17.1
Re: [PATCH] mm: slab: Avoid the use of one-element array and use struct_size() helper
On Wed, 29 Jul 2020, Qianli Zhao wrote:
> From: Qianli Zhao
>
> There is a regular need in the kernel to provide a way to declare having a
> dynamically sized set of trailing elements in a structure. Kernel code should
> always use “flexible array members”[1] for these cases. The older style of
> one-element or zero-length arrays should no longer be used[2].
>
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] https://github.com/KSPP/linux/issues/21
>
> Signed-off-by: Qianli Zhao
> ---
> mm/slab.h| 2 +-
> mm/slab_common.c | 7 ++-
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/mm/slab.h b/mm/slab.h
> index 74f7e09..c12fb65 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -34,7 +34,7 @@ struct kmem_cache {
>
> struct memcg_cache_array {
> struct rcu_head rcu;
> - struct kmem_cache *entries[0];
> + struct kmem_cache *entries[];
> };
>
> /*
This is removed in the -mm tree, see
https://www.ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-slab-use-a-single-set-of-kmem_caches-for-all-allocations.patch
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index fe8b684..56f4818 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -166,9 +166,7 @@ static int init_memcg_params(struct kmem_cache *s,
> if (!memcg_nr_cache_ids)
> return 0;
>
> - arr = kvzalloc(sizeof(struct memcg_cache_array) +
> -memcg_nr_cache_ids * sizeof(void *),
> -GFP_KERNEL);
> + arr = kvzalloc(struct_size(arr, entries, memcg_nr_cache_ids),
> GFP_KERNEL);
> if (!arr)
> return -ENOMEM;
>
> @@ -199,8 +197,7 @@ static int update_memcg_params(struct kmem_cache *s, int
> new_array_size)
> {
> struct memcg_cache_array *old, *new;
>
> - new = kvzalloc(sizeof(struct memcg_cache_array) +
> -new_array_size * sizeof(void *), GFP_KERNEL);
> + new = kvzalloc(struct_size(new, entries, new_array_size), GFP_KERNEL);
> if (!new)
> return -ENOMEM;
>
> --
> 2.7.4
>
>
[RFT PATCH v4 4/9] include: pe.h: Add RISC-V related PE definition
Define RISC-V related machine types. Signed-off-by: Atish Patra Reviewed-by: Palmer Dabbelt Link: https://lore.kernel.org/r/20200415195422.19866-3-atish.pa...@wdc.com Signed-off-by: Ard Biesheuvel --- include/linux/pe.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/pe.h b/include/linux/pe.h index 8ad71d763a77..daf09e38 100644 --- a/include/linux/pe.h +++ b/include/linux/pe.h @@ -55,6 +55,9 @@ #defineIMAGE_FILE_MACHINE_POWERPC 0x01f0 #defineIMAGE_FILE_MACHINE_POWERPCFP0x01f1 #defineIMAGE_FILE_MACHINE_R40000x0166 +#defineIMAGE_FILE_MACHINE_RISCV32 0x5032 +#defineIMAGE_FILE_MACHINE_RISCV64 0x5064 +#defineIMAGE_FILE_MACHINE_RISCV128 0x5128 #defineIMAGE_FILE_MACHINE_SH3 0x01a2 #defineIMAGE_FILE_MACHINE_SH3DSP 0x01a3 #defineIMAGE_FILE_MACHINE_SH3E 0x01a4 -- 2.24.0
[RFT PATCH v4 3/9] RISC-V: Implement late mapping page table allocation functions
Currently, page table setup is done during setup_va_final where fixmap can
be used to create the temporary mappings. The physical frame is allocated
from memblock_alloc_* functions. However, this won't work if page table
mapping needs to be created for a different mm context (i.e. efi mm) at
a later point of time.
Use generic kernel page allocation function & macros for any mapping
after setup_vm_final.
Signed-off-by: Atish Patra
---
arch/riscv/mm/init.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 68c608a0e91f..cba03fec08c1 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -212,6 +212,7 @@ pgd_t swapper_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
pte_t fixmap_pte[PTRS_PER_PTE] __page_aligned_bss;
static bool mmu_enabled;
+static bool late_mapping;
#define MAX_EARLY_MAPPING_SIZE SZ_128M
@@ -236,7 +237,9 @@ void __set_fixmap(enum fixed_addresses idx, phys_addr_t
phys, pgprot_t prot)
static pte_t *__init get_pte_virt(phys_addr_t pa)
{
- if (mmu_enabled) {
+ if (late_mapping)
+ return (pte_t *) __va(pa);
+ else if (mmu_enabled) {
clear_fixmap(FIX_PTE);
return (pte_t *)set_fixmap_offset(FIX_PTE, pa);
} else {
@@ -246,13 +249,19 @@ static pte_t *__init get_pte_virt(phys_addr_t pa)
static phys_addr_t __init alloc_pte(uintptr_t va)
{
+ unsigned long vaddr;
/*
* We only create PMD or PGD early mappings so we
* should never reach here with MMU disabled.
*/
BUG_ON(!mmu_enabled);
-
- return memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE);
+ if (late_mapping) {
+ vaddr = __get_free_page(GFP_KERNEL);
+ if (!vaddr || !pgtable_pte_page_ctor(virt_to_page(vaddr)))
+ BUG();
+ return __pa(vaddr);
+ } else
+ return memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE);
}
static void __init create_pte_mapping(pte_t *ptep,
@@ -281,7 +290,9 @@ pmd_t early_pmd[PTRS_PER_PMD * NUM_EARLY_PMDS] __initdata
__aligned(PAGE_SIZE);
static pmd_t *__init get_pmd_virt(phys_addr_t pa)
{
- if (mmu_enabled) {
+ if (late_mapping)
+ return (pmd_t *) __va(pa);
+ else if (mmu_enabled) {
clear_fixmap(FIX_PMD);
return (pmd_t *)set_fixmap_offset(FIX_PMD, pa);
} else {
@@ -292,8 +303,13 @@ static pmd_t *__init get_pmd_virt(phys_addr_t pa)
static phys_addr_t __init alloc_pmd(uintptr_t va)
{
uintptr_t pmd_num;
+ unsigned long vaddr;
- if (mmu_enabled)
+ if (late_mapping) {
+ vaddr = __get_free_page(GFP_KERNEL);
+ BUG_ON(!vaddr);
+ return __pa(vaddr);
+ } else if (mmu_enabled)
return memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE);
pmd_num = (va - PAGE_OFFSET) >> PGDIR_SHIFT;
@@ -533,6 +549,9 @@ static void __init setup_vm_final(void)
/* Move to swapper page table */
csr_write(CSR_SATP, PFN_DOWN(__pa_symbol(swapper_pg_dir)) | SATP_MODE);
local_flush_tlb_all();
+
+ /* generic page allocation function must be used to setup page table */
+ late_mapping = true;
}
#else
asmlinkage void __init setup_vm(uintptr_t dtb_pa)
--
2.24.0
[RFT PATCH v4 0/9] Add UEFI support for RISC-V
This series adds UEFI support for RISC-V.
Linux kernel: 5.8-rc7 + 1 exception vector setup patch (queued for for-next)
U-Boot: v2020.07
OpenSBI: master
This series depends on early setup of exeception vector patch
http://lists.infradead.org/pipermail/linux-riscv/2020-July/001207.html
Patch 1-3 are generic riscv feature addition required for UEFI support.
Patch 4-7 adds the efi stub support for RISC-V which was reviewed few months
back.
https://www.spinics.net/lists/linux-efi/msg19144.html
Patch 8 just renames arm-init code so that it can be used across different
architectures. Patch 11 adds the runtime services for RISC-V.
The working set of patches can also be found in following git repo.
https://github.com/atishp04/linux/tree/uefi_riscv_5.9_v4
The patches have been verified on Qemu/HiFive unleashed using bootefi command in
U-Boot for both RV32 and RV64.
For RV32, maximum allocated memory should be 1G as RISC-V kernel can not map
beyond 1G of physical memory for RV32.
Runtime services have been verified with fwts. Here is the snippet of the
result.
***
This test run on 16/07/20 at 17:54:53 on host Linux fedora-riscv
5.8.0-rc5-00015-g5e61441080fd-dirty #938 SMP Thu Jul 16 14:50:11 PDT 2020
riscv64.
Command: "fwts uefirtvariable".
Running tests: uefirtvariable.
uefirtvariable: UEFI Runtime service variable interface tests.
Test 1 of 9: Test UEFI RT service get variable interface.
SKIPPED: Test 1, Skipping test, SetVariable runtime service is not supported on
this platform.
Test 2 of 9: Test UEFI RT service get next variable name interface.
The runtime service GetNextVariableName interface function test.
SKIPPED: Test 2, Skipping test, SetVariable runtime service is not supported on
this platform.
...
Test 4 of 9: Test UEFI RT service query variable info interface.
SKIPPED: Test 4, Not support the QueryVariableInfo UEFI runtime interface:
cannot test.
ADVICE: Firmware also needs to check if the revision of system table is correct
or not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of
system table is less than EFI_2_00_SYSTEM_TABLE_REVISION.
...
***
Currently, U-Boot EFI implementation returns EFI_UNSUPPORTED for set_variable
service. That's why all tests have been skipped but I manually verified that the
value is returned from U-Boot not kernel :).
EDK2 can boot quite far into Linux with the current series. However, it crashes
before userspace because of a possible memory corruption by EDK2.
Changes from v3->v4:
1. Used pgd mapping to avoid copying DT to bss.
Changes from v2->v3:
1. Fixed few bugs in run time services page table mapping.
2. Dropped patch 1 as it is already taken into efi-tree.
3. Sent few generic mmu fixes as a separate series to ease the merge conflicts.
Changes from v1->v2:
1. Removed patch 1 as it is already taken into efi-tree.
2. Fixed compilation issues with patch 9.
3. Moved few function prototype declaration to header file to keep kbuild happy.
Changes from previous version:
1. Added full ioremap support.
2. Added efi runtime services support.
3. Fixes mm issues
Anup Patel (1):
RISC-V: Move DT mapping outof fixmap
Atish Patra (8):
RISC-V: Add early ioremap support
RISC-V: Implement late mapping page table allocation functions
include: pe.h: Add RISC-V related PE definition
RISC-V: Add PE/COFF header for EFI stub
RISC-V: Add EFI stub support.
efi: Rename arm-init to efi-init common for all arch
RISC-V: Add EFI runtime services
RISC-V: Add page table dump support for uefi
arch/riscv/Kconfig| 25 +++
arch/riscv/Makefile | 1 +
arch/riscv/configs/defconfig | 1 +
arch/riscv/include/asm/Kbuild | 1 +
arch/riscv/include/asm/efi.h | 56 +++
arch/riscv/include/asm/fixmap.h | 16 +-
arch/riscv/include/asm/io.h | 1 +
arch/riscv/include/asm/mmu.h | 2 +
arch/riscv/include/asm/pgtable.h | 5 +
arch/riscv/include/asm/sections.h | 13 ++
arch/riscv/kernel/Makefile| 5 +
arch/riscv/kernel/efi-header.S| 104 +
arch/riscv/kernel/efi.c | 105 +
arch/riscv/kernel/head.S | 17 ++-
arch/riscv/kernel/head.h | 2 -
arch/riscv/kernel/image-vars.h| 51 +++
arch/riscv/kernel/setup.c | 17 ++-
arch/riscv/kernel/vmlinux.lds.S | 22 ++-
arch/riscv/mm/init.c | 90 ---
arch/riscv/mm/ptdump.c| 48 +-
drivers/firmware/efi/Kconfig | 3 +-
drivers/firmware/efi/Makefile | 4 +-
.../firmware/efi/{arm-init.c => efi-init.c} | 0
drivers/firmware/efi/libstub/Makefile |
[RFT PATCH v4 2/9] RISC-V: Add early ioremap support
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/Kbuild | 1 +
arch/riscv/include/asm/fixmap.h | 13 +
arch/riscv/include/asm/io.h | 1 +
arch/riscv/kernel/setup.c | 1 +
arch/riscv/mm/init.c| 33 +
6 files changed, 50 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 3230c1d48562..e6c1c98a53fb 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -34,6 +34,7 @@ config RISCV
select GENERIC_ARCH_TOPOLOGY if SMP
select GENERIC_ATOMIC64 if !64BIT
select GENERIC_CLOCKEVENTS
+ select GENERIC_EARLY_IOREMAP
select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
select GENERIC_IOREMAP
select GENERIC_IRQ_MULTI_HANDLER
diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
index 3d9410bb4de0..59dd7be55005 100644
--- a/arch/riscv/include/asm/Kbuild
+++ b/arch/riscv/include/asm/Kbuild
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+generic-y += early_ioremap.h
generic-y += extable.h
generic-y += flat.h
generic-y += kvm_para.h
diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
index 11613f38228a..54cbf07fb4e9 100644
--- a/arch/riscv/include/asm/fixmap.h
+++ b/arch/riscv/include/asm/fixmap.h
@@ -27,6 +27,19 @@ enum fixed_addresses {
FIX_TEXT_POKE1,
FIX_TEXT_POKE0,
FIX_EARLYCON_MEM_BASE,
+
+ __end_of_permanent_fixed_addresses,
+ /*
+* Temporary boot-time mappings, used by early_ioremap(),
+* before ioremap() is functional.
+*/
+#define NR_FIX_BTMAPS (SZ_256K / PAGE_SIZE)
+#define FIX_BTMAPS_SLOTS 7
+#define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+
+ FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
+ FIX_BTMAP_BEGIN = FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1,
+
__end_of_fixed_addresses
};
diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
index 3835c3295dc5..c025a746a148 100644
--- a/arch/riscv/include/asm/io.h
+++ b/arch/riscv/include/asm/io.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/*
* MMIO access functions are separated out to break dependency cycles
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 6a0ee2405813..c71788e6aff4 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -72,6 +72,7 @@ void __init setup_arch(char **cmdline_p)
*cmdline_p = boot_command_line;
+ early_ioremap_setup();
parse_early_param();
setup_bootmem();
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 9c5f3e35adc2..68c608a0e91f 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -403,6 +403,9 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
uintptr_t load_pa = (uintptr_t)(&_start);
uintptr_t load_sz = (uintptr_t)(&_end) - load_pa;
uintptr_t map_size = best_map_size(load_pa, MAX_EARLY_MAPPING_SIZE);
+#ifndef __PAGETABLE_PMD_FOLDED
+ pmd_t fix_bmap_spmd, fix_bmap_epmd;
+#endif
va_pa_offset = PAGE_OFFSET - load_pa;
pfn_base = PFN_DOWN(load_pa);
@@ -456,6 +459,36 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
pa + PGDIR_SIZE, PGDIR_SIZE, PAGE_KERNEL);
dtb_early_va = (void *)DTB_EARLY_BASE_VA + (dtb_pa & (PGDIR_SIZE - 1));
dtb_early_pa = dtb_pa;
+
+ /*
+* Bootime fixmap only can handle PMD_SIZE mapping. Thus, boot-ioremap
+* range can not span multiple pmds.
+*/
+ BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
+!= (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));
+
+#ifndef __PAGETABLE_PMD_FOLDED
+ /*
+* Early ioremap fixmap is already created as it lies within first 2MB
+* of fixmap region. We always map PMD_SIZE. Thus, both FIX_BTMAP_END
+* FIX_BTMAP_BEGIN should lie in the same pmd. Verify that and warn
+* the user if not.
+*/
+ fix_bmap_spmd = fixmap_pmd[pmd_index(__fix_to_virt(FIX_BTMAP_BEGIN))];
+ fix_bmap_epmd = fixmap_pmd[pmd_index(__fix_to_virt(FIX_BTMAP_END))];
+ if (pmd_val(fix_bmap_spmd) != pmd_val(fix_bmap_epmd)) {
+ WARN_ON(1);
+ pr_warn("fixmap btmap start [%08lx] != end [%08lx]\n",
+ pmd_val(fix_bmap_spmd), pmd_val(fix_bmap_epmd));
+ pr_warn("fix_to_virt(FIX_BTMAP_BEGIN): %08lx\n",
+ fix_to_virt(FIX_BTMAP_BEGIN));
+ pr_warn("fix_to_virt(FIX_BTMAP_END): %08lx\n",
+ fix_to_virt(FIX_BTMAP_END));
+
+ pr_warn("FIX_BTMAP_END: %d\n", FIX_BTMAP_END);
+
[RFT PATCH v4 6/9] RISC-V: Add EFI stub support.
Add a RISC-V architecture specific stub code that actually copies the
actual kernel image to a valid address and jump to it after boot services
are terminated. Enable UEFI related kernel configs as well for RISC-V.
Signed-off-by: Atish Patra
Link: https://lore.kernel.org/r/2020042106.9663-4-atish.pa...@wdc.com
[ardb: - move hartid fetch into check_platform_features()
- use image_size not reserve_size
- select ISA_C ]
Signed-off-by: Ard Biesheuvel
---
arch/riscv/Kconfig| 22 +
arch/riscv/Makefile | 1 +
arch/riscv/configs/defconfig | 1 +
arch/riscv/include/asm/efi.h | 36 +++
drivers/firmware/efi/Kconfig | 3 +-
drivers/firmware/efi/libstub/Makefile | 10 ++
drivers/firmware/efi/libstub/riscv-stub.c | 110 ++
7 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/include/asm/efi.h
create mode 100644 drivers/firmware/efi/libstub/riscv-stub.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e6c1c98a53fb..a6569c268565 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -390,6 +390,26 @@ config CMDLINE_FORCE
endchoice
+config EFI_STUB
+ bool
+
+config EFI
+ bool "UEFI runtime support"
+ depends on OF
+ select LIBFDT
+ select UCS2_STRING
+ select EFI_PARAMS_FROM_FDT
+ select EFI_STUB
+ select EFI_GENERIC_STUB
+ select RISCV_ISA_C
+ default y
+ help
+ This option provides support for runtime services provided
+ by UEFI firmware (such as non-volatile variables, realtime
+ clock, and platform reset). A UEFI stub is also provided to
+ allow the kernel to be booted as an EFI application. This
+ is only useful on systems that have UEFI firmware.
+
endmenu
config BUILTIN_DTB
@@ -402,3 +422,5 @@ menu "Power management options"
source "kernel/power/Kconfig"
endmenu
+
+source "drivers/firmware/Kconfig"
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index fb6e37db836d..10df59f28add 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -80,6 +80,7 @@ head-y := arch/riscv/kernel/head.o
core-y += arch/riscv/
libs-y += arch/riscv/lib/
+libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
PHONY += vdso_install
vdso_install:
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 4da4886246a4..ae69e12d306a 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -129,3 +129,4 @@ CONFIG_DEBUG_BLOCK_EXT_DEVT=y
# CONFIG_RUNTIME_TESTING_MENU is not set
CONFIG_MEMTEST=y
# CONFIG_SYSFS_SYSCALL is not set
+CONFIG_EFI=y
diff --git a/arch/riscv/include/asm/efi.h b/arch/riscv/include/asm/efi.h
new file mode 100644
index ..86da231909bb
--- /dev/null
+++ b/arch/riscv/include/asm/efi.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+#ifndef _ASM_EFI_H
+#define _ASM_EFI_H
+
+#include
+#include
+#include
+#include
+
+/* on RISC-V, the FDT may be located anywhere in system RAM */
+static inline unsigned long efi_get_max_fdt_addr(unsigned long dram_base)
+{
+ return ULONG_MAX;
+}
+
+/* Load initrd at enough distance from DRAM start */
+static inline unsigned long efi_get_max_initrd_addr(unsigned long dram_base,
+ unsigned long image_addr)
+{
+ return dram_base + SZ_256M;
+}
+
+#define alloc_screen_info(x...)(_info)
+
+static inline void free_screen_info(struct screen_info *si)
+{
+}
+
+static inline void efifb_setup_from_dmi(struct screen_info *si, const char
*opt)
+{
+}
+
+#endif /* _ASM_EFI_H */
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 3939699e62fe..a29fbd6e657e 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -111,7 +111,7 @@ config EFI_GENERIC_STUB
config EFI_ARMSTUB_DTB_LOADER
bool "Enable the DTB loader"
- depends on EFI_GENERIC_STUB
+ depends on EFI_GENERIC_STUB && !RISCV
default y
help
Select this config option to add support for the dtb= command
@@ -128,6 +128,7 @@ config EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
bool "Enable the command line initrd loader" if !X86
depends on EFI_STUB && (EFI_GENERIC_STUB || X86)
default y
+ depends on !RISCV
help
Select this config option to add support for the initrd= command
line parameter, allowing an initrd that resides on the same volume
diff --git a/drivers/firmware/efi/libstub/Makefile
b/drivers/firmware/efi/libstub/Makefile
index 75daaf20374e..d1564ffcf82f 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -22,6 +22,8 @@ cflags-$(CONFIG_ARM64):= $(subst
[RFT PATCH v4 1/9] RISC-V: Move DT mapping outof fixmap
From: Anup Patel
Currently, RISC-V reserves 1MB of fixmap memory for device tree. However,
it maps only single PMD (2MB) space for fixmap which leaves only < 1MB space
left for other kernel features such as early ioremap which requires fixmap
as well. The fixmap size can be increased by another 2MB but it brings
additional complexity and changes the virtual memory layout as well.
If we require some additional feature requiring fixmap again, it has to be
moved again.
Technically, DT doesn't need a fixmap as the memory occupied by the DT is
only used during boot. That's why, We map device tree in early page table
using two consecutive PGD mappings at lower addresses (< PAGE_OFFSET).
This frees lot of space in fixmap and also makes maximum supported
device tree size supported as PGDIR_SIZE. Thus, init memory section can be used
for the same purpose as well. This simplifies fixmap implementation.
Signed-off-by: Anup Patel
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/fixmap.h | 3 ---
arch/riscv/include/asm/pgtable.h | 1 +
arch/riscv/kernel/head.S | 1 -
arch/riscv/kernel/head.h | 2 --
arch/riscv/kernel/setup.c| 9 +++--
arch/riscv/mm/init.c | 26 --
6 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
index 1ff075a8dfc7..11613f38228a 100644
--- a/arch/riscv/include/asm/fixmap.h
+++ b/arch/riscv/include/asm/fixmap.h
@@ -22,9 +22,6 @@
*/
enum fixed_addresses {
FIX_HOLE,
-#define FIX_FDT_SIZE SZ_1M
- FIX_FDT_END,
- FIX_FDT = FIX_FDT_END + FIX_FDT_SIZE / PAGE_SIZE - 1,
FIX_PTE,
FIX_PMD,
FIX_TEXT_POKE1,
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index eaea1f717010..815f8c959dd4 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -464,6 +464,7 @@ static inline void __kernel_map_pages(struct page *page,
int numpages, int enabl
#define kern_addr_valid(addr) (1) /* FIXME */
extern void *dtb_early_va;
+extern uintptr_t dtb_early_pa;
void setup_bootmem(void);
void paging_init(void);
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index d0c5c316e9bb..eb123eda3663 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -250,7 +250,6 @@ clear_bss_done:
#endif
/* Start the kernel */
call soc_early_init
- call parse_dtb
tail start_kernel
.Lsecondary_start:
diff --git a/arch/riscv/kernel/head.h b/arch/riscv/kernel/head.h
index 105fb0496b24..b48dda3d04f6 100644
--- a/arch/riscv/kernel/head.h
+++ b/arch/riscv/kernel/head.h
@@ -16,6 +16,4 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa);
extern void *__cpu_up_stack_pointer[];
extern void *__cpu_up_task_pointer[];
-void __init parse_dtb(void);
-
#endif /* __ASM_HEAD_H */
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index f04373be54a6..6a0ee2405813 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -49,8 +49,9 @@ atomic_t hart_lottery __section(.sdata);
unsigned long boot_cpu_hartid;
static DEFINE_PER_CPU(struct cpu, cpu_devices);
-void __init parse_dtb(void)
+static void __init parse_dtb(void)
{
+ /* Early scan of device tree from init memory */
if (early_init_dt_scan(dtb_early_va))
return;
@@ -63,6 +64,7 @@ void __init parse_dtb(void)
void __init setup_arch(char **cmdline_p)
{
+ parse_dtb();
init_mm.start_code = (unsigned long) _stext;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
@@ -77,7 +79,10 @@ void __init setup_arch(char **cmdline_p)
#if IS_ENABLED(CONFIG_BUILTIN_DTB)
unflatten_and_copy_device_tree();
#else
- unflatten_device_tree();
+ if (early_init_dt_verify(__va(dtb_early_pa)))
+ unflatten_device_tree();
+ else
+ pr_err("No DTB found in kernel mappings\n");
#endif
clint_init_boot_cpu();
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 79e9d55bdf1a..9c5f3e35adc2 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -28,7 +28,9 @@ unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned
long)]
EXPORT_SYMBOL(empty_zero_page);
extern char _start[];
-void *dtb_early_va;
+#define DTB_EARLY_BASE_VA PGDIR_SIZE
+void *dtb_early_va __initdata;
+uintptr_t dtb_early_pa __initdata;
static void __init zone_sizes_init(void)
{
@@ -141,8 +143,6 @@ static void __init setup_initrd(void)
}
#endif /* CONFIG_BLK_DEV_INITRD */
-static phys_addr_t dtb_early_pa __initdata;
-
void __init setup_bootmem(void)
{
struct memblock_region *reg;
@@ -399,7 +399,7 @@ static uintptr_t __init best_map_size(phys_addr_t base,
phys_addr_t size)
asmlinkage void __init setup_vm(uintptr_t dtb_pa)
{
- uintptr_t va, end_va;
+ uintptr_t va, pa, end_va;
[RFT PATCH v4 9/9] RISC-V: Add page table dump support for uefi
Extend the current page table dump support in RISC-V to include efi
pages as well.
Here is the output of efi runtime page table mappings.
---[ UEFI runtime start ]---
0x20002000-0x20003000 0xbe732000 4K PTE D A . . . W R V
0x20018000-0x20019000 0xbe738000 4K PTE D A . . . W R V
0x2002c000-0x2002d000 0xbe73c000 4K PTE D A . . . W R V
0x20031000-0x20032000 0xbff61000 4K PTE D A . . X W R V
---[ UEFI runtime end ]---
Signed-off-by: Atish Patra
---
arch/riscv/mm/ptdump.c | 48 --
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c
index 0831c2e61a8f..ace74dec7492 100644
--- a/arch/riscv/mm/ptdump.c
+++ b/arch/riscv/mm/ptdump.c
@@ -3,6 +3,7 @@
* Copyright (C) 2019 SiFive
*/
+#include
#include
#include
#include
@@ -49,6 +50,14 @@ struct addr_marker {
const char *name;
};
+/* Private information for debugfs */
+struct ptd_mm_info {
+ struct mm_struct*mm;
+ const struct addr_marker*markers;
+ unsigned long base_addr;
+ unsigned long end;
+};
+
static struct addr_marker address_markers[] = {
#ifdef CONFIG_KASAN
{KASAN_SHADOW_START,"Kasan shadow start"},
@@ -68,6 +77,28 @@ static struct addr_marker address_markers[] = {
{-1, NULL},
};
+static struct ptd_mm_info kernel_ptd_info = {
+ .mm = _mm,
+ .markers= address_markers,
+ .base_addr = KERN_VIRT_START,
+ .end= ULONG_MAX,
+};
+
+#ifdef CONFIG_EFI
+static struct addr_marker efi_addr_markers[] = {
+ { 0,"UEFI runtime start" },
+ { SZ_1G,"UEFI runtime end" },
+ { -1, NULL }
+};
+
+static struct ptd_mm_info efi_ptd_info = {
+ .mm = _mm,
+ .markers= efi_addr_markers,
+ .base_addr = 0,
+ .end= SZ_2G,
+};
+#endif
+
/* Page Table Entry */
struct prot_bits {
u64 mask;
@@ -245,22 +276,22 @@ static void note_page(struct ptdump_state *pt_st,
unsigned long addr,
}
}
-static void ptdump_walk(struct seq_file *s)
+static void ptdump_walk(struct seq_file *s, struct ptd_mm_info *pinfo)
{
struct pg_state st = {
.seq = s,
- .marker = address_markers,
+ .marker = pinfo->markers,
.level = -1,
.ptdump = {
.note_page = note_page,
.range = (struct ptdump_range[]) {
- {KERN_VIRT_START, ULONG_MAX},
+ {pinfo->base_addr, pinfo->end},
{0, 0}
}
}
};
- ptdump_walk_pgd(, _mm, NULL);
+ ptdump_walk_pgd(, pinfo->mm, NULL);
}
void ptdump_check_wx(void)
@@ -293,7 +324,7 @@ void ptdump_check_wx(void)
static int ptdump_show(struct seq_file *m, void *v)
{
- ptdump_walk(m);
+ ptdump_walk(m, m->private);
return 0;
}
@@ -308,8 +339,13 @@ static int ptdump_init(void)
for (j = 0; j < ARRAY_SIZE(pte_bits); j++)
pg_level[i].mask |= pte_bits[j].mask;
- debugfs_create_file("kernel_page_tables", 0400, NULL, NULL,
+ debugfs_create_file("kernel_page_tables", 0400, NULL, _ptd_info,
_fops);
+#ifdef CONFIG_EFI
+ if (efi_enabled(EFI_RUNTIME_SERVICES))
+ debugfs_create_file("efi_page_tables", 0400, NULL,
_ptd_info,
+ _fops);
+#endif
return 0;
}
--
2.24.0
[RFT PATCH v4 7/9] efi: Rename arm-init to efi-init common for all arch
arm-init is responsible for setting up efi runtime and doesn't actually
do any ARM specific stuff. RISC-V can use the same source code as it is.
Rename it to efi-init so that RISC-V can use it.
Signed-off-by: Atish Patra
---
drivers/firmware/efi/Makefile | 2 +-
drivers/firmware/efi/{arm-init.c => efi-init.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/firmware/efi/{arm-init.c => efi-init.c} (100%)
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 7a216984552b..61fd1e8b26fb 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -32,7 +32,7 @@ obj-$(CONFIG_EFI_EMBEDDED_FIRMWARE) += embedded-firmware.o
fake_map-y += fake_mem.o
fake_map-$(CONFIG_X86) += x86_fake_mem.o
-arm-obj-$(CONFIG_EFI) := arm-init.o arm-runtime.o
+arm-obj-$(CONFIG_EFI) := efi-init.o arm-runtime.o
obj-$(CONFIG_ARM) += $(arm-obj-y)
obj-$(CONFIG_ARM64)+= $(arm-obj-y)
obj-$(CONFIG_EFI_CAPSULE_LOADER) += capsule-loader.o
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/efi-init.c
similarity index 100%
rename from drivers/firmware/efi/arm-init.c
rename to drivers/firmware/efi/efi-init.c
--
2.24.0
[RFT PATCH v4 8/9] RISC-V: Add EFI runtime services
This patch adds EFI runtime service support for RISC-V.
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig | 2 +
arch/riscv/include/asm/efi.h| 20
arch/riscv/include/asm/mmu.h| 2 +
arch/riscv/include/asm/pgtable.h| 4 +
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/efi.c | 105 +
arch/riscv/kernel/setup.c | 7 +-
arch/riscv/mm/init.c| 2 +-
drivers/firmware/efi/Makefile | 2 +
drivers/firmware/efi/libstub/efi-stub.c | 11 +-
drivers/firmware/efi/riscv-runtime.c| 143
11 files changed, 295 insertions(+), 4 deletions(-)
create mode 100644 arch/riscv/kernel/efi.c
create mode 100644 drivers/firmware/efi/riscv-runtime.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a6569c268565..4858b19fe3a4 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -401,7 +401,9 @@ config EFI
select EFI_PARAMS_FROM_FDT
select EFI_STUB
select EFI_GENERIC_STUB
+ select EFI_RUNTIME_WRAPPERS
select RISCV_ISA_C
+ depends on MMU
default y
help
This option provides support for runtime services provided
diff --git a/arch/riscv/include/asm/efi.h b/arch/riscv/include/asm/efi.h
index 86da231909bb..93c305a638f4 100644
--- a/arch/riscv/include/asm/efi.h
+++ b/arch/riscv/include/asm/efi.h
@@ -5,11 +5,28 @@
#ifndef _ASM_EFI_H
#define _ASM_EFI_H
+#include
#include
#include
#include
#include
+#ifdef CONFIG_EFI
+extern void efi_init(void);
+#else
+#define efi_init()
+#endif
+
+int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
+int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
+
+#define arch_efi_call_virt_setup() efi_virtmap_load()
+#define arch_efi_call_virt_teardown() efi_virtmap_unload()
+
+#define arch_efi_call_virt(p, f, args...) p->f(args)
+
+#define ARCH_EFI_IRQ_FLAGS_MASK (SR_IE | SR_SPIE)
+
/* on RISC-V, the FDT may be located anywhere in system RAM */
static inline unsigned long efi_get_max_fdt_addr(unsigned long dram_base)
{
@@ -33,4 +50,7 @@ static inline void efifb_setup_from_dmi(struct screen_info
*si, const char *opt)
{
}
+void efi_virtmap_load(void);
+void efi_virtmap_unload(void);
+
#endif /* _ASM_EFI_H */
diff --git a/arch/riscv/include/asm/mmu.h b/arch/riscv/include/asm/mmu.h
index 967eacb01ab5..dabcf2cfb3dc 100644
--- a/arch/riscv/include/asm/mmu.h
+++ b/arch/riscv/include/asm/mmu.h
@@ -20,6 +20,8 @@ typedef struct {
#endif
} mm_context_t;
+void __init create_pgd_mapping(pgd_t *pgdp, uintptr_t va, phys_addr_t pa,
+ phys_addr_t sz, pgprot_t prot);
#endif /* __ASSEMBLY__ */
#endif /* _ASM_RISCV_MMU_H */
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 815f8c959dd4..183f1f4b2ae6 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -100,6 +100,10 @@
#define PAGE_KERNEL__pgprot(_PAGE_KERNEL)
#define PAGE_KERNEL_EXEC __pgprot(_PAGE_KERNEL | _PAGE_EXEC)
+#define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
+#define PAGE_KERNEL_EXEC __pgprot(_PAGE_KERNEL | _PAGE_EXEC)
+#define PAGE_KERNEL_READ_EXEC __pgprot((_PAGE_KERNEL & ~_PAGE_WRITE) \
+| _PAGE_EXEC)
#define PAGE_TABLE __pgprot(_PAGE_TABLE)
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 6f7a3b3771fd..239c44c451b6 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -36,6 +36,7 @@ OBJCOPYFLAGS := --prefix-symbols=__efistub_
$(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,objcopy)
+obj-$(CONFIG_EFI) += efi.o
obj-$(CONFIG_FPU) += fpu.o
obj-$(CONFIG_SMP) += smpboot.o
obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/riscv/kernel/efi.c b/arch/riscv/kernel/efi.c
new file mode 100644
index ..d7a723b446c3
--- /dev/null
+++ b/arch/riscv/kernel/efi.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ * Adapted from arch/arm64/kernel/efi.c
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+
+/*
+ * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
+ * executable, everything else can be mapped with the XN bits
+ * set. Also take the new (optional) RO/XP bits into account.
+ */
+static __init pgprot_t efimem_to_pgprot_map(efi_memory_desc_t *md)
+{
+ u64 attr = md->attribute;
+ u32 type = md->type;
+
+ if (type == EFI_MEMORY_MAPPED_IO)
+ return PAGE_KERNEL;
+
+ if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr),
+ "UEFI Runtime regions are not aligned to page size --
buggy firmware?"))
+ /*
+* If the region is not
[RFT PATCH v4 5/9] RISC-V: Add PE/COFF header for EFI stub
Linux kernel Image can appear as an EFI application With appropriate PE/COFF header fields in the beginning of the Image header. An EFI application loader can directly load a Linux kernel Image and an EFI stub residing in kernel can boot Linux kernel directly. Add the necessary PE/COFF header. Signed-off-by: Atish Patra Link: https://lore.kernel.org/r/2020042106.9663-3-atish.pa...@wdc.com [ardb: - use C prefix for c.li to ensure the expected opcode is emitted - align all image sections according to PE/COFF section alignment ] Signed-off-by: Ard Biesheuvel --- arch/riscv/include/asm/sections.h | 13 arch/riscv/kernel/Makefile| 4 ++ arch/riscv/kernel/efi-header.S| 104 ++ arch/riscv/kernel/head.S | 16 + arch/riscv/kernel/image-vars.h| 51 +++ arch/riscv/kernel/vmlinux.lds.S | 22 ++- 6 files changed, 208 insertions(+), 2 deletions(-) create mode 100644 arch/riscv/include/asm/sections.h create mode 100644 arch/riscv/kernel/efi-header.S create mode 100644 arch/riscv/kernel/image-vars.h diff --git a/arch/riscv/include/asm/sections.h b/arch/riscv/include/asm/sections.h new file mode 100644 index ..3a9971b1210f --- /dev/null +++ b/arch/riscv/include/asm/sections.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (C) 2020 Western Digital Corporation or its affiliates. + */ +#ifndef __ASM_SECTIONS_H +#define __ASM_SECTIONS_H + +#include + +extern char _start[]; +extern char _start_kernel[]; + +#endif /* __ASM_SECTIONS_H */ diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index b355cf485671..6f7a3b3771fd 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -32,6 +32,10 @@ obj-y+= patch.o obj-$(CONFIG_MMU) += vdso.o vdso/ obj-$(CONFIG_RISCV_M_MODE) += clint.o traps_misaligned.o +OBJCOPYFLAGS := --prefix-symbols=__efistub_ +$(obj)/%.stub.o: $(obj)/%.o FORCE + $(call if_changed,objcopy) + obj-$(CONFIG_FPU) += fpu.o obj-$(CONFIG_SMP) += smpboot.o obj-$(CONFIG_SMP) += smp.o diff --git a/arch/riscv/kernel/efi-header.S b/arch/riscv/kernel/efi-header.S new file mode 100644 index ..822b4c9ff2bb --- /dev/null +++ b/arch/riscv/kernel/efi-header.S @@ -0,0 +1,104 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (C) 2020 Western Digital Corporation or its affiliates. + * Adapted from arch/arm64/kernel/efi-header.S + */ + +#include +#include + + .macro __EFI_PE_HEADER + .long PE_MAGIC +coff_header: +#ifdef CONFIG_64BIT + .short IMAGE_FILE_MACHINE_RISCV64 // Machine +#else + .short IMAGE_FILE_MACHINE_RISCV32 // Machine +#endif + .short section_count // NumberOfSections + .long 0 // TimeDateStamp + .long 0 // PointerToSymbolTable + .long 0 // NumberOfSymbols + .short section_table - optional_header // SizeOfOptionalHeader + .short IMAGE_FILE_DEBUG_STRIPPED | \ + IMAGE_FILE_EXECUTABLE_IMAGE | \ + IMAGE_FILE_LINE_NUMS_STRIPPED // Characteristics + +optional_header: + .short PE_OPT_MAGIC_PE32PLUS // PE32+ format + .byte 0x02// MajorLinkerVersion + .byte 0x14// MinorLinkerVersion + .long __pecoff_text_end - efi_header_end // SizeOfCode + .long __pecoff_data_virt_size // SizeOfInitializedData + .long 0 // SizeOfUninitializedData + .long __efistub_efi_pe_entry - _start // AddressOfEntryPoint + .long efi_header_end - _start // BaseOfCode + +extra_header_fields: + .quad 0 // ImageBase + .long PECOFF_SECTION_ALIGNMENT// SectionAlignment + .long PECOFF_FILE_ALIGNMENT // FileAlignment + .short 0 // MajorOperatingSystemVersion + .short 0 // MinorOperatingSystemVersion + .short LINUX_EFISTUB_MAJOR_VERSION // MajorImageVersion + .short LINUX_EFISTUB_MINOR_VERSION // MinorImageVersion + .short 0 // MajorSubsystemVersion + .short 0 // MinorSubsystemVersion + .long 0 // Win32VersionValue + + .long _end - _start // SizeOfImage + + // Everything before the kernel image is considered part of the header + .long efi_header_end - _start
RE: [PATCH v3 2/4] iommu: Add iommu_aux_at(de)tach_group()
> From: Alex Williamson
> Sent: Thursday, July 30, 2020 4:04 AM
>
> On Thu, 16 Jul 2020 09:07:46 +0800
> Lu Baolu wrote:
>
> > Hi Jacob,
> >
> > On 7/16/20 12:01 AM, Jacob Pan wrote:
> > > On Wed, 15 Jul 2020 08:47:36 +0800
> > > Lu Baolu wrote:
> > >
> > >> Hi Jacob,
> > >>
> > >> On 7/15/20 12:39 AM, Jacob Pan wrote:
> > >>> On Tue, 14 Jul 2020 13:57:01 +0800
> > >>> Lu Baolu wrote:
> > >>>
> > This adds two new aux-domain APIs for a use case like vfio/mdev
> > where sub-devices derived from an aux-domain capable device are
> > created and put in an iommu_group.
> >
> > /**
> > * iommu_aux_attach_group - attach an aux-domain to an
> iommu_group
> > which
> > * contains sub-devices (for example
> > mdevs) derived
> > * from @dev.
> > * @domain: an aux-domain;
> > * @group: an iommu_group which contains sub-devices derived
> from
> > @dev;
> > * @dev:the physical device which supports
> IOMMU_DEV_FEAT_AUX.
> > *
> > * Returns 0 on success, or an error value.
> > */
> > int iommu_aux_attach_group(struct iommu_domain *domain,
> > struct iommu_group *group,
> > struct device *dev)
> >
> > /**
> > * iommu_aux_detach_group - detach an aux-domain from an
> > iommu_group *
> > * @domain: an aux-domain;
> > * @group: an iommu_group which contains sub-devices derived
> from
> > @dev;
> > * @dev:the physical device which supports
> IOMMU_DEV_FEAT_AUX.
> > *
> > * @domain must have been attached to @group via
> > iommu_aux_attach_group(). */
> > void iommu_aux_detach_group(struct iommu_domain *domain,
> > struct iommu_group *group,
> > struct device *dev)
> >
> > It also adds a flag in the iommu_group data structure to identify
> > an iommu_group with aux-domain attached from those normal ones.
> >
> > Signed-off-by: Lu Baolu
> > ---
> > drivers/iommu/iommu.c | 58
> > +++
> include/linux/iommu.h |
> > 17 + 2 files changed, 75 insertions(+)
> >
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index e1fdd3531d65..cad5a19ebf22 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -45,6 +45,7 @@ struct iommu_group {
> > struct iommu_domain *default_domain;
> > struct iommu_domain *domain;
> > struct list_head entry;
> > + unsigned int aux_domain_attached:1;
> > };
> >
> > struct group_device {
> > @@ -2759,6 +2760,63 @@ int iommu_aux_get_pasid(struct
> iommu_domain
> > *domain, struct device *dev) }
> > EXPORT_SYMBOL_GPL(iommu_aux_get_pasid);
> >
> > +/**
> > + * iommu_aux_attach_group - attach an aux-domain to an
> iommu_group
> > which
> > + * contains sub-devices (for example
> > mdevs) derived
> > + * from @dev.
> > + * @domain: an aux-domain;
> > + * @group: an iommu_group which contains sub-devices derived
> from
> > @dev;
> > + * @dev:the physical device which supports
> IOMMU_DEV_FEAT_AUX.
> > + *
> > + * Returns 0 on success, or an error value.
> > + */
> > +int iommu_aux_attach_group(struct iommu_domain *domain,
> > + struct iommu_group *group, struct
> > device *dev) +{
> > + int ret = -EBUSY;
> > +
> > + mutex_lock(>mutex);
> > + if (group->domain)
> > + goto out_unlock;
> > +
> > >>> Perhaps I missed something but are we assuming only one mdev per
> > >>> mdev group? That seems to change the logic where vfio does:
> > >>> iommu_group_for_each_dev()
> > >>> iommu_aux_attach_device()
> > >>>
> > >>
> > >> It has been changed in PATCH 4/4:
> > >>
> > >> static int vfio_iommu_attach_group(struct vfio_domain *domain,
> > >> struct vfio_group *group)
> > >> {
> > >> if (group->mdev_group)
> > >> return iommu_aux_attach_group(domain->domain,
> > >> group->iommu_group,
> > >> group->iommu_device);
> > >> else
> > >> return iommu_attach_group(domain->domain,
> > >> group->iommu_group);
> > >> }
> > >>
> > >> So, for both normal domain and aux-domain, we use the same concept:
> > >> attach a domain to a group.
> > >>
> > > I get that, but don't you have to attach all the devices within the
> >
> > This iommu_group includes only mediated devices derived from an
>
Re: linux-next: build failure after merge of the security tree
Hi all,
On Mon, 13 Jul 2020 12:04:19 +1000 Stephen Rothwell
wrote:
>
> On Wed, 8 Jul 2020 14:00:34 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the security tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/anon_inodes.c: In function 'anon_inode_make_secure_inode':
> > fs/anon_inodes.c:70:10: error: implicit declaration of function
> > 'security_inode_init_security_anon'; did you mean
> > 'security_inode_init_security'? [-Werror=implicit-function-declaration]
> >70 | error = security_inode_init_security_anon(
> > | ^
> > | security_inode_init_security
> >
> > Caused by commit
> >
> > 2749d3f84a70 ("Add a new LSM-supporting anonymous inode interface")
> >
> > # CONFIG_SECURITY is not set
> >
> > Also, the explicit include of linux/security.h is missing ...
> >
> > I have added the following patch for today.
> >
> > From b2bae25c9b715e06f7e802ec7b51cfbfec046e6c Mon Sep 17 00:00:00 2001
> > From: Stephen Rothwell
> > Date: Wed, 8 Jul 2020 13:43:01 +1000
> > Subject: [PATCH] fix up for "Add a new LSM-supporting anonymous inode
> > interface"
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > fs/anon_inodes.c | 1 +
> > include/linux/security.h | 7 +++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
> > index f87f221167cf..25d92c64411e 100644
> > --- a/fs/anon_inodes.c
> > +++ b/fs/anon_inodes.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > diff --git a/include/linux/security.h b/include/linux/security.h
> > index 95c133a8f8bb..7c6b3dcf4721 100644
> > --- a/include/linux/security.h
> > +++ b/include/linux/security.h
> > @@ -735,6 +735,13 @@ static inline int security_inode_init_security(struct
> > inode *inode,
> > return 0;
> > }
> >
> > +static inline int security_inode_init_security_anon(struct inode *inode,
> > + const struct qstr *name,
> > + const struct inode
> > *context_inode)
> > +{
> > + return 0;
> > +}
> > +
> > static inline int security_old_inode_init_security(struct inode *inode,
> >struct inode *dir,
> >const struct qstr *qstr,
>
> I am still applying the above patch ...
The merge window is coming up fast ... is anything happening about this
failure?
--
Cheers,
Stephen Rothwell
pgpgtf_d8Gp4C.pgp
Description: OpenPGP digital signature
Re: 回复: [PATCH] mm/slab.c: add node spinlock protect in __cache_free_alien
On Wed, 29 Jul 2020, Zhang, Qiang wrote:
> > From: Zhang Qiang
> >
> > We should add node spinlock protect "n->alien" which may be
> > assigned to NULL in cpuup_canceled func. cause address access
> > exception.
> >
>
> >Hi, do you have an example NULL pointer dereference where you have hit
> >this?
>
If you have a NULL pointer dereference or a GPF that occurred because of
this, it would be helpful to provide as rationale.
> >This rather looks like something to fix up in cpuup_canceled() since it's
> >currently manipulating the alien cache for the canceled cpu's node.
>
> yes , it is fix up in cpuup_canceled it's
> currently manipulating the alien cache for the canceled cpu's node which may
> be the same as the node being operated on in the __cache_free_alien func.
>
> void cpuup_canceled
> {
> n = get_node(cachep, node);
> spin_lock_irq(>list_lock);
> ...
> n->alien = NULL;
> spin_unlock_irq(>list_lock);
>
> }
>
Right, so the idea is that this should be fixed in cpuup_canceled()
instead -- why would we invaliate the entire node's alien cache because a
single cpu failed to come online?
[PATCH][next] staging: wfx: Use flex_array_size() helper in memcpy()
Make use of the flex_array_size() helper to calculate the size of a flexible array member within an enclosing structure. This helper offers defense-in-depth against potential integer overflows, while at the same time makes it explicitly clear that we are dealing with a flexible array member. Signed-off-by: Gustavo A. R. Silva --- drivers/staging/wfx/hif_tx_mib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wfx/hif_tx_mib.c b/drivers/staging/wfx/hif_tx_mib.c index 1689cb42acc0..05f1e1e98af9 100644 --- a/drivers/staging/wfx/hif_tx_mib.c +++ b/drivers/staging/wfx/hif_tx_mib.c @@ -113,7 +113,7 @@ int hif_set_beacon_filter_table(struct wfx_vif *wvif, int tbl_len, if (!val) return -ENOMEM; val->num_of_info_elmts = cpu_to_le32(tbl_len); - memcpy(val->ie_table, tbl, tbl_len * sizeof(*tbl)); + memcpy(val->ie_table, tbl, flex_array_size(val, ie_table, tbl_len)); ret = hif_write_mib(wvif->wdev, wvif->id, HIF_MIB_ID_BEACON_FILTER_TABLE, val, buf_len); kfree(val); -- 2.27.0
Re: [PATCH v3 6/6] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
On Wed, Jul 29, 2020 at 4:22 PM Guenter Roeck wrote:
> On 7/29/20 3:21 PM, Brian Norris wrote:
> > On Sun, Jul 26, 2020 at 03:01:01PM -0700, Guenter Roeck wrote:
> >> --- a/drivers/platform/chrome/cros_ec_proto.c
> >> +++ b/drivers/platform/chrome/cros_ec_proto.c
> > ^^ Maybe we want to double check 'ret != 0'? Or maybe
> >
> > ret = cros_ec_error_map[result];
> > if (!ret) {
>
> 'ret' won't ever be 0 here. Above:
> &&
> cros_ec_error_map[result]
>
> and below:
>
> else
> ret = -EPROTO;
Ah, I'm reading too quickly. You're correct, sorry.
> > ret = -EPROTO;
> > dev_err(..., "Unexpected EC result code
> > %d\n", result);
> > }
> >
> > ? Could even be WARN_ON(), since this would be an actionable programming
> > error, not exactly an external factor. Or maybe I'm being paranoid, and
> > future programmers are perfect.
> >
> I think, if anything, we might consider adding the message below (result >=
> ARRAY_SIZE(cros_ec_error_map) is just as bad). Not sure myself. I am
> open to adding it if people think it would be useful/desirable.
No, my primary motivation was that I thought the logic left room for
error if there were holes. I was mistaken on that point. Secondarily,
it was also potentially useful to point out when we fell into those
holes. I'm not sure logging the warning is that important. Generally,
we only care about a handful of result codes, and as long as the rest
don't end up as "success", I think we're in OK shape.
Sorry for the noise. Here's my tag (which given my misreading so far,
should probably have a heavy discount on its value):
Reviewed-by: Brian Norris
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
On Wed, Jul 29, 2020 at 10:07:14PM +, Fenghua Yu wrote: > Hi, Sean, > > On Wed, Jul 29, 2020 at 01:39:05PM -0700, Sean Christopherson wrote: > > On Wed, Jul 29, 2020 at 08:35:57PM +, Fenghua Yu wrote: > > > If sld=fatal and bld=ratelimit (both sld and bld are enabled in hw), > > > a split lock always generates #AC and kills the app and bld will never > > > have > > > a chance to trigger #DB for split lock. So effectively the combination > > > makes > > > the kernel to take two different actions after detecting a bus lock: if > > > the > > > bus lock comes from a split lock, fatal (sld); if the bus lock comes from > > > lock to non-WB memory, ratelimit (bld). Seems this is not a useful > > > combination > > > and is not what the user really wants to do because the user wants > > > ratelimit > > > for BLD, right? > > > > I understood all off that. And as I user I want to run sld=fatal and > > bld=ratelimit to provide maximum protection, i.e. disallow split locks at > > all times, and ratelimit the crud SLD #AC can't catch. > > Then this will expand the current usages and do need two options. Let me work > on adding a new "bus_lock_detect=" option as you suggested. I'd wait for feedback from others before spending too much effort rewriting everything, I'm just one person with an opinion.
Re: Kernel panic - not syncing: IO-APIC + timer doesn't work!
Hi Tom, On 2020-07-29 11:29 a.m., Tom Lendacky wrote: > On 7/29/20 4:50 AM, Thomas Gleixner wrote: >> Scott, >> >> Scott Branden writes: >>> On 2020-07-28 1:22 a.m., Thomas Gleixner wrote: Scott Branden writes: > Bios now updated to latest. Same kernel panic issue. Log below. > > I think it is related to power cycling quickly. > Should APIC work if PC power cycled in a few seconds or is that the > problem? Yes, emphasis on should. Just to clarify, if you reboot it works and cold start works as well if power was off long enough? >>> So far I have only been able to reproduce the issue by cold start with >>> power off for only a few seconds >>> before re-powering the system. It has not failed via reboot yet that I >>> remember. >>> Will have to keep my eye on whether using reboot is an issue or not. >>> And also keeping power off longer when doing a cold start. >> Weird. >> >>> Please find attached the failed console log with ignore_loglevel. >> Aside of the differences caused by the BIOS update there is nothing >> related to the APIC/IO-APIC setup which is different between the working >> and failing boot. >> >> TBH, I have no idea what's going wrong there. Maybe Tom has one. > I asked around and was told this is most likely the motherboard has not > decayed its DC rails. So it's quite possible that keeping it powered off > for a longer period of time before powering back on may help. It does appear that the APIC hardware or some other component does not reset something and assumes the power up value is 0. Too bad proper voltage monitoring/full reset is not in place. I was just reporting the issue as instructed by the kernel panic. I think the issue is avoided by leaving the system powered off longer. > Thanks, > Tom > >> Thanks, >> >> tglx >>
Re: [RFC PATCH v5 13/14] media: tegra-video: Add CSI MIPI pads calibration
28.07.2020 18:59, Sowjanya Komatineni пишет: ... >>> + ret = tegra_mipi_finish_calibration(csi_chan->mipi); >>> + if (ret < 0) >>> + dev_err(csi_chan->csi->dev, >>> + "MIPI calibration failed: %d\n", ret); >> Doesn't v4l2_subdev_call(OFF) need to be invoked here on error? > > Not required as on error streaming fails and runtime PM will turn off > power anyway. I see that camera drivers bump theirs RPM on s_stream=1, and thus, s_stream=0 should be invoked in order to balance the RPM. What am I missing? https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/media/i2c/ov2740.c#L634 > Also we only did csi subdev s_stream on and during sensor subdev > s_stream on fail, actual stream dont happen and on tegra side frame > capture by HW happens only when kthreads run. Secondly, perhaps a failed calibration isn't a very critical error? Hence just printing a warning message should be enough. Could you please make a patch that factors all ON/OFF code paths into a separate functions? It's a bit difficult to follow the combined code, especially partial changes in the patches. Thanks in advance!
Re: [PATCH v2 2/5] perf record: Prevent override of attr->sample_period for libpfm4 events
On Tue, Jul 28, 2020 at 9:10 AM Jiri Olsa wrote:
>
> On Tue, Jul 28, 2020 at 05:59:46PM +0200, Jiri Olsa wrote:
> > On Tue, Jul 28, 2020 at 01:57:31AM -0700, Ian Rogers wrote:
> > > From: Stephane Eranian
> > >
> > > Before:
> > > $ perf record -c 1 --pfm-events=cycles:period=7
> > >
> > > Would yield a cycles event with period=1, instead of 7.
> > >
> > > This was due to an ordering issue between libpfm4 parsing
> > > the event string and perf record initializing the event.
> > >
> > > This patch fixes the problem by preventing override for
> > > events with attr->sample_period != 0 by the time
> > > perf_evsel__config() is invoked. This seems to have been the
> > > intent of the author.
> > >
> > > Signed-off-by: Stephane Eranian
> > > Reviewed-by: Ian Rogers
> > > ---
> > > tools/perf/util/evsel.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > > index 811f538f7d77..8afc24e2ec52 100644
> > > --- a/tools/perf/util/evsel.c
> > > +++ b/tools/perf/util/evsel.c
> > > @@ -976,8 +976,7 @@ void evsel__config(struct evsel *evsel, struct
> > > record_opts *opts,
> > > * We default some events to have a default interval. But keep
> > > * it a weak assumption overridable by the user.
> > > */
> > > - if (!attr->sample_period || (opts->user_freq != UINT_MAX ||
> > > -opts->user_interval != ULLONG_MAX)) {
> > > + if (!attr->sample_period) {
> >
> > I was wondering why this wouldn't break record/top
> > but we take care of the via record_opts__config
> >
> > as long as 'perf test attr' works it looks ok to me
>
> hum ;-)
>
> [jolsa@krava perf]$ sudo ./perf test 17 -v
> 17: Setup struct perf_event_attr :
> ...
> running './tests/attr/test-record-C0'
> expected sample_period=4000, got 3000
> FAILED './tests/attr/test-record-C0' - match failure
I'm not able to reproduce this. Do you have a build configuration or
something else to look at? The test doesn't seem obviously connected
with this patch.
Thanks,
Ian
> jirka
>
> >
> > Acked-by: Jiri Olsa
> >
> > thanks,
> > jirka
>
Re: [PATCH v3 6/6] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
On 7/29/20 3:21 PM, Brian Norris wrote:
> Hi Guenter,
>
> On Sun, Jul 26, 2020 at 03:01:01PM -0700, Guenter Roeck wrote:
>> v3: Use -ENOPROTOOPT for EC_RES_INVALID_VERSION
>> Implement function to convert error codes
>> v2: No change
>>
>> drivers/platform/chrome/cros_ec_proto.c | 52 -
>> 1 file changed, 42 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_proto.c
>> b/drivers/platform/chrome/cros_ec_proto.c
>> index e5bbec979a2a..a081b8245682 100644
>> --- a/drivers/platform/chrome/cros_ec_proto.c
>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>> @@ -15,6 +15,43 @@
>>
>> #define EC_COMMAND_RETRIES 50
>>
>> +static const int cros_ec_error_map[] = {
>> +[EC_RES_INVALID_COMMAND] = -EOPNOTSUPP,
>> +[EC_RES_ERROR] = -EIO,
>> +[EC_RES_INVALID_PARAM] = -EINVAL,
>> +[EC_RES_ACCESS_DENIED] = -EACCES,
>> +[EC_RES_INVALID_RESPONSE] = -EPROTO,
>> +[EC_RES_INVALID_VERSION] = -ENOPROTOOPT,
>> +[EC_RES_INVALID_CHECKSUM] = -EBADMSG,
>> +[EC_RES_IN_PROGRESS] = -EINPROGRESS,
>> +[EC_RES_UNAVAILABLE] = -ENODATA,
>> +[EC_RES_TIMEOUT] = -ETIMEDOUT,
>> +[EC_RES_OVERFLOW] = -EOVERFLOW,
>> +[EC_RES_INVALID_HEADER] = -EBADR,
>> +[EC_RES_REQUEST_TRUNCATED] = -EBADR,
>> +[EC_RES_RESPONSE_TOO_BIG] = -EFBIG,
>> +[EC_RES_BUS_ERROR] = -EFAULT,
>> +[EC_RES_BUSY] = -EBUSY,
>> +[EC_RES_INVALID_HEADER_VERSION] = -EBADMSG,
>> +[EC_RES_INVALID_HEADER_CRC] = -EBADMSG,
>> +[EC_RES_INVALID_DATA_CRC] = -EBADMSG,
>> +[EC_RES_DUP_UNAVAILABLE] = -ENODATA,
>> +};
>
> Sorry I didn't pay attention to this earlier, but is there any
> programmatic way to ensure that we don't have unexpected holes here? If
> we do (e.g., we add new error codes, but they aren't contiguous for
> whatever reasons), then those will get treated as "success" with your
> current patch.
>
> I say "unexpected" hole, because EC_RES_SUCCESS (0) is an expected hole.
>
>> +
>> +static int cros_ec_map_error(uint32_t result)
>> +{
>> +int ret = 0;
>> +
>> +if (result != EC_RES_SUCCESS) {
>> +if (result < ARRAY_SIZE(cros_ec_error_map) &&
>> cros_ec_error_map[result])
>> +ret = cros_ec_error_map[result];
>
> ^^ Maybe we want to double check 'ret != 0'? Or maybe
>
> ret = cros_ec_error_map[result];
> if (!ret) {
'ret' won't ever be 0 here. Above:
&&
cros_ec_error_map[result]
and below:
else
ret = -EPROTO;
> ret = -EPROTO;
> dev_err(..., "Unexpected EC result code %d\n",
> result);
> }
>
> ? Could even be WARN_ON(), since this would be an actionable programming
> error, not exactly an external factor. Or maybe I'm being paranoid, and
> future programmers are perfect.
>
I think, if anything, we might consider adding the message below (result >=
ARRAY_SIZE(cros_ec_error_map) is just as bad). Not sure myself. I am
open to adding it if people think it would be useful/desirable.
Thanks,
Guenter
> Otherwise:
>
> Reviewed-by: Brian Norris
>
>> +else
>> +ret = -EPROTO;
>> +}
>> +
>> +return ret;
>> +}
>> +
>> static int prepare_packet(struct cros_ec_device *ec_dev,
>>struct cros_ec_command *msg)
>> {
Re: [RFC PATCH 3/5] mm: introduce VM_EXEC_KEEP
On 7/29/20 6:52 AM, Kirill A. Shutemov wrote:
> On Mon, Jul 27, 2020 at 10:11:25AM -0700, Anthony Yznaga wrote:
>> A vma with the VM_EXEC_KEEP flag is preserved across exec. For anonymous
>> vmas only. For safety, overlap with fixed address VMAs created in the new
>> mm during exec (e.g. the stack and elf load segments) is not permitted and
>> will cause the exec to fail.
>> (We are studying how to guarantee there are no conflicts. Comments welcome.)
>>
>> Signed-off-by: Steve Sistare
>> Signed-off-by: Anthony Yznaga
>> ---
>> arch/x86/Kconfig | 1 +
>> fs/exec.c | 20
>> include/linux/mm.h | 5 +
>> kernel/fork.c | 2 +-
>> mm/mmap.c | 47 +++
>> 5 files changed, 74 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 883da0abf779..fc36eb2f45c0 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -30,6 +30,7 @@ config X86_64
>> select MODULES_USE_ELF_RELA
>> select NEED_DMA_MAP_STATE
>> select SWIOTLB
>> +select ARCH_USES_HIGH_VMA_FLAGS
>>
>> config FORCE_DYNAMIC_FTRACE
>> def_bool y
>> diff --git a/fs/exec.c b/fs/exec.c
>> index 262112e5f9f8..1de09c4eef00 100644
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1069,6 +1069,20 @@ ssize_t read_code(struct file *file, unsigned long
>> addr, loff_t pos, size_t len)
>> EXPORT_SYMBOL(read_code);
>> #endif
>>
>> +static int vma_dup_some(struct mm_struct *old_mm, struct mm_struct *new_mm)
>> +{
>> +struct vm_area_struct *vma;
>> +int ret;
>> +
>> +for (vma = old_mm->mmap; vma; vma = vma->vm_next)
>> +if (vma->vm_flags & VM_EXEC_KEEP) {
>> +ret = vma_dup(vma, new_mm);
>> +if (ret)
>> +return ret;
>> +}
>> +return 0;
>> +}
>> +
>> /*
>> * Maps the mm_struct mm into the current task struct.
>> * On success, this function returns with the mutex
>> @@ -1104,6 +1118,12 @@ static int exec_mmap(struct mm_struct *mm)
>> mutex_unlock(>signal->exec_update_mutex);
>> return -EINTR;
>> }
>> +ret = vma_dup_some(old_mm, mm);
>> +if (ret) {
>> +mmap_read_unlock(old_mm);
>> +mutex_unlock(>signal->exec_update_mutex);
>> +return ret;
>> +}
>> }
>>
>> task_lock(tsk);
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index dc7b87310c10..1c538ba77f33 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -295,11 +295,15 @@ int overcommit_kbytes_handler(struct ctl_table *, int,
>> void *, size_t *,
>> #define VM_HIGH_ARCH_BIT_2 34 /* bit only usable on 64-bit
>> architectures */
>> #define VM_HIGH_ARCH_BIT_3 35 /* bit only usable on 64-bit
>> architectures */
>> #define VM_HIGH_ARCH_BIT_4 36 /* bit only usable on 64-bit
>> architectures */
>> +#define VM_HIGH_ARCH_BIT_5 37 /* bit only usable on 64-bit
>> architectures */
>> #define VM_HIGH_ARCH_0 BIT(VM_HIGH_ARCH_BIT_0)
>> #define VM_HIGH_ARCH_1 BIT(VM_HIGH_ARCH_BIT_1)
>> #define VM_HIGH_ARCH_2 BIT(VM_HIGH_ARCH_BIT_2)
>> #define VM_HIGH_ARCH_3 BIT(VM_HIGH_ARCH_BIT_3)
>> #define VM_HIGH_ARCH_4 BIT(VM_HIGH_ARCH_BIT_4)
>> +#define VM_EXEC_KEEPBIT(VM_HIGH_ARCH_BIT_5) /* preserve VMA across
>> exec */
>> +#else
>> +#define VM_EXEC_KEEPVM_NONE
>> #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */
>>
>> #ifdef CONFIG_ARCH_HAS_PKEYS
>> @@ -2534,6 +2538,7 @@ extern struct vm_area_struct *copy_vma(struct
>> vm_area_struct **,
>> unsigned long addr, unsigned long len, pgoff_t pgoff,
>> bool *need_rmap_locks);
>> extern void exit_mmap(struct mm_struct *);
>> +extern int vma_dup(struct vm_area_struct *vma, struct mm_struct *mm);
>>
>> static inline int check_data_rlimit(unsigned long rlim,
>> unsigned long new,
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index efc5493203ae..15ead613714f 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -564,7 +564,7 @@ static __latent_entropy int dup_mmap(struct mm_struct
>> *mm,
>> tmp->anon_vma = NULL;
>> } else if (anon_vma_fork(tmp, mpnt))
>> goto fail_nomem_anon_vma_fork;
>> -tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
>> +tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT | VM_EXEC_KEEP);
>> file = tmp->vm_file;
>> if (file) {
>> struct inode *inode = file_inode(file);
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 59a4682ebf3f..be2ff53743c3 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -3279,6 +3279,53 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
>> **vmap,
>> return NULL;
>> }
>>
>> +int vma_dup(struct vm_area_struct *old_vma, struct mm_struct
My Dear in the lord
My Dear in the lord My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina Faso, I am married to Mr. Brunel Patrice, a politicians who owns a small gold company in Burkina Faso; He died of Leprosy and Radesyge, in year February 2010, During his lifetime he deposited the sum of € 8.5 Million Euro) Eight million, Five hundred thousand Euros in a bank in Ouagadougou the capital city of of Burkina in West Africa. The money was from the sale of his company and death benefits payment and entitlements of my deceased husband by his company. I am sending you this message with heavy tears in my eyes and great sorrow in my heart, and also praying that it will reach you in good health because I am not in good health, I sleep every night without knowing if I may be alive to see the next day. I am suffering from long time cancer and presently I am partially suffering from Leprosy, which has become difficult for me to move around. I was married to my late husband for more than 6 years without having a child and my doctor confided that I have less chance to live, having to know when the cup of death will come, I decided to contact you to claim the fund since I don't have any relation I grew up from an orphanage home. I have decided to donate this money for the support of helping Motherless babies/Less privileged/Widows and churches also to build the house of God because I am dying and diagnosed with cancer for about 3 years ago. I have decided to donate from what I have inherited from my late husband to you for the good work of Almighty God; I will be going in for an operation surgery soon. Now I want you to stand as my next of kin to claim the funds for charity purposes. Because of this money remains unclaimed after my death, the bank executives or the government will take the money as unclaimed fund and maybe use it for selfishness and worthless ventures, I need a very honest person who can claim this money and use it for Charity works, for orphanages, widows and also build schools and churches for less privilege that will be named after my late husband and my name. I need your urgent answer to know if you will be able to execute this project, and I will give you more information on how the fund will be transferred to your bank account or online banking. Thanks Mrs. Mina A. Brunel
[PATCH v2] PCI/P2PDMA: Allow P2PDMA on all AMD CPUs newer than the Zen family
In order to avoid needing to add every new AMD CPU host bridge to the list
every cycle, allow P2PDMA if the CPUs vendor is AMD and family is
greater than 0x17 (Zen).
This should cut down a bunch of the churn adding to the list of allowed
host bridges.
Signed-off-by: Logan Gunthorpe
Cc: Bjorn Helgaas
Cc: Alex Deucher
Cc: Christian König
Cc: Huang Rui
---
Here's a reworked patch to enable P2PDMA on Zen2 (and in fact all
subsequent Zen platforms).
This should remove all the churn on the list for the AMD side. Still
don't have a good solution for Intel.
drivers/pci/p2pdma.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index e8e444eeb1cd..f1cab2c50595 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -273,6 +273,24 @@ static void seq_buf_print_bus_devfn(struct seq_buf *buf,
struct pci_dev *pdev)
seq_buf_printf(buf, "%s;", pci_name(pdev));
}
+#ifdef CONFIG_X86
+static bool cpu_supports_p2pdma(void)
+{
+ struct cpuinfo_x86 *c = _data(0);
+
+ /* Any AMD CPU who's family id is newer than Zen will support p2pdma */
+ if (c->x86_vendor == X86_VENDOR_AMD && c->x86 >= 0x17)
+ return true;
+
+ return false;
+}
+#else
+static bool cpu_supports_p2pdma(void)
+{
+ return false;
+}
+#endif
+
static const struct pci_p2pdma_whitelist_entry {
unsigned short vendor;
unsigned short device;
@@ -280,11 +298,6 @@ static const struct pci_p2pdma_whitelist_entry {
REQ_SAME_HOST_BRIDGE= 1 << 0,
} flags;
} pci_p2pdma_whitelist[] = {
- /* AMD ZEN */
- {PCI_VENDOR_ID_AMD, 0x1450, 0},
- {PCI_VENDOR_ID_AMD, 0x15d0, 0},
- {PCI_VENDOR_ID_AMD, 0x1630, 0},
-
/* Intel Xeon E5/Core i7 */
{PCI_VENDOR_ID_INTEL, 0x3c00, REQ_SAME_HOST_BRIDGE},
{PCI_VENDOR_ID_INTEL, 0x3c01, REQ_SAME_HOST_BRIDGE},
@@ -473,7 +486,8 @@ upstream_bridge_distance(struct pci_dev *provider, struct
pci_dev *client,
acs_redirects, acs_list);
if (map_type == PCI_P2PDMA_MAP_THRU_HOST_BRIDGE) {
- if (!host_bridge_whitelist(provider, client))
+ if (!cpu_supports_p2pdma() &&
+ !host_bridge_whitelist(provider, client))
map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
}
base-commit: 92ed301919932f13b9172e525674157e983d
--
2.20.1
arch/powerpc/sysdev/fsl_rcpm.c:32:9: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d3590ebf6f91350192737dd1d1b219c05277f067 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 6 weeks ago config: powerpc-randconfig-s031-20200729 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-97-gee4aea9a-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> arch/powerpc/sysdev/fsl_rcpm.c:32:9: sparse: sparse: incorrect type in >> argument 1 (different base types) @@ expected unsigned int volatile >> [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] >> __iomem * @@ >> arch/powerpc/sysdev/fsl_rcpm.c:32:9: sparse: expected unsigned int >> volatile [noderef] [usertype] __iomem *addr >> arch/powerpc/sysdev/fsl_rcpm.c:32:9: sparse: got restricted __be32 >> [noderef] __iomem * >> arch/powerpc/sysdev/fsl_rcpm.c:32:9: sparse: sparse: incorrect type in >> argument 1 (different base types) @@ expected unsigned int const >> volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 >> [noderef] __iomem * @@ >> arch/powerpc/sysdev/fsl_rcpm.c:32:9: sparse: expected unsigned int const >> volatile [noderef] [usertype] __iomem *addr >> arch/powerpc/sysdev/fsl_rcpm.c:32:9: sparse: got restricted __be32 >> [noderef] __iomem * arch/powerpc/sysdev/fsl_rcpm.c:33:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/sysdev/fsl_rcpm.c:33:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/sysdev/fsl_rcpm.c:33:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/sysdev/fsl_rcpm.c:33:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/sysdev/fsl_rcpm.c:33:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/sysdev/fsl_rcpm.c:33:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/sysdev/fsl_rcpm.c:34:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/sysdev/fsl_rcpm.c:34:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/sysdev/fsl_rcpm.c:34:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/sysdev/fsl_rcpm.c:34:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/sysdev/fsl_rcpm.c:34:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/sysdev/fsl_rcpm.c:34:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/sysdev/fsl_rcpm.c:35:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/sysdev/fsl_rcpm.c:35:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/sysdev/fsl_rcpm.c:35:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/sysdev/fsl_rcpm.c:35:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/sysdev/fsl_rcpm.c:35:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/sysdev/fsl_rcpm.c:35:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/sysdev/fsl_rcpm.c:43:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __i
[PATCH] Revert "Bluetooth: btusb: Disable runtime suspend on Realtek devices"
This reverts commit 7ecacafc240638148567742cca41aa7144b4fe1e. Testing this change on a board with RTL8822CE, I found that enabling autosuspend has no effect on the stability of the system. The board continued working after autosuspend, suspend and reboot. The original commit makes it impossible to enable autosuspend on working systems so it should be reverted. Disabling autosuspend should be done via module param or udev in userspace instead. Signed-off-by: Abhishek Pandit-Subedi --- We have a few Chromebooks using the RTL 8822CE part over USB and they are running without problems with autosuspend enabled. While bringing up a new board, I found some power regressions that I was able to narrow down to this change so I'm requesting a revert. I tested this on Hp Chromebook 14a (running 4.14 kernel and 5.4 kernel) with this revert: * Enabled autosuspend, used it normally with a HID device * Suspended the Chromebook and verified it worked normally on resume * Rebooted the Chromebook and verified Bluetooth was working on next boot I didn't see the issue that was originally reported with this fix. For the original reporter, if you're still seeing this issue, there are other ways to disable autosuspend for your device: * set module param: enable_autosuspend=0 * change your kconfig so BT_HCIBTUSB_AUTOSUSPEND=n * use a udev rule to disable autosuspend for specific vid:pid Keeping this change in the kernel makes it impossible to enable autosuspend so it should be reverted. drivers/bluetooth/btusb.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 1f51494f581812..8d2608ddfd0875 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -4086,10 +4086,6 @@ static int btusb_probe(struct usb_interface *intf, set_bit(BTUSB_USE_ALT1_FOR_WBS, >flags); else bt_dev_err(hdev, "Device does not support ALT setting 1"); - - err = usb_autopm_get_interface(intf); - if (err < 0) - goto out_free_dev; } if (!reset) -- 2.28.0.rc0.142.g3c755180ce-goog
Re: [PATCH] lib: kunit: add test_min_heap test conversion to KUnit
Hi Ian,
On Wed, Jul 29, 2020 at 7:57 PM 'Ian Rogers' via KUnit Development
wrote:
>
> On Wed, Jul 29, 2020 at 1:11 PM Vitor Massaru Iha wrote:
> >
> > This adds the conversion of the runtime tests of test_min_heap,
> > from `lib/test_min_heap.c` to KUnit tests.
> >
> > Please apply this commit first (linux-kselftest/kunit-fixes):
> > 3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing
> > of CONFIG options with space
>
> Thanks for this, I'm a fan of testing frameworks :-)
>
> > Signed-off-by: Vitor Massaru Iha
> > ---
> > lib/Kconfig.debug | 29 --
> > lib/Makefile | 2 +-
> > lib/{test_min_heap.c => min_heap_kunit.c} | 117 --
> > 3 files changed, 83 insertions(+), 65 deletions(-)
> > rename lib/{test_min_heap.c => min_heap_kunit.c} (60%)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 9ad9210d70a1..46674fc4972c 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -1864,16 +1864,6 @@ config TEST_LIST_SORT
> >
> > If unsure, say N.
> >
> > -config TEST_MIN_HEAP
> > - tristate "Min heap test"
> > - depends on DEBUG_KERNEL || m
> > - help
> > - Enable this to turn on min heap function tests. This test is
> > - executed only once during system boot (so affects only boot time),
> > - or at module load time.
> > -
> > - If unsure, say N.
> > -
> > config TEST_SORT
> > tristate "Array-based sort test"
> > depends on DEBUG_KERNEL || m
> > @@ -2185,6 +2175,25 @@ config LINEAR_RANGES_TEST
> >
> > If unsure, say N.
> >
> > +config MIN_HEAP_KUNIT
> > +tristate "KUnit test for Min heap"
> > +depends on KUNIT
> > +depends on DEBUG_KERNEL || m
> > +help
> > + Enable this to turn on min heap function tests. This test is
> > + executed only once during system boot (so affects only boot
> > time),
> > + or at module load time.
> > +
> > + KUnit tests run during boot and output the results to the debug
> > log
> > + in TAP format (http://testanything.org/). Only useful for kernel
> > devs
> > + running the KUnit test harness, and not intended for inclusion
> > into a
> > + production build.
> > +
> > + For more information on KUnit and unit tests in general please
> > refer
> > + to the KUnit documentation in Documentation/dev-tools/kunit/.
> > +
> > + If unsure, say N.
> > +
>
> It's a shame we need a config option for this. Could we have one
> option to cover all basic library tests?
Sure, I think so.
>
> > config TEST_UDELAY
> > tristate "udelay test driver"
> > help
> > diff --git a/lib/Makefile b/lib/Makefile
> > index b1c42c10073b..748f57063160 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -72,7 +72,6 @@ CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
> > UBSAN_SANITIZE_test_ubsan.o := y
> > obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
> > obj-$(CONFIG_TEST_LIST_SORT) += test_list_sort.o
> > -obj-$(CONFIG_TEST_MIN_HEAP) += test_min_heap.o
> > obj-$(CONFIG_TEST_LKM) += test_module.o
> > obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o
> > obj-$(CONFIG_TEST_OVERFLOW) += test_overflow.o
> > @@ -318,3 +317,4 @@ obj-$(CONFIG_OBJAGG) += objagg.o
> > # KUnit tests
> > obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> > obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> > +obj-$(CONFIG_MIN_HEAP_KUNIT) += min_heap_kunit.o
> > diff --git a/lib/test_min_heap.c b/lib/min_heap_kunit.c
> > similarity index 60%
> > rename from lib/test_min_heap.c
> > rename to lib/min_heap_kunit.c
> > index d19c8080fd4d..398db1c63146 100644
> > --- a/lib/test_min_heap.c
> > +++ b/lib/min_heap_kunit.c
> > @@ -7,9 +7,8 @@
> >
> > #include
> > #include
> > -#include
> > -#include
> > #include
> > +#include
> >
> > static __init bool less_than(const void *lhs, const void *rhs)
> > {
> > @@ -29,37 +28,34 @@ static __init void swap_ints(void *lhs, void *rhs)
> > *(int *)rhs = temp;
> > }
> >
> > -static __init int pop_verify_heap(bool min_heap,
> > +static __init void pop_verify_heap(struct kunit *context,
> > + bool min_heap,
> > struct min_heap *heap,
> > const struct min_heap_callbacks *funcs)
> > {
> > int *values = heap->data;
> > - int err = 0;
> > int last;
> >
> > last = values[0];
> > min_heap_pop(heap, funcs);
> > while (heap->nr > 0) {
> > if (min_heap) {
> > - if (last > values[0]) {
> > - pr_err("error: expected %d <= %d\n", last,
> > - values[0]);
> > - err++;
> > - }
> > +
Re: [PATCH v3 03/11] KVM: SVM: Change intercept_dr to generic intercepts
On 29/07/20 01:59, Jim Mattson wrote:
>> case SVM_EXIT_READ_DR0 ... SVM_EXIT_WRITE_DR7: {
>> - u32 bit = 1U << (exit_code - SVM_EXIT_READ_DR0);
>> - if (svm->nested.ctl.intercept_dr & bit)
>> + if (__is_intercept(>nested.ctl.intercepts, exit_code))
> Can I assume that all of these __ calls will become
> calls when the grand unification is done? (Maybe I should
> just look ahead.)
>
The calls are reserved for the active VMCB while these take a
vector. Probably it would be nicer to call them
vmcb_{set,clr,is}_intercept and make them take a struct
vmcb_control_area*, but apart from that the concept is fine
Once we do the vmcb01/vmcb02/vmcb12 work, there will not be anymore
>nested.ctl (replaced by >nested.vmcb12->ctl) and we will be
able to change them to take a struct vmcb*. Then is_intercept would for
example be simply:
return vmcb_is_intercept(svm->vmcb, nr);
as expected.
Paolo
Re: [PATCH v3 01/11] KVM: SVM: Introduce __set_intercept, __clr_intercept and __is_intercept
On 29/07/20 01:37, Babu Moger wrote:
> This is in preparation for the future intercept vector additions.
>
> Add new functions __set_intercept, __clr_intercept and __is_intercept
> using kernel APIs __set_bit, __clear_bit and test_bit espectively.
>
> Signed-off-by: Babu Moger
> ---
> arch/x86/kvm/svm/svm.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
> index 6ac4c00a5d82..3b669718190a 100644
> --- a/arch/x86/kvm/svm/svm.h
> +++ b/arch/x86/kvm/svm/svm.h
> @@ -217,6 +217,21 @@ static inline struct vmcb *get_host_vmcb(struct vcpu_svm
> *svm)
> return svm->vmcb;
> }
>
> +static inline void __set_intercept(void *addr, int bit)
> +{
> + __set_bit(bit, (unsigned long *)addr);
> +}
> +
> +static inline void __clr_intercept(void *addr, int bit)
> +{
> + __clear_bit(bit, (unsigned long *)addr);
> +}
> +
> +static inline bool __is_intercept(void *addr, int bit)
> +{
> + return test_bit(bit, (unsigned long *)addr);
> +}
> +
Probably worth adding a range check?
Paolo
> static inline void set_cr_intercept(struct vcpu_svm *svm, int bit)
> {
> struct vmcb *vmcb = get_host_vmcb(svm);
>
linux-next: build failure after merge of the origin tree
Hi all,
After merging the origin tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/asm-generic/percpu.h:7,
from arch/x86/include/asm/percpu.h:556,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:13,
from arch/x86/crypto/glue_helper.c:13:
include/linux/random.h:123:24: error: variable 'net_rand_state' with
'latent_entropy' attribute must not be local
123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
|^
include/linux/percpu-defs.h:88:38: note: in definition of macro
'DECLARE_PER_CPU_SECTION'
88 | extern __PCPU_ATTRS(sec) __typeof__(type) name
| ^~~~
include/linux/random.h:123:1: note: in expansion of macro 'DECLARE_PER_CPU'
123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
| ^~~
Caused by commit
f227e3ec3b5c ("random32: update the net random state on interrupt and
activity")
I have reverted that commit for today.
In case it matters:
$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 9.3.0-13) 9.3.0
--
Cheers,
Stephen Rothwell
pgp4DTgHZ7_B2.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 02/11] KVM: SVM: Change intercept_cr to generic intercepts
On 29/07/20 18:08, Babu Moger wrote:
>>>
>>> if (g->int_ctl & V_INTR_MASKING_MASK) {
>>> /* We only want the cr8 intercept bits of L1 */
>>> - c->intercept_cr &= ~(1U << INTERCEPT_CR8_READ);
>>> - c->intercept_cr &= ~(1U << INTERCEPT_CR8_WRITE);
>>> + __clr_intercept(>intercepts, INTERCEPT_CR8_READ);
>>> + __clr_intercept(>intercepts, INTERCEPT_CR8_WRITE);
>> Why the direct calls to the __clr_intercept worker function? Can't these be
>> calls
>> to clr_cr_intercept()?
>> Likewise throughout.
> This code uses the address to clear the bits. So called __clr_intercept
> directly. The call clr_cr_intercept() passes the structure vcpu_svm and
> then uses get_host_vmcb to get the address.
Yes, this is correct.
Paolo
Re: [PATCH v3 11/11] KVM:SVM: Enable INVPCID feature on AMD
On Tue, Jul 28, 2020 at 4:39 PM Babu Moger wrote:
>
> The following intercept bit has been added to support VMEXIT
> for INVPCID instruction:
> CodeNameCause
> A2h VMEXIT_INVPCID INVPCID instruction
>
> The following bit has been added to the VMCB layout control area
> to control intercept of INVPCID:
> Byte Offset Bit(s)Function
> 14h 2 intercept INVPCID
>
> Enable the interceptions when the the guest is running with shadow
> page table enabled and handle the tlbflush based on the invpcid
> instruction type.
>
> For the guests with nested page table (NPT) support, the INVPCID
> feature works as running it natively. KVM does not need to do any
> special handling in this case.
>
> AMD documentation for INVPCID feature is available at "AMD64
> Architecture Programmer’s Manual Volume 2: System Programming,
> Pub. 24593 Rev. 3.34(or later)"
>
> The documentation can be obtained at the links below:
> Link: https://www.amd.com/system/files/TechDocs/24593.pdf
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
>
> Signed-off-by: Babu Moger
> ---
> arch/x86/include/uapi/asm/svm.h |2 +
> arch/x86/kvm/svm/svm.c | 64
> +++
> 2 files changed, 66 insertions(+)
>
> diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h
> index 2e8a30f06c74..522d42dfc28c 100644
> --- a/arch/x86/include/uapi/asm/svm.h
> +++ b/arch/x86/include/uapi/asm/svm.h
> @@ -76,6 +76,7 @@
> #define SVM_EXIT_MWAIT_COND0x08c
> #define SVM_EXIT_XSETBV0x08d
> #define SVM_EXIT_RDPRU 0x08e
> +#define SVM_EXIT_INVPCID 0x0a2
> #define SVM_EXIT_NPF 0x400
> #define SVM_EXIT_AVIC_INCOMPLETE_IPI 0x401
> #define SVM_EXIT_AVIC_UNACCELERATED_ACCESS 0x402
> @@ -171,6 +172,7 @@
> { SVM_EXIT_MONITOR, "monitor" }, \
> { SVM_EXIT_MWAIT, "mwait" }, \
> { SVM_EXIT_XSETBV, "xsetbv" }, \
> + { SVM_EXIT_INVPCID, "invpcid" }, \
> { SVM_EXIT_NPF, "npf" }, \
> { SVM_EXIT_AVIC_INCOMPLETE_IPI, "avic_incomplete_ipi" }, \
> { SVM_EXIT_AVIC_UNACCELERATED_ACCESS, "avic_unaccelerated_access"
> }, \
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 99cc9c285fe6..6b099e0b28c0 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -813,6 +813,11 @@ static __init void svm_set_cpu_caps(void)
> if (boot_cpu_has(X86_FEATURE_LS_CFG_SSBD) ||
> boot_cpu_has(X86_FEATURE_AMD_SSBD))
> kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD);
> +
> + /* Enable INVPCID if both PCID and INVPCID enabled */
> + if (boot_cpu_has(X86_FEATURE_PCID) &&
> + boot_cpu_has(X86_FEATURE_INVPCID))
> + kvm_cpu_cap_set(X86_FEATURE_INVPCID);
> }
Why is PCID required? Can't this just be
'kvm_cpu_cap_check_and_set(X86_FEATURE_INVPCID);'?
> static __init int svm_hardware_setup(void)
> @@ -1099,6 +1104,18 @@ static void init_vmcb(struct vcpu_svm *svm)
> clr_intercept(svm, INTERCEPT_PAUSE);
> }
>
> + /*
> +* Intercept INVPCID instruction only if shadow page table is
> +* enabled. Interception is not required with nested page table
> +* enabled.
> +*/
> + if (boot_cpu_has(X86_FEATURE_INVPCID)) {
Shouldn't this be 'kvm_cpu_cap_has(X86_FEATURE_INVPCID),' so that it
is consistent with the code above?
> + if (!npt_enabled)
> + set_intercept(svm, INTERCEPT_INVPCID);
> + else
> + clr_intercept(svm, INTERCEPT_INVPCID);
> + }
> +
> if (kvm_vcpu_apicv_active(>vcpu))
> avic_init_vmcb(svm);
>
> @@ -2715,6 +2732,43 @@ static int mwait_interception(struct vcpu_svm *svm)
> return nop_interception(svm);
> }
>
> +static int invpcid_interception(struct vcpu_svm *svm)
> +{
> + struct kvm_vcpu *vcpu = >vcpu;
> + struct x86_exception e;
> + unsigned long type;
> + gva_t gva;
> + struct {
> + u64 pcid;
> + u64 gla;
> + } operand;
> +
> + if (!guest_cpuid_has(vcpu, X86_FEATURE_INVPCID)) {
> + kvm_queue_exception(vcpu, UD_VECTOR);
> + return 1;
> + }
> +
> + /*
> +* For an INVPCID intercept:
> +* EXITINFO1 provides the linear address of the memory operand.
> +* EXITINFO2 provides the contents of the register operand.
> +*/
> + type = svm->vmcb->control.exit_info_2;
> + gva = svm->vmcb->control.exit_info_1;
> +
> + if (type > 3) {
> + kvm_inject_gp(vcpu, 0);
> + return 1;
> + }
> +
> + if (kvm_read_guest_virt(vcpu, gva, , sizeof(operand), )) {
> + kvm_inject_emulated_page_fault(vcpu, );
> + return 1;
> + }
The emulated page fault is not always correct. See
Re: [PATCH V4 2/3] mfd: Intel Platform Monitoring Technology support
at 12:58 AM, Lee Jones wrote:
If you do:
do {
int pos;
pos = pci_find_next_ext_capability(pdev, pos,
PCI_EXT_CAP_ID_DVSEC);
if (!pos)
break;
Then you can invoke pci_find_next_ext_capability() once, no?
Part of your suggestion here won't work, because pos needs to be
initialized to 0 the first time. As such it needs to be declared and
initialized outside the loop. Other than that it may be ok.
--
Mark Rustad, mrus...@gmail.com
signature.asc
Description: Message signed with OpenPGP
Re: [PATCH] lib: kunit: add test_min_heap test conversion to KUnit
On Wed, Jul 29, 2020 at 1:11 PM Vitor Massaru Iha wrote:
>
> This adds the conversion of the runtime tests of test_min_heap,
> from `lib/test_min_heap.c` to KUnit tests.
>
> Please apply this commit first (linux-kselftest/kunit-fixes):
> 3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing of
> CONFIG options with space
Thanks for this, I'm a fan of testing frameworks :-)
> Signed-off-by: Vitor Massaru Iha
> ---
> lib/Kconfig.debug | 29 --
> lib/Makefile | 2 +-
> lib/{test_min_heap.c => min_heap_kunit.c} | 117 --
> 3 files changed, 83 insertions(+), 65 deletions(-)
> rename lib/{test_min_heap.c => min_heap_kunit.c} (60%)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 9ad9210d70a1..46674fc4972c 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1864,16 +1864,6 @@ config TEST_LIST_SORT
>
> If unsure, say N.
>
> -config TEST_MIN_HEAP
> - tristate "Min heap test"
> - depends on DEBUG_KERNEL || m
> - help
> - Enable this to turn on min heap function tests. This test is
> - executed only once during system boot (so affects only boot time),
> - or at module load time.
> -
> - If unsure, say N.
> -
> config TEST_SORT
> tristate "Array-based sort test"
> depends on DEBUG_KERNEL || m
> @@ -2185,6 +2175,25 @@ config LINEAR_RANGES_TEST
>
> If unsure, say N.
>
> +config MIN_HEAP_KUNIT
> +tristate "KUnit test for Min heap"
> +depends on KUNIT
> +depends on DEBUG_KERNEL || m
> +help
> + Enable this to turn on min heap function tests. This test is
> + executed only once during system boot (so affects only boot time),
> + or at module load time.
> +
> + KUnit tests run during boot and output the results to the debug log
> + in TAP format (http://testanything.org/). Only useful for kernel
> devs
> + running the KUnit test harness, and not intended for inclusion
> into a
> + production build.
> +
> + For more information on KUnit and unit tests in general please
> refer
> + to the KUnit documentation in Documentation/dev-tools/kunit/.
> +
> + If unsure, say N.
> +
It's a shame we need a config option for this. Could we have one
option to cover all basic library tests?
> config TEST_UDELAY
> tristate "udelay test driver"
> help
> diff --git a/lib/Makefile b/lib/Makefile
> index b1c42c10073b..748f57063160 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -72,7 +72,6 @@ CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
> UBSAN_SANITIZE_test_ubsan.o := y
> obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
> obj-$(CONFIG_TEST_LIST_SORT) += test_list_sort.o
> -obj-$(CONFIG_TEST_MIN_HEAP) += test_min_heap.o
> obj-$(CONFIG_TEST_LKM) += test_module.o
> obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o
> obj-$(CONFIG_TEST_OVERFLOW) += test_overflow.o
> @@ -318,3 +317,4 @@ obj-$(CONFIG_OBJAGG) += objagg.o
> # KUnit tests
> obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> +obj-$(CONFIG_MIN_HEAP_KUNIT) += min_heap_kunit.o
> diff --git a/lib/test_min_heap.c b/lib/min_heap_kunit.c
> similarity index 60%
> rename from lib/test_min_heap.c
> rename to lib/min_heap_kunit.c
> index d19c8080fd4d..398db1c63146 100644
> --- a/lib/test_min_heap.c
> +++ b/lib/min_heap_kunit.c
> @@ -7,9 +7,8 @@
>
> #include
> #include
> -#include
> -#include
> #include
> +#include
>
> static __init bool less_than(const void *lhs, const void *rhs)
> {
> @@ -29,37 +28,34 @@ static __init void swap_ints(void *lhs, void *rhs)
> *(int *)rhs = temp;
> }
>
> -static __init int pop_verify_heap(bool min_heap,
> +static __init void pop_verify_heap(struct kunit *context,
> + bool min_heap,
> struct min_heap *heap,
> const struct min_heap_callbacks *funcs)
> {
> int *values = heap->data;
> - int err = 0;
> int last;
>
> last = values[0];
> min_heap_pop(heap, funcs);
> while (heap->nr > 0) {
> if (min_heap) {
> - if (last > values[0]) {
> - pr_err("error: expected %d <= %d\n", last,
> - values[0]);
> - err++;
> - }
> + KUNIT_EXPECT_FALSE_MSG(context,
> + last > values[0],
> + "expected %d <= %d\n",
> + last, values[0]);
I'm not familiar with kunit, is there a reason not to prefer:
KUNIT_EXPECT_LT(context, last, values[0]);
> } else {
> - if
Re: [maemo-leste] Modem on Droid 4 (mdm6600) in recent mainline
Hi!
> There's something very wrong with /dev/ttyUSB4 in recent kernels:
> unsolicited incoming data from the modem are getting lost; I believe
> it means also SMS notifications, but it is very easy to reproduce with
> incoming call notifications.
>
> They just don't come.
>
> But if you keep pasting "AT" into minicom, they actually do.
>
> Of course... that means that trying to debug ofono is ... "interesting".
>
> I tried playing with
> /sys/bus/platform/drivers/phy-mapphone-mdm6600/usb-phy\@1/power/control
> files and timeouts, but could not get it to work.
>
> Any idea what could be wrong there?
>
> Is there easy way to disable power management for testing?
I tried this... and it did not fix the problem :-(.
Pavel
diff --git a/drivers/phy/motorola/phy-mapphone-mdm6600.c
b/drivers/phy/motorola/phy-mapphone-mdm6600.c
index 94a34cf75eb3..7ddf5aa35105 100644
--- a/drivers/phy/motorola/phy-mapphone-mdm6600.c
+++ b/drivers/phy/motorola/phy-mapphone-mdm6600.c
@@ -21,7 +21,7 @@
#define PHY_MDM6600_PHY_DELAY_MS 4000/* PHY enable 2.2s to 3.5s */
#define PHY_MDM6600_ENABLED_DELAY_MS 8000/* 8s more total for MDM6600 */
#define PHY_MDM6600_WAKE_KICK_MS 600 /* time on after GPIO toggle */
-#define MDM6600_MODEM_IDLE_DELAY_MS1000/* modem after USB suspend */
+#define MDM6600_MODEM_IDLE_DELAY_MS1 /* modem after USB
suspend */
#define MDM6600_MODEM_WAKE_DELAY_MS200 /* modem response after idle */
enum phy_mdm6600_ctrl_lines {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: PGP signature
Re: [PATCH] PCI: Move pci_info() after pci_fixup_device() in pci_setup_device()
On Mon, Jul 27, 2020 at 03:06:55PM +0800, Tiezhu Yang wrote: > In the current code, we can not see the PCI info after fixup which is > correct to reflect the reality, it is better to move pci_info() after > pci_fixup_device() in pci_setup_device(). > > Signed-off-by: Tiezhu Yang Applied to pci/enumeration for v5.9, thanks! > --- > drivers/pci/probe.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index 2f66988..7c046aed 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -1802,9 +1802,6 @@ int pci_setup_device(struct pci_dev *dev) > dev->revision = class & 0xff; > dev->class = class >> 8;/* upper 3 bytes */ > > - pci_info(dev, "[%04x:%04x] type %02x class %#08x\n", > -dev->vendor, dev->device, dev->hdr_type, dev->class); > - > if (pci_early_dump) > early_dump_pci_device(dev); > > @@ -1822,6 +1819,9 @@ int pci_setup_device(struct pci_dev *dev) > /* Early fixups, before probing the BARs */ > pci_fixup_device(pci_fixup_early, dev); > > + pci_info(dev, "[%04x:%04x] type %02x class %#08x\n", > + dev->vendor, dev->device, dev->hdr_type, dev->class); > + > /* Device class may be changed after fixup */ > class = dev->class >> 8; > > -- > 2.1.0 >
[PATCH][next] mlxsw: spectrum_cnt: Use flex_array_size() helper in memcpy()
Make use of the flex_array_size() helper to calculate the size of a
flexible array member within an enclosing structure.
This helper offers defense-in-depth against potential integer
overflows, while at the same time makes it explicitly clear that
we are dealing witha flexible array member.
Also, remove unnecessary pointer identifier sub_pool.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.c
index 7974982533b5..b65b93a2b9bc 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.c
@@ -121,7 +121,6 @@ int mlxsw_sp_counter_pool_init(struct mlxsw_sp *mlxsw_sp)
{
unsigned int sub_pools_count = ARRAY_SIZE(mlxsw_sp_counter_sub_pools);
struct devlink *devlink = priv_to_devlink(mlxsw_sp->core);
- struct mlxsw_sp_counter_sub_pool *sub_pool;
struct mlxsw_sp_counter_pool *pool;
unsigned int map_size;
int err;
@@ -131,9 +130,9 @@ int mlxsw_sp_counter_pool_init(struct mlxsw_sp *mlxsw_sp)
if (!pool)
return -ENOMEM;
mlxsw_sp->counter_pool = pool;
- memcpy(pool->sub_pools, mlxsw_sp_counter_sub_pools,
- sub_pools_count * sizeof(*sub_pool));
pool->sub_pools_count = sub_pools_count;
+ memcpy(pool->sub_pools, mlxsw_sp_counter_sub_pools,
+ flex_array_size(pool, sub_pools, pool->sub_pools_count));
spin_lock_init(>counter_pool_lock);
atomic_set(>active_entries_count, 0);
--
2.27.0
[PATCH] fbmem: pull fbcon_update_vcs() out of fb_set_var()
syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy()
based on outdated old_{rows,row_size} values, for resize_screen() can
recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates
old_{rows,row_size} values which were saved before calling resize_screen().
Daniel Vetter explained that resize_screen() should not recurse into
fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set
when calling resize_screen().
Instead of masking FBINFO_MISC_USEREVENT before calling fbcon_update_vcs(),
we can remove FBINFO_MISC_USEREVENT by calling fbcon_update_vcs() only if
fb_set_var() returned 0. This change assumes that it is harmless to call
fbcon_update_vcs() when fb_set_var() returned 0 without reaching
fb_notifier_call_chain().
[1]
https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e
Reported-and-tested-by: syzbot
Suggested-by: Daniel Vetter
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/core/fbmem.c | 8 ++--
drivers/video/fbdev/core/fbsysfs.c | 4 ++--
drivers/video/fbdev/ps3fb.c| 4 ++--
include/linux/fb.h | 2 --
4 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 30e73ec..da7c88f 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -957,7 +957,6 @@ static int fb_check_caps(struct fb_info *info, struct
fb_var_screeninfo *var,
int
fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
{
- int flags = info->flags;
int ret = 0;
u32 activate;
struct fb_var_screeninfo old_var;
@@ -1052,9 +1051,6 @@ static int fb_check_caps(struct fb_info *info, struct
fb_var_screeninfo *var,
event.data =
fb_notifier_call_chain(FB_EVENT_MODE_CHANGE, );
- if (flags & FBINFO_MISC_USEREVENT)
- fbcon_update_vcs(info, activate & FB_ACTIVATE_ALL);
-
return 0;
}
EXPORT_SYMBOL(fb_set_var);
@@ -1105,9 +1101,9 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
return -EFAULT;
console_lock();
lock_fb_info(info);
- info->flags |= FBINFO_MISC_USEREVENT;
ret = fb_set_var(info, );
- info->flags &= ~FBINFO_MISC_USEREVENT;
+ if (!ret)
+ fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
unlock_fb_info(info);
console_unlock();
if (!ret && copy_to_user(argp, , sizeof(var)))
diff --git a/drivers/video/fbdev/core/fbsysfs.c
b/drivers/video/fbdev/core/fbsysfs.c
index d54c88f..65dae05 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -91,9 +91,9 @@ static int activate(struct fb_info *fb_info, struct
fb_var_screeninfo *var)
var->activate |= FB_ACTIVATE_FORCE;
console_lock();
- fb_info->flags |= FBINFO_MISC_USEREVENT;
err = fb_set_var(fb_info, var);
- fb_info->flags &= ~FBINFO_MISC_USEREVENT;
+ if (!err)
+ fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
console_unlock();
if (err)
return err;
diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index 9df78fb..4b4a99f 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -824,12 +824,12 @@ static int ps3fb_ioctl(struct fb_info *info, unsigned int
cmd,
var = info->var;
fb_videomode_to_var(, vmode);
console_lock();
- info->flags |= FBINFO_MISC_USEREVENT;
/* Force, in case only special bits changed */
var.activate |= FB_ACTIVATE_FORCE;
par->new_mode_id = val;
retval = fb_set_var(info, );
- info->flags &= ~FBINFO_MISC_USEREVENT;
+ if (!retval)
+ fbcon_update_vcs(info, var.activate &
FB_ACTIVATE_ALL);
console_unlock();
}
break;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3b4b2f0..b11eb02 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -400,8 +400,6 @@ struct fb_tile_ops {
#define FBINFO_HWACCEL_YPAN0x2000 /* optional */
#define FBINFO_HWACCEL_YWRAP 0x4000 /* optional */
-#define FBINFO_MISC_USEREVENT 0x1 /* event request
- from userspace */
#define FBINFO_MISC_TILEBLITTING 0x2 /* use tile blitting */
/* A driver may set this flag to indicate that it does want a set_par to be
--
1.8.3.1
Re: [PATCH v4 2/2] soc: mediatek: add mtk-devapc driver
Hi, Neal:
Neal Liu 於 2020年7月29日 週三 下午4:29寫道：
>
> MediaTek bus fabric provides TrustZone security support and data
> protection to prevent slaves from being accessed by unexpected
> masters.
> The security violation is logged and sent to the processor for
> further analysis or countermeasures.
>
> Any occurrence of security violation would raise an interrupt, and
> it will be handled by mtk-devapc driver. The violation
> information is printed in order to find the murderer.
>
> Signed-off-by: Neal Liu
[snip]
> +
> +static void devapc_vio_info_print(struct mtk_devapc_context *ctx)
> +{
> + struct mtk_devapc_vio_info *vio_info = ctx->vio_info;
> +
> + /* Print violation information */
> + if (vio_info->write)
> + dev_info(ctx->dev, "Write Violation\n");
> + else if (vio_info->read)
> + dev_info(ctx->dev, "Read Violation\n");
> +
> + dev_info(ctx->dev, "Vio Addr:0x%x, High:0x%x, Bus ID:0x%x, Dom
> ID:%x\n",
> +vio_info->vio_addr, vio_info->vio_addr_high,
> +vio_info->master_id, vio_info->domain_id);
> +}
devapc_vio_info_print() is small function and only called by
devapc_extract_vio_dbg(), so I would like to merge this function into
devapc_extract_vio_dbg() and you could drop struct mtk_devapc_vio_info
because its member are all local variable.
> +
> +/*
> + * devapc_extract_vio_dbg - extract full violation information after doing
> + * shift mechanism.
> + */
> +static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> +{
> + const struct mtk_devapc_vio_dbgs *vio_dbgs;
> + struct mtk_devapc_vio_info *vio_info;
> + void __iomem *vio_dbg0_reg;
> + void __iomem *vio_dbg1_reg;
> + u32 dbg0;
> +
> + vio_dbg0_reg = ctx->devapc_pd_base + ctx->offset->vio_dbg0;
> + vio_dbg1_reg = ctx->devapc_pd_base + ctx->offset->vio_dbg1;
> +
> + vio_dbgs = ctx->vio_dbgs;
> + vio_info = ctx->vio_info;
> +
> + /* Starts to extract violation information */
> + dbg0 = readl(vio_dbg0_reg);
> + vio_info->vio_addr = readl(vio_dbg1_reg);
> +
> + vio_info->master_id = (dbg0 & vio_dbgs->mstid.mask) >>
> + vio_dbgs->mstid.start;
> + vio_info->domain_id = (dbg0 & vio_dbgs->dmnid.mask) >>
> + vio_dbgs->dmnid.start;
> + vio_info->write = ((dbg0 & vio_dbgs->vio_w.mask) >>
> + vio_dbgs->vio_w.start) == 1;
> + vio_info->read = ((dbg0 & vio_dbgs->vio_r.mask) >>
> + vio_dbgs->vio_r.start) == 1;
> + vio_info->vio_addr_high = (dbg0 & vio_dbgs->addr_h.mask) >>
> + vio_dbgs->addr_h.start;
> +
> + devapc_vio_info_print(ctx);
> +}
> +
[snip]
> +
> +/*
> + * start_devapc - unmask slave's irq to start receiving devapc violation.
> + */
> +static void start_devapc(struct mtk_devapc_context *ctx)
> +{
> + u32 vio_idx;
> +
> + for (vio_idx = 0; vio_idx < ctx->vio_idx_num; vio_idx++)
> + mask_module_irq(ctx, vio_idx, false);
Are these bits default true? If they are default false, you need not
to setup it to false again.
> +}
> +
[snip]
> diff --git a/drivers/soc/mediatek/mtk-devapc.h
> b/drivers/soc/mediatek/mtk-devapc.h
> new file mode 100644
> index 000..7bd7e66
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-devapc.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020 MediaTek Inc.
> + */
> +
> +#ifndef __MTK_DEVAPC_H__
> +#define __MTK_DEVAPC_H__
> +
> +#define VIO_MOD_TO_REG_IND(m) ((m) / 32)
> +#define VIO_MOD_TO_REG_OFF(m) ((m) % 32)
> +
> +struct mtk_devapc_pd_offset {
> + u32 vio_mask;
> + u32 vio_sta;
> + u32 vio_dbg0;
> + u32 vio_dbg1;
> + u32 apc_con;
> + u32 vio_shift_sta;
> + u32 vio_shift_sel;
> + u32 vio_shift_con;
> +};
> +
> +struct mtk_devapc_vio_dbgs_desc {
> + u32 mask;
> + u32 start;
> +};
> +
> +struct mtk_devapc_vio_dbgs {
> + struct mtk_devapc_vio_dbgs_desc mstid;
> + struct mtk_devapc_vio_dbgs_desc dmnid;
> + struct mtk_devapc_vio_dbgs_desc vio_w;
> + struct mtk_devapc_vio_dbgs_desc vio_r;
> + struct mtk_devapc_vio_dbgs_desc addr_h;
> +};
> +
> +struct mtk_devapc_vio_info {
> + bool read;
> + bool write;
> + u32 vio_addr;
> + u32 vio_addr_high;
> + u32 master_id;
> + u32 domain_id;
> +};
> +
> +struct mtk_devapc_context {
> + struct device *dev;
> + u32 vio_idx_num;
> + void __iomem *devapc_pd_base;
> + struct mtk_devapc_vio_info *vio_info;
> + const struct mtk_devapc_pd_offset *offset;
> + const struct mtk_devapc_vio_dbgs *vio_dbgs;
> +};
> +
> +#endif /* __MTK_DEVAPC_H__ */
Data in this header file is only used in mtk-devapc.c and mtk-devapc.c
is a small file, so I think it's better to move data in header file
into .c
Re: [PATCH v7 7/8] scsi: ufs: Move dumps in IRQ handler to error handler
On 7/29/2020 6:02 AM, Can Guo wrote:
Hi Asutosh,
On 2020-07-29 02:06, Asutosh Das (asd) wrote:
On 7/27/2020 10:00 PM, Can Guo wrote:
Sometime dumps in IRQ handler are heavy enough to cause system stability
issues, move them to error handler.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c480823..b2bafa3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5682,6 +5682,21 @@ static void ufshcd_err_handler(struct
work_struct *work)
UFSHCD_UIC_DL_TCx_REPLAY_ERROR
needs_reset = true;
+ if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR |
+ UFSHCD_UIC_HIBERN8_MASK)) {
+ bool pr_prdt = !!(hba->saved_err & SYSTEM_BUS_FATAL_ERROR);
+
+ dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 0x%x\n",
+ __func__, hba->saved_err, hba->saved_uic_err);
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+ ufshcd_print_host_state(hba);
+ ufshcd_print_pwr_info(hba);
+ ufshcd_print_host_regs(hba);
+ ufshcd_print_tmrs(hba, hba->outstanding_tasks);
+ ufshcd_print_trs(hba, hba->outstanding_reqs, pr_prdt);
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ }
+
/*
* if host reset is required then skip clearing the pending
* transfers forcefully because they will get cleared during
@@ -5900,22 +5915,6 @@ static irqreturn_t ufshcd_check_errors(struct
ufs_hba *hba)
/* block commands from scsi mid-layer */
ufshcd_scsi_block_requests(hba);
-
- /* dump controller state before resetting */
- if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR)) {
- bool pr_prdt = !!(hba->saved_err &
- SYSTEM_BUS_FATAL_ERROR);
-
- dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err
0x%x\n",
- __func__, hba->saved_err,
- hba->saved_uic_err);
-
- ufshcd_print_host_regs(hba);
- ufshcd_print_pwr_info(hba);
How about keep the above prints and move the tmrs and trs to eh?
Sometimes in system instability, the eh may not get a chance to run
even. Still the above prints would provide some clues.
Here is the IRQ handler, ufshcd_print_host_regs() is sometime heavy
enough to cause stability issues during my fault injection test, since
it prints host regs, reg's history, crypto debug infos plus prints
from vops_dump.
How about just printing host regs and reg history here? Most time, these
infos are enough.
That'd work too.
Thanks,
Can Guo.
- ufshcd_print_tmrs(hba, hba->outstanding_tasks);
- ufshcd_print_trs(hba, hba->outstanding_reqs,
- pr_prdt);
- }
ufshcd_schedule_eh_work(hba);
retval |= IRQ_HANDLED;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
On Wed, Jul 29, 2020 at 03:44:56PM -0400, Vladis Dronov wrote:
> > > Certain warnings are emitted for powerpc code when building with a gcc-10
> > > toolset:
> > >
> > > WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch
> > > in
> > > reference from the function remove_pmd_table() to the function
> > > .meminit.text:split_kernel_mapping()
> > > The function remove_pmd_table() references
> > > the function __meminit split_kernel_mapping().
> > > This is often because remove_pmd_table lacks a __meminit
> > > annotation or the annotation of split_kernel_mapping is wrong.
> > >
> > > Add the appropriate __init and __meminit annotations to make modpost not
> > > complain. In all the cases there are just a single callsite from another
> > > __init or __meminit function:
> > >
> > > __meminit remove_pagetable() -> remove_pud_table() -> remove_pmd_table()
> > > __init prom_init() -> setup_secure_guest()
> > > __init xive_spapr_init() -> xive_spapr_disabled()
> >
> > So what changed? These functions were inlined with older compilers, but
> > not anymore?
>
> Yes, exactly. Gcc-10 does not inline them anymore. If this is because of my
> build system, this can happen to others also.
>
> The same thing was fixed by Linus in e99332e7b4cd ("gcc-10: mark more
> functions
> __init to avoid section mismatch warnings").
It sounds like this is part of "-finline-functions was retuned" on
? So everyone should see it
(no matter what config or build system), and it is a good thing too :-)
Thanks for the confirmation,
Segher
Re: [PATCH v3 0/6] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
On Sun, Jul 26, 2020 at 03:00:55PM -0700, Guenter Roeck wrote: > The EC reports a variety of error codes. Most of those, with the exception > of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual > error code gets lost. In cros_ec_cmd_xfer_status(), convert all EC errors > to Linux error codes to report a more meaningful error to the caller to aid > debugging. > > To prepare for this change, handle error codes other than -EPROTO for all > callers of cros_ec_cmd_xfer_status(). Specifically, no longer assume that > -EPROTO reflects an error from the EC and all other error codes reflect a > transfer error. > > v2: Add patches 1/4 to 3/4 to handle callers of cros_ec_cmd_xfer_status() > v3: Add patches 4/6 and 5/6 to handle additional callers of > cros_ec_cmd_xfer_status() > Use -ENOPROTOOPT for EC_RES_INVALID_VERSION > Implement function to convert error codes A small potential (i.e., being paranoid about future changes) note on patch 6, but otherwise looks fine to me: Reviewed-by: Brian Norris
Re: [tip:locking/core 9/30] arch/mips/include/asm/smp.h:28:19: error: static declaration of 'raw_smp_processor_id' follows non-static declaration
On Thu, Jul 30, 2020 at 02:05:18AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking/core > head: b5e6a027bd327daa679ca55182a920659e2cbb90 > commit: 859247d39fb008ea812e8f0c398a58a20c12899e [9/30] seqlock: lockdep > assert non-preemptibility on seqcount_t write > config: mips-allyesconfig (attached as .config) > compiler: mips-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 859247d39fb008ea812e8f0c398a58a20c12899e > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=mips > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >In file included from arch/mips/include/asm/bug.h:42, > from include/linux/bug.h:5, > from include/linux/thread_info.h:12, > from include/asm-generic/preempt.h:5, > from ./arch/mips/include/generated/asm/preempt.h:1, > from include/linux/preempt.h:78, > from include/linux/spinlock.h:51, > from include/linux/seqlock.h:15, > from include/linux/time.h:6, > from include/linux/compat.h:10, > from arch/mips/kernel/asm-offsets.c:12: >include/linux/seqlock.h: In function 'write_seqcount_begin_nested': *sigh*, so I've no idea what happened, I've had these patches in my git tree for about a week and the worst 0day found was a Sparse bug :/ Anyway, I've got the below hackery, and am now able to build: - sparc64 - mips - x86_64 - arm - arm64 - powerpc64 - powerpc allmodconfig vmlinux (that is, the vmlinux target of that config, I didn't power up an EX because the kids are asleep, so building full allmodconfig's is out). i386 is broken, but I'm too tired, I've not yet tried any of the other archs. I'll continue in the morning if Ingo doesn't beat me to it. --- arch/sparc/include/asm/timer_64.h| 1 + arch/sparc/include/asm/vvar.h| 3 ++- arch/sparc/kernel/vdso.c | 1 - arch/x86/include/asm/fixmap.h| 2 +- arch/x86/kernel/apic/apic_noop.c | 1 + arch/x86/kernel/apic/hw_nmi.c| 1 + arch/x86/kernel/apic/probe_64.c | 1 + arch/x86/kernel/cpu/amd.c| 1 + arch/x86/kernel/cpu/common.c | 1 + arch/x86/kernel/cpu/hygon.c | 1 + arch/x86/kernel/cpu/intel.c | 1 + arch/x86/kernel/jailhouse.c | 1 + arch/x86/kernel/tsc_msr.c| 1 + arch/x86/xen/apic.c | 1 + arch/x86/xen/smp_hvm.c | 1 + arch/x86/xen/suspend_pv.c| 4 ++-- include/asm-generic/fixmap.h | 4 ++-- include/linux/dynamic_queue_limits.h | 2 ++ include/linux/hrtimer.h | 1 + include/linux/ktime.h| 1 + include/linux/lockdep.h | 1 + include/linux/mutex.h| 11 +++ include/linux/sched.h| 1 + include/linux/seqlock.h | 1 - include/linux/time.h | 1 - include/linux/ww_mutex.h | 8 26 files changed, 36 insertions(+), 17 deletions(-) diff --git a/arch/sparc/include/asm/timer_64.h b/arch/sparc/include/asm/timer_64.h index c7e4fb601a57..dcfad4613e18 100644 --- a/arch/sparc/include/asm/timer_64.h +++ b/arch/sparc/include/asm/timer_64.h @@ -7,6 +7,7 @@ #ifndef _SPARC64_TIMER_H #define _SPARC64_TIMER_H +#include #include #include diff --git a/arch/sparc/include/asm/vvar.h b/arch/sparc/include/asm/vvar.h index 0289503d1cb0..6eaf5cfcaae1 100644 --- a/arch/sparc/include/asm/vvar.h +++ b/arch/sparc/include/asm/vvar.h @@ -6,7 +6,8 @@ #define _ASM_SPARC_VVAR_DATA_H #include -#include +#include +#include #include #include diff --git a/arch/sparc/kernel/vdso.c b/arch/sparc/kernel/vdso.c index 58880662b271..0e27437eb97b 100644 --- a/arch/sparc/kernel/vdso.c +++ b/arch/sparc/kernel/vdso.c @@ -7,7 +7,6 @@ * a different vsyscall implementation for Linux/IA32 and for the name. */ -#include #include #include diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h index b9527a54db99..0f0dd645b594 100644 --- a/arch/x86/include/asm/fixmap.h +++ b/arch/x86/include/asm/fixmap.h @@ -26,9 +26,9 @@ #ifndef __ASSEMBLY__ #include -#include #include #include +#include #ifdef CONFIG_X86_32 #include #include diff --git a/arch/x86/kernel/apic/apic_noop.c b/arch/x86/kernel/apic/apic_noop.c index 98c9bb75d185..780c702969b7 100644 --- a/arch/x86/kernel/apic/apic_noop.c +++ b/arch/x86/kernel/apic/apic_noop.c @@ -10,6 +10,7 @@ * like self-ipi, etc... */ #include
Re: [PATCH v3 10/11] KVM: X86: Move handling of INVPCID types to x86
On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote: > > INVPCID instruction handling is mostly same across both VMX and > SVM. So, move the code to common x86.c. > > Signed-off-by: Babu Moger Reviewed-by: Jim Mattson
drivers/staging/media/atomisp/pci/atomisp_cmd.c:2805:31: warning: variable 'stream_config' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: 5b552b198c2557295becd471bff53bb520fefee5 media: atomisp: re-enable
warnings again
date: 7 weeks ago
config: i386-randconfig-r016-20200729 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
git checkout 5b552b198c2557295becd471bff53bb520fefee5
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
cc1: warning:
drivers/staging/media/atomisp//pci/hive_isp_css_include/memory_access/: No such
file or directory [-Wmissing-include-dirs]
drivers/staging/media/atomisp/pci/atomisp_cmd.c: In function
'atomisp_get_metadata':
>> drivers/staging/media/atomisp/pci/atomisp_cmd.c:2805:31: warning: variable
>> 'stream_config' set but not used [-Wunused-but-set-variable]
2805 | struct ia_css_stream_config *stream_config;
| ^
drivers/staging/media/atomisp/pci/atomisp_cmd.c: In function
'atomisp_get_metadata_by_type':
drivers/staging/media/atomisp/pci/atomisp_cmd.c:2884:31: warning: variable
'stream_config' set but not used [-Wunused-but-set-variable]
2884 | struct ia_css_stream_config *stream_config;
| ^
In file included from drivers/staging/media/atomisp//pci/system_local.h:8,
from
drivers/staging/media/atomisp//pci/ia_css_acc_types.h:23,
from
drivers/staging/media/atomisp//pci/ia_css_pipe_public.h:29,
from drivers/staging/media/atomisp/pci/sh_css_legacy.h:23,
from
drivers/staging/media/atomisp/pci/atomisp_internal.h:34,
from drivers/staging/media/atomisp/pci/atomisp_cmd.h:30,
from drivers/staging/media/atomisp/pci/atomisp_cmd.c:37:
At top level:
drivers/staging/media/atomisp//pci/isp2401_system_local.h:217:26: warning:
'STREAM2MMIO_CTRL_BASE' defined but not used [-Wunused-const-variable=]
217 | static const hrt_address STREAM2MMIO_CTRL_BASE[N_STREAM2MMIO_ID] = {
| ^
drivers/staging/media/atomisp//pci/isp2401_system_local.h:210:26: warning:
'PIXELGEN_CTRL_BASE' defined but not used [-Wunused-const-variable=]
210 | static const hrt_address PIXELGEN_CTRL_BASE[N_PIXELGEN_ID] = {
| ^~
drivers/staging/media/atomisp//pci/isp2401_system_local.h:203:26: warning:
'CSI_RX_BE_CTRL_BASE' defined but not used [-Wunused-const-variable=]
203 | static const hrt_address CSI_RX_BE_CTRL_BASE[N_CSI_RX_BACKEND_ID] = {
| ^~~
drivers/staging/media/atomisp//pci/isp2401_system_local.h:196:26: warning:
'CSI_RX_FE_CTRL_BASE' defined but not used [-Wunused-const-variable=]
196 | static const hrt_address CSI_RX_FE_CTRL_BASE[N_CSI_RX_FRONTEND_ID] =
{
| ^~~
drivers/staging/media/atomisp//pci/isp2401_system_local.h:189:26: warning:
'ISYS_IRQ_BASE' defined but not used [-Wunused-const-variable=]
189 | static const hrt_address ISYS_IRQ_BASE[N_ISYS_IRQ_ID] = {
| ^
drivers/staging/media/atomisp//pci/isp2401_system_local.h:182:26: warning:
'IBUF_CTRL_BASE' defined but not used [-Wunused-const-variable=]
182 | static const hrt_address IBUF_CTRL_BASE[N_IBUF_CTRL_ID] = {
| ^~
drivers/staging/media/atomisp//pci/isp2401_system_local.h:177:26: warning:
'RX_BASE' defined but not used [-Wunused-const-variable=]
177 | static const hrt_address RX_BASE[N_RX_ID] = {
| ^~~
drivers/staging/media/atomisp//pci/isp2401_system_local.h:162:26: warning:
'INPUT_SYSTEM_BASE' defined but not used [-Wunused-const-variable=]
162 | static const hrt_address INPUT_SYSTEM_BASE[N_INPUT_SYSTEM_ID] = {
| ^
drivers/staging/media/atomisp//pci/isp2401_system_local.h:154:26: warning:
'INPUT_FORMATTER_BASE' defined but not used [-Wunused-const-variable=]
154 | static const hrt_address INPUT_FORMATTER_BASE[N_INPUT_FORMATTER_ID]
= {
| ^~~~
drivers/staging/media/atomisp//pci/isp2401_system_local.h:149:26: warning:
'TIMED_CTRL_BASE' defined but not used [-Wunused-const-variable=]
149 | static const hrt_address TIMED_CTRL_BASE[N_TIMED_CTRL_ID] = {
| ^~~
drivers/staging/media/atomisp//pci/isp2401_system_local.h:144:26: warning:
'GPIO_BASE' defined but not used [-Wunused-const-variable=]
144 | static
Re: [PATCH-next v5 0/7] x86/boot: Remove run-time relocations from compressed kernel
On Wed, Jul 29, 2020 at 03:04:43PM -0700, Kees Cook wrote: > On Fri, Jul 17, 2020 at 04:17:54PM -0400, Arvind Sankar wrote: > > Same as v5 previously posted, but rebased onto next-20200717. > > > > v5: > > https://lore.kernel.org/lkml/20200715004133.1430068-1-nived...@alum.mit.edu/ > > BTW, some bits of feedback on process: > > - please don't re-use version numbers, this is confusing :) This was a special case as there were no actual changes in this version. > - please fix whatever is happening with the "In-Reply-To:" headers, the > threading is extremely hard to understand (each patch isn't a reply to > the cover letter, and everything is a reply to a single earlier email) > > -- > Kees Cook I think this is because I'm passing --in-reply-to to format-patch. Seems like I should specify that in send-email instead, hopefully that will fix the threading. Thanks.
Re: [PATCH v3 6/6] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
Hi Guenter,
On Sun, Jul 26, 2020 at 03:01:01PM -0700, Guenter Roeck wrote:
> v3: Use -ENOPROTOOPT for EC_RES_INVALID_VERSION
> Implement function to convert error codes
> v2: No change
>
> drivers/platform/chrome/cros_ec_proto.c | 52 -
> 1 file changed, 42 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index e5bbec979a2a..a081b8245682 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -15,6 +15,43 @@
>
> #define EC_COMMAND_RETRIES 50
>
> +static const int cros_ec_error_map[] = {
> + [EC_RES_INVALID_COMMAND] = -EOPNOTSUPP,
> + [EC_RES_ERROR] = -EIO,
> + [EC_RES_INVALID_PARAM] = -EINVAL,
> + [EC_RES_ACCESS_DENIED] = -EACCES,
> + [EC_RES_INVALID_RESPONSE] = -EPROTO,
> + [EC_RES_INVALID_VERSION] = -ENOPROTOOPT,
> + [EC_RES_INVALID_CHECKSUM] = -EBADMSG,
> + [EC_RES_IN_PROGRESS] = -EINPROGRESS,
> + [EC_RES_UNAVAILABLE] = -ENODATA,
> + [EC_RES_TIMEOUT] = -ETIMEDOUT,
> + [EC_RES_OVERFLOW] = -EOVERFLOW,
> + [EC_RES_INVALID_HEADER] = -EBADR,
> + [EC_RES_REQUEST_TRUNCATED] = -EBADR,
> + [EC_RES_RESPONSE_TOO_BIG] = -EFBIG,
> + [EC_RES_BUS_ERROR] = -EFAULT,
> + [EC_RES_BUSY] = -EBUSY,
> + [EC_RES_INVALID_HEADER_VERSION] = -EBADMSG,
> + [EC_RES_INVALID_HEADER_CRC] = -EBADMSG,
> + [EC_RES_INVALID_DATA_CRC] = -EBADMSG,
> + [EC_RES_DUP_UNAVAILABLE] = -ENODATA,
> +};
Sorry I didn't pay attention to this earlier, but is there any
programmatic way to ensure that we don't have unexpected holes here? If
we do (e.g., we add new error codes, but they aren't contiguous for
whatever reasons), then those will get treated as "success" with your
current patch.
I say "unexpected" hole, because EC_RES_SUCCESS (0) is an expected hole.
> +
> +static int cros_ec_map_error(uint32_t result)
> +{
> + int ret = 0;
> +
> + if (result != EC_RES_SUCCESS) {
> + if (result < ARRAY_SIZE(cros_ec_error_map) &&
> cros_ec_error_map[result])
> + ret = cros_ec_error_map[result];
^^ Maybe we want to double check 'ret != 0'? Or maybe
ret = cros_ec_error_map[result];
if (!ret) {
ret = -EPROTO;
dev_err(..., "Unexpected EC result code %d\n",
result);
}
? Could even be WARN_ON(), since this would be an actionable programming
error, not exactly an external factor. Or maybe I'm being paranoid, and
future programmers are perfect.
Otherwise:
Reviewed-by: Brian Norris
> + else
> + ret = -EPROTO;
> + }
> +
> + return ret;
> +}
> +
> static int prepare_packet(struct cros_ec_device *ec_dev,
> struct cros_ec_command *msg)
> {
Re: kernel BUG at mm/internal.h:LINE! (2)
On Wed, Jul 29, 2020 at 01:04:21PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:68845a55 Merge branch 'akpm' into master (patches from And.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=17c86c5490 > kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 > dashboard link: https://syzkaller.appspot.com/bug?extid=f62749569eab36774dc5 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+f62749569eab36774...@syzkaller.appspotmail.com > > vma 888000153210 start 000770077000 end 00077000 > next 00077000 prev 07070707 mm 00077000 > prot 7770077000 anon_vma vm_ops 885cecc0 All these 0 and 7 look very broken. Is it some magic or just garbage? -- Kirill A. Shutemov
RE: [PATCH v3 06/11] KVM: SVM: Add new intercept vector in vmcb_control_area
> -Original Message-
> From: Jim Mattson
> Sent: Wednesday, July 29, 2020 4:24 PM
> To: Moger, Babu
> Cc: Paolo Bonzini ; Vitaly Kuznetsov
> ; Wanpeng Li ; Sean
> Christopherson ; kvm list
> ; Joerg Roedel ; the arch/x86
> maintainers ; LKML ; Ingo
> Molnar ; Borislav Petkov ; H . Peter Anvin
> ; Thomas Gleixner
> Subject: Re: [PATCH v3 06/11] KVM: SVM: Add new intercept vector in
> vmcb_control_area
>
> On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote:
> >
> > The new intercept bits have been added in vmcb control area to support
> > few more interceptions. Here are the some of them.
> > - INTERCEPT_INVLPGB,
> > - INTERCEPT_INVLPGB_ILLEGAL,
> > - INTERCEPT_INVPCID,
> > - INTERCEPT_MCOMMIT,
> > - INTERCEPT_TLBSYNC,
> >
> > Add new intercept vector in vmcb_control_area to support these instructions.
> > Also update kvm_nested_vmrun trace function to support the new addition.
> >
> > AMD documentation for these instructions is available at "AMD64
> > Architecture Programmer’s Manual Volume 2: System Programming, Pub.
> > 24593 Rev. 3.34(or later)"
> >
> > The documentation can be obtained at the links below:
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24593.pdfdata=02%7C01%
> 7Cbab
> >
> u.moger%40amd.com%7C04dafd87052d4ed59f9808d83405b0a4%7C3dd8961fe
> 4884e6
> >
> 08e11a82d994e183d%7C0%7C0%7C637316547054108593sdata=2ncYK2
> NY1J3xL
> > 9ZXSdb24zq0M0ZkF0iy%2FIW7SUDoFeg%3Dreserved=0
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> >
> illa.kernel.org%2Fshow_bug.cgi%3Fid%3D206537data=02%7C01%7Cbab
> u.m
> >
> oger%40amd.com%7C04dafd87052d4ed59f9808d83405b0a4%7C3dd8961fe488
> 4e608e
> >
> 11a82d994e183d%7C0%7C0%7C637316547054108593sdata=Trw3tJE1Z6
> dOTXi0
> > DbPhOUAh4Ulr7HxxoJNpM2IjbvM%3Dreserved=0
> >
> > Signed-off-by: Babu Moger
> > ---
>
> > @@ -16,6 +16,7 @@ enum vector_offset {
> > EXCEPTION_VECTOR,
> > INTERCEPT_VECTOR_3,
> > INTERCEPT_VECTOR_4,
> > + INTERCEPT_VECTOR_5,
> > MAX_VECTORS,
> > };
>
> Is this enumeration actually adding any value?
Yea. It is not much of a value add. It helps readability a little bit.
That’s why I kept that way. Thanks
> vmcb->control.intercepts[INTERCEPT_VECTOR_5] doesn't seem in any way
> "better" than just vmcb->control.intercepts[5].
>
> Reviewed-by: Jim Mattson
[PATCH][next] ALSA: hda_codec: Use flex_array_size() helper in memcpy()
Make use of the flex_array_size() helper to calculate the size of a flexible array member within an enclosing structure. This helper offers defense-in-depth against potential integer overflows and makes it explicitly clear that we are dealing with a flexible array member. Signed-off-by: Gustavo A. R. Silva --- sound/pci/hda/hda_codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 58c698f4d131..453c4ec77c48 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -113,7 +113,7 @@ static int add_conn_list(struct hda_codec *codec, hda_nid_t nid, int len, return -ENOMEM; p->len = len; p->nid = nid; - memcpy(p->conns, list, len * sizeof(hda_nid_t)); + memcpy(p->conns, list, flex_array_size(p, conns, len)); list_add(>list, >conn_list); return 0; } -- 2.27.0
Re: [PATCH v3 09/11] KVM: SVM: Remove set_exception_intercept and clr_exception_intercept
On Tue, Jul 28, 2020 at 4:38 PM Babu Moger wrote: > > Remove set_exception_intercept and clr_exception_intercept. > Replace with generic set_intercept and clr_intercept for these calls. > > Signed-off-by: Babu Moger Reviewed-by: Jim Mattson
Re: kernel BUG at include/linux/swapops.h:LINE!
On Wed, Jul 29, 2020 at 08:54:32PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 29, 2020 at 10:21:51PM +0300, Kirill A. Shutemov wrote:
> > On Mon, Jul 27, 2020 at 01:03:10PM +0100, Matthew Wilcox wrote:
> > > > It would be interesting to know if the migration entires ever got
> > > > removed
> > > > for pfn. I mean if remove_migration_pte() got called for it.
> > > >
> > > > It can be rmap issue too. Maybe it misses PMD on remove_migration_ptes()
> > > > or something.
> > >
> > > It's not mapped with a PMD. I tweaked my debugging slightly:
> > >
> > > static inline swp_entry_t make_migration_entry(struct page *page, int
> > > write)
> > > {
> > > - BUG_ON(!PageLocked(compound_head(page)));
> > > + VM_BUG_ON_PAGE(!PageLocked(page), page);
> > >
> > > +if (PageHead(page)) dump_page(page, "make entry");
> > > +if (PageTail(page)) printk("pfn %lx order %d\n", page_to_pfn(page),
> > > thp_order(thp_head(page)));
> > >
> > > 1523 page:06f62206 refcount:490 mapcount:1
> > > mapping: index:0x562b12a00 pfn:0x1dc00
> > > 1523 head:06f62206 order:9 compound_mapcount:0 compound_pincount:0
> > > 1523 anon flags:
> > > 0x4009003d(locked|uptodate|dirty|lru|active|head|swapbacked)
> > > 1523 raw: 4009003d ecfd41301308 ecfd41b08008
> > > 9e9971c00059
> > > 1523 raw: 000562b12a00 01ea
> > >
> > > 1523 page dumped because: make entry
> > > 1523 pfn 1dc01 order 9
> > > 1523 pfn 1dc02 order 9
> > > 1523 pfn 1dc03 order 9
> > > ...
> > >
> > > Notice that it's an anonymous page, so it's not related to my work.
> >
> > I don't have much hope, but could you try if the patch below would blow
> > up?
>
> Running it now. Results probably in twenty minutes.
It didn't blow up. I added a dump_stack() after the call to dump_page()
and got this ...
2922 page:85a5c107 refcount:474 mapcount:1 mapping:
index:0x559e98a00 pfn:0x35200
2922 head:85a5c107 order:9 compound_mapcount:0 compound_pincount:0
2922 anon flags:
0x4009003d(locked|uptodate|dirty|lru|active|head|swapbacked)
2922 raw: 4009003d e8e5c1bbaf48 e8e5c046ee88 a2e7f3787ec9
2922 raw: 000559e98a00 01da
2922 page dumped because: make entry
2922 CPU: 5 PID: 23471 Comm: dd Kdump: loaded Tainted: GW
5.8.0-rc6-00067-gd8b18bdf9870-dirty #358
2922 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1
04/01/2014
2922 Call Trace:
2922 dump_stack+0x5e/0x7a
2922 try_to_unmap_one+0x846/0x860
2922 rmap_walk_anon+0x13d/0x2a0
2922 rmap_walk_locked+0x23/0x30
2922 try_to_unmap+0x64/0xbc
2922 split_huge_page_to_list+0x188/0xdb0
2922 deferred_split_scan+0x148/0x240
2922 shrink_slab.constprop.0+0x198/0x330
2922 shrink_node+0x1a8/0x440
2922 try_to_free_pages+0x18f/0x480
2922 __alloc_pages_slowpath.constprop.0+0x297/0xca0
2922 __alloc_pages_nodemask+0x1ba/0x1e0
2922 pagecache_get_page+0xd8/0x330
2922 grab_cache_page_write_begin+0x1c/0x40
2922 iomap_write_begin+0x2d6/0x6d0
2922 iomap_write_actor+0x8b/0x1c0
2922 iomap_apply+0xe3/0x310
2922 iomap_file_buffered_write+0x5c/0x80
2922 xfs_file_buffered_aio_write+0xbd/0x310
2922 xfs_file_write_iter+0xa8/0xc0
2922 new_sync_write+0xf5/0x170
2922 vfs_write+0x191/0x1e0
I think that's interesting because it's not trying to allocate a huge
page itself (I didn't touch the write_begin path). Rather, I presume
the additional memory pressure from allocating huge pages is causing
anonymous pages to be split to free up memory.
It survived all the way to generic/224 this run, but I don't think
that's relevant.
[PATCH][next] ALSA: vmaster: Use flex_array_size() helper in memcpy()
Make use of the flex_array_size() helper to calculate the size of a flexible array member within an enclosing structure. This helper offers defense-in-depth against potential integer overflows and makes it explicitly clear that we are dealing with a flexible array member. Signed-off-by: Gustavo A. R. Silva --- sound/core/vmaster.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/vmaster.c b/sound/core/vmaster.c index ab36f9898711..21ce4082cb5f 100644 --- a/sound/core/vmaster.c +++ b/sound/core/vmaster.c @@ -262,7 +262,8 @@ int _snd_ctl_add_follower(struct snd_kcontrol *master, return -ENOMEM; srec->kctl = follower; srec->follower = *follower; - memcpy(srec->follower.vd, follower->vd, follower->count * sizeof(*follower->vd)); + memcpy(srec->follower.vd, follower->vd, flex_array_size(srec, follower.vd, + srec->follower.count)); srec->master = master_link; srec->flags = flags; -- 2.27.0
Re: linux-next: Fixes tag needs some work in the block tree
Hi all,
[Just adding cc's]
On Thu, 30 Jul 2020 08:08:49 +1000 Stephen Rothwell
wrote:
>
> In commit
>
> 64d452b3560b ("nvme-loop: set ctrl state connecting after init")
>
> Fixes tag
>
> Fixes: aa63fa6776a7 ("nvme-fabrics: allow to queue requests for live
> queues")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> I can't easily find what commit is meant :-(
--
Cheers,
Stephen Rothwell
pgpmp0DYRHa_I.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/1] scsi: virtio-scsi: handle correctly case when all LUNs were unplugged
On 29/07/20 21:48, Maxim Levitsky wrote:
> Commit 5ff843721467 ("scsi: virtio_scsi: unplug LUNs when events missed"),
> almost fixed the case of mass unpluging of LUNs, but it missed a
> corner case in which all the LUNs are unplugged at the same time.
>
> In this case INQUIRY ends with DID_BAD_TARGET.
> Detect this and unplug the LUN.
>
> Signed-off-by: Maxim Levitsky
> ---
> drivers/scsi/virtio_scsi.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 0e0910c5b9424..c7f0c22b6f11d 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -351,6 +351,16 @@ static void virtscsi_rescan_hotunplug(struct virtio_scsi
> *vscsi)
> /* PQ indicates the LUN is not attached */
> scsi_remove_device(sdev);
> }
> +
> + else if (host_byte(result) == DID_BAD_TARGET) {
> + /*
> + * if all LUNs of a virtio-scsi device are unplugged,
> + * it will respond with BAD TARGET on any INQUIRY
> + * command.
> + * Remove the device in this case as well
> + */
> + scsi_remove_device(sdev);
> + }
> }
>
> kfree(inq_result);
>
Acked-by: Paolo Bonzini
linux-next: Fixes tag needs some work in the block tree
Hi all,
In commit
64d452b3560b ("nvme-loop: set ctrl state connecting after init")
Fixes tag
Fixes: aa63fa6776a7 ("nvme-fabrics: allow to queue requests for live queues")
has these problem(s):
- Target SHA1 does not exist
I can't easily find what commit is meant :-(
--
Cheers,
Stephen Rothwell
pgpL2jUosDbJF.pgp
Description: OpenPGP digital signature
Modem on Droid 4 (mdm6600) in recent mainline
Hi! There's something very wrong with /dev/ttyUSB4 in recent kernels: unsolicited incoming data from the modem are getting lost; I believe it means also SMS notifications, but it is very easy to reproduce with incoming call notifications. They just don't come. But if you keep pasting "AT" into minicom, they actually do. Of course... that means that trying to debug ofono is ... "interesting". I tried playing with /sys/bus/platform/drivers/phy-mapphone-mdm6600/usb-phy\@1/power/control files and timeouts, but could not get it to work. Any idea what could be wrong there? Is there easy way to disable power management for testing? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection
Hi, Sean, On Wed, Jul 29, 2020 at 01:39:05PM -0700, Sean Christopherson wrote: > On Wed, Jul 29, 2020 at 08:35:57PM +, Fenghua Yu wrote: > > If sld=fatal and bld=ratelimit (both sld and bld are enabled in hw), > > a split lock always generates #AC and kills the app and bld will never have > > a chance to trigger #DB for split lock. So effectively the combination makes > > the kernel to take two different actions after detecting a bus lock: if the > > bus lock comes from a split lock, fatal (sld); if the bus lock comes from > > lock to non-WB memory, ratelimit (bld). Seems this is not a useful > > combination > > and is not what the user really wants to do because the user wants ratelimit > > for BLD, right? > > I understood all off that. And as I user I want to run sld=fatal and > bld=ratelimit to provide maximum protection, i.e. disallow split locks at > all times, and ratelimit the crud SLD #AC can't catch. Then this will expand the current usages and do need two options. Let me work on adding a new "bus_lock_detect=" option as you suggested. Thanks. -Fenghua
[tip:sched/fifo] BUILD REGRESSION 4fd5750af02ab7bba7c58a073060cc1da8a69173
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/fifo branch HEAD: 4fd5750af02ab7bba7c58a073060cc1da8a69173 sched,tracing: Convert to sched_set_fifo() Error/Warning in current branch: drivers/pinctrl/core.c:1356: error: Cannot parse struct or union! Error/Warning ids grouped by kconfigs: recent_errors |-- alpha-allmodconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- alpha-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- alpha-randconfig-r002-20200729 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- arc-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- arc-randconfig-r005-20200729 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- arc-randconfig-r021-20200728 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- c6x-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- ia64-allmodconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- ia64-randconfig-r035-20200729 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- mips-allmodconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- mips-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- nds32-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- nios2-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- nios2-randconfig-r031-20200729 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- parisc-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- parisc-randconfig-c004-20200729 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- s390-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- sh-allmodconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- sparc-allyesconfig | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- sparc-randconfig-r025-20200728 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union |-- sparc64-randconfig-r001-20200729 | `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union `-- xtensa-allyesconfig `-- drivers-pinctrl-core.c:error:Cannot-parse-struct-or-union elapsed time: 721m configs tested: 66 configs skipped: 1 arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20200729 i386 randconfig-a004-20200729 i386 randconfig-a005-20200729 i386 randconfig-a002-20200729 i386 randconfig-a006-20200729 i386 randconfig-a001-20200729 i386 randconfig-a016-20200729 i386 randconfig-a012-20200729 i386 randconfig-a013-20200729 i386 randconfig-a014-20200729 i386 randconfig-a011-20200729 i386 randconfig-a015-20200729 x86_64 randconfig-a004-20200729 x86_64 randconfig-a005-20200729 x86_64 randconfig-a002-20200729 x86_64 randconfig-a006-20200729 x86_64 randconfig-a003-20200729 x86_64
[no subject]
Urgent attention please Dearest, how are you? I am sorry for intruding your mailbox, but I need to talk to you. I got your email address in my dream and i wonder if it is correct because i emailed you earlier without any response. You should know that my contact to you is by the special grace of God. I am in urgent need of a reliable and reputable person and i believe you are a person of fine repute, hence the revelation of your email to me in the dream. I am Mrs. Celine Marchand a citizen of France (French). But reside in Burkina Faso for business purposes. I need your collaboration to execute some projects worth € 2.800.000 Euro and it is very urgent as am presently in very critical condition. Please reply through this email address ( celine88...@gmail.com ) with your full contact information for more private and confidential communication. Thank you as i wait for your reply. Mrs. Celine Marchand
Re: [PATCH-next v5 0/7] x86/boot: Remove run-time relocations from compressed kernel
On Fri, Jul 17, 2020 at 04:17:54PM -0400, Arvind Sankar wrote: > Same as v5 previously posted, but rebased onto next-20200717. > > v5: > https://lore.kernel.org/lkml/20200715004133.1430068-1-nived...@alum.mit.edu/ BTW, some bits of feedback on process: - please don't re-use version numbers, this is confusing :) - please fix whatever is happening with the "In-Reply-To:" headers, the threading is extremely hard to understand (each patch isn't a reply to the cover letter, and everything is a reply to a single earlier email) -- Kees Cook
linux-next: Fixes tag needs some work in the sound-asoc tree
Hi all,
In commit
e5448d7ec656 ("ASoC: tlv320adcx140: Fix various style errors and warnings")
Fixes tag
Fixes: 689c7655b50 ("ASoC: tlv320adcx140: Add the tlv320adcx140 codec driver
family")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
Just a hint for the future.
--
Cheers,
Stephen Rothwell
pgpFuAgURq01q.pgp
Description: OpenPGP digital signature
Re: [PATCH] perf bench: Add benchmark of find_next_bit
On Wed, Jul 29, 2020 at 1:44 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Wed, Jul 29, 2020 at 04:59:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Tue, Jul 28, 2020 at 08:51:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Jul 24, 2020 at 12:19:59AM -0700, Ian Rogers escreveu:
> > > > for_each_set_bit, or similar functions like for_each_cpu, may be hot
> > > > within the kernel. If many bits were set then one could imagine on
> > > > Intel a "bt" instruction with every bit may be faster than the function
> > > > call and word length find_next_bit logic. Add a benchmark to measure
> > > > this.
> > >
> > > Thanks, applied.
>
> > > > This benchmark on AMD rome and Intel skylakex shows "bt" is not a good
> > > > option except for very small bitmaps.
> >
> > > > +++ b/tools/perf/bench/find-bit-bench.c
> >
> > > > +#if defined(__i386__) || defined(__x86_64__)
> > > > +static bool asm_test_bit(long nr, const unsigned long *addr)
> > > > +{
> > > > + bool oldbit;
> > > > +
> > > > + asm volatile("bt %2,%1"
> > > > + : "=@ccc" (oldbit)
> > > > + : "m" (*(unsigned long *)addr), "Ir" (nr) : "memory");
> > > > +
> > > > + return oldbit;
> >
> > Some old clang versions are not liking this:
>
> Failed with:
>
> clang version 3.8.0 (tags/RELEASE_380/final)
> clang version 3.8.1 (tags/RELEASE_381/final)
> clang version 4.0.0 (tags/RELEASE_400/final)
> Alpine clang version 8.0.0 (tags/RELEASE_800/final) (based on LLVM 8.0.0)
> Alpine clang version 5.0.0 (tags/RELEASE_500/final) (based on LLVM 5.0.0)
> Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
> Alpine clang version 5.0.1 (tags/RELEASE_502/final) (based on LLVM 5.0.1)
>
> Worked with:
>
> Alpine clang version 9.0.0 (https://git.alpinelinux.org/aports
> f7f0d2c2b8bcd6a5843401a9a702029556492689) (based on LLVM 9.0.0)
> Alpine clang version 10.0.0
> (https://gitlab.alpinelinux.org/alpine/aports.git
> 7445adce501f8473efdb93b17b5eaf2f1445ed4c)
> Alpine clang version 10.0.0 (git://git.alpinelinux.org/aports
> 7445adce501f8473efdb93b17b5eaf2f1445ed4c)
>
>
> Also failed for;
>
> # grep FAIL dm.log/summary | grep -v alpine
> alt:p8: FAIL
>clang version 3.8.0 (tags/RELEASE_380/final)
> alt:p9: FAIL
>clang version 7.0.1
> amazonlinux:1: FAIL
>clang version 3.6.2 (tags/RELEASE_362/final)
> amazonlinux:2: FAIL
>clang version 7.0.1 (Amazon Linux 2 7.0.1-1.amzn2.0.2)
> #
Thanks, I added a __GCC_ASM_FLAG_OUTPUTS__ guard:
https://lore.kernel.org/lkml/20200729220034.1337168-1-irog...@google.com/T/#u
Ian
Re: [PATCH net-next] hinic: add generating mailbox random index support
On Wed, 29 Jul 2020 08:59:19 +0800 Luo bin wrote: > add support to generate mailbox random id for VF to ensure that > the mailbox message from VF is valid and PF should check whether > the cmd from VF is supported before passing it to hw. This is hard to review. I don't see how the addition of hinic_mbox_check_cmd_valid() correlates to the random id thing. Please split this into two or more patches making one logical change each.
[PATCH v2] perf bench: Add benchmark of find_next_bit
for_each_set_bit, or similar functions like for_each_cpu, may be hot
within the kernel. If many bits were set then one could imagine on
Intel a "bt" instruction with every bit may be faster than the function
call and word length find_next_bit logic. Add a benchmark to measure
this.
This benchmark on AMD rome and Intel skylakex shows "bt" is not a good
option except for very small bitmaps.
Signed-off-by: Ian Rogers
---
tools/perf/bench/Build| 1 +
tools/perf/bench/bench.h | 1 +
tools/perf/bench/find-bit-bench.c | 135 ++
tools/perf/builtin-bench.c| 1 +
4 files changed, 138 insertions(+)
create mode 100644 tools/perf/bench/find-bit-bench.c
diff --git a/tools/perf/bench/Build b/tools/perf/bench/Build
index 768e408757a0..fb114bca3a8d 100644
--- a/tools/perf/bench/Build
+++ b/tools/perf/bench/Build
@@ -10,6 +10,7 @@ perf-y += epoll-wait.o
perf-y += epoll-ctl.o
perf-y += synthesize.o
perf-y += kallsyms-parse.o
+perf-y += find-bit-bench.o
perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-lib.o
perf-$(CONFIG_X86_64) += mem-memcpy-x86-64-asm.o
diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 61cae4966cae..3291b0fe 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -35,6 +35,7 @@ int bench_sched_messaging(int argc, const char **argv);
int bench_sched_pipe(int argc, const char **argv);
int bench_mem_memcpy(int argc, const char **argv);
int bench_mem_memset(int argc, const char **argv);
+int bench_mem_find_bit(int argc, const char **argv);
int bench_futex_hash(int argc, const char **argv);
int bench_futex_wake(int argc, const char **argv);
int bench_futex_wake_parallel(int argc, const char **argv);
diff --git a/tools/perf/bench/find-bit-bench.c
b/tools/perf/bench/find-bit-bench.c
new file mode 100644
index ..fa90f3e9d368
--- /dev/null
+++ b/tools/perf/bench/find-bit-bench.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Benchmark find_next_bit and related bit operations.
+ *
+ * Copyright 2020 Google LLC.
+ */
+#include
+#include "bench.h"
+#include "../util/stat.h"
+#include
+#include
+#include
+#include
+
+static unsigned int outer_iterations = 5;
+static unsigned int inner_iterations = 10;
+
+static const struct option options[] = {
+ OPT_UINTEGER('i', "outer-iterations", _iterations,
+ "Number of outerer iterations used"),
+ OPT_UINTEGER('j', "inner-iterations", _iterations,
+ "Number of outerer iterations used"),
+ OPT_END()
+};
+
+static const char *const bench_usage[] = {
+ "perf bench mem find_bit ",
+ NULL
+};
+
+static unsigned int accumulator;
+static unsigned int use_of_val;
+
+static noinline void workload(int val)
+{
+ use_of_val += val;
+ accumulator++;
+}
+
+#if (defined(__i386__) || defined(__x86_64__)) &&
defined(__GCC_ASM_FLAG_OUTPUTS__)
+static bool asm_test_bit(long nr, const unsigned long *addr)
+{
+ bool oldbit;
+
+ asm volatile("bt %2,%1"
+: "=@ccc" (oldbit)
+: "m" (*(unsigned long *)addr), "Ir" (nr) : "memory");
+
+ return oldbit;
+}
+#else
+#define asm_test_bit test_bit
+#endif
+
+static int do_for_each_set_bit(unsigned int num_bits)
+{
+ unsigned long *to_test = bitmap_alloc(num_bits);
+ struct timeval start, end, diff;
+ u64 runtime_us;
+ struct stats fb_time_stats, tb_time_stats;
+ double time_average, time_stddev;
+ unsigned int bit, i, j;
+ unsigned int set_bits, skip;
+ unsigned int old;
+
+ init_stats(_time_stats);
+ init_stats(_time_stats);
+
+ for (set_bits = 1; set_bits <= num_bits; set_bits <<= 1) {
+ bitmap_zero(to_test, num_bits);
+ skip = num_bits / set_bits;
+ for (i = 0; i < num_bits; i += skip)
+ set_bit(i, to_test);
+
+ for (i = 0; i < outer_iterations; i++) {
+ old = accumulator;
+ gettimeofday(, NULL);
+ for (j = 0; j < inner_iterations; j++) {
+ for_each_set_bit(bit, to_test, num_bits)
+ workload(bit);
+ }
+ gettimeofday(, NULL);
+ assert(old + (inner_iterations * set_bits) ==
accumulator);
+ timersub(, , );
+ runtime_us = diff.tv_sec * USEC_PER_SEC + diff.tv_usec;
+ update_stats(_time_stats, runtime_us);
+
+ old = accumulator;
+ gettimeofday(, NULL);
+ for (j = 0; j < inner_iterations; j++) {
+ for (bit = 0; bit < num_bits; bit++) {
+ if (asm_test_bit(bit, to_test))
+ workload(bit);
+
Re: [PATCH -next] drm/amd/powerplay: Remove unneeded cast from memory allocation
Applied. Thanks! Alex On Wed, Jul 29, 2020 at 9:11 AM Li Heng wrote: > > Remove casting the values returned by memory allocation function. > > Coccinelle emits WARNING: > > ./drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c:893:37-46: > WARNING: casting value returned by memory allocation function to (PPTable_t > *) is useless. > > Signed-off-by: Li Heng > --- > drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c > b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c > index 7a7f15d..f56a3cb 100644 > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c > @@ -890,7 +890,7 @@ static int init_powerplay_table_information( > power_saving_clock_count); > } > > - pptable_information->smc_pptable = (PPTable_t > *)kmalloc(sizeof(PPTable_t), GFP_KERNEL); > + pptable_information->smc_pptable = kmalloc(sizeof(PPTable_t), > GFP_KERNEL); > if (pptable_information->smc_pptable == NULL) > return -ENOMEM; > > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v6 5/6] iommu/uapi: Handle data and argsz filled by users
On Tue, 28 Jul 2020 13:19:44 -0600
Alex Williamson wrote:
> On Thu, 23 Jul 2020 10:25:39 -0700
> Jacob Pan wrote:
>
> > IOMMU user APIs are responsible for processing user data. This patch
> > changes the interface such that user pointers can be passed into
> > IOMMU code directly. Separate kernel APIs without user pointers are
> > introduced for in-kernel users of the UAPI functionality.
> >
> > IOMMU UAPI data has a user filled argsz field which indicates the
> > data length of the structure. User data is not trusted, argsz must
> > be validated based on the current kernel data size, mandatory data
> > size, and feature flags.
> >
> > User data may also be extended, resulting in possible argsz
> > increase. Backward compatibility is ensured based on size and flags
> > (or the functional equivalent fields) checking.
> >
> > This patch adds sanity checks in the IOMMU layer. In addition to
> > argsz, reserved/unused fields in padding, flags, and version are
> > also checked. Details are documented in
> > Documentation/userspace-api/iommu.rst
> >
> > Signed-off-by: Liu Yi L
> > Signed-off-by: Jacob Pan
> > ---
> > drivers/iommu/iommu.c | 202
> > --
> > include/linux/iommu.h | 28 --- 2 files changed, 213
> > insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 3a913ce94a3d..1ce2a61058c6 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -1950,33 +1950,219 @@ int iommu_attach_device(struct
> > iommu_domain *domain, struct device *dev) }
> > EXPORT_SYMBOL_GPL(iommu_attach_device);
> >
> > +/*
> > + * Check flags and other user provided data for valid
> > combinations. We also
> > + * make sure no reserved fields or unused flags are set. This is
> > to ensure
> > + * not breaking userspace in the future when these fields or flags
> > are used.
> > + */
> > +static int iommu_check_cache_invl_data(struct
> > iommu_cache_invalidate_info *info) +{
> > + u32 mask;
> > + int i;
> > +
> > + if (info->version != IOMMU_CACHE_INVALIDATE_INFO_VERSION_1)
> > + return -EINVAL;
> > +
> > + mask = (1 << IOMMU_CACHE_INV_TYPE_NR) - 1;
> > + if (info->cache & ~mask)
> > + return -EINVAL;
> > +
> > + if (info->granularity >= IOMMU_INV_GRANU_NR)
> > + return -EINVAL;
> > +
> > + switch (info->granularity) {
> > + case IOMMU_INV_GRANU_ADDR:
> > + if (info->cache & IOMMU_CACHE_INV_TYPE_PASID)
> > + return -EINVAL;
> > +
> > + mask = IOMMU_INV_ADDR_FLAGS_PASID |
> > + IOMMU_INV_ADDR_FLAGS_ARCHID |
> > + IOMMU_INV_ADDR_FLAGS_LEAF;
> > +
> > + if (info->granu.addr_info.flags & ~mask)
> > + return -EINVAL;
> > + break;
> > + case IOMMU_INV_GRANU_PASID:
> > + mask = IOMMU_INV_PASID_FLAGS_PASID |
> > + IOMMU_INV_PASID_FLAGS_ARCHID;
> > + if (info->granu.pasid_info.flags & ~mask)
> > + return -EINVAL;
> > +
> > + break;
> > + case IOMMU_INV_GRANU_DOMAIN:
> > + if (info->cache & IOMMU_CACHE_INV_TYPE_DEV_IOTLB)
> > + return -EINVAL;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + /* Check reserved padding fields */
> > + for (i = 0; i < 6; i++) {
>
> We could use sizeof(info->padding) here to avoid future issues
> relative to the number of padding bytes.
>
yes, much better.
> > + if (info->padding[i])
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > int iommu_uapi_cache_invalidate(struct iommu_domain *domain,
> > struct device *dev,
> > - struct iommu_cache_invalidate_info
> > *inv_info)
> > + void __user *uinfo)
> > {
> > + struct iommu_cache_invalidate_info inv_info = { 0 };
> > + u32 minsz;
> > + int ret = 0;
> > +
> > if (unlikely(!domain->ops->cache_invalidate))
> > return -ENODEV;
> >
> > - return domain->ops->cache_invalidate(domain, dev,
> > inv_info);
> > + /*
> > +* No new spaces can be added before the variable sized
> > union, the
> > +* minimum size is the offset to the union.
> > +*/
> > + minsz = offsetof(struct iommu_cache_invalidate_info,
> > granu); +
> > + /* Copy minsz from user to get flags and argsz */
> > + if (copy_from_user(_info, uinfo, minsz))
> > + return -EFAULT;
> > +
> > + /* Fields before variable size union is mandatory */
> > + if (inv_info.argsz < minsz)
> > + return -EINVAL;
> > +
> > + /* PASID and address granu require additional info beyond
> > minsz */
> > + if (inv_info.argsz == minsz &&
> > + ((inv_info.granularity == IOMMU_INV_GRANU_PASID) ||
> > + (inv_info.granularity ==
> > IOMMU_INV_GRANU_ADDR)))
> > + return -EINVAL;
> > +
> > + if
Re: [PATCH] lib: kunit: add test_min_heap test conversion to KUnit
Hi Peter,
On Wed, Jul 29, 2020 at 5:39 PM wrote:
>
> On Wed, Jul 29, 2020 at 05:11:46PM -0300, Vitor Massaru Iha wrote:
> > This adds the conversion of the runtime tests of test_min_heap,
> > from `lib/test_min_heap.c` to KUnit tests.
> >
> > Please apply this commit first (linux-kselftest/kunit-fixes):
> > 3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing
> > of CONFIG options with space
> >
> > Signed-off-by: Vitor Massaru Iha
> > ---
> > lib/Kconfig.debug | 29 --
> > lib/Makefile | 2 +-
> > lib/{test_min_heap.c => min_heap_kunit.c} | 117 --
> > 3 files changed, 83 insertions(+), 65 deletions(-)
> > rename lib/{test_min_heap.c => min_heap_kunit.c} (60%)
>
> So where's the win? What's KUnit, why should I care and more lines.
KUnit is a unit testing and mocking framework for the Linux kernel. [0]
In Kconfig.debug you only have some more information about KUnit.
If the number of lines is a parameter that should be considered, I can
change sections like this
- if (last > values[0]) {
- pr_err("error: expected %d <= %d\n", last,
- values[0]);
- err++;
- }
+ KUNIT_EXPECT_FALSE_MSG(context,
+ last > values[0],
+ "expected %d <= %d\n",
+ last, values[0]);
To this:
- if (last > values[0]) {
- pr_err("error: expected %d <= %d\n", last,
- values[0]);
- err++;
- }
+ KUNIT_EXPECT_FALSE_MSG(context, last >
values[0], "expected %d <= %d\n", last, values[0]);
And from this:
+static struct kunit_case __refdata min_heap_test_cases[] = {
+ KUNIT_CASE(test_heapify_all_true),
+ KUNIT_CASE(test_heapify_all_false),
+ KUNIT_CASE(test_heap_push_true),
+ KUNIT_CASE(test_heap_push_false),
+ KUNIT_CASE(test_heap_pop_push_true),
+ KUNIT_CASE(test_heap_pop_push_false),
+ {}
To this:
+static struct kunit_case __refdata min_heap_test_cases[] = {
+ KUNIT_CASE(test_min_heap),
+ {}
I did the latter this way to be more informative, but if the goal is
to reduce lines of code, this is possible.
The results can be seen this way:
This is an excerpt from the test.log with the result in TAP format:
[snip]
ok 5 - example
# Subtest: min-heap
1..6
ok 1 - test_heapify_all_true
ok 2 - test_heapify_all_false
ok 3 - test_heap_push_true
ok 4 - test_heap_push_false
ok 5 - test_heap_pop_push_true
ok 6 - test_heap_pop_push_false
[snip]
And this from kunit-tool:
[snip]
[18:43:32]
[18:43:32] [PASSED] min-heap
[18:43:32] [PASSED] test_heapify_all_true
[18:43:32] [PASSED] test_heapify_all_false
[18:43:32] [PASSED] test_heap_push_true
[18:43:32] [PASSED] test_heap_push_false
[18:43:32] [PASSED] test_heap_pop_push_true
[18:43:32] [PASSED] test_heap_pop_push_false
[18:43:32]
[18:43:32] Testing complete. 20 tests run. 0 failed. 0 crashed.
[18:43:32] Elapsed time: 9.758s total, 0.001s configuring, 6.012s
building, 0.000s running
[snip]
BR,
Vitor
[0]
https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html#what-is-kunit
linux-next: Fixes tag needs some work in the powerpc tree
Hi all,
In commit
443359aebce0 ("powerpc/perf: Fix MMCRA_BHRB_DISABLE define for binutils <
2.28")
Fixes tag
Fixes: 9908c826d5ed ("Add Power10 PMU feature to DT CPU features")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
Just a hint for the future.
--
Cheers,
Stephen Rothwell
pgp8Rx7kLbcHU.pgp
Description: OpenPGP digital signature
Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
Applied. Thanks!
Alex
On Wed, Jul 29, 2020 at 4:11 AM Christian König
wrote:
>
> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> > Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> > amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> > when `size` is greater than 356.
> >
> > In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
> > unfortunately does not initialize that 4-byte hole. Fix it by using
> > memset() instead.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
> > Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> > Suggested-by: Dan Carpenter
> > Signed-off-by: Peilin Ye
>
> Reviewed-by: Christian König
>
> I can't count how many of those we have fixed over the years.
>
> At some point we should probably document that using "= {}" or "= { 0 }"
> in the kernel is a really bad idea and should be avoided.
>
> Thanks,
> Christian.
>
> > ---
> > $ pahole -C "drm_amdgpu_info_device" drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o
> > struct drm_amdgpu_info_device {
> > __u32 device_id;/* 0 4 */
> > __u32 chip_rev; /* 4 4 */
> > __u32 external_rev; /* 8 4 */
> > __u32 pci_rev; /*12 4 */
> > __u32 family; /*16 4 */
> > __u32 num_shader_engines; /*20 4 */
> > __u32 num_shader_arrays_per_engine; /*24
> > 4 */
> > __u32 gpu_counter_freq; /*28 4 */
> > __u64 max_engine_clock; /*32 8 */
> > __u64 max_memory_clock; /*40 8 */
> > __u32 cu_active_number; /*48 4 */
> > __u32 cu_ao_mask; /*52 4 */
> > __u32 cu_bitmap[4][4]; /*5664 */
> > /* --- cacheline 1 boundary (64 bytes) was 56 bytes ago --- */
> > __u32 enabled_rb_pipes_mask; /* 120 4 */
> > __u32 num_rb_pipes; /* 124 4 */
> > /* --- cacheline 2 boundary (128 bytes) --- */
> > __u32 num_hw_gfx_contexts; /* 128 4 */
> > __u32 _pad; /* 132 4 */
> > __u64 ids_flags;/* 136 8 */
> > __u64 virtual_address_offset; /* 144 8 */
> > __u64 virtual_address_max; /* 152 8 */
> > __u32 virtual_address_alignment; /* 160 4
> > */
> > __u32 pte_fragment_size;/* 164 4 */
> > __u32 gart_page_size; /* 168 4 */
> > __u32 ce_ram_size; /* 172 4 */
> > __u32 vram_type;/* 176 4 */
> > __u32 vram_bit_width; /* 180 4 */
> > __u32 vce_harvest_config; /* 184 4 */
> > __u32 gc_double_offchip_lds_buf; /* 188 4
> > */
> > /* --- cacheline 3 boundary (192 bytes) --- */
> > __u64 prim_buf_gpu_addr;/* 192 8 */
> > __u64 pos_buf_gpu_addr; /* 200 8 */
> > __u64 cntl_sb_buf_gpu_addr; /* 208 8 */
> > __u64 param_buf_gpu_addr; /* 216 8 */
> > __u32 prim_buf_size;/* 224 4 */
> > __u32 pos_buf_size; /* 228 4 */
> > __u32 cntl_sb_buf_size; /* 232 4 */
> > __u32 param_buf_size; /* 236 4 */
> > __u32 wave_front_size; /* 240 4 */
> > __u32 num_shader_visible_vgprs; /* 244 4 */
> > __u32 num_cu_per_sh;/* 248 4 */
> > __u32 num_tcc_blocks; /* 252 4 */
> > /* --- cacheline 4 boundary (256 bytes) --- */
> > __u32 gs_vgt_table_depth; /* 256 4 */
> > __u32 gs_prim_buffer_depth; /* 260 4 */
> > __u32 max_gs_waves_per_vgt; /* 264 4 */
> > __u32 _pad1;/* 268 4 */
> > __u32 cu_ao_bitmap[4][4]; /* 27264 */
> > /* --- cacheline 5 boundary (320 bytes) was 16 bytes ago --- */
> > __u64 high_va_offset; /*
[PATCH] arm64/alternatives: move length validation inside the subsection
Commit f7b93d42945c ("arm64/alternatives: use subsections for replacement
sequences") breaks LLVM's integrated assembler, because due to its
one-pass design, it cannot compute instruction sequence lengths before the
layout for the subsection has been finalized. This change fixes the build
by moving the .org directives inside the subsection, so they are processed
after the subsection layout is known.
Link: https://github.com/ClangBuiltLinux/linux/issues/1078
Cc: # 4.14+
Signed-off-by: Sami Tolvanen
---
arch/arm64/include/asm/alternative.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/alternative.h
b/arch/arm64/include/asm/alternative.h
index 12f0eb56a1cc..619db9b4c9d5 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -77,9 +77,9 @@ static inline void apply_alternatives_module(void *start,
size_t length) { }
"663:\n\t" \
newinstr "\n" \
"664:\n\t" \
- ".previous\n\t" \
".org . - (664b-663b) + (662b-661b)\n\t" \
- ".org . - (662b-661b) + (664b-663b)\n"\
+ ".org . - (662b-661b) + (664b-663b)\n\t" \
+ ".previous\n" \
".endif\n"
#define __ALTERNATIVE_CFG_CB(oldinstr, feature, cfg_enabled, cb) \
base-commit: 6ba1b005ffc388c2aeaddae20da29e4810dea298
--
2.28.0.163.g6104cc2f0b6-goog
Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush
On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen wrote: > > Melissa Wen > > On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter wrote: > > > > On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen wrote: > > > > > > On 07/25, Daniel Vetter wrote: > > > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang wrote: > > > > > > > > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote: > > > > > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen > > > > > > wrote: > > > > > > > > > > > > > > On 07/22, dan...@ffwll.ch wrote: > > > > > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote: > > > > > > > > > This patch adds a missing drm_crtc_vblank_put op to the pair > > > > > > > > > drm_crtc_vblank_get/put (inc/decrement counter to guarantee > > > > > > > > > vblanks). > > > > > > > > > > > > > > > > > > It clears the execution of the following kms_cursor_crc > > > > > > > > > subtests: > > > > > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, > > > > > > > > > off-screen, sliding, > > > > > > > > >random, fast-moving])] - successful when running > > > > > > > > > individually. > > > > > > > > > 2. pipe-A-cursor-dpms passes again > > > > > > > > > 3. pipe-A-cursor-suspend also passes > > > > > > > > > > > > > > > > > > The issue was initially tracked in the sequential execution > > > > > > > > > of IGT > > > > > > > > > kms_cursor_crc subtest: when running the test sequence or one > > > > > > > > > of its > > > > > > > > > subtests twice, the odd execs complete and the pairs get > > > > > > > > > stuck in an > > > > > > > > > endless wait. In the IGT code, calling a wait_for_vblank > > > > > > > > > before the start > > > > > > > > > of CRC capture prevented the busy-wait. But the problem > > > > > > > > > persisted in the > > > > > > > > > pipe-A-cursor-dpms and -suspend subtests. > > > > > > > > > > > > > > > > > > Checking the history, the pipe-A-cursor-dpms subtest was > > > > > > > > > successful when, > > > > > > > > > in vkms_atomic_commit_tail, instead of using the flip_done > > > > > > > > > op, it used > > > > > > > > > wait_for_vblanks. Another way to prevent blocking was > > > > > > > > > wait_one_vblank when > > > > > > > > > enabling crtc. However, in both cases, pipe-A-cursor-suspend > > > > > > > > > persisted > > > > > > > > > blocking in the 2nd start of CRC capture, which may indicate > > > > > > > > > that > > > > > > > > > something got stuck in the step of CRC setup. Indeed, > > > > > > > > > wait_one_vblank in > > > > > > > > > the crc setup was able to sync things and free all > > > > > > > > > kms_cursor_crc > > > > > > > > > subtests. > > > > > > > > > > > > > > > > > > Tracing and comparing a clean run with a blocked one: > > > > > > > > > - in a clean one, vkms_crtc_atomic_flush enables vblanks; > > > > > > > > > - when blocked, only in next op, vkms_crtc_atomic_enable, the > > > > > > > > > vblanks > > > > > > > > > started. Moreover, a series of vkms_vblank_simulate flow out > > > > > > > > > until > > > > > > > > > disabling vblanks. > > > > > > > > > Also watching the steps of vkms_crtc_atomic_flush, when the > > > > > > > > > very first > > > > > > > > > drm_crtc_vblank_get returned an error, the subtest crashed. > > > > > > > > > On the other > > > > > > > > > hand, when vblank_get succeeded, the subtest completed. > > > > > > > > > Finally, checking > > > > > > > > > the flush steps: it increases counter to hold a vblank > > > > > > > > > reference (get), > > > > > > > > > but there isn't a op to decreased it and release vblanks > > > > > > > > > (put). > > > > > > > > > > > > > > > > > > Cc: Daniel Vetter > > > > > > > > > Cc: Rodrigo Siqueira > > > > > > > > > Cc: Haneen Mohammed > > > > > > > > > Signed-off-by: Melissa Wen > > > > > > > > > --- > > > > > > > > > drivers/gpu/drm/vkms/vkms_crtc.c | 1 + > > > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c > > > > > > > > > b/drivers/gpu/drm/vkms/vkms_crtc.c > > > > > > > > > index ac85e17428f8..a99d6b4a92dd 100644 > > > > > > > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c > > > > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c > > > > > > > > > @@ -246,6 +246,7 @@ static void vkms_crtc_atomic_flush(struct > > > > > > > > > drm_crtc *crtc, > > > > > > > > > > > > > > > > > > spin_unlock(>dev->event_lock); > > > > > > > > > > > > > > > > > > + drm_crtc_vblank_put(crtc); > > > > > > > > > > > > > > > > Uh so I reviewed this a bit more carefully now, and I dont > > > > > > > > think this is > > > > > > > > the correct bugfix. From the kerneldoc of > > > > > > > > drm_crtc_arm_vblank_event(): > > > > > > > > > > > > > > > > * Caller must hold a vblank reference for the event @e > > > > > > > > acquired by a > > > > > > > > * drm_crtc_vblank_get(), which will be dropped when the next > > > > > > > > vblank arrives. > > > > > > > > > > > > > > > > So when we call
Re: [PATCH 1/1] netfilter: nat: add range checks for access to nf_nat_l[34]protos[]
Hi Will, On Mon, Jul 27, 2020 at 05:57:20PM +, Will McVicker wrote: > The indexes to the nf_nat_l[34]protos arrays come from userspace. So we > need to make sure that before indexing the arrays, we verify the index > is within the array bounds in order to prevent an OOB memory access. > Here is an example kernel panic on 4.14.180 when userspace passes in an > index greater than NFPROTO_NUMPROTO. > > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > Modules linked in:... > Process poc (pid: 5614, stack limit = 0xa3933121) > CPU: 4 PID: 5614 Comm: poc Tainted: G S W O4.14.180-g051355490483 > Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150 Google Inc. MSM > task: 2a3dfffe task.stack: a3933121 > pc : __cfi_check_fail+0x1c/0x24 > lr : __cfi_check_fail+0x1c/0x24 > ... > Call trace: > __cfi_check_fail+0x1c/0x24 > name_to_dev_t+0x0/0x468 > nfnetlink_parse_nat_setup+0x234/0x258 If this oops is only triggerable from userspace, I think a sanity check in nfnetlink_parse_nat_setup should suffice to reject unsupported layer 3 and layer 4 protocols. I mean, in this patch I see more chunks in the packet path, such as nf_nat_l3proto_ipv4 that should never happen. I would just fix the userspace ctnetlink path. BTW, do you have a Fixes: tag for this? This will be useful for -stable maintainer to pick up this fix. Thanks.
Re: [git pull] drm fixes for 5.8-rc8
The pull request you sent on Wed, 29 Jul 2020 14:44:16 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-29 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c2f3850df7f95537e79c561f7be49df2e4ad8060 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] include: Replace HTTP links with HTTPS ones
On Wed, 29 Jul 2020 14:21:12 -0700 Kees Cook wrote: > On Sun, Jul 26, 2020 at 01:01:17PM +0200, Alexander A. Klimov wrote: > > Rationale: > > Reduces attack surface on kernel devs opening the links for MITM > > as HTTPS traffic is much harder to manipulate. > > > > Signed-off-by: Alexander A. Klimov > > Reviewed-by: Kees Cook > > Jon, do you want to take this? I added this to -mm yesterday.
Re: [GIT PULL] Audit fixes for v5.8 (#1)
The pull request you sent on Wed, 29 Jul 2020 10:54:14 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git > tags/audit-pr-20200729 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d3590ebf6f91350192737dd1d1b219c05277f067 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] 9p update for 5.8
The pull request you sent on Wed, 29 Jul 2020 08:33:06 +0200: > https://github.com/martinetd/linux tags/9p-for-5.8-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/21391520cbb597823050ac1bc343a0df3222ac90 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: kernel BUG at mm/internal.h:LINE! (2)
On Wed, 29 Jul 2020 13:04:21 -0700 syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:68845a55 Merge branch 'akpm' into master (patches from And.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=17c86c5490 > kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 > dashboard link: https://syzkaller.appspot.com/bug?extid=f62749569eab36774dc5 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+f62749569eab36774...@syzkaller.appspotmail.com > > vma 888000153210 start 000770077000 end 00077000 > next 00077000 prev 07070707 mm 00077000 > prot 7770077000 anon_vma vm_ops 885cecc0 > pgoff 0 file 88809e09a7c0 private_data > flags: 0x0() Well that is one messed up VMA. Something in the kernel scribbled on some memory. Possibly scribbled on the vma itself, possibly scribbled somewhere in the pointer chase which led us to the vma. Interestingly, vm_ops (0x885cecc0) appears to be a valid address. Would it be possible to look up that symbol in your kernel, see if it points at something interesting? But don't try too hard - I doubt if we'll learn much from it :( > [ cut here ] > kernel BUG at mm/internal.h:401! > invalid opcode: [#1] PREEMPT SMP KASAN > CPU: 0 PID: 1676 Comm: kswapd0 Not tainted 5.8.0-rc6-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:vma_address mm/internal.h:401 [inline] > RIP: 0010:vma_address mm/internal.h:393 [inline] > RIP: 0010:rmap_walk_file+0x6a4/0xbf0 mm/rmap.c:1921 > Code: e8 91 20 cc ff 48 83 eb 01 48 89 e8 48 29 d8 48 c1 f8 06 48 01 44 24 18 > e9 1a fb ff ff e8 74 20 cc ff 4c 89 e7 e8 95 e3 f9 ff <0f> 0b e8 65 20 cc ff > 48 8b 44 24 10 4c 8d 68 78 4c 89 ef e8 b4 8a > RSP: 0018:c90006987598 EFLAGS: 00010287 > RAX: 010f RBX: 00077019e000 RCX: > RDX: 8880a425e540 RSI: 815d4eb7 RDI: f52000d30e8e > RBP: ea00021eac40 R08: 010f R09: 8880ae6318e7 > R10: R11: R12: 888000153210 > R13: dc00 R14: 000770077000 R15: 00077000 > FS: () GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 00788070 CR3: 00020b00c000 CR4: 001426f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > rmap_walk+0x105/0x190 mm/rmap.c:1946 > page_referenced+0x417/0x4b0 mm/rmap.c:888 > shrink_active_list+0x3a6/0x1350 mm/vmscan.c:2061 > shrink_list mm/vmscan.c:2167 [inline] > shrink_lruvec+0x842/0x10f0 mm/vmscan.c:2467 > shrink_node_memcgs mm/vmscan.c:2656 [inline] > shrink_node+0x4b0/0x1b60 mm/vmscan.c:2770 > kswapd_shrink_node mm/vmscan.c:3517 [inline] > balance_pgdat+0x72f/0x10d0 mm/vmscan.c:3675 > kswapd+0x5a5/0xe70 mm/vmscan.c:3932 > kthread+0x3b5/0x4a0 kernel/kthread.c:291 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 > > ... >
Re: [PATCH v2 1/5] perf record: Set PERF_RECORD_PERIOD if attr->freq is set.
On Wed, Jul 29, 2020 at 11:52 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Tue, Jul 28, 2020 at 01:57:30AM -0700, Ian Rogers escreveu:
> > From: David Sharp
> >
> > evsel__config() would only set PERF_RECORD_PERIOD if it set attr->freq
>
> There is no such thing as 'PERF_RECORD_PERIOD', its PERF_SAMPLE_PERIOD,
> also...
>
> > from perf record options. When it is set by libpfm events, it would not
> > get set. This changes evsel__config to see if attr->freq is set outside of
> > whether or not it changes attr->freq itself.
> >
> > Signed-off-by: David Sharp
> > Signed-off-by: Ian Rogers
> > ---
> > tools/perf/util/evsel.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > index ef802f6d40c1..811f538f7d77 100644
> > --- a/tools/perf/util/evsel.c
> > +++ b/tools/perf/util/evsel.c
> > @@ -979,13 +979,18 @@ void evsel__config(struct evsel *evsel, struct
> > record_opts *opts,
> > if (!attr->sample_period || (opts->user_freq != UINT_MAX ||
> >opts->user_interval != ULLONG_MAX)) {
> > if (opts->freq) {
> > - evsel__set_sample_bit(evsel, PERIOD);
> > attr->freq = 1;
> > attr->sample_freq = opts->freq;
> > } else {
> > attr->sample_period = opts->default_interval;
> > }
> > }
> > + /*
> > + * If attr->freq was set (here or earlier), ask for period
> > + * to be sampled.
> > + */
> > + if (attr->freq)
> > + evsel__set_sample_bit(evsel, PERIOD);
>
> Why can't the libpfm code set opts?
>
> With this patch we will end up calling evsel__set_sample_bit(evsel,
> PERIOD) twice, which isn't a problem but looks strange.
Thanks Arnaldo! The case I was looking at was something like:
perf record --pfm-events cycles:freq=1000
For regular events this would be:
perf record -e cycles/freq=1000/
With libpfm4 events the perf_event_attr is set up (a public API in
linux/perf_event.h) and then parse_events__add_event is used (an
internal API) to make the evsel and this added to the evlist
(parse_libpfm_events_option). This is similar to the parse_events
function except rather than set up a perf_event_attr the regular
parsing sets up config terms that are then applied to evsel and attr
later in evsel__config, via evsel__apply_config_terms.
I think we can update this change so that in pfm.c after
parse_events__add_event we do:
if (attr.freq)
evsel__set_sample_bit(evsel, PERIOD);
This code could also be part of parse_events__add_event. I think the
intent in placing this code here was that it is close to the similar
evsel__apply_config_terms and setting of sample bits in the evsel. The
logic here is already dependent on reading the attr->sample_period.
I'm not sure I follow the double setting case - I think that is only
possible with a config term or with period_set (-P).
Thanks,
Ian
> - Arnaldo
>
> >
> > if (opts->no_samples)
> > attr->sample_freq = 0;
> > --
> > 2.28.0.163.g6104cc2f0b6-goog
> >
>
> --
>
> - Arnaldo
[PATCH 3/3] MAINTAINERS: bcm-vk: add maintainer for Broadcom VK Driver
Add maintainer entry for new Broadcom VK Driver Signed-off-by: Scott Branden --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f0569cf304ca..10e4e286baeb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3658,6 +3658,13 @@ L: net...@vger.kernel.org S: Supported F: drivers/net/ethernet/broadcom/tg3.* +BROADCOM VK DRIVER +M: Scott Branden +L: bcm-kernel-feedback-l...@broadcom.com +S: Supported +F: drivers/misc/bcm-vk/ +F: include/uapi/linux/misc/bcm_vk.h + BROCADE BFA FC SCSI DRIVER M: Anil Gurumurthy M: Sudarsana Kalluru -- 2.17.1
[PATCH 2/3] misc: bcm-vk: add Broadcom VK driver
Add Broadcom VK driver offload engine. This driver interfaces to the VK PCIe offload engine to perform should offload functions as video transcoding on multiple streams in parallel. VK device is booted from files loaded using request_firmware_into_buf mechanism. After booted card status is updated and messages can then be sent to the card. Such messages contain scatter gather list of addresses to pull data from the host to perform operations on. Co-developed-by: Desmond Yan Signed-off-by: Desmond Yan Co-developed-by: James Hu Signed-off-by: James Hu Signed-off-by: Scott Branden --- drivers/misc/Kconfig |1 + drivers/misc/Makefile|1 + drivers/misc/bcm-vk/Kconfig | 29 + drivers/misc/bcm-vk/Makefile | 11 + drivers/misc/bcm-vk/bcm_vk.h | 424 + drivers/misc/bcm-vk/bcm_vk_dev.c | 1369 +++ drivers/misc/bcm-vk/bcm_vk_msg.c | 1507 ++ drivers/misc/bcm-vk/bcm_vk_msg.h | 211 + drivers/misc/bcm-vk/bcm_vk_sg.c | 275 ++ drivers/misc/bcm-vk/bcm_vk_sg.h | 61 ++ drivers/misc/bcm-vk/bcm_vk_tty.c | 365 11 files changed, 4254 insertions(+) create mode 100644 drivers/misc/bcm-vk/Kconfig create mode 100644 drivers/misc/bcm-vk/Makefile create mode 100644 drivers/misc/bcm-vk/bcm_vk.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_tty.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index e1b1ba5e2b92..55d733d3a640 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -469,6 +469,7 @@ source "drivers/misc/genwqe/Kconfig" source "drivers/misc/echo/Kconfig" source "drivers/misc/cxl/Kconfig" source "drivers/misc/ocxl/Kconfig" +source "drivers/misc/bcm-vk/Kconfig" source "drivers/misc/cardreader/Kconfig" source "drivers/misc/habanalabs/Kconfig" source "drivers/misc/uacce/Kconfig" diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index c7bd01ac6291..766837e4b961 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_ECHO)+= echo/ obj-$(CONFIG_CXL_BASE) += cxl/ obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o obj-$(CONFIG_OCXL) += ocxl/ +obj-$(CONFIG_BCM_VK) += bcm-vk/ obj-y += cardreader/ obj-$(CONFIG_PVPANIC) += pvpanic.o obj-$(CONFIG_HABANA_AI)+= habanalabs/ diff --git a/drivers/misc/bcm-vk/Kconfig b/drivers/misc/bcm-vk/Kconfig new file mode 100644 index ..a3a020b19e3b --- /dev/null +++ b/drivers/misc/bcm-vk/Kconfig @@ -0,0 +1,29 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Broadcom VK device +# +config BCM_VK + tristate "Support for Broadcom VK Accelerators" + depends on PCI_MSI + help + Select this option to enable support for Broadcom + VK Accelerators. VK is used for performing + specific offload processing. + This driver enables userspace programs to access these + accelerators via /dev/bcm-vk.N devices. + + If unsure, say N. + +if BCM_VK + +config BCM_VK_QSTATS + bool "VK Queue Statistics" + help + Turn on to enable Queue Statistics. + These are useful for debugging purposes. + Some performance loss by enabling this debug config. + For properly operating PCIe hardware no need to enable this. + + If unsure, say N. + +endif diff --git a/drivers/misc/bcm-vk/Makefile b/drivers/misc/bcm-vk/Makefile new file mode 100644 index ..05cb213ee826 --- /dev/null +++ b/drivers/misc/bcm-vk/Makefile @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for Broadcom VK driver +# + +obj-$(CONFIG_BCM_VK) += bcm_vk.o +bcm_vk-objs := \ + bcm_vk_dev.o \ + bcm_vk_msg.o \ + bcm_vk_sg.o \ + bcm_vk_tty.o diff --git a/drivers/misc/bcm-vk/bcm_vk.h b/drivers/misc/bcm-vk/bcm_vk.h new file mode 100644 index ..e812d65bb8ea --- /dev/null +++ b/drivers/misc/bcm-vk/bcm_vk.h @@ -0,0 +1,424 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright 2018-2020 Broadcom. + */ + +#ifndef BCM_VK_H +#define BCM_VK_H + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "bcm_vk_msg.h" + +#define DRV_MODULE_NAME"bcm-vk" + +/* + * Load Image is completed in two stages: + * + * 1) When the VK device boot-up, M7 CPU runs and executes the BootROM. + * The Secure Boot Loader (SBL) as part of the BootROM will run + * to open up ITCM for host to push BOOT1 image. + * SBL will authenticate the image before jumping to BOOT1 image. + * + * 2) Because BOOT1 image is a secured image, we also called
[PATCH 0/3] Add Broadcom VK driver
This patch series drops previous patches in [1] that were incorporated by Kees Cook into patch series "Introduce partial kernel_read_file() support" [2]. Remaining patches are contained in this series to add Broadcom VK driver. (which depends on request_firmware_into_buf API addition in other patch series [2] being applied first). [1] https://lore.kernel.org/lkml/20200706232309.12010-1-scott.bran...@broadcom.com/ [2] https://lore.kernel.org/lkml/20200729175845.1745471-1-keesc...@chromium.org/ Scott Branden (3): bcm-vk: add bcm_vk UAPI misc: bcm-vk: add Broadcom VK driver MAINTAINERS: bcm-vk: add maintainer for Broadcom VK Driver MAINTAINERS |7 + drivers/misc/Kconfig |1 + drivers/misc/Makefile|1 + drivers/misc/bcm-vk/Kconfig | 29 + drivers/misc/bcm-vk/Makefile | 11 + drivers/misc/bcm-vk/bcm_vk.h | 424 + drivers/misc/bcm-vk/bcm_vk_dev.c | 1369 +++ drivers/misc/bcm-vk/bcm_vk_msg.c | 1507 ++ drivers/misc/bcm-vk/bcm_vk_msg.h | 211 + drivers/misc/bcm-vk/bcm_vk_sg.c | 275 ++ drivers/misc/bcm-vk/bcm_vk_sg.h | 61 ++ drivers/misc/bcm-vk/bcm_vk_tty.c | 365 include/uapi/linux/misc/bcm_vk.h | 99 ++ 13 files changed, 4360 insertions(+) create mode 100644 drivers/misc/bcm-vk/Kconfig create mode 100644 drivers/misc/bcm-vk/Makefile create mode 100644 drivers/misc/bcm-vk/bcm_vk.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_tty.c create mode 100644 include/uapi/linux/misc/bcm_vk.h -- 2.17.1
[PATCH 1/3] bcm-vk: add bcm_vk UAPI
Add user space api for bcm-vk driver.
Signed-off-by: Scott Branden
---
include/uapi/linux/misc/bcm_vk.h | 99
1 file changed, 99 insertions(+)
create mode 100644 include/uapi/linux/misc/bcm_vk.h
diff --git a/include/uapi/linux/misc/bcm_vk.h b/include/uapi/linux/misc/bcm_vk.h
new file mode 100644
index ..783087b7c31f
--- /dev/null
+++ b/include/uapi/linux/misc/bcm_vk.h
@@ -0,0 +1,99 @@
+/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-2-Clause) */
+/*
+ * Copyright 2018-2020 Broadcom.
+ */
+
+#ifndef __UAPI_LINUX_MISC_BCM_VK_H
+#define __UAPI_LINUX_MISC_BCM_VK_H
+
+#include
+#include
+
+#define BCM_VK_MAX_FILENAME 64
+
+struct vk_image {
+ __u32 type; /* Type of image */
+#define VK_IMAGE_TYPE_BOOT1 1 /* 1st stage (load to SRAM) */
+#define VK_IMAGE_TYPE_BOOT2 2 /* 2nd stage (load to DDR) */
+ char filename[BCM_VK_MAX_FILENAME]; /* Filename of image */
+};
+
+struct vk_reset {
+ __u32 arg1;
+ __u32 arg2;
+};
+
+#define VK_MAGIC 0x5e
+
+/* Load image to Valkyrie */
+#define VK_IOCTL_LOAD_IMAGE_IOW(VK_MAGIC, 0x2, struct vk_image)
+
+/* Send Reset to Valkyrie */
+#define VK_IOCTL_RESET _IOW(VK_MAGIC, 0x4, struct vk_reset)
+
+/*
+ * message block - basic unit in the message where a message's size is always
+ *N x sizeof(basic_block)
+ */
+struct vk_msg_blk {
+ __u8 function_id;
+#define VK_FID_TRANS_BUF 5
+#define VK_FID_SHUTDOWN8
+ __u8 size;
+ __u16 trans_id; /* transport id, queue & msg_id */
+ __u32 context_id;
+ __u32 args[2];
+#define VK_CMD_PLANES_MASK 0x000f /* number of planes to up/download */
+#define VK_CMD_UPLOAD 0x0400 /* memory transfer to vk */
+#define VK_CMD_DOWNLOAD0x0500 /* memory transfer from vk */
+#define VK_CMD_MASK0x0f00 /* command mask */
+};
+
+#define VK_BAR_FWSTS 0x41c
+#define VK_BAR_COP_FWSTS 0x428
+/* VK_FWSTS definitions */
+#define VK_FWSTS_RELOCATION_ENTRY BIT(0)
+#define VK_FWSTS_RELOCATION_EXIT BIT(1)
+#define VK_FWSTS_INIT_STARTBIT(2)
+#define VK_FWSTS_ARCH_INIT_DONEBIT(3)
+#define VK_FWSTS_PRE_KNL1_INIT_DONEBIT(4)
+#define VK_FWSTS_PRE_KNL2_INIT_DONEBIT(5)
+#define VK_FWSTS_POST_KNL_INIT_DONEBIT(6)
+#define VK_FWSTS_INIT_DONE BIT(7)
+#define VK_FWSTS_APP_INIT_STARTBIT(8)
+#define VK_FWSTS_APP_INIT_DONE BIT(9)
+#define VK_FWSTS_MASK 0x
+#define VK_FWSTS_READY (VK_FWSTS_INIT_START | \
+VK_FWSTS_ARCH_INIT_DONE | \
+VK_FWSTS_PRE_KNL1_INIT_DONE | \
+VK_FWSTS_PRE_KNL2_INIT_DONE | \
+VK_FWSTS_POST_KNL_INIT_DONE | \
+VK_FWSTS_INIT_DONE | \
+VK_FWSTS_APP_INIT_START | \
+VK_FWSTS_APP_INIT_DONE)
+/* Deinit */
+#define VK_FWSTS_APP_DEINIT_START BIT(23)
+#define VK_FWSTS_APP_DEINIT_DONE BIT(24)
+#define VK_FWSTS_DRV_DEINIT_START BIT(25)
+#define VK_FWSTS_DRV_DEINIT_DONE BIT(26)
+#define VK_FWSTS_RESET_DONEBIT(27)
+#define VK_FWSTS_DEINIT_TRIGGERED (VK_FWSTS_APP_DEINIT_START | \
+VK_FWSTS_APP_DEINIT_DONE | \
+VK_FWSTS_DRV_DEINIT_START | \
+VK_FWSTS_DRV_DEINIT_DONE)
+/* Last nibble for reboot reason */
+#define VK_FWSTS_RESET_REASON_SHIFT28
+#define VK_FWSTS_RESET_REASON_MASK (0xf << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_SYS_PWRUP (0x0 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_MBOX_DB (0x1 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_M7_WDOG (0x2 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_TEMP(0x3 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_FLR (0x4 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_HOT (0x5 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_WARM(0x6 <<
VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_PCI_COLD(0x7 <<
VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_L1 (0x8 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_L0 (0x9 << VK_FWSTS_RESET_REASON_SHIFT)
+#define VK_FWSTS_RESET_UNKNOWN (0xf << VK_FWSTS_RESET_REASON_SHIFT)
+
+#endif /* __UAPI_LINUX_MISC_BCM_VK_H */
--
2.17.1
Re: [PATCH] MAINTAINERS: edac: socfpga: transfer SoCFPGA EDAC maintainership
On 7/29/20 12:45 PM, Dinh Nguyen wrote: Thor Thayer is leaving Intel and will no longer be able to maintain the EDAC for SoCFPGA, thus transfer maintainership to Dinh Nguyen. Signed-off-by: Dinh Nguyen --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index f0569cf304ca..c53fc9febf12 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2466,7 +2466,7 @@ S:Maintained F:drivers/clk/socfpga/ ARM/SOCFPGA EDAC SUPPORT -M: Thor Thayer +M: Dinh Nguyen S:Maintained F:drivers/edac/altera_edac. Acked-by: Thor Thayer
Re: [PATCH] ext4: check superblock mapped prior to get write access
Hello!
On Tue 28-07-20 10:33:53, Xianting Tian wrote:
> One crash issue happened when directly down the network interface,
> which nbd device is connected to. The kernel version is kernel
> 4.14.0-115.
> According to the debug log and call trace, the buffer of ext4
> superblock already unmapped after the network of nbd device down.
> But the code continue to run until crash.
> I checked latest kernel code of 5.8-rc7 based on the call trace,
> no function checked if buffer of ext4 superblock unmapped.
> The patch is similar to commit 742b06b, aim to check superblock
> mapped prior to get write access.
>
> The crash reason described as below:
> struct journal_head *jbd2_journal_add_journal_head(struct buffer_head *bh)
> {
> ... ...
> jbd_lock_bh_journal_head(bh);
> if (buffer_jbd(bh)) {
> jh = bh2jh(bh); <<== jh is null!!!
> } else {
> ... ...
> }
> jh->b_jcount++; <<==crash here
> jbd_unlock_bh_journal_head(bh);
> ... ...
> }
This is the same problem as you've tried to fix in [1] for jbd2. And the
answer is still the same as I mentioned in my reply [2]. This is just
papering over the real problem. Please check whether this still happens
with recent kernel, if yes, we need do find out how there can be
buffer_jbd() buffer with bh->b_private == NULL.
[1]
https://lore.kernel.org/lkml/1595078883-8647-1-git-send-email-xianting_t...@126.com
[2] https://lore.kernel.org/lkml/20200727085706.ge23...@quack2.suse.cz
Honza
>
> Debug code added to __ext4_journal_get_write_access:
> int __ext4_journal_get_write_access(const char *where, unsigned int line,
> handle_t *handle, struct buffer_head *bh)
> {
> int err = 0;
>
> might_sleep();
>
> if (ext4_handle_valid(handle)) {
> struct super_block *sb;
> struct buffer_head *sbh;
>
> sb = handle->h_transaction->t_journal->j_private;
> if (unlikely(ext4_forced_shutdown(EXT4_SB(sb {
> jbd2_journal_abort_handle(handle);
> return -EIO;
> }
>
> sbh = EXT4_SB(sb)->s_sbh;
> if (!buffer_mapped(sbh)) {
> ext4 sb bh not mapped\n"); <<==debug code
> }
>
> err = jbd2_journal_get_write_access(handle, bh);
> if (err)
> ext4_journal_abort_handle(where, line, __func__, bh,
> handle, err);
> }
> return err;
> }
>
> Call trace of crash:
> [ 1715.669527] print_req_error: I/O error, dev nbd3, sector 42211904
>
> [ 1715.674940] ext4 sb bh not mapped <<== debug log, which is added and
> printed by the
> function
> "__ext4_journal_get_write_access"
>
> [ 1715.674946] BUG: unable to handle kernel NULL pointer dereference at
> 0008
> [ 1715.674955] IP: jbd2_journal_add_journal_head+0x9d/0x110 [jbd2]
> [ 1715.674956] PGD 2010004067 P4D 2010004067 PUD 201000b067 PMD 0
> [ 1715.674961] Oops: 0002 [#1] SMP
> [ 1715.675020] task: 8808a4d3dac0 task.stack: c9002e78c000
> [ 1715.675024] RIP: 0010:jbd2_journal_add_journal_head+0x9d/0x110 [jbd2] <==
> the crash is caused
> [ 1715.675025] RSP: 0018:c9002e78fb50 EFLAGS: 00010206
> [ 1715.675026] RAX: RBX: 8816b71cad00 RCX:
>
> [ 1715.675026] RDX: RSI: 8816b71cad00 RDI:
> 8816b71cad00
> [ 1715.675027] RBP: c9002e78fb58 R08: 001b R09:
> 88207f82fe07
> [ 1715.675028] R10: 113d R11: R12:
> 8820223a5ab0
> [ 1715.675028] R13: R14: 8816b71cad00 R15:
> 88196053d930
> [ 1715.675029] FS: 7fc2ce9e9700() GS:88203d74()
> knlGS:
> [ 1715.675030] CS: 0010 DS: ES: CR0: 80050033
> [ 1715.675031] CR2: 0008 CR3: 002016d2c004 CR4:
> 007606e0
> [ 1715.675033] DR0: DR1: DR2:
>
> [ 1715.675034] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 1715.675034] PKRU: 5554
> [ 1715.675035] Call Trace:
> [ 1715.675041] jbd2_journal_get_write_access+0x6c/0xc0 [jbd2]
> [ 1715.675057] __ext4_journal_get_write_access+0x8f/0x120 [ext4]
> [ 1715.675069] ext4_reserve_inode_write+0x7b/0xb0 [ext4]
> [ 1715.675079] ? ext4_dirty_inode+0x48/0x70 [ext4]
> [ 1715.675088] ext4_mark_inode_dirty+0x53/0x1e0 [ext4]
> [ 1715.675096] ? __ext4_journal_start_sb+0x6d/0xf0 [ext4]
> [ 1715.675104] ext4_dirty_inode+0x48/0x70 [ext4]
> [ 1715.675111] __mark_inode_dirty+0x17f/0x350
> [ 1715.675116] generic_update_time+0x87/0xd0
> [ 1715.675119] file_update_time+0xbc/0x110
> [ 1715.675122] ?
[PATCH 4/9] drm/nouveau/kms/fbcon: Fix pm_runtime calls in nouveau_fbcon_output_poll_changed()
Noticed two problems here:
* We're not dropping our runtime PM refs after getting an error
* We're not backing off when pm_runtime_get() indicates that there's
already a resume in progress (-EINPROGRESS) (after which any delayed
fbcon events will get handled anyway)
So, let's fix those.
Signed-off-by: Lyude Paul
Fixes: 7fec8f5379fb ("drm/nouveau/drm/nouveau: Fix deadlock with fb_helper with
async RPM requests")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.19+
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 4d9f3b5ae72d2..b936bf1c14dec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -503,10 +503,7 @@ nouveau_fbcon_output_poll_changed(struct drm_device *dev)
ret = pm_runtime_get(dev->dev);
if (ret == 1 || ret == -EACCES) {
drm_fb_helper_hotplug_event(>helper);
-
- pm_runtime_mark_last_busy(dev->dev);
- pm_runtime_put_autosuspend(dev->dev);
- } else if (ret == 0) {
+ } else if (ret == 0 || ret == -EINPROGRESS) {
/* If the GPU was already in the process of suspending before
* this event happened, then we can't block here as we'll
* deadlock the runtime pmops since they wait for us to
@@ -516,11 +513,15 @@ nouveau_fbcon_output_poll_changed(struct drm_device *dev)
NV_DEBUG(drm, "fbcon HPD event deferred until runtime
resume\n");
fbcon->hotplug_waiting = true;
pm_runtime_put_noidle(drm->dev->dev);
+ goto out;
} else {
DRM_WARN("fbcon HPD event lost due to RPM failure: %d\n",
ret);
}
+ pm_runtime_mark_last_busy(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
+out:
mutex_unlock(>hotplug_lock);
}
--
2.26.2
[PATCH 3/9] drm/nouveau/kms/fbcon: Correct pm_runtime calls in nouveau_fbcon_release()
We want to update the last busy timer for our device and use
pm_runtime_put_autosuspend() here instead so that our GPU can
autosuspend when we're done.
Signed-off-by: Lyude Paul
Fixes: f231976c2e89 ("drm/nouveau/fbcon: take runpm reference when userspace
has an open fd")
Cc: Ben Skeggs
Cc: sta...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.3+
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index fad8030ec1f81..4d9f3b5ae72d2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -200,8 +200,11 @@ static int
nouveau_fbcon_release(struct fb_info *info, int user)
{
struct nouveau_fbdev *fbcon = info->par;
- struct nouveau_drm *drm = nouveau_drm(fbcon->helper.dev);
- pm_runtime_put(drm->dev->dev);
+ struct drm_device *dev = fbcon->helper.dev;
+
+ pm_runtime_mark_last_busy(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
+
return 0;
}
--
2.26.2
[PATCH 6/9] drm/nouveau/kms: Use pm_runtime_put_autosuspend() in hpd_work
Again, we don't have any need to suspend the device synchronously here, and doing so could in theory lead to a deadlock (although it's unlikely since we've called pm_runtime_mark_last_busy() before-hand). Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 63c58f12458c9..cdc5a2200f95e 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -444,7 +444,7 @@ nouveau_display_hpd_work(struct work_struct *work) drm_helper_hpd_irq_event(drm->dev); pm_runtime_mark_last_busy(drm->dev->dev); - pm_runtime_put_sync(drm->dev->dev); + pm_runtime_put_autosuspend(drm->dev->dev); } #ifdef CONFIG_ACPI -- 2.26.2
[PATCH 9/9] drm/nouveau/kms: Handle -EINPROGRESS in nouveau_display_acpi_ntfy()
This isn't an error, this just means there's multiple asynchronous
resume requests going at the same time. Treat it like a success.
Signed-off-by: Lyude Paul
Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events
too early")
Cc: sta...@vger.kernel.org
Cc: Karol Herbst
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.19+
---
drivers/gpu/drm/nouveau/nouveau_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index ad63d4f052deb..691bb8d37759e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -462,10 +462,10 @@ nouveau_display_acpi_ntfy(struct notifier_block *nb,
unsigned long val,
return NOTIFY_DONE;
ret = pm_runtime_get(drm->dev->dev);
- if (ret == 1 || ret == -EACCES) {
- /* If the GPU is already awake, or in a state
-* where we can't wake it up, it can handle
-* it's own hotplug events.
+ if (ret == 1 || ret == -EACCES || ret == -EINPROGRESS) {
+ /* If the GPU is already awake, is waking up, or is in a state
+* where we can't wake it up, it can handle its own hotplug
+* events.
*/
pm_runtime_put_autosuspend(drm->dev->dev);
} else if (ret == 0) {
--
2.26.2
[PATCH 8/9] drm/nouveau/kms: Fix runtime PM leak in nouveau_display_acpi_ntfy()
Signed-off-by: Lyude Paul
Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events
too early")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.19+
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 96c9e7f550537..ad63d4f052deb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -479,6 +479,8 @@ nouveau_display_acpi_ntfy(struct notifier_block *nb,
unsigned long val,
} else {
NV_WARN(drm, "Dropped ACPI reprobe event due to RPM error:
%d\n",
ret);
+ pm_runtime_mark_last_busy(drm->dev->dev);
+ pm_runtime_put_autosuspend(drm->dev->dev);
}
/* acpi-video should not generate keypresses for this */
--
2.26.2
[PATCH 7/9] drm/nouveau/kms: Invert conditionals in nouveau_display_acpi_ntfy()
No functional changes here, just a drive-by cleanup.
Signed-off-by: Lyude Paul
[cc'd to stable since the next fix needs this patch to apply]
Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events
too early")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.19+
---
drivers/gpu/drm/nouveau/nouveau_display.c | 50 +++
1 file changed, 24 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index cdc5a2200f95e..96c9e7f550537 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -457,34 +457,32 @@ nouveau_display_acpi_ntfy(struct notifier_block *nb,
unsigned long val,
struct acpi_bus_event *info = data;
int ret;
- if (!strcmp(info->device_class, ACPI_VIDEO_CLASS)) {
- if (info->type == ACPI_VIDEO_NOTIFY_PROBE) {
- ret = pm_runtime_get(drm->dev->dev);
- if (ret == 1 || ret == -EACCES) {
- /* If the GPU is already awake, or in a state
-* where we can't wake it up, it can handle
-* it's own hotplug events.
-*/
- pm_runtime_put_autosuspend(drm->dev->dev);
- } else if (ret == 0) {
- /* This may be the only indication we receive
-* of a connector hotplug on a runtime
-* suspended GPU, schedule hpd_work to check.
-*/
- NV_DEBUG(drm, "ACPI requested connector
reprobe\n");
- schedule_work(>hpd_work);
- pm_runtime_put_noidle(drm->dev->dev);
- } else {
- NV_WARN(drm, "Dropped ACPI reprobe event due to
RPM error: %d\n",
- ret);
- }
-
- /* acpi-video should not generate keypresses for this */
- return NOTIFY_BAD;
- }
+ if (strcmp(info->device_class, ACPI_VIDEO_CLASS) ||
+ info->type != ACPI_VIDEO_NOTIFY_PROBE)
+ return NOTIFY_DONE;
+
+ ret = pm_runtime_get(drm->dev->dev);
+ if (ret == 1 || ret == -EACCES) {
+ /* If the GPU is already awake, or in a state
+* where we can't wake it up, it can handle
+* it's own hotplug events.
+*/
+ pm_runtime_put_autosuspend(drm->dev->dev);
+ } else if (ret == 0) {
+ /* This may be the only indication we receive
+* of a connector hotplug on a runtime
+* suspended GPU, schedule hpd_work to check.
+*/
+ NV_DEBUG(drm, "ACPI requested connector reprobe\n");
+ schedule_work(>hpd_work);
+ pm_runtime_put_noidle(drm->dev->dev);
+ } else {
+ NV_WARN(drm, "Dropped ACPI reprobe event due to RPM error:
%d\n",
+ ret);
}
- return NOTIFY_DONE;
+ /* acpi-video should not generate keypresses for this */
+ return NOTIFY_BAD;
}
#endif
--
2.26.2
