* [Intel-gfx] [PATCH i-g-t] tests/i915/userptr: fix mapping type
From: Matthew Auld @ 2022-01-05 17:21 UTC (permalink / raw)
To: igt-dev; +Cc: Thomas Hellström, intel-gfx, Priyanka Dandamudi
We need to use the FIXED mapping type on discrete platforms.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Priyanka Dandamudi <priyanka.dandamudi@intel.com>
---
tests/i915/gem_userptr_blits.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 3464db66..a4dca4c0 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -2185,7 +2185,10 @@ static void test_probe(int fd)
*/
memset(&mmap_offset, 0, sizeof(mmap_offset));
mmap_offset.handle = gem_create(fd, PAGE_SIZE);
- mmap_offset.flags = I915_MMAP_OFFSET_WB;
+ if (gem_has_lmem(fd))
+ mmap_offset.flags = I915_MMAP_OFFSET_FIXED;
+ else
+ mmap_offset.flags = I915_MMAP_OFFSET_WB;
igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_OFFSET, &mmap_offset), 0);
for (unsigned long pass = 0; pass < 4 * 4 * 4 * 4 * 4; pass++) {
--
2.31.1
^ permalink raw reply related
* [GIT PULL] seccomp updates for v5.17-rc1
From: Kees Cook @ 2022-01-05 17:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Andy Lutomirski, Eric W. Biederman, Kees Cook,
linux-kselftest, Will Drewry
Hi Linus,
Please pull these seccomp selftest updates for v5.17-rc1. The core
seccomp code hasn't changed for this cycle, but the selftests were
improved while helping to debug the recent signal handling refactoring
work Eric did.
Thanks!
-Kees
The following changes since commit d9bbdbf324cda23aa44873f505be77ed4b61d79c:
x86: deduplicate the spectre_v2_user documentation (2021-10-04 12:12:57 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v5.17-rc1
for you to fetch changes up to 1e6d69c7b9cd7735bbf4c6754ccbb9cce8bd8ff4:
selftests/seccomp: Report event mismatches more clearly (2021-11-03 12:02:07 -0700)
----------------------------------------------------------------
seccomp updates for v5.17-rc1
- Improve seccomp selftests in support of signal handler refactoring (Kees Cook)
----------------------------------------------------------------
Kees Cook (2):
selftests/seccomp: Stop USER_NOTIF test if kcmp() fails
selftests/seccomp: Report event mismatches more clearly
tools/testing/selftests/seccomp/seccomp_bpf.c | 56 ++++++++++++++++++++++++---
1 file changed, 50 insertions(+), 6 deletions(-)
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 1/2] gnss: add USB support
From: kernel test robot @ 2022-01-05 17:20 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 6163 bytes --]
CC: kbuild-all(a)lists.01.org
In-Reply-To: <20211220111901.23206-2-johan@kernel.org>
References: <20211220111901.23206-2-johan@kernel.org>
TO: Johan Hovold <johan@kernel.org>
Hi Johan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on johan-usb-serial/usb-next]
[also build test WARNING on usb/usb-testing linus/master balbi-usb/testing/next peter-chen-usb/for-usb-next v5.16-rc8]
[cannot apply to next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Johan-Hovold/gnss-add-USB-support/20211220-192005
base: https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git usb-next
:::::: branch date: 2 weeks ago
:::::: commit date: 2 weeks ago
config: parisc-randconfig-m031-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060110.w9bLWwnW-lkp(a)intel.com/config)
compiler: hppa-linux-gcc (GCC) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
drivers/gnss/usb.c:155 gnss_usb_probe() warn: missing error code 'ret'
vim +/ret +155 drivers/gnss/usb.c
8b66a253fbf538 Johan Hovold 2021-12-20 116
8b66a253fbf538 Johan Hovold 2021-12-20 117 static int gnss_usb_probe(struct usb_interface *intf, const struct usb_device_id *id)
8b66a253fbf538 Johan Hovold 2021-12-20 118 {
8b66a253fbf538 Johan Hovold 2021-12-20 119 struct usb_device *udev = interface_to_usbdev(intf);
8b66a253fbf538 Johan Hovold 2021-12-20 120 struct usb_endpoint_descriptor *in, *out;
8b66a253fbf538 Johan Hovold 2021-12-20 121 struct gnss_device *gdev;
8b66a253fbf538 Johan Hovold 2021-12-20 122 struct gnss_usb *gusb;
8b66a253fbf538 Johan Hovold 2021-12-20 123 struct urb *urb;
8b66a253fbf538 Johan Hovold 2021-12-20 124 size_t buf_len;
8b66a253fbf538 Johan Hovold 2021-12-20 125 void *buf;
8b66a253fbf538 Johan Hovold 2021-12-20 126 int ret;
8b66a253fbf538 Johan Hovold 2021-12-20 127
8b66a253fbf538 Johan Hovold 2021-12-20 128 ret = usb_find_common_endpoints(intf->cur_altsetting, &in, &out, NULL,
8b66a253fbf538 Johan Hovold 2021-12-20 129 NULL);
8b66a253fbf538 Johan Hovold 2021-12-20 130 if (ret)
8b66a253fbf538 Johan Hovold 2021-12-20 131 return ret;
8b66a253fbf538 Johan Hovold 2021-12-20 132
8b66a253fbf538 Johan Hovold 2021-12-20 133 gusb = kzalloc(sizeof(*gusb), GFP_KERNEL);
8b66a253fbf538 Johan Hovold 2021-12-20 134 if (!gusb)
8b66a253fbf538 Johan Hovold 2021-12-20 135 return -ENOMEM;
8b66a253fbf538 Johan Hovold 2021-12-20 136
8b66a253fbf538 Johan Hovold 2021-12-20 137 gdev = gnss_allocate_device(&intf->dev);
8b66a253fbf538 Johan Hovold 2021-12-20 138 if (!gdev) {
8b66a253fbf538 Johan Hovold 2021-12-20 139 ret = -ENOMEM;
8b66a253fbf538 Johan Hovold 2021-12-20 140 goto err_free_gusb;
8b66a253fbf538 Johan Hovold 2021-12-20 141 }
8b66a253fbf538 Johan Hovold 2021-12-20 142
8b66a253fbf538 Johan Hovold 2021-12-20 143 gdev->ops = &gnss_usb_gnss_ops;
8b66a253fbf538 Johan Hovold 2021-12-20 144 gdev->type = GNSS_TYPE_NMEA;
8b66a253fbf538 Johan Hovold 2021-12-20 145 gnss_set_drvdata(gdev, gusb);
8b66a253fbf538 Johan Hovold 2021-12-20 146
8b66a253fbf538 Johan Hovold 2021-12-20 147 urb = usb_alloc_urb(0, GFP_KERNEL);
8b66a253fbf538 Johan Hovold 2021-12-20 148 if (!urb)
8b66a253fbf538 Johan Hovold 2021-12-20 149 goto err_put_gdev;
8b66a253fbf538 Johan Hovold 2021-12-20 150
8b66a253fbf538 Johan Hovold 2021-12-20 151 buf_len = max(usb_endpoint_maxp(in), GNSS_USB_READ_BUF_LEN);
8b66a253fbf538 Johan Hovold 2021-12-20 152
8b66a253fbf538 Johan Hovold 2021-12-20 153 buf = kzalloc(buf_len, GFP_KERNEL);
8b66a253fbf538 Johan Hovold 2021-12-20 154 if (!buf)
8b66a253fbf538 Johan Hovold 2021-12-20 @155 goto err_free_urb;
8b66a253fbf538 Johan Hovold 2021-12-20 156
8b66a253fbf538 Johan Hovold 2021-12-20 157 usb_fill_bulk_urb(urb, udev,
8b66a253fbf538 Johan Hovold 2021-12-20 158 usb_rcvbulkpipe(udev, usb_endpoint_num(in)),
8b66a253fbf538 Johan Hovold 2021-12-20 159 buf, buf_len, gnss_usb_rx_complete, gusb);
8b66a253fbf538 Johan Hovold 2021-12-20 160
8b66a253fbf538 Johan Hovold 2021-12-20 161 gusb->intf = intf;
8b66a253fbf538 Johan Hovold 2021-12-20 162 gusb->udev = udev;
8b66a253fbf538 Johan Hovold 2021-12-20 163 gusb->gdev = gdev;
8b66a253fbf538 Johan Hovold 2021-12-20 164 gusb->read_urb = urb;
8b66a253fbf538 Johan Hovold 2021-12-20 165 gusb->write_pipe = usb_sndbulkpipe(udev, usb_endpoint_num(out));
8b66a253fbf538 Johan Hovold 2021-12-20 166
8b66a253fbf538 Johan Hovold 2021-12-20 167 ret = gnss_register_device(gdev);
8b66a253fbf538 Johan Hovold 2021-12-20 168 if (ret)
8b66a253fbf538 Johan Hovold 2021-12-20 169 goto err_free_buf;
8b66a253fbf538 Johan Hovold 2021-12-20 170
8b66a253fbf538 Johan Hovold 2021-12-20 171 usb_set_intfdata(intf, gusb);
8b66a253fbf538 Johan Hovold 2021-12-20 172
8b66a253fbf538 Johan Hovold 2021-12-20 173 return 0;
8b66a253fbf538 Johan Hovold 2021-12-20 174
8b66a253fbf538 Johan Hovold 2021-12-20 175 err_free_buf:
8b66a253fbf538 Johan Hovold 2021-12-20 176 kfree(buf);
8b66a253fbf538 Johan Hovold 2021-12-20 177 err_free_urb:
8b66a253fbf538 Johan Hovold 2021-12-20 178 usb_free_urb(urb);
8b66a253fbf538 Johan Hovold 2021-12-20 179 err_put_gdev:
8b66a253fbf538 Johan Hovold 2021-12-20 180 gnss_put_device(gdev);
8b66a253fbf538 Johan Hovold 2021-12-20 181 err_free_gusb:
8b66a253fbf538 Johan Hovold 2021-12-20 182 kfree(gusb);
8b66a253fbf538 Johan Hovold 2021-12-20 183
8b66a253fbf538 Johan Hovold 2021-12-20 184 return ret;
8b66a253fbf538 Johan Hovold 2021-12-20 185 }
8b66a253fbf538 Johan Hovold 2021-12-20 186
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ 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: 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: <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.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [LTP] [PATCH 2/2] ustat0{1, 2}: Mark failure on Btrfs with known-fail tag
From: Petr Vorel @ 2022-01-05 17:16 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: ltp
In-Reply-To: <YdQpS0WPRvz4vZup@yuki>
Hi Cyril,
> > + .tags = (const struct tst_tag[]) {
> > + {"known-fail", "ustat() is known to fail with EINVAL on Btrfs"},
> ^
> Maybe we should just remove the
> "known to fail" from these messages.
> Since the code in the library will print:
> ---
> You _MAY_ be hit by known kernel failures:
> ustat() is known to fail with EINVAL on Btrfs
> ---
> so the 'known to fail' part is redundant here.
> What about:
> ---
> You _MAY_ be hit by known kernel failures:
> ustat() fails with EINVAL on Btrfs
> ---
+1
> Other than this I think that this is a good way how to put these kind of
> hints into the testcases.
> Also I do wonder if there is a good URL that would contain more verbose
> description of the problem but I guess there isn't. Well maybe this one:
> https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg95697.html
Let's use lore.
https://lore.kernel.org/linux-btrfs/CAB=NE6X2-mbZwVFnKUwjRmTGp3auZFHQXJ1h_YTJ2driUeoR+A@mail.gmail.com/
But I'd put Josef Bacik's reply as he's a maintainer:
https://lore.kernel.org/linux-btrfs/e7e867b8-b57a-7eb2-2432-1627bd3a88fb@toxicpanda.com/
> Not sure how to encode that, maybe just add it to the test top level
> comment?
I'd prefer to have it in metadata html/pdf and in known-bug section.
Thus I'd prefer:
.tags = (const struct tst_tag[]) {
{"known-fail", "ustat() is known to fail with EINVAL on Btrfs, see "
"https://lore.kernel.org/linux-btrfs/e7e867b8-b57a-7eb2-2432-1627bd3a88fb@toxicpanda.com/"
},
{}
But while this is obviously ok for test output:
$ ./ustat01 -h
...
Tags
----
known-fail: ustat() is known to fail with EINVAL on Btrfs, see https://lore.kernel.org/linux-btrfs/e7e867b8-b57a-7eb2-2432-1627bd3a88fb@toxicpanda.com/
It gets parsed as new line:
"ustat01": {
"tags": [
[
"known-fail",
"ustat() is known to fail with EINVAL on Btrfs, see ",
"https://lore.kernel.org/linux-btrfs/e7e867b8-b57a-7eb2-2432-1627bd3a88fb@toxicpanda.com/"
]
],
"fname": "testcases/kernel/syscalls/ustat/ustat01.c"
}
Unless you think it's useful to expect that tag values can have longer input and
thus testinfo.pl should use all array items (except the first which is key),
I'd go the easy way and put the link only to top level docparse section as you
suggested.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* Re: [PATCH] RDMA: null pointer in __ib_umem_release causes kernel panic
From: Trond Myklebust @ 2022-01-05 17:16 UTC (permalink / raw)
To: jgg@nvidia.com
Cc: linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org,
trondmy@kernel.org
In-Reply-To: <20220105160916.GT2328285@nvidia.com>
On Wed, 2022-01-05 at 12:09 -0400, Jason Gunthorpe wrote:
> On Wed, Jan 05, 2022 at 03:02:34PM +0000, Trond Myklebust wrote:
> > On Wed, 2022-01-05 at 10:37 -0400, Jason Gunthorpe wrote:
> > > On Wed, Jan 05, 2022 at 09:18:41AM -0500,
> > > trondmy@kernel.org wrote:
> > > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > >
> > > > When doing RPC/RDMA, we're seeing a kernel panic when
> > > > __ib_umem_release()
> > > > iterates over the scatter gather list and hits NULL pages.
> > > >
> > > > It turns out that commit 79fbd3e1241c ended up changing the
> > > > iteration
> > > > from being over only the mapped entries to being over the
> > > > original
> > > > list
> > > > size.
> > >
> > > You mean this?
> > >
> > > - for_each_sg(umem->sg_head.sgl, sg, umem->sg_nents, i)
> > > + for_each_sgtable_sg(&umem->sgt_append.sgt, sg, i)
> > >
> > > I don't see what changed there? The invarient should be that
> > >
> > > umem->sg_nents == sgt->orig_nents
> > >
> > > > @@ -55,7 +55,7 @@ static void __ib_umem_release(struct
> > > > ib_device
> > > > *dev, struct ib_umem *umem, int d
> > > > ib_dma_unmap_sgtable_attrs(dev, &umem-
> > > > > sgt_append.sgt,
> > > > DMA_BIDIRECTIONAL,
> > > > 0);
> > > >
> > > > - for_each_sgtable_sg(&umem->sgt_append.sgt, sg, i)
> > > > + for_each_sgtable_dma_sg(&umem->sgt_append.sgt, sg, i)
> > > > unpin_user_page_range_dirty_lock(sg_page(sg),
> > >
> > > Calling sg_page() from under a dma_sg iterator is unconditionally
> > > wrong..
> > >
> > > More likely your case is something has gone wrong when the
> > > sgtable
> > > was
> > > created and it has the wrong value in orig_nents..
> >
> > Can you define "wrong value" in this case? Chuck's RPC/RDMA code
> > appears to call ib_alloc_mr() with an 'expected maximum number of
> > entries' (depth) in net/sunrpc/xprtrdma/frwr_ops.c:frwr_mr_init().
> >
> > It then fills that table with a set of n <= depth pages in
> > net/sunrpc/xprtrdma/frwr_ops.c:frwr_map() and calls ib_dma_map_sg()
> > to
> > map them, and then adjusts the sgtable with a call to
> > ib_map_mr_sg().
>
> I'm confused, RPC/RDMA should never touch a umem at all.
>
> Is this really the other bug where user and kernel MR are getting
> confused?
>
As far as I know, RPC/RDMA is just using the RDMA api to register and
unregister chunks of memory, so it is definitely not directly touching
the umem.
Let me just copy/paste the stack dump that we got. This was a 5.15.12
kernel running on Azure with an infiniband setup. It's a little garbled
(sorry) but the stack trace itself is fairly clear that this is
happening on transport teardown and that we're iterating through a NULL
page.
2022-01-04 17:53:24 kernel: [ 2922.654038] nf[s: 2922.656486] BUG:
kernel NULL pointer dereference, address: 0000000000000000
[ 2922.660304] #PF: supervisor read access in kernel mode
serv[er 1722.1962.20..662320] #PF: error_code(0x0000) - not-present
page
[ 2922.664606] PGD 1d6c381067 P4D 1d6c381067 PUD 1d0c93e067 PMD 0
2[1 no2t9 r2espo2ndi.n667089] Oops: 0000 [#1] SMP NOPTI
[ 2922.668823] CPU: 27 PID: 11384 Comm: kworker/u241:4 Kdump: loaded
Tainted: G W 5.15.12-200.pd.17715.el7.x86_64 #1
73695] Hardware name: Microsoft Corporation Virtual Machine/Virtual
Machine, BIOS 090008 12/07/2018
[ 2922.677741] Workqueue: xprtiod xprt_autoclose [sunrpc]
[202 2-2019-042 217.:5679875] RIP: 0010:__ib_umem_release+0x7a/0xa0
[ib_uverbs]
[ 2922.682325] Code: f6 cb 48 89 ef e8 16 90 2e cc 48 89 c5 41 39 5c 24
5c 77 cd 5b 49 8d 7c 24 50 5d 41 5c 41 5d e9 ec 96 2e cc 41 bd 01 00 00
00 <48> 8b 3f 48 85 ff 74 9f 41 8b 54 24 5c 49 8b 74 24 50 45 31 c0 31
3:24[ k2e92rn2.el6: [ 920363] RSP: 0018:ffffb53dee517d28 EFLAGS:
00010246
[ 2922.692787] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
ffff9f222edfa180
[92 2.2692540428.]6 nf9s:5675] RDX: 0000000000000001 RSI:
ffff9f31b0dc4000 RDI: 0000000000000000
[ 2922.698735] RBP: ffff9f31b0dc4000 R08: 0000000000000000 R09:
0000000000000000
s[er ver2 19722.126.0.701658] R10: ffff9f3ddfb69680 R11:
ffffb53dee517d50 R12: ffff9f31b0dc4000
[ 2922.704764] R13: 0000000000000000 R14: 0000000000000000 R15:
ffff9f23f2cc09b0
[. 212 n9ot2 re2s.po7nd0i8268] FS: 0000000000000000(0000)
GS:ffff9f3d0fcc0000(0000) knlGS:0000000000000000
[ 2922.713056] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
ng[, st2il9l22 .tr7y1in5g925] CR2: 0000000000000000 CR3:
0000001dafdb6005 CR4: 0000000000370ee0
[ 2922.720003] Call Trace:
202229-2021.-047 127:1202] <TASK>
[ 2922.722467] ib_umem_release+0x2a/0x90 [ib_uverbs]
53:24[ ke rn2el9: [2 2.724829] mlx5_ib_dereg_mr+0x1fe/0x3d0 [mlx5_ib]
[ 2922.727447] ib_dereg_mr_user+0x40/0xa0 [ib_core]
2922.6[540 51]2 nfs922.729658] frwr_mr_release+0x20/0x70 [rpcrdma]
[ 2922.732133] rpcrdma_xprt_disconnect+0x2b4/0x3a0 [rpcrdma]
[: se2rve9r 1272.126..734753] xprt_rdma_close+0xe/0x30 [rpcrdma]
[ 2922.737096] xprt_autoclose+0x52/0xf0 [sunrpc]
0.[21 no2t r9es2pon2d.739248] process_one_work+0x1f1/0x390
[ 2922.741247] worker_thread+0x53/0x3e0
ing[, s2til9l try2in2.743081] ? process_one_work+0x390/0x390
[ 2922.745341] kthread+0x127/0x150
[
2922.747185] ? set_kthread_struct+0x40/0x40
[ 2922.749685] ret_from_fork+0x22/0x30
[ 2922.751889] </TASK>
[ 2922.753068] Modules linked in: nfsv3 bpf_preload veth
nfs_layout_flexfiles auth_name rpcsec_gss_krb5 nfsv4 dns_resolver
nfsidmap nfs fscache netfs xt_nat xt_MASQUERADE nf_conntrack_netlink
xt_addrtypebr_netfilter bridge stp llc nfsd auth_rpcgss overlay nfs_acl
lockd grace xt_owner nf_nat_ftp nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_ftp xt_CT xt_sctp ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack
ip6table_nat ip6table_mangle ip6table_security ip6table_raw iptable_nat
nf_nat iptable_mangle iptable_security iptable_raw nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 ip_set nfnetlink ip6table_filter
ip6_tables iptable_filter bonding ipmi_msghandler rpcrdma sunrpc
rdma_ucm ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib
iw_cm ib_cm mlx5_ib raid0 ib_uverbs ib_core vfat fat mlx5_core nvme
mlxfw psample nvme_core tls intel_rapl_msr intel_rapl_common
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pci_hyperv hyperv_drm
hv_balloon
[ 2922.753108] hv_utils hyperv_keyboard hid_hyperv pci_hyperv_intf
drm_kms_helper cec drm i2c_piix4 hyperv_fb dm_multipath ip_tables xfs
hv_storvsc hv_netvsc scsi_transport_fc crc32c_intel ata_generic
hv_vmbus pata_acpi
[ 2922.803987] CR2: 0000000000000000
[ 2922.805713] ---[ end trace 450d08bd4a337f29 ]---
[ 2922.808718] RIP: 0010:__ib_umem_release+0x7a/0xa0 [ib_uverbs]
[ 2922.812103] Code: f6 cb 48 89 ef e8 16 90 2e cc 48 89 c5 41 39 5c 24
5c 77 cd 5b 49 8d 7c 24 50 5d 41 5c 41 5d e9 ec 96 2e cc 41 bd 01 00 00
00 <48> 8b 3f 48 85 ff 74 9f 41 8b 54 24 5c 49 8b 74 24 50 45 31 c0 31
[ 2922.821369] RSP: 0018:ffffb53dee517d28 EFLAGS: 00010246
[ 2922.824135] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
ffff9f222edfa180
[ 2922.827639] RDX: 0000000000000001 RSI: ffff9f31b0dc4000 RDI:
0000000000000000
[ 2922.831121] RBP: ffff9f31b0dc4000 R08: 0000000000000000 R09:
0000000000000000
[ 2922.834528] R10: ffff9f3ddfb69680 R11: ffffb53dee517d50 R12:
ffff9f31b0dc4000
[ 2922.838042] R13: 0000000000000000 R14: 0000000000000000 R15:
ffff9f23f2cc09b0
[ 2922.841442] FS: 0000000000000000(0000) GS:ffff9f3d0fcc0000(0000)
knlGS:0000000000000000
[ 2922.845340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2922.848327] CR2: 0000000000000000 CR3: 0000001dafdb6005 CR4:
0000000000370ee0
[ 2922.852791] Kernel panic - not syncing: Fatal exception
[ 2922.858167] Kernel Offset: 0xc000000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
^ permalink raw reply
* [xen-unstable-smoke test] 167610: tolerable all pass - PUSHED
From: osstest service owner @ 2022-01-05 17:14 UTC (permalink / raw)
To: xen-devel
flight 167610 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167610/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass
test-armhf-armhf-xl 15 migrate-support-check fail never pass
test-armhf-armhf-xl 16 saverestore-support-check fail never pass
version targeted for testing:
xen 31f3bc97f4508687215e459a5e35676eecf1772b
baseline version:
xen af0c5430a82c77432729d61c9b409dd32c477b20
Last test of basis 167602 2022-01-04 10:02:48 Z 1 days
Testing same since 167610 2022-01-05 13:01:38 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD <anthony.perard@citrix.com>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-libvirt pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
To xenbits.xen.org:/home/xen/git/xen.git
af0c5430a8..31f3bc97f4 31f3bc97f4508687215e459a5e35676eecf1772b -> smoke
^ permalink raw reply
* Rational behind partial AVX support in Qemu
From: Stevie Lavern @ 2022-01-05 17:09 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
Hello,
I'm currently testing various binaries under qemu linux user and went into
a strange bug.
Here is the TLDR: is there a reason to allow VEX.L to be 1 when not
supporting AVX instructions? Crashing with illegal op may save some time
and headache to users.
And now for some context:
One of my test binaries had some AVX instructions and crashed in a weird
way.
As I understand AVX is not supported, and so a Qemu crash should be
expected.
However, in this instance, it's the guest that crashed, long after the
offending AVX instruction.
The faulty instruction was a `vmovups ymmword ptr [rsp], ymm0`.
Looking into i386/translate.c, it seems that it is correctly decoded but
its generation (see 'case 0x111' in `gen_sse`) is invalid.
Indeed, while the VEX prefix is correctly decoded, its VEX.L bit is never
used during the instruction generation and is always assumed to be 0.
Therefore, the instruction generated is a `vmovups xmmword ptr [rsp],
xmm0`, using a 128bits register instead of the orignal one using a 256bits
register.
My understanding is that the VEX prefix and 256 bits registers where
introduced by AVX. As Qemu does not support AVX, is there any kind of
reason not to crash (illegalop) when VEX.L = 1?
Best regards,
Thanks,
Stevie
[-- Attachment #2: Type: text/html, Size: 1551 bytes --]
^ permalink raw reply
* [GIT PULL] pstore update for v5.17-rc1
From: Kees Cook @ 2022-01-05 17:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook, Uwe Kleine-König
Hi Linus,
Please pull this tiny pstore update for v5.17-rc1. The pstore tree has
been pretty quiet, which just a single change queued up.
Thanks!
-Kees
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.17-rc1
for you to fetch changes up to a5d05b07961a2df47d3b4aae3bdae61ac095a43c:
pstore/ftrace: Allow immediate recording (2021-11-18 10:29:52 -0800)
----------------------------------------------------------------
pstore update for v5.17-rc1
- Add boot param for early ftrace recording in pstore (Uwe Kleine-König)
----------------------------------------------------------------
Uwe Kleine-König (1):
pstore/ftrace: Allow immediate recording
fs/pstore/ftrace.c | 46 ++++++++++++++++++++++++++++++----------------
1 file changed, 30 insertions(+), 16 deletions(-)
--
Kees Cook
^ permalink raw reply
* Re: mdadm regression tests fail
From: Randy Dunlap @ 2022-01-05 17:12 UTC (permalink / raw)
To: Bruce Dubbs, Linux Kernel Mailing List, linux-raid
Cc: Douglas R. Reno, Pierre Labastie
In-Reply-To: <c4c17b11-16f4-ef70-5897-02f923907963@gmail.com>
Hi.
[adding linux-raid mailing list]
On 1/4/22 10:55, Bruce Dubbs wrote:
> I am trying to document the mdadm-4.2 installation procedures for our book,
> https://www.linuxfromscratch.org/blfs/view/svn/postlfs/mdadm.html
>
> For testing, I am doing a simple:
>
> make
> sudo ./test --keep-going --logdir=test-logs --save-logs
>
> But I get failures for about half the tests.
>
> Digging in a bit I just ran:
>
> sudo ./test --tests=00raid0 --logdir=test-logs
>
> This is the first test that fails. With some hacking, it appears that the first portion of this test that fails is:
>
> mdadm -CR $md0 -e0.90 -l0 -n4 $dev0 $dev1 $dev2 $dev3
>
> This resolves to
>
> mdadm -CR /dev/md0 -e0.90 -l0 -n4 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
>
> There is not a lot of error output in the test, so I manually ran:
>
> dd if=/dev/zero of=/tmp/mdtest0 count=20000 bs=1K
> losetup /dev/loop0 /tmp/mdtest0
>
> For /dev/loop[0123]
>
> Then I ran
>
> mdadm -CR /dev/md0 -e0.90 -l0 -n4 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
> mdadm: 0.90 metadata does not support layouts for RAID0
>
> My question is whether the regression tests in the tarball are valid for mdadm-4.2?
>
> -- Bruce Dubbs
> linuxfromscratch.org
>
> Note: The kernel is version 5.15.12.
--
~Randy
^ permalink raw reply
* Re: [PATCH dt + pci 1/2] dt-bindings: Add 'slot-power-limit-milliwatt' PCIe port property
From: Marek Behún @ 2022-01-05 17:11 UTC (permalink / raw)
To: Rob Herring; +Cc: Pali Rohár, devicetree, PCI, Bjorn Helgaas
In-Reply-To: <CAL_JsqL0mfRb7k4V-wjyGgjpB3pu88yPNT38k8zs-HoiVYaekQ@mail.gmail.com>
On Wed, 5 Jan 2022 09:26:22 -0600
Rob Herring <robh@kernel.org> wrote:
> The only issue I see is the property would be allowed in host bridge
> nodes rather than only root port or PCIe-PCIe bridge nodes because the
> current file is a mixture of all of those. I think a note that the
> property is not valid in host bridge nodes would be sufficient. It's
> still better than documenting in pci.txt.
>
> Rob
Created PR
https://github.com/devicetree-org/dt-schema/pull/66
Marek
^ permalink raw reply
* Sensor Whitelist
From: Mike Jones @ 2022-01-05 17:09 UTC (permalink / raw)
To: openbmc
Hi,
I’m getting an error from psusensor saying my driver is not found in sensor whitelist.
What defines this whitelist?
Note that the driver name is ltc3888, which is part of hwmon module ltc2978. In case the white listed name must refer to the module name instead of the driver name the module supports.
Also, I have not added this sensor to ipmi, but I am also using adm1278 without ipmi and it works. But in that case, the driver and module names are the same.
I searched for answers and found little. Perhaps there are docs but I am searching for the wrong key words.
Mike
Sent from my iPad
^ permalink raw reply
* Re: pull-request: ieee802154 for net 2022-01-05
From: patchwork-bot+netdevbpf @ 2022-01-05 17:10 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: davem, kuba, linux-wpan, alex.aring, netdev
In-Reply-To: <20220105153914.512305-1-stefan@datenfreihafen.org>
Hello:
This pull request was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 5 Jan 2022 16:39:14 +0100 you wrote:
> Hello Dave, Jakub.
>
> An update from ieee802154 for your *net* tree.
>
> Below I have a last minute fix for the atusb driver.
>
> Pavel fixes a KASAN uninit report for the driver. This version is the
> minimal impact fix to ease backporting. A bigger rework of the driver to
> avoid potential similar problems is ongoing and will come through net-next
> when ready.
>
> [...]
Here is the summary with links:
- pull-request: ieee802154 for net 2022-01-05
https://git.kernel.org/netdev/net/c/af872b691926
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net-next] netlink: do not allocate a device refcount tracker in ethnl_default_notify()
From: Eric Dumazet @ 2022-01-05 17:08 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski
Cc: netdev, Eric Dumazet, Eric Dumazet, Johannes Berg
From: Eric Dumazet <edumazet@google.com>
As reported by Johannes, the tracker allocated in
ethnl_default_notify() is not really needed, as this
function is not expected to change a device reference count.
Fixes: e4b8954074f6 ("netlink: add net device refcount tracker to struct ethnl_req_info")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Johannes Berg <johannes@sipsolutions.net>
---
net/ethtool/netlink.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
index ea23659fab28c734d1a8c11d857b3795f104beec..5fe8f4ae2cebc48eed6d0ce2b9d6607546e66bd6 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);
req_info->flags |= ETHTOOL_FLAG_COMPACT_BITSETS;
ethnl_init_reply_data(reply_data, ops, dev);
--
2.34.1.448.ga2b2bfdf31-goog
^ permalink raw reply related
* Re: [PATCH v4 23/32] mm/memcg: Convert slab objcgs from struct page to struct slab
From: Vlastimil Babka @ 2022-01-05 17:08 UTC (permalink / raw)
To: Roman Gushchin
Cc: Matthew Wilcox, Christoph Lameter, David Rientjes, Joonsoo Kim,
Pekka Enberg, linux-mm, Andrew Morton, Johannes Weiner,
Hyeonggon Yoo, patches, Michal Hocko, Vladimir Davydov, cgroups
In-Reply-To: <YdUFXUbeYGdFbVbq@carbon.dhcp.thefacebook.com>
On 1/5/22 03:41, Roman Gushchin wrote:
> On Tue, Jan 04, 2022 at 01:10:37AM +0100, Vlastimil Babka wrote:
>> page->memcg_data is used with MEMCG_DATA_OBJCGS flag only for slab pages
>> so convert all the related infrastructure to struct slab. Also use
>> struct folio instead of struct page when resolving object pointers.
>>
>> This is not just mechanistic changing of types and names. Now in
>> mem_cgroup_from_obj() we use folio_test_slab() to decide if we interpret
>> the folio as a real slab instead of a large kmalloc, instead of relying
>> on MEMCG_DATA_OBJCGS bit that used to be checked in page_objcgs_check().
>> Similarly in memcg_slab_free_hook() where we can encounter
>> kmalloc_large() pages (here the folio slab flag check is implied by
>> virt_to_slab()). As a result, page_objcgs_check() can be dropped instead
>> of converted.
>>
>> To avoid include cycles, move the inline definition of slab_objcgs()
>> from memcontrol.h to mm/slab.h.
>>
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>> Cc: Johannes Weiner <hannes@cmpxchg.org>
>> Cc: Michal Hocko <mhocko@kernel.org>
>> Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
>> Cc: <cgroups@vger.kernel.org>
>> /*
>> * Slab objects are accounted individually, not per-page.
>> * Memcg membership data for each individual object is saved in
>> * the page->obj_cgroups.
> ^^^^^^^^^^^^^^^^^
> slab->memcg_data
Good catch, fixed.
>> */
>> - if (page_objcgs_check(page)) {
>> - struct obj_cgroup *objcg;
>> + if (folio_test_slab(folio)) {
>> + struct obj_cgroup **objcgs;
>> + struct slab *slab;
>> unsigned int off;
>>
>> - off = obj_to_index(page->slab_cache, page_slab(page), p);
>> - objcg = page_objcgs(page)[off];
>> - if (objcg)
>> - return obj_cgroup_memcg(objcg);
>> + slab = folio_slab(folio);
>> + objcgs = slab_objcgs(slab);
>> + if (!objcgs)
>> + return NULL;
>> +
>> + off = obj_to_index(slab->slab_cache, slab, p);
>> + if (objcgs[off])
>> + return obj_cgroup_memcg(objcgs[off]);
>>
>> return NULL;
>> }
>
> There is a comment below, which needs some changes:
> /*
> * page_memcg_check() is used here, because page_has_obj_cgroups()
> * check above could fail because the object cgroups vector wasn't set
> * at that moment, but it can be set concurrently.
> * page_memcg_check(page) will guarantee that a proper memory
> * cgroup pointer or NULL will be returned.
> */
>
> In reality the folio's slab flag can be cleared before releasing the objcgs \
> vector. It seems that there is no such possibility at setting the flag,
> it's always set before allocating and assigning the objcg vector.
You're right. I'm changing it to:
* page_memcg_check() is used here, because in theory we can encounter
* a folio where the slab flag has been cleared already, but
* slab->memcg_data has not been freed yet
* page_memcg_check(page) will guarantee that a proper memory
* cgroup pointer or NULL will be returned.
I wrote "in theory" because AFAICS it implies a race as we would have to be
freeing a slab and at the same time query an object address. We probably
could have used the non-check version, but at this point I don't want to
make any functional changes besides these comment fixes.
I assume your patch on top would cover it?
>> @@ -2896,7 +2901,7 @@ struct mem_cgroup *mem_cgroup_from_obj(void *p)
>> * page_memcg_check(page) will guarantee that a proper memory
>> * cgroup pointer or NULL will be returned.
>> */
>> - return page_memcg_check(page);
>> + return page_memcg_check(folio_page(folio, 0));
>> }
>>
>> __always_inline struct obj_cgroup *get_obj_cgroup_from_current(void)
>> diff --git a/mm/slab.h b/mm/slab.h
>> index bca9181e96d7..36e0022d8267 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
>> @@ -412,15 +412,36 @@ static inline bool kmem_cache_debug_flags(struct kmem_cache *s, slab_flags_t fla
>> }
>>
>> #ifdef CONFIG_MEMCG_KMEM
>> -int memcg_alloc_page_obj_cgroups(struct page *page, struct kmem_cache *s,
>> - gfp_t gfp, bool new_page);
>> +/*
>> + * slab_objcgs - get the object cgroups vector associated with a slab
>> + * @slab: a pointer to the slab struct
>> + *
>> + * Returns a pointer to the object cgroups vector associated with the slab,
>> + * or NULL. This function assumes that the slab is known to have an
>> + * associated object cgroups vector. It's not safe to call this function
>> + * against slabs with underlying pages, which might have an associated memory
>> + * cgroup: e.g. kernel stack pages.
>
> Hm, is it still true? I don't think so. It must be safe to call it for any
> slab now.
Right, forgot to update after removing the _check variant.
Changing to:
* Returns a pointer to the object cgroups vector associated with the slab,
* or NULL if no such vector has been associated yet.
> The rest looks good to me, please feel free to add
> Reviewed-by: Roman Gushchin <guro@fb.com>
> after fixing these comments.
Thanks!
> Thanks!
^ permalink raw reply
* Re: [PATCH v4 23/32] mm/memcg: Convert slab objcgs from struct page to struct slab
From: Vlastimil Babka @ 2022-01-05 17:08 UTC (permalink / raw)
To: Roman Gushchin
Cc: Matthew Wilcox, Christoph Lameter, David Rientjes, Joonsoo Kim,
Pekka Enberg, linux-mm-Bw31MaZKKs3YtjvyW6yDsg, Andrew Morton,
Johannes Weiner, Hyeonggon Yoo, patches-cunTk1MwBs/YUNznpcFYbw,
Michal Hocko, Vladimir Davydov, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <YdUFXUbeYGdFbVbq-cx5fftMpWqeCjSd+JxjunQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
On 1/5/22 03:41, Roman Gushchin wrote:
> On Tue, Jan 04, 2022 at 01:10:37AM +0100, Vlastimil Babka wrote:
>> page->memcg_data is used with MEMCG_DATA_OBJCGS flag only for slab pages
>> so convert all the related infrastructure to struct slab. Also use
>> struct folio instead of struct page when resolving object pointers.
>>
>> This is not just mechanistic changing of types and names. Now in
>> mem_cgroup_from_obj() we use folio_test_slab() to decide if we interpret
>> the folio as a real slab instead of a large kmalloc, instead of relying
>> on MEMCG_DATA_OBJCGS bit that used to be checked in page_objcgs_check().
>> Similarly in memcg_slab_free_hook() where we can encounter
>> kmalloc_large() pages (here the folio slab flag check is implied by
>> virt_to_slab()). As a result, page_objcgs_check() can be dropped instead
>> of converted.
>>
>> To avoid include cycles, move the inline definition of slab_objcgs()
>> from memcontrol.h to mm/slab.h.
>>
>> Signed-off-by: Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>
>> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
>> Cc: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Vladimir Davydov <vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> /*
>> * Slab objects are accounted individually, not per-page.
>> * Memcg membership data for each individual object is saved in
>> * the page->obj_cgroups.
> ^^^^^^^^^^^^^^^^^
> slab->memcg_data
Good catch, fixed.
>> */
>> - if (page_objcgs_check(page)) {
>> - struct obj_cgroup *objcg;
>> + if (folio_test_slab(folio)) {
>> + struct obj_cgroup **objcgs;
>> + struct slab *slab;
>> unsigned int off;
>>
>> - off = obj_to_index(page->slab_cache, page_slab(page), p);
>> - objcg = page_objcgs(page)[off];
>> - if (objcg)
>> - return obj_cgroup_memcg(objcg);
>> + slab = folio_slab(folio);
>> + objcgs = slab_objcgs(slab);
>> + if (!objcgs)
>> + return NULL;
>> +
>> + off = obj_to_index(slab->slab_cache, slab, p);
>> + if (objcgs[off])
>> + return obj_cgroup_memcg(objcgs[off]);
>>
>> return NULL;
>> }
>
> There is a comment below, which needs some changes:
> /*
> * page_memcg_check() is used here, because page_has_obj_cgroups()
> * check above could fail because the object cgroups vector wasn't set
> * at that moment, but it can be set concurrently.
> * page_memcg_check(page) will guarantee that a proper memory
> * cgroup pointer or NULL will be returned.
> */
>
> In reality the folio's slab flag can be cleared before releasing the objcgs \
> vector. It seems that there is no such possibility at setting the flag,
> it's always set before allocating and assigning the objcg vector.
You're right. I'm changing it to:
* page_memcg_check() is used here, because in theory we can encounter
* a folio where the slab flag has been cleared already, but
* slab->memcg_data has not been freed yet
* page_memcg_check(page) will guarantee that a proper memory
* cgroup pointer or NULL will be returned.
I wrote "in theory" because AFAICS it implies a race as we would have to be
freeing a slab and at the same time query an object address. We probably
could have used the non-check version, but at this point I don't want to
make any functional changes besides these comment fixes.
I assume your patch on top would cover it?
>> @@ -2896,7 +2901,7 @@ struct mem_cgroup *mem_cgroup_from_obj(void *p)
>> * page_memcg_check(page) will guarantee that a proper memory
>> * cgroup pointer or NULL will be returned.
>> */
>> - return page_memcg_check(page);
>> + return page_memcg_check(folio_page(folio, 0));
>> }
>>
>> __always_inline struct obj_cgroup *get_obj_cgroup_from_current(void)
>> diff --git a/mm/slab.h b/mm/slab.h
>> index bca9181e96d7..36e0022d8267 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
>> @@ -412,15 +412,36 @@ static inline bool kmem_cache_debug_flags(struct kmem_cache *s, slab_flags_t fla
>> }
>>
>> #ifdef CONFIG_MEMCG_KMEM
>> -int memcg_alloc_page_obj_cgroups(struct page *page, struct kmem_cache *s,
>> - gfp_t gfp, bool new_page);
>> +/*
>> + * slab_objcgs - get the object cgroups vector associated with a slab
>> + * @slab: a pointer to the slab struct
>> + *
>> + * Returns a pointer to the object cgroups vector associated with the slab,
>> + * or NULL. This function assumes that the slab is known to have an
>> + * associated object cgroups vector. It's not safe to call this function
>> + * against slabs with underlying pages, which might have an associated memory
>> + * cgroup: e.g. kernel stack pages.
>
> Hm, is it still true? I don't think so. It must be safe to call it for any
> slab now.
Right, forgot to update after removing the _check variant.
Changing to:
* Returns a pointer to the object cgroups vector associated with the slab,
* or NULL if no such vector has been associated yet.
> The rest looks good to me, please feel free to add
> Reviewed-by: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
> after fixing these comments.
Thanks!
> Thanks!
^ permalink raw reply
* Re: [RFC PATCH 1/2] merge-ort: add new merge-tree-ort command
From: Elijah Newren @ 2022-01-05 17:08 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano, Christian Couder,
Ævar Arnfjörð Bjarmason, Taylor Blau,
Johannes Schindelin
In-Reply-To: <20220105163324.73369-2-chriscool@tuxfamily.org>
On Wed, Jan 5, 2022 at 8:33 AM Christian Couder
<christian.couder@gmail.com> wrote:
>
> This new command is similar as merge-tree, but uses
> merge-ort code and features, especially
> merge_incore_nonrecursive(), instead of those from
> resursive merge, to perform the merge.
s/resursive/recursive/
> The output from this new command is very different from
> merge-tree's custom output, as we are only using code and
> features from diff.{h,c}, especially diff_tree_oid(). This
> should make it easy to customize and standardize the output
> using regular diff options in the future.
>
> This command will be extended to support new features
> with the long-term goal of enabling merges and rebases
> without a worktree.
And cherry-picks? And reverts?
I think the cherry-pick/rebase replacement actually deserves a
separate command from what merges should use. Replaying a sequence of
commits just has a number of UI differences and abilities that I think
pull it in a different direction. And I don't want replaying of a
sequence of commits via a script like the old days (even if one that
calls something that doesn't update the working tree and index would
be better than the old rebases built on top of `git merge-recursive`
and `git cherry-pick`). I'm working on such a thing, though it's
still kind of early.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> .gitignore | 1 +
> Makefile | 1 +
> builtin.h | 1 +
> builtin/merge-tree-ort.c | 93 ++++++++++++++++++++++++++++++++++++++++
> git.c | 1 +
> 5 files changed, 97 insertions(+)
> create mode 100644 builtin/merge-tree-ort.c
>
> diff --git a/.gitignore b/.gitignore
> index 054249b20a..2dfcb1a589 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -98,6 +98,7 @@
> /git-merge-index
> /git-merge-file
> /git-merge-tree
> +/git-merge-tree-ort
> /git-merge-octopus
> /git-merge-one-file
> /git-merge-ours
> diff --git a/Makefile b/Makefile
> index 75ed168adb..915e500b06 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1124,6 +1124,7 @@ BUILTIN_OBJS += builtin/merge-index.o
> BUILTIN_OBJS += builtin/merge-ours.o
> BUILTIN_OBJS += builtin/merge-recursive.o
> BUILTIN_OBJS += builtin/merge-tree.o
> +BUILTIN_OBJS += builtin/merge-tree-ort.o
> BUILTIN_OBJS += builtin/merge.o
> BUILTIN_OBJS += builtin/mktag.o
> BUILTIN_OBJS += builtin/mktree.o
> diff --git a/builtin.h b/builtin.h
> index 8a58743ed6..c68f46b118 100644
> --- a/builtin.h
> +++ b/builtin.h
> @@ -182,6 +182,7 @@ int cmd_merge_ours(int argc, const char **argv, const char *prefix);
> int cmd_merge_file(int argc, const char **argv, const char *prefix);
> int cmd_merge_recursive(int argc, const char **argv, const char *prefix);
> int cmd_merge_tree(int argc, const char **argv, const char *prefix);
> +int cmd_merge_tree_ort(int argc, const char **argv, const char *prefix);
> int cmd_mktag(int argc, const char **argv, const char *prefix);
> int cmd_mktree(int argc, const char **argv, const char *prefix);
> int cmd_multi_pack_index(int argc, const char **argv, const char *prefix);
> diff --git a/builtin/merge-tree-ort.c b/builtin/merge-tree-ort.c
> new file mode 100644
> index 0000000000..1c8ecd16ec
> --- /dev/null
> +++ b/builtin/merge-tree-ort.c
> @@ -0,0 +1,93 @@
> +#include "builtin.h"
> +#include "merge-ort.h"
> +#include "diff.h"
> +
> +static const char merge_tree_ort_usage[] = "git merge-tree-ort <base-tree> <branch1> <branch2>";
I think this is somewhat limiting to use for merges in general; it'll
generate trees that do not match what users get from `git merge ...`
at the command line, because specifying a single base-tree is
different than having the algorithm determine the merge base,
particularly when it needs to construct a virtual merge base.
> +
> +static void show_result(struct tree *base_tree,
> + struct tree *head_tree,
> + struct tree *merge_tree,
> + struct merge_result *result)
> +{
> + const struct object_id *base_oid = &(base_tree->object.oid);
> + const struct object_id *head_oid = &(head_tree->object.oid);
> + const struct object_id *merge_oid = &(merge_tree->object.oid);
> + const struct object_id *result_oid = &(result->tree->object.oid);
> + struct diff_options opts;
> +
> + repo_diff_setup(the_repository, &opts);
> + opts.stat_width = -1; /* use full terminal width */
> + opts.output_format |= DIFF_FORMAT_RAW | DIFF_FORMAT_PATCH;
> + opts.detect_rename = DIFF_DETECT_RENAME;
> + diff_setup_done(&opts);
> +
> + printf("result tree: %s\n", oid_to_hex(result_oid));
> + printf("clean: %d\n", result->clean);
> +
> + printf("diff with branch1:\n");
> + diff_tree_oid(head_oid, result_oid, "", &opts);
> + diffcore_std(&opts);
> + diff_flush(&opts);
> +
> + printf("diff with branch2:\n");
> + diff_tree_oid(merge_oid, result_oid, "", &opts);
> + diffcore_std(&opts);
> + diff_flush(&opts);
> +
> + printf("diff with base:\n");
> + diff_tree_oid(base_oid, result_oid, "", &opts);
> + diffcore_std(&opts);
> + diff_flush(&opts);
I commented on the diffs in my response on the cover letter.
> +}
> +
> +static struct commit *get_commit_by_name_or_die(const char *name)
> +{
> + struct commit *c = lookup_commit_reference_by_name(name);
> + if (!c)
> + die(_("not a valid commit name '%s'"), name);
> + return c;
> +}
> +
> +static void merge_trees_ort(const char *base_name,
> + const char *branch1,
> + const char *branch2)
> +{
> + struct merge_result result;
> + struct merge_options merge_opt;
> +
> + struct commit *base = get_commit_by_name_or_die(base_name);
> + struct commit *head = get_commit_by_name_or_die(branch1);
> + struct commit *merge = get_commit_by_name_or_die(branch2);
> +
> + struct tree *base_tree = get_commit_tree(base);
> + struct tree *head_tree = get_commit_tree(head);
> + struct tree *merge_tree = get_commit_tree(merge);
> +
> + memset(&result, 0, sizeof(result));
> + init_merge_options(&merge_opt, the_repository);
> +
> + merge_opt.show_rename_progress = 1;
> + merge_opt.branch1 = branch1;
> + merge_opt.branch2 = branch2;
> + merge_opt.ancestor = base_name;
> +
> + result.tree = head_tree;
> +
> + merge_incore_nonrecursive(&merge_opt,
> + base_tree,
> + result.tree,
> + merge_tree,
> + &result);
I think for server side merges, merge_incore_recursive() should be
used, so that they match what a `git merge ...` would provide. I
think merge_incore_nonrecursive() is better used for replaying a
sequence of commits.
So, I view this as more suitable for usage with the server side
rebase, except that it seems to be serving as a building block and
expecting the rebase to be some script on top. I think server-side
rebase/cherry-pick should be a builtin of some form.
> +
> + show_result(base_tree, head_tree, merge_tree, &result);
As noted in the cover letter, this current form doesn't provide 2
things that users can't get some other way: (1) a list of conflicted
paths, and (2) the various conflict and warning messages generated
during the merge. I agree that many usecases might not want those,
but since they can't be obtained another way I think it'd be prudent
to provide them.
And this show_result provides 3 things that users could generate on
their own with the information already provided -- namely the three
diffs that you do. I'm curious what the usecase is for those diffs.
> +}
> +
> +int cmd_merge_tree_ort(int argc, const char **argv, const char *prefix)
> +{
> + if (argc != 4)
> + usage(merge_tree_ort_usage);
> +
> + merge_trees_ort(argv[1], argv[2], argv[3]);
> +
> + return 0;
> +}
> diff --git a/git.c b/git.c
> index 7edafd8ecf..90b8a4984c 100644
> --- a/git.c
> +++ b/git.c
> @@ -562,6 +562,7 @@ static struct cmd_struct commands[] = {
> { "merge-recursive-theirs", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
> { "merge-subtree", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
> { "merge-tree", cmd_merge_tree, RUN_SETUP | NO_PARSEOPT },
> + { "merge-tree-ort", cmd_merge_tree_ort, RUN_SETUP | NO_PARSEOPT },
> { "mktag", cmd_mktag, RUN_SETUP | NO_PARSEOPT },
> { "mktree", cmd_mktree, RUN_SETUP },
> { "multi-pack-index", cmd_multi_pack_index, RUN_SETUP },
> --
> 2.34.1.433.g7bc349372a.dirty
^ permalink raw reply
* [syzbot] WARNING in fixup_exception
From: syzbot @ 2022-01-05 17:07 UTC (permalink / raw)
To: andrii, ast, bp, bpf, daniel, dave.hansen, hpa, john.fastabend,
kafai, kpsingh, linux-kernel, luto, mingo, netdev, peterz,
songliubraving, syzkaller-bugs, tglx, x86, yhs
Hello,
syzbot found the following issue on:
HEAD commit: 800829388818 mm: vmscan: reduce throttling due to a failur..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=100bafc3b00000
kernel config: https://syzkaller.appspot.com/x/.config?x=1a86c22260afac2f
dashboard link: https://syzkaller.appspot.com/bug?extid=d9a0f6db5058ce56e260
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=154be92bb00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=112fd30bb00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d9a0f6db5058ce56e260@syzkaller.appspotmail.com
------------[ cut here ]------------
General protection fault in user access. Non-canonical address?
WARNING: CPU: 0 PID: 2529 at arch/x86/mm/extable.c:57 ex_handler_uaccess arch/x86/mm/extable.c:57 [inline]
WARNING: CPU: 0 PID: 2529 at arch/x86/mm/extable.c:57 fixup_exception+0x5da/0x690 arch/x86/mm/extable.c:140
Modules linked in:
CPU: 0 PID: 2529 Comm: syz-executor223 Not tainted 5.16.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ex_handler_uaccess arch/x86/mm/extable.c:57 [inline]
RIP: 0010:fixup_exception+0x5da/0x690 arch/x86/mm/extable.c:140
Code: 0c 31 ff 89 de e8 06 f5 42 00 84 db 0f 85 9b fc ff ff e8 19 f1 42 00 48 c7 c7 20 59 a9 89 c6 05 49 33 48 0c 01 e8 52 cf cb 07 <0f> 0b e9 7c fc ff ff e8 fa f0 42 00 48 89 de 48 c7 c7 c0 59 a9 89
RSP: 0018:ffffc90003bf7bf0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88801dbd0000 RSI: ffffffff815f0948 RDI: fffff5200077ef70
RBP: ffffffff8b6d0044 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ea6ee R11: 0000000000000000 R12: ffffc90003bf7cc8
R13: 000000000000000d R14: ffffc90003bf7d48 R15: 0000000000000000
FS: 00007f46f7487700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f46f7d44190 CR3: 0000000022544000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__exc_general_protection arch/x86/kernel/traps.c:601 [inline]
exc_general_protection+0xed/0x300 arch/x86/kernel/traps.c:562
asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:562
RIP: 0010:__put_user_nocheck_2+0x3/0x11
Code: 00 00 48 39 d9 73 74 0f 01 cb 88 01 31 c9 0f 01 ca c3 66 0f 1f 44 00 00 48 bb ff ef ff ff ff 7f 00 00 48 39 d9 73 54 0f 01 cb <66> 89 01 31 c9 0f 01 ca c3 0f 1f 44 00 00 48 bb fd ef ff ff ff 7f
RSP: 0018:ffffc90003bf7d78 EFLAGS: 00050293
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0006020200000004
RDX: ffff88801dbd0000 RSI: ffffffff86d1fba8 RDI: 0000000000000003
RBP: ffff888077ff01a8 R08: 0000000000000002 R09: 0000000000000001
R10: ffffffff86d1fb95 R11: 0000000000000000 R12: 0006020200000004
R13: ffff888077ff0258 R14: 0000000000000000 R15: 0000000000000000
vhost_put_used_flags drivers/vhost/vhost.c:969 [inline]
vhost_update_used_flags+0x1a3/0x3d0 drivers/vhost/vhost.c:1969
vhost_vq_init_access+0x114/0x5c0 drivers/vhost/vhost.c:2013
vhost_net_set_backend drivers/vhost/net.c:1548 [inline]
vhost_net_ioctl+0xbad/0x1740 drivers/vhost/net.c:1705
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f46f7d02839
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 31 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f46f7487208 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f46f7d8a278 RCX: 00007f46f7d02839
RDX: 0000000020000000 RSI: 000000004008af30 RDI: 0000000000000003
RBP: 00007f46f7d8a270 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f46f7d8a27c
R13: 00007ffc8471e10f R14: 00007f46f7487300 R15: 0000000000022000
</TASK>
----------------
Code disassembly (best guess):
0: 00 00 add %al,(%rax)
2: 48 39 d9 cmp %rbx,%rcx
5: 73 74 jae 0x7b
7: 0f 01 cb stac
a: 88 01 mov %al,(%rcx)
c: 31 c9 xor %ecx,%ecx
e: 0f 01 ca clac
11: c3 retq
12: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
18: 48 bb ff ef ff ff ff movabs $0x7fffffffefff,%rbx
1f: 7f 00 00
22: 48 39 d9 cmp %rbx,%rcx
25: 73 54 jae 0x7b
27: 0f 01 cb stac
* 2a: 66 89 01 mov %ax,(%rcx) <-- trapping instruction
2d: 31 c9 xor %ecx,%ecx
2f: 0f 01 ca clac
32: c3 retq
33: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
38: 48 rex.W
39: bb fd ef ff ff mov $0xffffeffd,%ebx
3e: ff (bad)
3f: 7f .byte 0x7f
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [OE-core] [PATCH 2/2] package.bbclass: don't skip kernel and kernel modules
From: Richard Purdie @ 2022-01-05 17:07 UTC (permalink / raw)
To: Saul Wold, openembedded-core, JPEWhacker, Bruce Ashfield
In-Reply-To: <b90b0597-15e4-f19d-2431-9afe77d6c33c@windriver.com>
On Tue, 2022-01-04 at 14:07 -0800, Saul Wold wrote:
>
> On 12/22/21 01:09, Richard Purdie wrote:
> > On Tue, 2021-12-21 at 11:08 -0800, Saul Wold wrote:
> > > Stop ignoring or skipping the kernel and kernel modules code in the
> > > split debug and striping functions, this will allow create_spdx to
> > > process the kernel and modules.
> > >
> > > Signed-off-by: Saul Wold <saul.wold@windriver.com>
> > > ---
> > > meta/classes/package.bbclass | 8 ++------
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> > > index 84eafbd529..4b7fe4f1e1 100644
> > > --- a/meta/classes/package.bbclass
> > > +++ b/meta/classes/package.bbclass
> > > @@ -390,10 +390,6 @@ def splitdebuginfo(file, dvar, debugdir, debuglibdir, debugappend, debugsrcdir,
> > > dvar = d.getVar('PKGD')
> > > objcopy = d.getVar("OBJCOPY")
> > >
> > > - # We ignore kernel modules, we don't generate debug info files.
> > > - if file.find("/lib/modules/") != -1 and file.endswith(".ko"):
> > > - return (file, sources)
> > > -
> > > newmode = None
> > > if not os.access(file, os.W_OK) or os.access(file, os.R_OK):
> > > origmode = os.stat(file)[stat.ST_MODE]
> > > @@ -1147,7 +1143,7 @@ python split_and_strip_files () {
> > >
> > > if file.endswith(".ko") and file.find("/lib/modules/") != -1:
> > > kernmods.append(file)
> > > - continue
> > > +
> > > if oe.package.is_static_lib(file):
> > > staticlibs.append(file)
> > > continue
> > > @@ -1165,7 +1161,7 @@ python split_and_strip_files () {
> > > continue
> > > # Check its an executable
> > > if (s[stat.ST_MODE] & stat.S_IXUSR) or (s[stat.ST_MODE] & stat.S_IXGRP) or (s[stat.ST_MODE] & stat.S_IXOTH) \
> > > - or ((file.startswith(libdir) or file.startswith(baselibdir)) and (".so" in f or ".node" in f)):
> > > + or ((file.startswith(libdir) or file.startswith(baselibdir)) and (".so" in f or ".node" in f)) or (f.startswith('vmlinux') or ".ko" in f):
> > >
> > > if cpath.islink(file):
> > > checkelflinks[file] = ltarget
> >
> > edgerouter:
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/4513
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/111/builds/2507/steps/11/logs/stdio
> >
> So I have been digging into this and it seems that an option was added a
> decade ago or so to strip the kernel/vmlinux when it's too big, this was
> done for at least the routerstationpro according to bug #3515 [0], and
> persists with the edgerouter, although I am not sure if it would still
> actually be required as the edgerouter also uses the
> KERNEL_ALT_IMAGETYPE to create a smaller binary kernel image.
>
> The change I proposed causes the all kernels to be stripped all the time
> as part of the split_and_strip_files(). As I see it there few different
> options:
>
> 1) Set KERNEL_IMAGE_EXTRA_STRIP_SECTIONS = "" in create_spdx.bbclass
> - This solves the problem with create_spdx.bbclass is in use, but not
> the general case
I don't think I like this as it is a side effect that isn't obvious or expected.
>
> 2) Remove the KERNEL_IMAGE_EXTRA_STRIP_SECTIONS from edgerouter.conf
> - Will solve the edgerouter case but may not solve other usages
> unknown to me.
> - Does anyone know of other machines/layers usage of this variable?
>
> 3) deprecate the kernel.bbclass:do_strip function in favor of using the
> split_and_strip_files() of package.bbclass
I know Bruce has said he doesn't like this, however stepping back, these issues
were from a time our stripping code was young and evolving. If we can
standardise and have it all work together well in one set of functions, I think
that is worth looking at. I'd prefer the kernel wasn't a special case if it no
longer needs to be.
That said, I don't remember the details of why we did this.
>
> 4) Change error to warning in packaging.bbclass for the kernel only
> - This would explain that a kernel image (vmlinux) is already
> stripped and extended package data would not be available for for SPDX
> creation.
>
> RP, Bruce, Joshua: Thoughts?
If we can simplify and stop the kernel being a special case for this code (or
handle kernels generically) that would be worth a bit of effort IMO...
Cheers,
Richard
^ permalink raw reply
* [PATCH v2] drm/amd/display: explicitly update clocks when DC is set to D3 in s0i3
From: Mario Limonciello @ 2022-01-05 17:06 UTC (permalink / raw)
To: amd-gfx
Cc: Qingqing Zhuo, Scott Bruce, Mario Limonciello, Chris Hixon,
spasswolf
The WA from commit 5965280abd30 ("drm/amd/display: Apply w/a for
hard hang on HPD") causes a regression in s0ix where the system will
fail to resume properly. This may be because an HPD was active the last
time clocks were updated but clocks didn't get updated again during s0ix.
So add an extra call to update clocks as part of the suspend routine:
dm_suspend->dc_set_power_state->clk_mgr_optimize_pwr_state
In case HPD is set during this time, also check if the call happened during
suspend to allow overriding the WA.
Cc: Qingqing Zhuo <qingqing.zhuo@amd.com>
Reported-by: Scott Bruce <smbruce@gmail.com>
Reported-by: Chris Hixon <linux-kernel-bugs@hixontech.com>
Reported-by: spasswolf@web.de
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215436
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1821
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1852
Fixes: 5965280abd30 ("drm/amd/display: Apply w/a for hard hang on HPD")
Fixes: 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard hang on HPD to dcn20")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
changes from v1->v2:
* Add fallthrough statement
* Extend case to check if call was explicitly in s0ix since #1852 showed hpd_state
can be set at this time too
* Adjust commit message and title
* Add extra commit and bug fixed to metadata
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 5 ++++-
drivers/gpu/drm/amd/display/dc/core/dc.c | 3 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index fbda42313bfe..fa5efe10b779 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -23,6 +23,8 @@
*
*/
+#include "amdgpu.h"
+
#include "dccg.h"
#include "clk_mgr_internal.h"
@@ -126,6 +128,7 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
bool safe_to_lower)
{
struct clk_mgr_internal *clk_mgr = TO_CLK_MGR_INTERNAL(clk_mgr_base);
+ struct amdgpu_device *adev = clk_mgr_base->ctx->driver_context;
struct dc_clocks *new_clocks = &context->bw_ctx.bw.dcn.clk;
struct dc *dc = clk_mgr_base->ctx->dc;
int display_count;
@@ -157,7 +160,7 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
}
/* if we can go lower, go lower */
- if (display_count == 0 && !hpd_state) {
+ if (display_count == 0 && (adev->in_s0ix || !hpd_state)) {
rn_vbios_smu_set_dcn_low_power_state(clk_mgr, DCN_PWR_STATE_LOW_POWER);
/* update power state */
clk_mgr_base->clks.pwr_state = DCN_PWR_STATE_LOW_POWER;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 91c4874473d6..8e0c820f6892 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3299,6 +3299,9 @@ void dc_set_power_state(
}
break;
+ case DC_ACPI_CM_POWER_STATE_D3:
+ clk_mgr_optimize_pwr_state(dc, dc->clk_mgr);
+ fallthrough;
default:
ASSERT(dc->current_state->stream_count == 0);
/* Zero out the current context so that on resume we start with
--
2.25.1
^ permalink raw reply related
* Re: [lttng-dev] Running trace-rotate and session-rotate together
From: Jérémie Galarneau via lttng-dev @ 2022-01-05 17:05 UTC (permalink / raw)
To: Subrata Paul; +Cc: lttng-dev
In-Reply-To: <CABAcCUNcS1yaP7-mLijXmecOczr9vQkOukhW4Q-YgKc6Vz-bZw@mail.gmail.com>
----- Message original -----
> De: "lttng-dev" <lttng-dev@lists.lttng.org>
> À: "lttng-dev" <lttng-dev@lists.lttng.org>
> Envoyé: Mardi 21 Décembre 2021 01:47:12
> Objet: [lttng-dev] Running trace-rotate and session-rotate together
> Hi,
> 1. In the lttng-enable-rotation manpage it is mentioned that we should not use
> trace rotate when automatic session rotate is enabled. Can you please tell me
> why?
> ```
> Important
> You may only use the enable-rotation command when:
> * The selected recording session was created in normal mode or in network
> streaming mode
> (see lttng-create(1)).
> * No channel was created with a configured trace file count or size limit (see
> the
> --tracefile-size and --tracefile-count options of the lttng-enable-channel(1)
> command).
> ```
Hi,
The reason mostly boils down to the fact that we didn't see a use case for this. Hence, it's not implemented nor tested.
Let me know if you have a use case for combining both features, though.
> 2. When automatic session rotate is running, is there any race condition in
> writing the current ring buffers and archiving the current trace chunk?
I am not sure I understand your question, but I think you're asking if session rotations are "atomic" with respect to the switchover of all per-CPU streams from one trace archive to the next?
The switchover is not instantaneous. The file output of each per-CPU stream is switched to the new trace archive sequentially. That leaves you with a window of time during which information, for a given stream, may be found in either the old trace archive or the new one. To be clear, no information is ever duplicated or lost during this operation.
I briefly touched on this topic in a presentation at the Open Source Summit 2018, see slide 32+[1]
The various colours represent successive trace archives produced by session rotations.
This transition window makes writing analyses a bit harder since the beginning and end of trace archives may not have all of the information for all per-CPU streams during a short window of time. That window is contained between issuing the rotation and receiving a confirmation that it has been completed (using the CLI or the liblttng-ctl API).
You can see that in that context, I chose to process trace archives in pairs to constitute an "effective trace archive" (slide 34) during which I can be sure I always have access to all events from all per-CPU streams.
Thanks,
Jérémie
[1] https://events19.linuxfoundation.org/wp-content/uploads/2017/12/Fine-grained-Distributed-Application-Monitoring-Using-LTTng-J%C3%A9r%C3%A9mie-Galarneau-EfficiOS.pdf
> --------------------------------------------------------------
> Regards,
> Subrata Paul
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* [PATCHv3 4/4] nvme-pci: fix queue_rqs list splitting
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>
If command prep fails, current handling will orphan subsequent requests
in the list. Consider a simple example:
rqlist = [ 1 -> 2 ]
When prep for request '1' fails, it will be appended to the
'requeue_list', leaving request '2' disconnected from the original
rqlist and no longer tracked. Meanwhile, rqlist is still pointing to the
failed request '1' and will attempt to submit the unprepped command.
Fix this by updating the rqlist accordingly using the request list
helper functions.
Fixes: d62cbcf62f2f ("nvme: add support for mq_ops->queue_rqs()")
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
drivers/nvme/host/pci.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 50deb8b69c40..d8585df2c2fd 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -999,30 +999,30 @@ static bool nvme_prep_rq_batch(struct nvme_queue *nvmeq, struct request *req)
static void nvme_queue_rqs(struct request **rqlist)
{
- struct request *req = rq_list_peek(rqlist), *prev = NULL;
+ struct request *req, *next, *prev = NULL;
struct request *requeue_list = NULL;
- do {
+ rq_list_for_each_safe(rqlist, req, next) {
struct nvme_queue *nvmeq = req->mq_hctx->driver_data;
if (!nvme_prep_rq_batch(nvmeq, req)) {
/* detach 'req' and add to remainder list */
- if (prev)
- prev->rq_next = req->rq_next;
- rq_list_add(&requeue_list, req);
- } else {
- prev = req;
+ rq_list_move(rqlist, &requeue_list, req, prev);
+
+ req = prev;
+ if (!req)
+ continue;
}
- req = rq_list_next(req);
- if (!req || (prev && req->mq_hctx != prev->mq_hctx)) {
+ if (!next || req->mq_hctx != next->mq_hctx) {
/* detach rest of list, and submit */
- if (prev)
- prev->rq_next = NULL;
+ req->rq_next = NULL;
nvme_submit_cmds(nvmeq, rqlist);
- *rqlist = req;
- }
- } while (req);
+ *rqlist = next;
+ prev = NULL;
+ } else
+ prev = req;
+ }
*rqlist = requeue_list;
}
--
2.25.4
^ permalink raw reply related
* [PATCHv3 2/4] block: introduce rq_list_for_each_safe macro
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>
While iterating a list, a particular request may need to be removed for
special handling. Provide an iterator that can safely handle that.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
include/linux/blk-mq.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index bf64b94cd64e..1467f0fa2142 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -242,6 +242,10 @@ static inline unsigned short req_get_ioprio(struct request *req)
#define rq_list_for_each(listptr, pos) \
for (pos = rq_list_peek((listptr)); pos; pos = rq_list_next(pos))
+#define rq_list_for_each_safe(listptr, pos, nxt) \
+ for (pos = rq_list_peek((listptr)), nxt = rq_list_next(pos); \
+ pos; pos = nxt, nxt = pos ? rq_list_next(pos) : NULL)
+
#define rq_list_next(rq) (rq)->rq_next
#define rq_list_empty(list) ((list) == (struct request *) NULL)
--
2.25.4
^ permalink raw reply related
* [PATCHv3 3/4] block: introduce rq_list_move
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>
When iterating a list, a particular request may need to be moved for
special handling. Provide a helper function to achieve that so drivers
don't need to reimplement rqlist manipulation.
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
include/linux/blk-mq.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 1467f0fa2142..f40a05ecca4a 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -249,6 +249,23 @@ static inline unsigned short req_get_ioprio(struct request *req)
#define rq_list_next(rq) (rq)->rq_next
#define rq_list_empty(list) ((list) == (struct request *) NULL)
+/**
+ * rq_list_move() - move a struct request from one list to another
+ * @src: The source list @rq is currently in
+ * @dst: The destination list that @rq will be appended to
+ * @rq: The request to move
+ * @prev: The request preceding @rq in @src (NULL if @rq is the head)
+ */
+static void inline rq_list_move(struct request **src, struct request **dst,
+ struct request *rq, struct request *prev)
+{
+ if (prev)
+ prev->rq_next = rq->rq_next;
+ else
+ *src = rq->rq_next;
+ rq_list_add(dst, rq);
+}
+
enum blk_eh_timer_return {
BLK_EH_DONE, /* drivers has completed the command */
BLK_EH_RESET_TIMER, /* reset timer and try again */
--
2.25.4
^ permalink raw reply related
* [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
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.