* [PATCHv3 1/4] block: move rq_list macros to blk-mq.h
From: Keith Busch @ 2022-01-05 17:05 UTC (permalink / raw)
To: linux-nvme, linux-block, axboe; +Cc: hch, sagi, mgurtovoy, Keith Busch
In-Reply-To: <20220105170518.3181469-1-kbusch@kernel.org>
Move the request list macros to the header file that defines that struct
they operate on.
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
fs/io_uring.c | 2 +-
include/linux/blk-mq.h | 29 +++++++++++++++++++++++++++++
include/linux/blkdev.h | 29 -----------------------------
3 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 90002bb3fdf4..33f72b3b302c 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -57,7 +57,7 @@
#include <linux/mman.h>
#include <linux/percpu.h>
#include <linux/slab.h>
-#include <linux/blkdev.h>
+#include <linux/blk-mq.h>
#include <linux/bvec.h>
#include <linux/net.h>
#include <net/sock.h>
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 550996cf419c..bf64b94cd64e 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -216,6 +216,35 @@ static inline unsigned short req_get_ioprio(struct request *req)
#define rq_dma_dir(rq) \
(op_is_write(req_op(rq)) ? DMA_TO_DEVICE : DMA_FROM_DEVICE)
+#define rq_list_add(listptr, rq) do { \
+ (rq)->rq_next = *(listptr); \
+ *(listptr) = rq; \
+} while (0)
+
+#define rq_list_pop(listptr) \
+({ \
+ struct request *__req = NULL; \
+ if ((listptr) && *(listptr)) { \
+ __req = *(listptr); \
+ *(listptr) = __req->rq_next; \
+ } \
+ __req; \
+})
+
+#define rq_list_peek(listptr) \
+({ \
+ struct request *__req = NULL; \
+ if ((listptr) && *(listptr)) \
+ __req = *(listptr); \
+ __req; \
+})
+
+#define rq_list_for_each(listptr, pos) \
+ for (pos = rq_list_peek((listptr)); pos; pos = rq_list_next(pos))
+
+#define rq_list_next(rq) (rq)->rq_next
+#define rq_list_empty(list) ((list) == (struct request *) NULL)
+
enum blk_eh_timer_return {
BLK_EH_DONE, /* drivers has completed the command */
BLK_EH_RESET_TIMER, /* reset timer and try again */
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 22746b2d6825..9c95df26fc26 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1339,33 +1339,4 @@ struct io_comp_batch {
#define DEFINE_IO_COMP_BATCH(name) struct io_comp_batch name = { }
-#define rq_list_add(listptr, rq) do { \
- (rq)->rq_next = *(listptr); \
- *(listptr) = rq; \
-} while (0)
-
-#define rq_list_pop(listptr) \
-({ \
- struct request *__req = NULL; \
- if ((listptr) && *(listptr)) { \
- __req = *(listptr); \
- *(listptr) = __req->rq_next; \
- } \
- __req; \
-})
-
-#define rq_list_peek(listptr) \
-({ \
- struct request *__req = NULL; \
- if ((listptr) && *(listptr)) \
- __req = *(listptr); \
- __req; \
-})
-
-#define rq_list_for_each(listptr, pos) \
- for (pos = rq_list_peek((listptr)); pos; pos = rq_list_next(pos))
-
-#define rq_list_next(rq) (rq)->rq_next
-#define rq_list_empty(list) ((list) == (struct request *) NULL)
-
#endif /* _LINUX_BLKDEV_H */
--
2.25.4
^ permalink raw reply related
* [PATCHv3 0/4] queue_rqs error handling
From: Keith Busch @ 2022-01-05 17:05 UTC (permalink / raw)
To: linux-nvme, linux-block, axboe; +Cc: hch, sagi, mgurtovoy, Keith Busch
The only real change since v2 is a prep patch that relocates the rq list
macros to blk-mq.h since that's where 'struct request' is defined.
Patch 3 removes the 'next' parameter since it is trivially obtainable
via 'rq->rq_next' anyway.
Otherwise, the series is the same as v2 and tested with lots of random
error injection in the prep path. The same errors would have lost
requests in the current driver, but is successful with this series.
Keith Busch (4):
block: move rq_list macros to blk-mq.h
block: introduce rq_list_for_each_safe macro
block: introduce rq_list_move
nvme-pci: fix queue_rqs list splitting
drivers/nvme/host/pci.c | 28 +++++++++++------------
fs/io_uring.c | 2 +-
include/linux/blk-mq.h | 50 +++++++++++++++++++++++++++++++++++++++++
include/linux/blkdev.h | 29 ------------------------
4 files changed, 65 insertions(+), 44 deletions(-)
--
2.25.4
^ permalink raw reply
* Re: [oe][meta-oe][hardknott][PATCH] udisks2: upgrade from 2.9.2 to 2.9.4
From: akuster808 @ 2022-01-05 17:05 UTC (permalink / raw)
To: Chen Qi, openembedded-devel
In-Reply-To: <20220105075924.77639-1-Qi.Chen@windriver.com>
On 1/4/22 11:59 PM, Chen Qi wrote:
> Upgrade udisks2 from 2.9.2 to 2.9.4. This upgrade will solves
> CVE-2021-3802.
This does not apply on top of current hardknott.
This recipe already has the protocol changes which this patch is missing.
-armin
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
> .../udisks/{udisks2_2.9.2.bb => udisks2_2.9.4.bb} | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta-oe/recipes-support/udisks/{udisks2_2.9.2.bb => udisks2_2.9.4.bb} (90%)
>
> diff --git a/meta-oe/recipes-support/udisks/udisks2_2.9.2.bb b/meta-oe/recipes-support/udisks/udisks2_2.9.4.bb
> similarity index 90%
> rename from meta-oe/recipes-support/udisks/udisks2_2.9.2.bb
> rename to meta-oe/recipes-support/udisks/udisks2_2.9.4.bb
> index f9e127438..ebda86fa6 100644
> --- a/meta-oe/recipes-support/udisks/udisks2_2.9.2.bb
> +++ b/meta-oe/recipes-support/udisks/udisks2_2.9.4.bb
> @@ -17,8 +17,8 @@ DEPENDS += "${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
>
> RDEPENDS_${PN} = "acl"
>
> -SRC_URI = "git://github.com/storaged-project/udisks.git;branch=master"
> -SRCREV = "da6d9480fefeb0ffdf8a84626b5096827d8d7030"
> +SRC_URI = "git://github.com/storaged-project/udisks.git;branch=2.9.x-branch"
> +SRCREV = "001c486e6d099ed33e2de4f5c73c03e3ee180f81"
> S = "${WORKDIR}/git"
>
> CVE_PRODUCT = "udisks"
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#94657): https://lists.openembedded.org/g/openembedded-devel/message/94657
> Mute This Topic: https://lists.openembedded.org/mt/88209858/3616698
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [akuster808@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Ard Biesheuvel @ 2022-01-05 17:02 UTC (permalink / raw)
To: Jon Hunter
Cc: Geert Uytterhoeven, Marek Szyprowski, Linux ARM, Russell King,
Nicolas Pitre, Arnd Bergmann, Kees Cook, Keith Packard,
Linus Walleij, Nick Desaulniers, Tony Lindgren,
Krzysztof Kozlowski, Linux Samsung SOC, Linux-Renesas,
linux-tegra@vger.kernel.org
In-Reply-To: <c0d71f87-1329-205c-c4fb-d82d0f118a7b@nvidia.com>
On Wed, 5 Jan 2022 at 17:50, Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 05/01/2022 11:12, Ard Biesheuvel wrote:
>
> ...
>
> > Thanks for the report.
> >
> > It would be helpful if you could provide some more context:
> > - does it happen on a LPAE build too?
>
> Enabling CONFIG_ARM_LPAE does work.
>
> > - does it only happen on SMP capable systems?
> > - does it reproduce on such systems when using only a single CPU?
> > (i.e., pass 'nosmp' on the kernel command line)
>
> Adding 'nosmp' does not help.
>
> > - when passing 'no_console_suspend' on the kernel command line, are
> > any useful diagnostics produced?
>
> Adding 'no_console_suspend' does not produce any interesting logs.
>
> > - is there any way you could tell whether the crash/hang (assuming
> > that is what you are observing) occurs on the suspend path or on
> > resume?
>
> That is not clear. I see it entering suspend, but not clear if it is
> failing on entering suspend or resuming.
>
Thanks a lot for providing this info.
The fact that enabling LPAE makes the issue go away is a fairly strong
hint that one of the CPUs comes up running in an address space that
lacks the stack's vmapping in its copy of the swapper_pg_dir region -
LPAE builds map swapper_pg_dir directly so there it can never go out
of sync.
Given that vmappings are global, and therefore cached in the TLB
across context switches, it is not unlikely that the missing vmapping
of the stack is in a task that runs before suspend, but does not cause
any issues until after the CPU is reset completely (which takes cached
TLB entries down with it)
So in summary, this gives me something to chew on, and hopefully, I
will be able to provide a proper fix shortly.
_______________________________________________
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 v5 13/16] mm: memcontrol: reuse memory cgroup ID for kmem ID
From: Michal Koutný @ 2022-01-05 17:03 UTC (permalink / raw)
To: Muchun Song
Cc: willy, akpm, hannes, mhocko, vdavydov.dev, shakeelb, guro,
shy828301, alexs, richard.weiyang, david, trond.myklebust,
anna.schumaker, jaegeuk, chao, kari.argillander, linux-fsdevel,
linux-kernel, linux-mm, linux-nfs, zhengqi.arch, duanxiongchun,
fam.zheng, smuchun
In-Reply-To: <20211220085649.8196-14-songmuchun@bytedance.com>
On Mon, Dec 20, 2021 at 04:56:46PM +0800, Muchun Song <songmuchun@bytedance.com> wrote:
> There are two idrs being used by memory cgroup, one is for kmem ID,
> another is for memory cgroup ID. The maximum ID of both is 64Ki.
> Both of them can limit the total number of memory cgroups.
> Actually, we can reuse memory cgroup ID for kmem ID to simplify the
> code.
An interesting improvement.
I'm a bit dense -- what's the purpose the MEM_CGROUP_ID_DIFF offset?
Couldn't this deduplication be extended to only use mem_cgroup.id.id
instead of mem_cgroup.kmemcg_id? (With a boolean telling whether kmem
accounting is active.)
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v3 kvm/queue 11/16] KVM: Add kvm_map_gfn_range
From: Sean Christopherson @ 2022-01-05 17:03 UTC (permalink / raw)
To: Chao Peng
Cc: kvm, linux-kernel, linux-mm, linux-fsdevel, qemu-devel,
Paolo Bonzini, Jonathan Corbet, Vitaly Kuznetsov, Wanpeng Li,
Jim Mattson, Joerg Roedel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, H . Peter Anvin, Hugh Dickins, Jeff Layton,
J . Bruce Fields, Andrew Morton, Yu Zhang, Kirill A . Shutemov,
luto, john.ji, susie.li, jun.nakajima, dave.hansen, ak, david
In-Reply-To: <20220105061410.GA25283@chaop.bj.intel.com>
On Wed, Jan 05, 2022, Chao Peng wrote:
> On Tue, Jan 04, 2022 at 05:31:30PM +0000, Sean Christopherson wrote:
> > On Fri, Dec 31, 2021, Chao Peng wrote:
> > > On Fri, Dec 24, 2021 at 12:13:51PM +0800, Chao Peng wrote:
> > > > On Thu, Dec 23, 2021 at 06:06:19PM +0000, Sean Christopherson wrote:
> > > > > On Thu, Dec 23, 2021, Chao Peng wrote:
> > > > > > This new function establishes the mapping in KVM page tables for a
> > > > > > given gfn range. It can be used in the memory fallocate callback for
> > > > > > memfd based memory to establish the mapping for KVM secondary MMU when
> > > > > > the pages are allocated in the memory backend.
> > > > >
> > > > > NAK, under no circumstance should KVM install SPTEs in response to allocating
> > > > > memory in a file. The correct thing to do is to invalidate the gfn range
> > > > > associated with the newly mapped range, i.e. wipe out any shared SPTEs associated
> > > > > with the memslot.
> > > >
> > > > Right, thanks.
> > >
> > > BTW, I think the current fallocate() callback is just useless as long as
> > > we don't want to install KVM SPTEs in response to allocating memory in a
> > > file. The invalidation of the shared SPTEs should be notified through
> > > mmu_notifier of the shared memory backend, not memfd_notifier of the
> > > private memory backend.
> >
> > No, because the private fd is the final source of truth as to whether or not a
> > GPA is private, e.g. userspace may choose to not unmap the shared backing.
> > KVM's rule per Paolo's/this proposoal is that a GPA is private if it has a private
> > memslot and is present in the private backing store. And the other core rule is
> > that KVM must never map both the private and shared variants of a GPA into the
> > guest.
>
> That's true, but I'm wondering if zapping the shared variant can be
> handled at the time when the private one gets mapped in the KVM page
> fault. No bothering the backing store to dedicate a callback to tell
> KVM.
Hmm, I don't think that would work for the TDP MMU due to page faults taking
mmu_lock for read. E.g. if two vCPUs concurrently fault in both the shared and
private variants, a race could exist where the private page fault sees the gfn
as private and the shared page fault sees it as shared. In that case, both faults
will install a SPTE and KVM would end up running with both variants mapped into the
guest.
There's also a performance penalty, as KVM would need to walk the shared EPT tree
on every private page fault.
^ permalink raw reply
* Re: [RFC PATCH 00/10] KVM: selftests: Add support for test-selectable ucall implementations
From: Michael Roth @ 2022-01-05 17:02 UTC (permalink / raw)
To: Sean Christopherson
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: <YdTjnRZQID5IabK0@google.com>
On Wed, Jan 05, 2022 at 12:17:33AM +0000, Sean Christopherson wrote:
> On Tue, Jan 04, 2022, Michael Roth wrote:
> > On Thu, Dec 30, 2021 at 09:11:12PM +0000, Sean Christopherson wrote:
> > > not in-kernel. That is bound to bite someone. The only issue with SEV is the
> > > address, not the VM-Exit mechanism. That doesn't change with SEV-ES, SEV-SNP,
> > > or TDX, as PIO and HLT will both get reflected as #VC/#VE, i.e. the guest side
> > > needs to be updated to use VMGEXIT/TDCALL no matter what, at which point having
> > > the hypercall request PIO emulation is just as easy as requesting HLT.
> >
> > I'm not aware of any #VC handling needed for HLT in the case of
> > SEV-ES/SEV-SNP. That was one of the reasons for the SEV tests using
> > this ucall implementation.
>
> Ah, you're right, HLT is an "automatic" exit and the CPU takes care of adjusting
> RIP. TDX is the only one that requires a hypercall.
>
> > Of course, at some point, we'd want full support for PIO/MMIO/etc. in the #VC
> > handler, but it's not something I'd planned on adding until after the SEV-SNP
> > tests, since it seems like we'd need to import a bunch of intruction decoding
> > code from elsewhere in the kernel, which is a lot of churn that's not
> > immediately necessary for getting at least some basic tests in place. Since
> > the HLT implementation is only 20 lines of code it seemed like a reasonable
> > stop-gap until we start getting more CoCo tests in place. But the in-kernel
> > APIC issue probably needs more consideration...
> >
> > Perhaps for *just* PIO, the intruction decoding can be open-coded so it
> > can be added to the initial #VC handler implementation, which would avoid the
> > need for HLT implementation. I'll take a look at that.
>
> PIO shouldn't require instruction decoding or a #VC handler. What I was thinking
> is that the guest in the selftest would make a direct #VMGEXIT/TDCALL to request
> PIO instead of executing an OUT.
That seems like a nicer approach. But it sort of lends itself to having
test-specific ucall implementations in some form. How are you thinking
vm_create() should decide what implementation to use? With this series
in place it could be something like:
vm_create(..., struct ucall_ops *ops)
ucall_init_ops(ops)
and with the SEV selftests in their current form it would look something
like:
sev_vm_create(...)
vm_create_with_ucall(..., ops=ucall_ops_pio_vmgexit)
ucall_init_ops(ops)
is that sort of what you're thinking, or something else?
>
> > > I also don't like having to differentiate between a "shared" and "regular" ucall.
> > > I kind of like having to explicitly pass the ucall object being used, but that
> > > puts undue burden on simple single-vCPU tests.
> >
> > I tried to avoid it, but I got hung up on that fact that pre-allocating
> > arrays/lists of ucall structs needs to be done for each VM, and so we'd
> > end up needing some way for a guest to identify which pool it's ucall
> > struct should be allocated from. But you've gotten around that by just
> > sync_global_to_guest()'ing for each pool at the time ucall_init() is
> > called, so the guest only ever sees it's particular pool. Then the switch
> > from writing GVA to writing GPA solves the translation problem. Nice.
> >
> > >
> > > The inability to read guest private memory is really the only issue, and that can
> > > be easily solved without completely revamping the ucall framework, and without
> > > having to update a huge pile of tests to make them place nice with private memory.
> >
> > I think the first 5 patches in this series are still relevant cleanups
> > vs. having a complete standalone ucall implementation for each arch, and Andrew
> > has also already started looking at other header cleanups related to
> > patch #1, so maybe Paolo would still like to queue those. Would also
> > provide a better starting point for having a centralized allocator for
> > the ucall structs, which you hinted at wanting below.
> >
> > But the subsequent patches that add the ucall_shared() interfaces should
> > probably be set aside for now in favor of your proposal.
> >
> > >
> > > This would also be a good opportunity to clean up the stupidity of tests having to
> > > manually call ucall_init(), drop the unused/pointless @arg from ucall_init(), and
> > > maybe even fix arm64's lurking landmine of not being SMP safe (the address is shared
> > > by all vCPUs).
> >
> > I thought you *didn't* want to update a huge pile of tests :) I suppose
> > it's unavoidable, since with your proposal, having something like ucall_init()
> > being called at some point is required, as opposed to the current
> > implementation where it is optional. Are you intending to have it be
> > called automatically by vm_create*()?
>
> Yeah, I was thinking it could be done at the lowest level vm_create() helper.
> We'll need to expand vm_create() (or add yet another layer to avoid modifying a
> pile of tests) to allow opting out of initializing ucall, e.g. sev_migrate_tests.c
> needs to create multiple concurrent VMs, but happily doesn't need ucall support.
Why does sev_migrate_tests need to opt out? Couldn't it use
ucall_ops_pio_vmgexit like that SEV case above?
I ask because there is a ucall() in the exception handling code where
some unhandled exceptions result in the guest automatically issuing a
ucall(UCALL_UNHANDLED), so even when tests don't use ucall() they
might still rely on it if they enable exception handling. So that might
be an argument for always setting up at least the default ucall_ops_pio
implementation and creating a pool just in case. (or an argument for
dropping the UCALL_HANDLED handling).
>
> > > To reduce the burden on tests and avoid ordering issues with creating vCPUs,
> > > allocate a ucall struct for every possible vCPU when the VM is created and stuff
> > > the GPA of the struct in the struct itself so that the guest can communicate the
> > > GPA instead of the GVA. Then confidential VMs just need to make all structs shared.
> >
> > So a separate call like:
> >
> > ucall_make_shared(vm->ucall_list)
> >
> > ? Might need some good documentation/assertions to make sure it gets
> > called at the right place for confidential VMs, and may need some extra
> > hooks in SEV selftest implementation for switching from private to shared
> > after the memory has already been allocated, but seems reasonable.
>
> Again, I was thinking that it would be done unconditionally by ucall_init(), i.e.
> would be automatically handled by the selftest framework and would Just Work for
> individual tests.
Ok, I'll have to think that through more. Currently with the SEV
selftests as they we have:
sev_vm_create(policy, npages)
vm = vm_create(...)
vm_set_memory_encryption(vm, encrypt_by_default, enc_bit)
//vm_vaddr_alloc_shared() can be used now
The ucall struct allocations would need to go through
vm_vaddr_alloc_shared() to make sure the selftest library tracks/maps
the pages as shared, but that vm_set_memory_encryption() happens too
late if the ucall_init() stuff is done in vm_create(). It should be
possible to pass the vm_set_memory_encryption() arguments directly to
vm_create() to allow for what you're proposing, but I guess we'd need
a new vm_create() wrapper that handles both the
vm_set_memory_encryption() args, along with the ucall_ops above,
something like:
sev_vm_create(policy, npages)
vm = vm_create_coco(..., encrypt_by_default, enc_bit/shared_bit, ucall_ops)
Or were you thinking something else? Just trying to get an idea of how
this will all need to tie in with the SEV selftests and what needs to
change on that end.
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Ard Biesheuvel @ 2022-01-05 17:02 UTC (permalink / raw)
To: Jon Hunter
Cc: Geert Uytterhoeven, Marek Szyprowski, Linux ARM, Russell King,
Nicolas Pitre, Arnd Bergmann, Kees Cook, Keith Packard,
Linus Walleij, Nick Desaulniers, Tony Lindgren,
Krzysztof Kozlowski, Linux Samsung SOC, Linux-Renesas,
linux-tegra@vger.kernel.org
In-Reply-To: <c0d71f87-1329-205c-c4fb-d82d0f118a7b@nvidia.com>
On Wed, 5 Jan 2022 at 17:50, Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 05/01/2022 11:12, Ard Biesheuvel wrote:
>
> ...
>
> > Thanks for the report.
> >
> > It would be helpful if you could provide some more context:
> > - does it happen on a LPAE build too?
>
> Enabling CONFIG_ARM_LPAE does work.
>
> > - does it only happen on SMP capable systems?
> > - does it reproduce on such systems when using only a single CPU?
> > (i.e., pass 'nosmp' on the kernel command line)
>
> Adding 'nosmp' does not help.
>
> > - when passing 'no_console_suspend' on the kernel command line, are
> > any useful diagnostics produced?
>
> Adding 'no_console_suspend' does not produce any interesting logs.
>
> > - is there any way you could tell whether the crash/hang (assuming
> > that is what you are observing) occurs on the suspend path or on
> > resume?
>
> That is not clear. I see it entering suspend, but not clear if it is
> failing on entering suspend or resuming.
>
Thanks a lot for providing this info.
The fact that enabling LPAE makes the issue go away is a fairly strong
hint that one of the CPUs comes up running in an address space that
lacks the stack's vmapping in its copy of the swapper_pg_dir region -
LPAE builds map swapper_pg_dir directly so there it can never go out
of sync.
Given that vmappings are global, and therefore cached in the TLB
across context switches, it is not unlikely that the missing vmapping
of the stack is in a task that runs before suspend, but does not cause
any issues until after the CPU is reset completely (which takes cached
TLB entries down with it)
So in summary, this gives me something to chew on, and hopefully, I
will be able to provide a proper fix shortly.
^ permalink raw reply
* Re: [ERROR: Nothing RPROVIDES 'u-boot-default-env']
From: Patrick Williams @ 2022-01-05 17:01 UTC (permalink / raw)
To: Nikhil V; +Cc: openbmc, akartashev
In-Reply-To: <17e29ef3ecb.f538ffea22697.1377643688691911450@zohocorp.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Wed, Jan 05, 2022 at 04:40:52PM +0530, Nikhil V wrote:
> Trying to implement openbmc on SAMA5D27 development board and to use secure boot feature provided by microchip. To make openbmc more secure.
I don't have much help on your specific problem, but I think there is some
surprise in your use of this chip for a few reasons.
- This isn't really a BMC-oriented chip and is likely missing hardware that
a BMC would typically have for interacting with the host processors.
- The A5 core in this chip is probably slower than the AST2500 (or maybe in
the same ballpark) which is already a generation behind.
- Aspeed has secure boot support also / already.
This isn't to say that you might not be able to get the SAMA5D27 working as a
BMC-like device for your system, but the fact that nobody else has decided to
build a server around it would give me a bit of concern if it showed up in a
system design I was working on.
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/1] perf arm64: Implement --topdown with metrics
From: Andrew Kilroy @ 2022-01-05 16:58 UTC (permalink / raw)
To: John Garry, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, acme@kernel.org, Andi Kleen
Cc: Will Deacon, Mathieu Poirier, Leo Yan, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Namhyung Kim,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <48437bee-9c39-38ba-e990-ba9a6a5378b4@huawei.com>
On 17/12/2021 10:19, John Garry wrote:
>
> And there is no colouring for results which are above/below standard
> thresholds (see stat-shadow.c:get_radio_color()).
>
> My impression is that we're not plugging the results from
> metricgroup__parse_groups_to_evlist() into the --topdown print
> functionality properly.
>
The --topdown kernel event colouring is dictated by a large if-else
statement in stat-shadow.c:perf_stat__print_shadow_stats.
There are branches depending on what is returned by
perf_stat_evsel__is() for example
} else if (perf_stat_evsel__is(evsel, TOPDOWN_FETCH_BUBBLES)) {
double fe_bound = td_fe_bound(cpu, st, &rsd);
if (fe_bound > 0.2)
color = PERF_COLOR_RED;
print_metric(config, ctxp, color, "%8.1f%%", "frontend bound",
fe_bound * 100.);
} else if (perf_stat_evsel__is(evsel, TOPDOWN_SLOTS_RETIRED)) {
Because the patches are enabling metrics (equivalent of the -M
'somemetricname' option), the perf_stat__print_shadow_stats function
always makes calls to generic_metric(), where colours are never picked.
Seeing thresholds like:
retiring > 0.7
fe_bound > 0.2
be_bound > 0.2
bad_spec > 0.1
I'm not sure about adding the colouring really. Are these thresholds
x86 specific?
> Thanks,
> John
Andrew
_______________________________________________
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] ALSA: hda: ALC287: Add Lenovo IdeaPad Slim 9i 14ITL5 speaker quirk
From: Takashi Iwai @ 2022-01-05 16:59 UTC (permalink / raw)
To: Bart Kroon; +Cc: alsa-devel
In-Reply-To: <JAG24R.7NLJGWBF4G8U@tarmack.eu>
On Mon, 13 Dec 2021 19:20:43 +0100,
Bart Kroon wrote:
>
> Hello,
>
> The speaker fixup that is used for the Yoga 7 14ITL5 also applies to
> the IdeaPad Slim 9i 14ITL5. The attached patch applies the quirk to
> initialise the amplifier on the IdeaPad Slim 9i as well.
>
> This is validated to work on my laptop.
>
> Signed-off-by: Bart Kroon <bart@tarmack.eu>
This one was almost forgotten... Now applied with a minor
correction.
At the next time, please put maintainers (me) to Cc, so that it won't
get lost.
Thanks!
Takashi
^ permalink raw reply
* Re: [PATCH rdma-rc] Revert "RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow"
From: Jason Gunthorpe @ 2022-01-05 17:00 UTC (permalink / raw)
To: Maor Gottlieb; +Cc: alaa, chuck.lever, linux-kernel, linux-rdma, tonylu, leon
In-Reply-To: <20211222101312.1358616-1-maorg@nvidia.com>
On Wed, Dec 22, 2021 at 12:13:12PM +0200, Maor Gottlieb wrote:
> This patch is not the full fix and still causes to call traces
> during mlx5_ib_dereg_mr().
>
> This reverts commit f0ae4afe3d35e67db042c58a52909e06262b740f.
>
> Fixes: f0ae4afe3d35 ("RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow")
> Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
> Acked-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 6 +++---
> drivers/infiniband/hw/mlx5/mr.c | 26 ++++++++++++++------------
> 2 files changed, 17 insertions(+), 15 deletions(-)
Applied to for-rc, lets get the correct fix for the next cycle.
Thanks
Jason
^ permalink raw reply
* Re: [RFC PATCH 1/1] perf arm64: Implement --topdown with metrics
From: Andrew Kilroy @ 2022-01-05 16:58 UTC (permalink / raw)
To: John Garry, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, acme@kernel.org, Andi Kleen
Cc: Will Deacon, Mathieu Poirier, Leo Yan, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Namhyung Kim,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <48437bee-9c39-38ba-e990-ba9a6a5378b4@huawei.com>
On 17/12/2021 10:19, John Garry wrote:
>
> And there is no colouring for results which are above/below standard
> thresholds (see stat-shadow.c:get_radio_color()).
>
> My impression is that we're not plugging the results from
> metricgroup__parse_groups_to_evlist() into the --topdown print
> functionality properly.
>
The --topdown kernel event colouring is dictated by a large if-else
statement in stat-shadow.c:perf_stat__print_shadow_stats.
There are branches depending on what is returned by
perf_stat_evsel__is() for example
} else if (perf_stat_evsel__is(evsel, TOPDOWN_FETCH_BUBBLES)) {
double fe_bound = td_fe_bound(cpu, st, &rsd);
if (fe_bound > 0.2)
color = PERF_COLOR_RED;
print_metric(config, ctxp, color, "%8.1f%%", "frontend bound",
fe_bound * 100.);
} else if (perf_stat_evsel__is(evsel, TOPDOWN_SLOTS_RETIRED)) {
Because the patches are enabling metrics (equivalent of the -M
'somemetricname' option), the perf_stat__print_shadow_stats function
always makes calls to generic_metric(), where colours are never picked.
Seeing thresholds like:
retiring > 0.7
fe_bound > 0.2
be_bound > 0.2
bad_spec > 0.1
I'm not sure about adding the colouring really. Are these thresholds
x86 specific?
> Thanks,
> John
Andrew
^ permalink raw reply
* Re: [PATCH v12 07/10] arm64: Introduce stack trace reliability checks in the unwinder
From: Mark Brown @ 2022-01-05 16:58 UTC (permalink / raw)
To: madvenka
Cc: mark.rutland, jpoimboe, ardb, nobuta.keiya, sjitindarsingh,
catalin.marinas, will, jmorris, linux-arm-kernel, live-patching,
linux-kernel
In-Reply-To: <20220103165212.9303-8-madvenka@linux.microsoft.com>
[-- Attachment #1.1: Type: text/plain, Size: 361 bytes --]
On Mon, Jan 03, 2022 at 10:52:09AM -0600, madvenka@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>
> There are some kernel features and conditions that make a stack trace
> unreliable. Callers may require the unwinder to detect these cases.
> E.g., livepatch.
Reviwed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] PCI: iproc: Set all 24 bits of PCI class code
From: Roman Bacik @ 2022-01-05 16:57 UTC (permalink / raw)
To: Pali Rohár
Cc: Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Bjorn Helgaas, bcm-kernel-feedback-list, linux-pci,
linux-arm-kernel, linux-kernel
In-Reply-To: <20220105093552.27542-1-pali@kernel.org>
On Wed, Jan 5, 2022 at 1:36 AM Pali Rohár <pali@kernel.org> wrote:
>
> Register 0x43c in its low 24 bits contains PCI class code.
>
> Update code to set all 24 bits of PCI class code and not only upper 16 bits
> of PCI class code.
>
> Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits
> of normal PCI bridge class.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
>
> ---
> Roman helped me with this change and confirmed that class code is stored
> really in bits [23:0] of custom register 0x43c (normally class code is
> stored in bits [31:8] of pci register 0x08).
>
> This patch depends on patch which adds PCI_CLASS_BRIDGE_PCI_NORMAL macro:
> https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
> ---
> drivers/pci/controller/pcie-iproc.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 3df4ab209253..2519201b0e51 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -789,14 +789,13 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
> return -EFAULT;
> }
>
> - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
> + /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
> #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
> -#define PCI_CLASS_BRIDGE_MASK 0xffff00
> -#define PCI_CLASS_BRIDGE_SHIFT 8
> +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
> iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, &class);
> - class &= ~PCI_CLASS_BRIDGE_MASK;
> - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
> + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> + class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
> iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, class);
>
> --
> 2.20.1
>
Acked-by: Roman Bacik <roman.bacik@broadcom.com>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Bug 1862619] Re: "-serial telnet::xxxx, server" causes "Device 'serial0' is in use"
From: Thomas Huth @ 2022-01-05 16:49 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <158133547000.19789.14380673630783179726.malonedeb@wampee.canonical.com>
Hi Andrew! The QEMU project does not use this bug tracker anymore -
could you please open a new issue here: https://gitlab.com/qemu-
project/qemu/-/issues - Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1862619
Title:
"-serial telnet::xxxx,server" causes "Device 'serial0' is in use"
Status in QEMU:
Fix Released
Bug description:
I start qemu version 4.2.50 in a first terminal :
$ sudo ./qemu-system-hppa -boot d -serial telnet::4441,server -drive
if=scsi,bus=0,index=6,file=./hpux.img,format=raw -serial mon:stdio -D
/tmp/foo -nographic -m 512 -d nochain -cdrom
./HPUX_9.05_Installation_Disc_S700.iso -D /tmp/foo -net
nic,model=tulip -net tap
qemu-system-hppa: -serial telnet::4441,server: info: QEMU waiting for
connection on: disconnected:telnet:0.0.0.0:4441,server
In another terminal, I launch "telnet localhost 4441"
And in the qemu window I have the following error:
Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:220:
qemu-system-hppa: Device 'serial0' is in use
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1862619/+subscriptions
^ permalink raw reply
* Re: [PATCH net-next 11/13] netlink: add net device refcount tracker to struct ethnl_req_info
From: Eric Dumazet @ 2022-01-05 16:58 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Eric Dumazet, Johannes Berg, David S . Miller, netdev
In-Reply-To: <20220105085744.52015420@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
On Wed, Jan 5, 2022 at 8:57 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 04 Jan 2022 17:23:51 +0100 Johannes Berg wrote:
> > > diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
> > > index ea23659fab28..5fe8f4ae2ceb 100644
> > > --- a/net/ethtool/netlink.c
> > > +++ b/net/ethtool/netlink.c
> > > @@ -627,7 +627,6 @@ static void ethnl_default_notify(struct net_device
> > > *dev, unsigned int cmd,
> > > }
> > >
> > > req_info->dev = dev;
> > > - netdev_tracker_alloc(dev, &req_info->dev_tracker, GFP_KERNEL);
> >
> > So I had already tested both this and explicitly doing
> > netdev_tracker_free() when req_info is freed, both work fine.
> >
> > Tested-by: Johannes Berg <johannes@sipsolutions.net>
> >
> > Just wasn't sure it was correct or I was missing something. :)
>
> Hi Eric, I didn't see this one submitted, is it coming?
> No rush, just checking if it fell thru the cracks.
Yes, this is coming ;)
[-- Attachment #2: cleardot.gif --]
[-- Type: image/gif, Size: 43 bytes --]
^ permalink raw reply
* Re: [PATCH v12 07/10] arm64: Introduce stack trace reliability checks in the unwinder
From: Mark Brown @ 2022-01-05 16:58 UTC (permalink / raw)
To: madvenka
Cc: mark.rutland, jpoimboe, ardb, nobuta.keiya, sjitindarsingh,
catalin.marinas, will, jmorris, linux-arm-kernel, live-patching,
linux-kernel
In-Reply-To: <20220103165212.9303-8-madvenka@linux.microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
On Mon, Jan 03, 2022 at 10:52:09AM -0600, madvenka@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>
> There are some kernel features and conditions that make a stack trace
> unreliable. Callers may require the unwinder to detect these cases.
> E.g., livepatch.
Reviwed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: Roman Bacik @ 2022-01-05 16:57 UTC (permalink / raw)
To: Pali Rohár
Cc: Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Bjorn Helgaas, bcm-kernel-feedback-list, linux-pci,
linux-arm-kernel, linux-kernel
In-Reply-To: <20220105093552.27542-1-pali@kernel.org>
On Wed, Jan 5, 2022 at 1:36 AM Pali Rohár <pali@kernel.org> wrote:
>
> Register 0x43c in its low 24 bits contains PCI class code.
>
> Update code to set all 24 bits of PCI class code and not only upper 16 bits
> of PCI class code.
>
> Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits
> of normal PCI bridge class.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
>
> ---
> Roman helped me with this change and confirmed that class code is stored
> really in bits [23:0] of custom register 0x43c (normally class code is
> stored in bits [31:8] of pci register 0x08).
>
> This patch depends on patch which adds PCI_CLASS_BRIDGE_PCI_NORMAL macro:
> https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
> ---
> drivers/pci/controller/pcie-iproc.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 3df4ab209253..2519201b0e51 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -789,14 +789,13 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
> return -EFAULT;
> }
>
> - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
> + /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
> #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
> -#define PCI_CLASS_BRIDGE_MASK 0xffff00
> -#define PCI_CLASS_BRIDGE_SHIFT 8
> +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
> iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, &class);
> - class &= ~PCI_CLASS_BRIDGE_MASK;
> - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
> + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> + class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
> iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, class);
>
> --
> 2.20.1
>
Acked-by: Roman Bacik <roman.bacik@broadcom.com>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
^ permalink raw reply
* Re: [PATCH v12 05/10] arm64: Copy unwind arguments to unwind_state
From: Mark Brown @ 2022-01-05 16:57 UTC (permalink / raw)
To: madvenka
Cc: mark.rutland, jpoimboe, ardb, nobuta.keiya, sjitindarsingh,
catalin.marinas, will, jmorris, linux-arm-kernel, live-patching,
linux-kernel
In-Reply-To: <20220103165212.9303-6-madvenka@linux.microsoft.com>
[-- Attachment #1.1: Type: text/plain, Size: 378 bytes --]
On Mon, Jan 03, 2022 at 10:52:07AM -0600, madvenka@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>
> Copy the following arguments passed to arch_stack_walk() to unwind_state
> so that they can be passed to unwind functions via unwind_state rather
> than as separate arguments:
Reviwed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [LTP] LTP Release preparations
From: Petr Vorel @ 2022-01-05 16:57 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: Gabriel Krisman Bertazi, LTP List
In-Reply-To: <YdWw4rza2wHGQqA9@yuki>
> Hi!
> > > As usuall it's time to start preparing for the next release.
> > > Given the amount patches waiting for the review I guess that we should
> > > try to get reviewed and merged as much as possible in the next few days.
> > > I would go for git freeze at 14. 1. as that would give us a week for
> > > pre-release testing and the release would be, as usuall, finalized
> > > around the 21. 1. Feel free to reply if you think that the schedulle
> > > should be different.
> > > Also if there are patches that you think should be merged before the
> > > release let me know ASAP so we can have a look soon enough.
> > Maybe that's a good time to say I did not understand the resolution on the
> > discussion [1] about timing of merging tests for new (i.e. v5.16) features.
Good point, I hoped we'd release LTP after v5.16 to get fanotify and IMA [1]
testes merged before release anyway.
> I guess that's because we haven't ended up with one as the discussion
> faded away before christmas break. I guess I will read that again and
> try to do something about it.
+1 thanks Cyril!
Kind regards,
Petr
[1] https://patchwork.ozlabs.org/project/ltp/list/?series=265664
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* Re: [PATCH net-next 11/13] netlink: add net device refcount tracker to struct ethnl_req_info
From: Jakub Kicinski @ 2022-01-05 16:57 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet; +Cc: Johannes Berg, David S . Miller, netdev
In-Reply-To: <e2f0315e65052b7ff798e61100a02f624a609afb.camel@sipsolutions.net>
On Tue, 04 Jan 2022 17:23:51 +0100 Johannes Berg wrote:
> > diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
> > index ea23659fab28..5fe8f4ae2ceb 100644
> > --- a/net/ethtool/netlink.c
> > +++ b/net/ethtool/netlink.c
> > @@ -627,7 +627,6 @@ static void ethnl_default_notify(struct net_device
> > *dev, unsigned int cmd,
> > }
> >
> > req_info->dev = dev;
> > - netdev_tracker_alloc(dev, &req_info->dev_tracker, GFP_KERNEL);
>
> So I had already tested both this and explicitly doing
> netdev_tracker_free() when req_info is freed, both work fine.
>
> Tested-by: Johannes Berg <johannes@sipsolutions.net>
>
> Just wasn't sure it was correct or I was missing something. :)
Hi Eric, I didn't see this one submitted, is it coming?
No rush, just checking if it fell thru the cracks.
^ permalink raw reply
* Re: [PATCH v12 05/10] arm64: Copy unwind arguments to unwind_state
From: Mark Brown @ 2022-01-05 16:57 UTC (permalink / raw)
To: madvenka
Cc: mark.rutland, jpoimboe, ardb, nobuta.keiya, sjitindarsingh,
catalin.marinas, will, jmorris, linux-arm-kernel, live-patching,
linux-kernel
In-Reply-To: <20220103165212.9303-6-madvenka@linux.microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Mon, Jan 03, 2022 at 10:52:07AM -0600, madvenka@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>
> Copy the following arguments passed to arch_stack_walk() to unwind_state
> so that they can be passed to unwind functions via unwind_state rather
> than as separate arguments:
Reviwed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH u-boot-pci] pci: iproc: Set all 24 bits of PCI class code
From: Roman Bacik @ 2022-01-05 16:55 UTC (permalink / raw)
To: Pali Rohár
Cc: Bharat Gooty, Simon Glass, Stefan Roese, U-Boot Mailing List
In-Reply-To: <20220105095020.28249-1-pali@kernel.org>
On Wed, Jan 5, 2022 at 1:50 AM Pali Rohár <pali@kernel.org> wrote:
>
> Register 0x43c in its low 24 bits contains PCI class code.
>
> Update code to set all 24 bits of PCI class code and not only upper 16 bits
> of PCI class code.
>
> Use standard U-Boot macro (PCI_CLASS_BRIDGE_PCI << 8) for constructing all
> 24-bits of PCI class for PCI bridge Normal decode.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
>
> ---
> Roman helped me with this change and confirmed that class code is stored
> really in bits [23:0] of custom register 0x43c (normally class code is
> stored in bits [31:8] of pci register 0x08).
> ---
> drivers/pci/pcie_iproc.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pcie_iproc.c b/drivers/pci/pcie_iproc.c
> index be03dcbd97c0..fe68e417ae80 100644
> --- a/drivers/pci/pcie_iproc.c
> +++ b/drivers/pci/pcie_iproc.c
> @@ -1127,15 +1127,14 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
> u32 link_status, class;
>
> pcie->link_is_active = false;
> - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
> + /* force class to PCI bridge Normal decode (0x060400) */
> #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
> -#define PCI_CLASS_BRIDGE_MASK 0xffff00
> -#define PCI_CLASS_BRIDGE_SHIFT 8
> +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
> iproc_pci_raw_config_read32(pcie, 0,
> PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, &class);
> - class &= ~PCI_CLASS_BRIDGE_MASK;
> - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
> + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> + class |= (PCI_CLASS_BRIDGE_PCI << 8);
> iproc_pci_raw_config_write32(pcie, 0,
> PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, class);
> --
> 2.20.1
>
Acked-by: Roman Bacik <roman.bacik@broadcom.com>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
^ permalink raw reply
* [bitbake][dunfell][1.46][PATCH 1/1] cooker/command: Add a dummy event for tinfoil testing
From: Steve Sakoman @ 2022-01-05 16:56 UTC (permalink / raw)
To: bitbake-devel
In-Reply-To: <cover.1641401726.git.steve@sakoman.com>
From: Richard Purdie <richard.purdie@linuxfoundation.org>
We need a command genetating an event to test through the tinfoil API. The
current test has IO load issues so add a dummy version which won't have
the IO constraints.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a144178584394ea0700ffc2f2bfac94e8690effc)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
lib/bb/command.py | 10 ++++++++++
lib/bb/cooker.py | 5 +++++
2 files changed, 15 insertions(+)
diff --git a/lib/bb/command.py b/lib/bb/command.py
index 07128027..98c945ed 100644
--- a/lib/bb/command.py
+++ b/lib/bb/command.py
@@ -624,6 +624,16 @@ class CommandsAsync:
command.finishAsyncCommand()
findFilesMatchingInDir.needcache = False
+ def testCookerCommandEvent(self, command, params):
+ """
+ Dummy command used by OEQA selftest to test tinfoil without IO
+ """
+ pattern = params[0]
+
+ command.cooker.testCookerCommandEvent(pattern)
+ command.finishAsyncCommand()
+ testCookerCommandEvent.needcache = False
+
def findConfigFilePath(self, command, params):
"""
Find the path of the requested configuration file
diff --git a/lib/bb/cooker.py b/lib/bb/cooker.py
index 8d9ca680..ac54d437 100644
--- a/lib/bb/cooker.py
+++ b/lib/bb/cooker.py
@@ -1019,6 +1019,11 @@ class BBCooker:
if matches:
bb.event.fire(bb.event.FilesMatchingFound(filepattern, matches), self.data)
+ def testCookerCommandEvent(self, filepattern):
+ # Dummy command used by OEQA selftest to test tinfoil without IO
+ matches = ["A", "B"]
+ bb.event.fire(bb.event.FilesMatchingFound(filepattern, matches), self.data)
+
def findProviders(self, mc=''):
return bb.providers.findProviders(self.databuilder.mcdata[mc], self.recipecaches[mc], self.recipecaches[mc].pkg_pn)
--
2.25.1
^ 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.