* [PATCH 3/3] acpi: sleep: Don't offer s2idle on AMD platforms without LPS0
From: Mario Limonciello @ 2022-01-05 19:39 UTC (permalink / raw)
To: Rafael J . Wysocki, linux-acpi
Cc: Shyam-sundar.S-k, Basavaraj Natikar, Mario Limonciello,
Bjoren Dasse
In-Reply-To: <20220105193910.25678-1-mario.limonciello@amd.com>
On some OEM platforms a BIOS option is offered that will set the
sleep mode between S3 and S2idle. This option will change certain HW
behaviors. When in S2idle mode, Linux works properly. However when S3 mode
is picked but the user chooses S2idle in Linux the platform may not be
properly resumed.
To avoid users getting into this situation, don't offer s2idle on AMD
systems missing the LPS0 device either by a BIOS option or by using the
acpi "no_sleep_lps0" module parameter.
Reported-by: Bjoren Dasse <bjoern.daase@gmail.com>
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1824
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215387
Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/acpi/x86/s2idle.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index a1626737e5e0..c3d35a42ac2f 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -363,6 +363,13 @@ static int validate_dsm(acpi_handle handle, const char *uuid, int rev, guid_t *d
static bool acpi_s2idle_valid(void)
{
+ /* AMD systems must have low level firmware support */
+ if (acpi_s2idle_vendor_amd())
+#if IS_ENABLED(CONFIG_AMD_PMC)
+ return lps0_device_handle && !sleep_no_lps0;
+#else
+ return false;
+#endif
return true;
}
@@ -450,6 +457,9 @@ static int lps0_device_attach(struct acpi_device *adev,
if (!acpi_s2idle_vendor_amd())
acpi_ec_mark_gpe_for_wake();
+ /* reset these so we update valid */
+ s2idle_set_ops(&acpi_s2idle_ops_lps0);
+
return 0;
}
--
2.25.1
^ permalink raw reply related
* Re: [RFC PATCH 00/10] KVM: selftests: Add support for test-selectable ucall implementations
From: Sean Christopherson @ 2022-01-05 19:40 UTC (permalink / raw)
To: Michael Roth
Cc: linux-kselftest, kvm, linux-kernel, x86, Nathan Tempelman,
Marc Orr, Steve Rutherford, Mingwei Zhang, Brijesh Singh,
Tom Lendacky, Varad Gautam, Shuah Khan, Vitaly Kuznetsov,
David Woodhouse, Ricardo Koller, Jim Mattson, Joerg Roedel,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H . Peter Anvin,
Christian Borntraeger, Janosch Frank, David Hildenbrand,
Claudio Imbrenda, Marc Zyngier, James Morse, Alexandru Elisei,
Suzuki K Poulose, kvmarm
In-Reply-To: <20220105191107.qx67wf2coc3q6giu@amd.com>
On Wed, Jan 05, 2022, Michael Roth wrote:
> On Wed, Jan 05, 2022 at 05:43:21PM +0000, Sean Christopherson wrote:
> > Because it uses multiple VMs, and my rough sketch only allows for a single VM to
> > use ucall. Though I suppose we could simply keep appending to the ucall list for
> > every VM. The requirement would then be that all VMs are of the same type, i.e.
> > utilize the same ucall_ops.
>
> Hmm, maybe I misread your patch. Not supporting multiple VMs was the
> reason I gave up on having the ucall structs allocated on-demand and
> went with requiring them to be passed as arguments to ucall().
>
> I thought with your patch you had solved that by having each vm have it's
> own pool, via vm->ucall_list, and then mapping each pool into each guest
> separately via:
>
> ucall_init(vm):
> ucall_list = vm->ucall_list
> sync_global_to_guest(ucall_list).
>
> then as long as that ucall_init() is done *after* the guest calls
> kvm_vm_elf_load(), it will end up with a 'ucall_list' global that points
> to it's own specific vm->ucall_list. Then on the test side it doesn't
> matter what the 'ucall_list' global is currently set to since you have
> the GPA and know what vm exited.
>
> Or am I missing something there?
Ha, that was not at all intented. But yes, it should work. I'd rather be lucky
than good?
> Although even if that is the case, now that we're proposing doing the
> ucall_init() inside vm_create(), then we run the risk of a test calling
> kvm_vm_elf_load() after, which might clobber the guest's copy of
> ucall_list global if ucall_init() had since been called for another VM.
> But that could maybe be worked around by having whatever vm_create()
> variant we use also do the kvm_vm_elf_load() unconditionally as part of
> creation.
Will sync_global_to_guest() even work as intended if kvm_vm_elf_load() hasn't
been called? If not, then sync_global_{to,from}_guest() should really assert if
the test hasn't been loaded.
As for ucall_init(), I think the best approach would be to make kvm_vm_elf_load()
a static and replace all calls with:
kvm_vm_load_guest(vm);
where its implementation is:
void kvm_vm_load_guest(struct kvm_vm *vm)
{
kvm_vm_elf_load(vm, program_invocation_name);
ucall_init(vm);
}
The logic being that if a test creates a VM but never loads any code into the guest,
e.g. kvm_create_max_vcpus, then it _can't_ make ucalls.
^ permalink raw reply
* Re: [RFC PATCH 00/10] KVM: selftests: Add support for test-selectable ucall implementations
From: Sean Christopherson @ 2022-01-05 19:40 UTC (permalink / raw)
To: Michael Roth
Cc: Brijesh Singh, kvm, David Hildenbrand, Marc Orr, linux-kselftest,
H . Peter Anvin, Claudio Imbrenda, Shuah Khan, kvmarm,
Nathan Tempelman, Janosch Frank, Marc Zyngier, Joerg Roedel, x86,
Ingo Molnar, Mingwei Zhang, Christian Borntraeger, Tom Lendacky,
Borislav Petkov, Thomas Gleixner, Varad Gautam, Jim Mattson,
Steve Rutherford, linux-kernel, Vitaly Kuznetsov, David Woodhouse
In-Reply-To: <20220105191107.qx67wf2coc3q6giu@amd.com>
On Wed, Jan 05, 2022, Michael Roth wrote:
> On Wed, Jan 05, 2022 at 05:43:21PM +0000, Sean Christopherson wrote:
> > Because it uses multiple VMs, and my rough sketch only allows for a single VM to
> > use ucall. Though I suppose we could simply keep appending to the ucall list for
> > every VM. The requirement would then be that all VMs are of the same type, i.e.
> > utilize the same ucall_ops.
>
> Hmm, maybe I misread your patch. Not supporting multiple VMs was the
> reason I gave up on having the ucall structs allocated on-demand and
> went with requiring them to be passed as arguments to ucall().
>
> I thought with your patch you had solved that by having each vm have it's
> own pool, via vm->ucall_list, and then mapping each pool into each guest
> separately via:
>
> ucall_init(vm):
> ucall_list = vm->ucall_list
> sync_global_to_guest(ucall_list).
>
> then as long as that ucall_init() is done *after* the guest calls
> kvm_vm_elf_load(), it will end up with a 'ucall_list' global that points
> to it's own specific vm->ucall_list. Then on the test side it doesn't
> matter what the 'ucall_list' global is currently set to since you have
> the GPA and know what vm exited.
>
> Or am I missing something there?
Ha, that was not at all intented. But yes, it should work. I'd rather be lucky
than good?
> Although even if that is the case, now that we're proposing doing the
> ucall_init() inside vm_create(), then we run the risk of a test calling
> kvm_vm_elf_load() after, which might clobber the guest's copy of
> ucall_list global if ucall_init() had since been called for another VM.
> But that could maybe be worked around by having whatever vm_create()
> variant we use also do the kvm_vm_elf_load() unconditionally as part of
> creation.
Will sync_global_to_guest() even work as intended if kvm_vm_elf_load() hasn't
been called? If not, then sync_global_{to,from}_guest() should really assert if
the test hasn't been loaded.
As for ucall_init(), I think the best approach would be to make kvm_vm_elf_load()
a static and replace all calls with:
kvm_vm_load_guest(vm);
where its implementation is:
void kvm_vm_load_guest(struct kvm_vm *vm)
{
kvm_vm_elf_load(vm, program_invocation_name);
ucall_init(vm);
}
The logic being that if a test creates a VM but never loads any code into the guest,
e.g. kvm_create_max_vcpus, then it _can't_ make ucalls.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [PATCH 1/9] scsi_debug: address races following module load
From: Bart Van Assche @ 2022-01-05 19:41 UTC (permalink / raw)
To: Douglas Gilbert, linux-scsi; +Cc: martin.petersen, jejb, Luis Chamberlain
In-Reply-To: <20211231020829.29147-2-dgilbert@interlog.com>
On 12/30/21 18:08, Douglas Gilbert wrote:
> + if (READ_ONCE(sdebug_deflect_incoming)) {
> + pr_info("Exit early due to deflect_incoming\n");
> + return 1;
> + }
The new mechanism will work fine on x86 but not on ARM systems. Please
change all READ_ONCE(sdebug_deflect_incoming) calls into
smp_load_acquire(&sdebug_deflect_incoming) and all
WRITE_ONCE(sdebug_deflect_incoming) calls into
smp_store_release(&sdebug_deflect_incoming).
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v2 net-next 2/7] net: dsa: merge all bools of struct dsa_port into a single u8
From: Florian Fainelli @ 2022-01-05 19:42 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev@vger.kernel.org, David S. Miller, Jakub Kicinski,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20220105185627.vq6kgnw2yhbymiuc@skbuf>
On 1/5/22 10:56 AM, Vladimir Oltean wrote:
> On Wed, Jan 05, 2022 at 10:46:44AM -0800, Florian Fainelli wrote:
>> On 1/5/22 10:39 AM, Vladimir Oltean wrote:
>>> Hi Florian,
>>>
>>> On Wed, Jan 05, 2022 at 10:30:54AM -0800, Florian Fainelli wrote:
>>>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>>>
>>> Thanks a lot for the review.
>>>
>>> I'm a bit on the fence on this patch and the other one for dsa_switch.
>>> The thing is that bit fields are not atomic in C89, so if we update any
>>> of the flags inside dp or ds concurrently (like dp->vlan_filtering),
>>> we're in trouble. Right now this isn't a problem, because most of the
>>> flags are set either during probe, or during ds->ops->setup, or are
>>> serialized by the rtnl_mutex in ways that are there to stay (switchdev
>>> notifiers). That's why I didn't say anything about it. But it may be a
>>> caveat to watch out for in the future. Do you think we need to do
>>> something about it? A lock would not be necessary, strictly speaking.
>>
>> I would probably start with a comment that describes these pitfalls, I
>> wish we had a programmatic way to ensure that these flags would not be
>> set dynamically and outside of the probe/setup path but that won't
>> happen easily.
>
> A comment is probably good.
>
>> Should we be switching to a bitmask and bitmap helpers to be future proof?
>
> We could have done that, and it would certainly raise the awareness a
> bit more, but the reason I went with the bit fields at least in the
> first place was to reduce the churn in drivers. Otherwise, sure, if
> driver changes are on the table for this, we can even discuss about
> adding more arguments to dsa_register_switch(). The amount of poking
> that drivers do inside struct dsa_switch has grown, and sometimes it's
> not even immediately clear which members of that structure are supposed
> to be populated by whom and when. We could definitely just tell them to
> provide their desired behavior as arguments (vlan_filtering_is_global,
> needs_standalone_vlan_filtering, configure_vlan_while_not_filtering,
> untag_bridge_pvid, assisted_learning_on_cpu_port, ageing_time_min,
> ageing_time_max, phys_mii_mask, num_tx_queues, num_lag_ids, max_num_bridges)
> and only DSA will update struct dsa_switch, and we could then control
> races better that way. But the downside is that we'd have 11 extra
> arguments to dsa_register_switch()....
I would not mind if we introduced a dsa_switch::features or similar
bitmap and require driver to set bits in there before
dsa_register_switch() but that seems outside the scope of your patch
set, and I am not sure what the benefits would be unless we do happen to
do dynamic bit/feature toggling.
So for now, I believe a comment is enough, and if we spot a driver
changing that paradigm we consider a more "dynamic" solution.
--
Florian
^ permalink raw reply
* RE: [PATCH v2 4/5] RISC-V: Typed CSRs in gdbserver
From: Schwarz, Konrad @ 2022-01-05 19:24 UTC (permalink / raw)
To: Alex Bennée
Cc: Palmer Dabbelt, Bin Meng, Alistair Francis, Ralf Ramsauer,
qemu-devel@nongnu.org
In-Reply-To: <874k6ij9z4.fsf@linaro.org>
> -----Original Message-----
> From: Alex Bennée <alex.bennee@linaro.org>
> Konrad Schwarz <konrad.schwarz@siemens.com> writes:
>
> > static int riscv_gen_dynamic_csr_xml(CPUState *cs, int base_reg)
> > {
> > RISCVCPU *cpu = RISCV_CPU(cs);
> > @@ -163,21 +167,33 @@ static int riscv_gen_dynamic_csr_xml(CPUState *cs, int base_reg)
> > riscv_csr_predicate_fn predicate;
> > int bitsize = 16 << env->misa_mxl_max;
> > int i;
> > + riscv_csr_operations *csr_op;
> > + struct riscv_gdb_csr_tg const *csr_tg;
> >
> > g_string_printf(s, "<?xml version=\"1.0\"?>");
> > g_string_append_printf(s, "<!DOCTYPE feature SYSTEM \"gdb-target.dtd\">");
> > g_string_append_printf(s, "<feature> name=\"org.gnu.gdb.riscv.csr\">");
>
> With these changes does it still match the org.gnu.gdb.riscv.csr
> register description in gdb? Previously for custom XML I've used the
> org.qemu.ARCH.REGS form to distinguish between something GDB expects and
> something we invented (changed since 797920b952ea).
I don't expect it to match -- but why should it?
The whole point of target descriptions is for GDBserver to inform
GDB of the precise set and layout of pre-defined register classes.
The class `org.gnu.gdb.riscv.csr' is known to a RISC-V capable
GDB as the class of all CSRs; a specific RISC-V core might
have vendor-specific CSRs, but they would still be included
in `org.gnu.gdb.riscv.csr'.
Section G.5 in the GDB manual makes this clear:
"You can add additional registers to any of the standard features --
GDB will display them just as they were added to an
unrecognized feature."
--
Konrad
^ permalink raw reply
* Re: [PATCH v4 1/2] name-rev: deprecate --stdin in favor of --annotate-stdin
From: Junio C Hamano @ 2022-01-05 19:47 UTC (permalink / raw)
To: Phillip Wood
Cc: John Cai via GitGitGadget, git, Johannes Schindelin, John Cai
In-Reply-To: <16666d32-833a-f3d7-351a-eeef7f25b002@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
>> @@ -613,8 +622,8 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
>> for_each_ref(name_ref, &data);
>> name_tips();
>> - if (transform_stdin) {
>> - char buffer[2048];
>> + if (annotate_stdin) {
>> + struct strbuf sb = STRBUF_INIT;
>
> I think this hunk belongs in the next patch. Before posting a patch
> series I find it helpful to run
>
> git rebase --keep-base -x'make -j4 git && cd t && prove -j4 <tests
> I think might fail> :: --root=/dev/shm'
>
> to check that the individual patches compile and pass the relevant
> tests. I've never got round to trying it but git-test[1] also lets you
> test all the commits in a series
Ahh, I saw and pointed out exactly the same mistake in an earlier
round, but failed to spot it this time around. Thanks for spotting.
^ permalink raw reply
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
^ permalink raw reply
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: John Garry
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
^ permalink raw reply
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: John Garry
Cc: linux-fbdev, linux-pci, Wim Van Sebroeck, Ettore Chimenti,
linux-ide, Albert Ou, Guo Ren, linux-i2c, linux-riscv,
Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Bartosz Golaszewski, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, Jaroslav Kysela,
Jean Delvare, linux-watchdog, Arnd Bergmann, Niklas Schnelle,
Jouni Malinen, Suganath Prabu Subramani, Kalle Valo, linux-input,
linux-spi, linux-gpio, Ian Abbott, Mark Brown, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Mauro Carvalho Chehab,
megaraidlinux.pdl, Teddy Wang, linux-hwmon, Arnd Bergmann,
Karsten Keil, Sreekanth Reddy, Martin K. Petersen, Nick Hu,
Sudip Mukherjee, Shivasharan S, Greg Kroah-Hartman, dri-devel,
Dmitry Torokhov, linux-wireless, Takashi Iwai, David S. Miller,
H Hartley Sweeten, Palmer Dabbelt, Forest Bond, netdev,
Hans Verkuil, Tony Nguyen, Damien Le Moal
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
^ permalink raw reply
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: John Garry
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH] RDMA: use default_groups in kobj_type
From: Jason Gunthorpe @ 2022-01-05 19:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, Doug Ledford, Christian Benvenuti, Nelson Escobar,
Leon Romanovsky, Wenpeng Liang, Mark Zhang, Weihang Li,
Aharon Landau, linux-rdma
In-Reply-To: <20220103152259.531034-1-gregkh@linuxfoundation.org>
On Mon, Jan 03, 2022 at 04:22:59PM +0100, Greg Kroah-Hartman wrote:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the IB code to use default_groups field which has been the
> preferred way since aa30f47cf666 ("kobject: Add support for default
> attribute groups to kobj_type") so that we can soon get rid of the
> obsolete default_attrs field.
>
> Cc: Doug Ledford <dledford@redhat.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Christian Benvenuti <benve@cisco.com>
> Cc: Nelson Escobar <neescoba@cisco.com>
> Cc: Leon Romanovsky <leon@kernel.org>
> Cc: Wenpeng Liang <liangwenpeng@huawei.com>
> Cc: Mark Zhang <markzhang@nvidia.com>
> Cc: Weihang Li <liweihang@huawei.com>
> Cc: Aharon Landau <aharonl@nvidia.com>
> Cc: linux-rdma@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/infiniband/core/sysfs.c | 3 ++-
> drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH v3] RDMA/rxe: Fix indentations and operators sytle
From: Jason Gunthorpe @ 2022-01-05 19:48 UTC (permalink / raw)
To: Li Zhijian; +Cc: zyjzyj2000, hch, linux-rdma, linux-kernel, leon
In-Reply-To: <20220105042605.14343-1-lizhijian@fujitsu.com>
On Wed, Jan 05, 2022 at 12:26:04PM +0800, Li Zhijian wrote:
> * Fix these up to always have the '+', and '|' on the continuing line which
> is the normal kernel style.
> * Fix indentations correspondingly
>
> NOTE: this patch also remove the 2 redundant plus in IB_OPCODE_RD_FETCH_ADD
> and IB_OPCODE_RD_COMPARE_SWAP
>
> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
> V3: it's former version is [PATCH v2] RDMA/rxe: Get rid of redundant plus
> ---
> drivers/infiniband/sw/rxe/rxe_opcode.c | 737 +++++++++++++------------
> 1 file changed, 369 insertions(+), 368 deletions(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH rdma-next] RDMA/mad: Delete duplicated init_query_mad functions
From: Jason Gunthorpe @ 2022-01-05 19:49 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Leon Romanovsky, linux-kernel, linux-rdma
In-Reply-To: <af6f35c590ff5ef56d0137351b8b295af0f7c13c.1641369858.git.leonro@nvidia.com>
On Wed, Jan 05, 2022 at 10:04:56AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Several drivers used same function to initialize query MAD,
> so move that function to global header file.
>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> Reviewed-by: Håkon Bugge <haakon.bugge@oracle.com>
> ---
> drivers/infiniband/hw/mlx4/main.c | 24 +++++++-------------
> drivers/infiniband/hw/mlx5/mad.c | 18 +++++++--------
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 8 -------
> drivers/infiniband/hw/mthca/mthca_provider.c | 20 +++++-----------
> include/rdma/ib_smi.h | 12 +++++++++-
> 5 files changed, 34 insertions(+), 48 deletions(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH rdma-next] RDMA/rxe: Delete deprecated module parameters interface
From: Jason Gunthorpe @ 2022-01-05 19:49 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Leon Romanovsky, linux-kernel, linux-rdma, Zhu Yanjun
In-Reply-To: <c8376d7517aebe7cc851f0baaeef7b13707cf767.1641372460.git.leonro@nvidia.com>
On Wed, Jan 05, 2022 at 10:50:35AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Starting from the commit 66920e1b2586 ("rdma_rxe: Use netlink messages
> to add/delete links") from the 2019, the RXE modules parameters are marked
> as deprecated in favour of rdmatool. So remove the kernel code too.
>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> Reviewed-by: Zhu Yanjun <zyjzyj2000@gmail.com>
> ---
> drivers/infiniband/sw/rxe/Makefile | 1 -
> drivers/infiniband/sw/rxe/rxe.c | 4 -
> drivers/infiniband/sw/rxe/rxe.h | 2 -
> drivers/infiniband/sw/rxe/rxe_sysfs.c | 119 --------------------------
> 4 files changed, 126 deletions(-)
> delete mode 100644 drivers/infiniband/sw/rxe/rxe_sysfs.c
Applied to for-next, thanks
Jason
^ permalink raw reply
* [PATCH] dpp: use %zu for printing size_t
From: James Prestwood @ 2022-01-05 19:50 UTC (permalink / raw)
To: iwd
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
---
src/dpp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dpp.c b/src/dpp.c
index 9eb1d642..dedbd3b2 100644
--- a/src/dpp.c
+++ b/src/dpp.c
@@ -1272,7 +1272,7 @@ static void authenticate_request(struct dpp_sm *dpp, const uint8_t *from,
}
if (i_nonce_len != dpp->nonce_len) {
- l_debug("I-Nonce has unexpected length %lu", i_nonce_len);
+ l_debug("I-Nonce has unexpected length %zu", i_nonce_len);
goto auth_request_failed;
}
--
2.31.1
^ permalink raw reply related
* Re: [PATCH bpf-next] bpf, sockmap: fix return codes from tcp_bpf_recvmsg_parser()
From: patchwork-bot+netdevbpf @ 2022-01-05 19:50 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, netdev, bpf, joamaki
In-Reply-To: <20220104205918.286416-1-john.fastabend@gmail.com>
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:
On Tue, 4 Jan 2022 12:59:18 -0800 you wrote:
> Applications can be confused slightly because we do not always return the
> same error code as expected, e.g. what the TCP stack normally returns. For
> example on a sock err sk->sk_err instead of returning the sock_error we
> return EAGAIN. This usually means the application will 'try again'
> instead of aborting immediately. Another example, when a shutdown event
> is received we should immediately abort instead of waiting for data when
> the user provides a timeout.
>
> [...]
Here is the summary with links:
- [bpf-next] bpf, sockmap: fix return codes from tcp_bpf_recvmsg_parser()
https://git.kernel.org/bpf/bpf-next/c/5b2c5540b811
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] bpf, arm64: use emit_addr_mov_i64() for BPF_PSEUDO_FUNC
From: patchwork-bot+netdevbpf @ 2022-01-05 19:50 UTC (permalink / raw)
To: Hou Tao
Cc: ast, kafai, yhs, daniel, andrii, zlim.lnx, will, netdev, bpf,
linux-arm-kernel
In-Reply-To: <20211231151018.3781550-1-houtao1@huawei.com>
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:
On Fri, 31 Dec 2021 23:10:18 +0800 you wrote:
> The following error is reported when running "./test_progs -t for_each"
> under arm64:
>
> bpf_jit: multi-func JIT bug 58 != 56
> ......
> JIT doesn't support bpf-to-bpf calls
>
> [...]
Here is the summary with links:
- bpf, arm64: use emit_addr_mov_i64() for BPF_PSEUDO_FUNC
https://git.kernel.org/bpf/bpf-next/c/e4a41c2c1fa9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, sockmap: fix double bpf_prog_put on error case in map_link
From: patchwork-bot+netdevbpf @ 2022-01-05 19:50 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, netdev, bpf, joamaki
In-Reply-To: <20220104214645.290900-1-john.fastabend@gmail.com>
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:
On Tue, 4 Jan 2022 13:46:45 -0800 you wrote:
> sock_map_link() is called to update a sockmap entry with a sk. But, if the
> sock_map_init_proto() call fails then we return an error to the map_update
> op against the sockmap. In the error path though we need to cleanup psock
> and dec the refcnt on any programs associated with the map, because we
> refcnt them early in the update process to ensure they are pinned for the
> psock. (This avoids a race where user deletes programs while also updating
> the map with new socks.)
>
> [...]
Here is the summary with links:
- [bpf-next] bpf, sockmap: fix double bpf_prog_put on error case in map_link
https://git.kernel.org/bpf/bpf-next/c/218d747a4142
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* stable-rc/queue/4.14 baseline: 144 runs, 1 regressions (v4.14.260-19-gae196dc2c9ce)
From: kernelci.org bot @ 2022-01-05 19:51 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/4.14 baseline: 144 runs, 1 regressions (v4.14.260-19-gae196dc2c9ce)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
---------+------+---------------+----------+---------------------+------------
panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1
Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.260-19-gae196dc2c9ce/plan/baseline/
Test: baseline
Tree: stable-rc
Branch: queue/4.14
Describe: v4.14.260-19-gae196dc2c9ce
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
SHA: ae196dc2c9ce32094877e4d1b8ab1742141a8970
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
---------+------+---------------+----------+---------------------+------------
panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1
Details: https://kernelci.org/test/plan/id/61d5c16349a1626644ef67a1
Results: 4 PASS, 1 FAIL, 1 SKIP
Full config: omap2plus_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.260-19-gae196dc2c9ce/arm/omap2plus_defconfig/gcc-10/lab-collabora/baseline-panda.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.260-19-gae196dc2c9ce/arm/omap2plus_defconfig/gcc-10/lab-collabora/baseline-panda.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20211210.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/61d5c16349a1626644ef67a4
failing since 2 days (last pass: v4.14.260-5-g5ba2b1f2b4df, first fail: v4.14.260-9-gb7bb5018400c)
2 lines
2022-01-05T16:03:27.240074 [ 19.977935] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=pass UNITS=lines MEASUREMENT=0>
2022-01-05T16:03:27.284522 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/105
2022-01-05T16:03:27.293582 kern :emerg : lock: emif_lock+0x0/0xffffed3c [emif], .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
^ permalink raw reply
* Re: [PATCH] bpf, arm64: use emit_addr_mov_i64() for BPF_PSEUDO_FUNC
From: patchwork-bot+netdevbpf @ 2022-01-05 19:50 UTC (permalink / raw)
To: Hou Tao
Cc: ast, kafai, yhs, daniel, andrii, zlim.lnx, will, netdev, bpf,
linux-arm-kernel
In-Reply-To: <20211231151018.3781550-1-houtao1@huawei.com>
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:
On Fri, 31 Dec 2021 23:10:18 +0800 you wrote:
> The following error is reported when running "./test_progs -t for_each"
> under arm64:
>
> bpf_jit: multi-func JIT bug 58 != 56
> ......
> JIT doesn't support bpf-to-bpf calls
>
> [...]
Here is the summary with links:
- bpf, arm64: use emit_addr_mov_i64() for BPF_PSEUDO_FUNC
https://git.kernel.org/bpf/bpf-next/c/e4a41c2c1fa9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] enic: Use dma_set_mask_and_coherent()
From: Christophe JAILLET @ 2022-01-05 19:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: benve, govind, davem, kuba, netdev, linux-kernel, kernel-janitors
In-Reply-To: <YdK4IIFvi5O5eXHC@infradead.org>
Le 03/01/2022 à 09:47, Christoph Hellwig a écrit :
> On Sat, Jan 01, 2022 at 03:02:45PM +0100, Christophe JAILLET wrote:
>> - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(47));
>> + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(47));
>> if (err) {
>> + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>> if (err) {
>> dev_err(dev, "No usable DMA configuration, aborting\n");
>> goto err_out_release_regions;
>> }
>> } else {
>> using_dac = 1;
>
> There is no need for the callback. All the routines to set a DMA mask
> will only fail if the passed in mask is too small, but never if it is
> larger than what is supported. Also the using_dac variable is not
> needed, NETIF_F_HIGHDMA can and should be set unconditionally.
>
Ok, thanks.
I was only aware of the 64 bits case.
The patch has already reached -next.
I'll send another patch on to of it to go one step further.
CJ
^ permalink raw reply
* Re: [PATCH v4 1/2] name-rev: deprecate --stdin in favor of --annotate-stdin
From: Junio C Hamano @ 2022-01-05 19:52 UTC (permalink / raw)
To: Phillip Wood
Cc: John Cai via GitGitGadget, git, Johannes Schindelin, John Cai
In-Reply-To: <16666d32-833a-f3d7-351a-eeef7f25b002@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
>> @@ -539,6 +539,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
>> OPT_GROUP(""),
>> OPT_BOOL(0, "all", &all, N_("list all commits reachable from all refs")),
>> OPT_BOOL(0, "stdin", &transform_stdin, N_("read from stdin")),
>
> If the intention is to deprecate this option then it might be worth
> marking it as PARSE_OPT_HIDDEN so that it is not shown by 'git
> name-rev -h'. (You need to change OPT_BOOL to OPT_BOOL_F to pass the
> flag)
Whether we want to do HIDDEN now or not, it is probably a good idea
to update the help text to
N_("deprecated synonym to --annotate-stdin")
or something like that.
^ permalink raw reply
* Re: [PATCH v8 13/40] x86/kernel: Make the bss.decrypted section shared in RMP table
From: Brijesh Singh @ 2022-01-05 19:52 UTC (permalink / raw)
To: Venu Busireddy
Cc: brijesh.singh, x86, linux-kernel, kvm, linux-efi,
platform-driver-x86, linux-coco, linux-mm, Thomas Gleixner,
Ingo Molnar, Joerg Roedel, Tom Lendacky, H. Peter Anvin,
Ard Biesheuvel, Paolo Bonzini, Sean Christopherson,
Vitaly Kuznetsov, Jim Mattson, Andy Lutomirski, Dave Hansen,
Sergio Lopez, Peter Gonda, Peter Zijlstra, Srinivas Pandruvada,
David Rientjes, Dov Murik, Tobin Feldman-Fitzthum,
Borislav Petkov, Michael Roth, Vlastimil Babka,
Kirill A . Shutemov, Andi Kleen, Dr . David Alan Gilbert,
tony.luck, marcorr, sathyanarayanan.kuppuswamy
In-Reply-To: <YdSKQKSTS83cRzGZ@dt>
On 1/4/22 11:56 AM, Venu Busireddy wrote:
> On 2021-12-10 09:43:05 -0600, Brijesh Singh wrote:
>> The encryption attribute for the bss.decrypted region is cleared in the
>> initial page table build. This is because the section contains the data
>> that need to be shared between the guest and the hypervisor.
>>
>> When SEV-SNP is active, just clearing the encryption attribute in the
>> page table is not enough. The page state need to be updated in the RMP
>> table.
>>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> arch/x86/kernel/head64.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
>> index fa02402dcb9b..72c5082a3ba4 100644
>> --- a/arch/x86/kernel/head64.c
>> +++ b/arch/x86/kernel/head64.c
>> @@ -143,7 +143,14 @@ static unsigned long sme_postprocess_startup(struct boot_params *bp, pmdval_t *p
>> if (sme_get_me_mask()) {
>> vaddr = (unsigned long)__start_bss_decrypted;
>> vaddr_end = (unsigned long)__end_bss_decrypted;
>> +
>> for (; vaddr < vaddr_end; vaddr += PMD_SIZE) {
>> + /*
>> + * When SEV-SNP is active then transition the page to shared in the RMP
>> + * table so that it is consistent with the page table attribute change.
>> + */
>> + early_snp_set_memory_shared(__pa(vaddr), __pa(vaddr), PTRS_PER_PMD);
>
> Shouldn't the first argument be vaddr as below?
>
Nope, sme_postprocess_startup() is called while we are fixing the
initial page table and running with identity mapping (so va == pa).
thanks
> early_snp_set_memory_shared(vaddr, __pa(vaddr), PTRS_PER_PMD);
>
> Venu
>
^ permalink raw reply
* [PATCH v2] xfs: take the ILOCK when accessing the inode core
From: Darrick J. Wong @ 2022-01-05 19:52 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-xfs
From: Darrick J. Wong <djwong@kernel.org>
I was poking around in the directory code while diagnosing online fsck
bugs, and noticed that xfs_readdir doesn't actually take the directory
ILOCK when it calls xfs_dir2_isblock. xfs_dir_open most probably loaded
the data fork mappings and the VFS took i_rwsem (aka IOLOCK_SHARED) so
we're protected against writer threads, but we really need to follow the
locking model like we do in other places.
To avoid unnecessarily cycling the ILOCK for fairly small directories,
change the block/leaf _getdents functions to consume the ILOCK hold that
the parent readdir function took to decide on a _getdents implementation.
It is ok to cycle the ILOCK in readdir because the VFS takes the IOLOCK
in the appropriate mode during lookups and writes, and we don't want to
be holding the ILOCK when we copy directory entries to userspace in case
there's a page fault. We really only need it to protect against data
fork lookups, like we do for other files.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
v2: reduce the scope of the locked region, and reduce lock cycling
---
fs/xfs/xfs_dir2_readdir.c | 52 +++++++++++++++++++++++++++++----------------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/fs/xfs/xfs_dir2_readdir.c b/fs/xfs/xfs_dir2_readdir.c
index 8310005af00f..74844edd86a7 100644
--- a/fs/xfs/xfs_dir2_readdir.c
+++ b/fs/xfs/xfs_dir2_readdir.c
@@ -138,7 +138,8 @@ xfs_dir2_sf_getdents(
STATIC int
xfs_dir2_block_getdents(
struct xfs_da_args *args,
- struct dir_context *ctx)
+ struct dir_context *ctx,
+ unsigned int *lock_mode)
{
struct xfs_inode *dp = args->dp; /* incore directory inode */
struct xfs_buf *bp; /* buffer for block */
@@ -146,7 +147,6 @@ xfs_dir2_block_getdents(
int wantoff; /* starting block offset */
xfs_off_t cook;
struct xfs_da_geometry *geo = args->geo;
- int lock_mode;
unsigned int offset, next_offset;
unsigned int end;
@@ -156,12 +156,13 @@ xfs_dir2_block_getdents(
if (xfs_dir2_dataptr_to_db(geo, ctx->pos) > geo->datablk)
return 0;
- lock_mode = xfs_ilock_data_map_shared(dp);
error = xfs_dir3_block_read(args->trans, dp, &bp);
- xfs_iunlock(dp, lock_mode);
if (error)
return error;
+ xfs_iunlock(dp, *lock_mode);
+ *lock_mode = 0;
+
/*
* Extract the byte offset we start at from the seek pointer.
* We'll skip entries before this.
@@ -344,7 +345,8 @@ STATIC int
xfs_dir2_leaf_getdents(
struct xfs_da_args *args,
struct dir_context *ctx,
- size_t bufsize)
+ size_t bufsize,
+ unsigned int *lock_mode)
{
struct xfs_inode *dp = args->dp;
struct xfs_mount *mp = dp->i_mount;
@@ -356,7 +358,6 @@ xfs_dir2_leaf_getdents(
xfs_dir2_off_t curoff; /* current overall offset */
int length; /* temporary length value */
int byteoff; /* offset in current block */
- int lock_mode;
unsigned int offset = 0;
int error = 0; /* error return value */
@@ -390,13 +391,16 @@ xfs_dir2_leaf_getdents(
bp = NULL;
}
- lock_mode = xfs_ilock_data_map_shared(dp);
+ if (*lock_mode == 0)
+ *lock_mode = xfs_ilock_data_map_shared(dp);
error = xfs_dir2_leaf_readbuf(args, bufsize, &curoff,
&rablk, &bp);
- xfs_iunlock(dp, lock_mode);
if (error || !bp)
break;
+ xfs_iunlock(dp, *lock_mode);
+ *lock_mode = 0;
+
xfs_dir3_data_check(dp, bp);
/*
* Find our position in the block.
@@ -507,8 +511,9 @@ xfs_readdir(
size_t bufsize)
{
struct xfs_da_args args = { NULL };
- int rval;
- int v;
+ unsigned int lock_mode;
+ int isblock;
+ int error;
trace_xfs_readdir(dp);
@@ -523,13 +528,22 @@ xfs_readdir(
args.trans = tp;
if (dp->i_df.if_format == XFS_DINODE_FMT_LOCAL)
- rval = xfs_dir2_sf_getdents(&args, ctx);
- else if ((rval = xfs_dir2_isblock(&args, &v)))
- ;
- else if (v)
- rval = xfs_dir2_block_getdents(&args, ctx);
- else
- rval = xfs_dir2_leaf_getdents(&args, ctx, bufsize);
-
- return rval;
+ return xfs_dir2_sf_getdents(&args, ctx);
+
+ lock_mode = xfs_ilock_data_map_shared(dp);
+ error = xfs_dir2_isblock(&args, &isblock);
+ if (error)
+ goto out_unlock;
+
+ if (isblock) {
+ error = xfs_dir2_block_getdents(&args, ctx, &lock_mode);
+ goto out_unlock;
+ }
+
+ error = xfs_dir2_leaf_getdents(&args, ctx, bufsize, &lock_mode);
+
+out_unlock:
+ if (lock_mode)
+ xfs_iunlock(dp, lock_mode);
+ return error;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.