On Fri, Apr 16, 2021 at 2:14 AM Randy Dunlap wrote:
>
> Currently when using "W=1" with UML builds, there are over 700 warnings
> like so:
>
> CC arch/um/drivers/stderr_console.o
> cc1: warning: ./arch/um/include/uapi: No such file or directory
> [-Wmissing-include-dirs]
>
> but arch/um/
Hi Jacopo,
On Thu, Apr 15, 2021 at 08:58:48AM +0200, Jacopo Mondi wrote:
> On Thu, Apr 15, 2021 at 03:00:56AM +0300, Laurent Pinchart wrote:
> > On Wed, Apr 14, 2021 at 03:51:25PM +0200, Jacopo Mondi wrote:
> > > The 'maxim,gpio-poc' property is used when the remote camera
> > > power-over-coax
Hi!
> This is the start of the stable review cycle for the 4.19.188 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any kernel problems here: (some
On Thu, 15 Apr 2021, Axel Rasmussen wrote:
> Base
>
>
> This series is based on (and therefore should apply cleanly to) the tag
> "v5.12-rc7-mmots-2021-04-11-20-49", additionally with Peter's selftest cleanup
> series applied first:
>
> https://lore.kernel.org/patchwork/cover/1412450/
>
>
Hi!
> This is the start of the stable review cycle for the 5.10.31 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any kernel problems here: (some
On Thu, Apr 15, 2021 at 06:47:48PM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 15, 2021 at 4:47 PM Laurent Pinchart wrote:
> > On Thu, Apr 15, 2021 at 02:25:59PM +0200, Jacopo Mondi wrote:
> > > Declare port@0 in the csi40 device node and leave it un-connected.
> > > Each board .dts file will
On 4/15/21 2:53 PM, Johannes Weiner wrote:
On Thu, Apr 15, 2021 at 02:16:17PM -0400, Waiman Long wrote:
On 4/15/21 1:53 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:27PM -0400, Waiman Long wrote:
Most kmem_cache_alloc() calls are from user context. With instrumentation
enabled,
Bump, this is very important in 8994's case..
Konrad
On Thu, Apr 15, 2021, Wanpeng Li wrote:
> On Thu, 15 Apr 2021 at 08:49, Sean Christopherson wrote:
> >
> > On Wed, Apr 14, 2021, Wanpeng Li wrote:
> > > On Wed, 14 Apr 2021 at 01:25, Sean Christopherson
> > > wrote:
> > > >
> > > > On Tue, Apr 13, 2021, Wanpeng Li wrote:
> > > > > The bugzilla
[cc +Pali]
On Thu, 15 Apr 2021 20:02:23 +0200
Ingmar Klein wrote:
> First thanks to you both, Alex and Bjorn!
> I am in no way an expert on this topic, so I have to fully rely on your
> feedback, concerning this issue.
>
> If you should have any other solution approach, in form of patch-set, I
+PPC and PCI lists
On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras wrote:
>
> Many other resource flag parsers already add this flag when the input
> has bits 24 & 25 set, so update this one to do the same.
Many others? Looks like sparc and powerpc to me. Those would be the
ones I worry about
On Thu, Apr 15 2021 at 12:39, Marcelo Tosatti wrote:
> +static bool need_reprogram_timer(struct hrtimer_cpu_base *cpu_base)
> +{
> + unsigned int active = 0;
> +
> + if (cpu_base->softirq_activated)
> + return true;
> +
> + active = cpu_base->active_bases &
On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> Rust is a systems programming language that brings several key
> advantages over C in the context of the Linux kernel:
>
> - No undefined behavior in the safe subset (when unsafe code is
> sound), including memory safety
On 15 Apr 2021, at 2:45, Huang, Ying wrote:
> "Zi Yan" writes:
>
>> On 13 Apr 2021, at 23:00, Huang, Ying wrote:
>>
>>> Yang Shi writes:
>>>
The generic migration path will check refcount, so no need check refcount
here.
But the old code actually prevents from migrating shared
On Thu, 15 Apr 2021 12:23:55 +0200 Christophe Leroy
wrote:
> > +* is done. STRICT_MODULE_RWX may require extra work to support this
> > +* too.
> > +*/
> >
> > - return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> > GFP_KERNEL,
> > -
On 4/15/21 3:35 AM, Oscar Salvador wrote:
> alloc_contig_range will fail if it ever sees a HugeTLB page within the
> range we are trying to allocate, even when that page is free and can be
> easily reallocated.
> This has proved to be problematic for some users of alloc_contic_range,
> e.g: CMA
On Wed, Apr 14, 2021 at 10:49:39AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> The physical address of monitor pages in the CHANNELMSG_INITIATE_CONTACT
> msg should be in the extra address space for SNP support and these
What is this 'extra address space'? Is that just normal virtual
On Thu, Apr 15, 2021 at 02:16:17PM -0400, Waiman Long wrote:
> On 4/15/21 1:53 PM, Johannes Weiner wrote:
> > On Tue, Apr 13, 2021 at 09:20:27PM -0400, Waiman Long wrote:
> > > Most kmem_cache_alloc() calls are from user context. With instrumentation
> > > enabled, the measured amount of
When user modifies a custom feature value and sensor_hub_set_feature()
fails, return error.
Reported-by: Abaci Robot
Signed-off-by: Srinivas Pandruvada
---
Replaces patch: HID: hid-sensor-custom: remove useless variable
by Jiapeng Chong
drivers/hid/hid-sensor-custom.c | 2 ++
1 file
In the function sensor_hub_set_feature(), return error when hid_set_field()
fails.
Signed-off-by: Srinivas Pandruvada
---
drivers/hid/hid-sensor-hub.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
Hi Christoph,
Thanks for the review.
On Thu, 15 Apr 2021 07:40:33 +0100, Christoph Hellwig
wrote:
> On Wed, Apr 14, 2021 at 08:27:56AM -0700, Jacob Pan wrote:
> > static int idxd_enable_system_pasid(struct idxd_device *idxd)
> > {
> > - int flags;
> > + unsigned int flags;
> >
On 4/15/21 3:35 AM, Oscar Salvador wrote:
> Pages allocated after boot get its private field cleared by means
> of post_alloc_hook().
> Pages allocated during boot, that is directly from the memblock allocator,
> get cleared by paging_init()->..->memmap_init_zone->..->__init_single_page()
> before
Generally, the documentation we wrote for hugetlbfs-based minor faults
still all applies. The only missing piece is to mention the new feature
flag which indicates that the kernel supports this for shmem as well.
Signed-off-by: Axel Rasmussen
---
Documentation/admin-guide/mm/userfaultfd.rst | 3
Currently, the context (fds, mmap-ed areas, etc.) are global. Each test
mutates this state in some way, in some cases really "clobbering it"
(e.g., the events test mremap-ing area_dst over the top of area_src, or
the minor faults tests overwriting the count_verify values in the test
areas). We run
In a previous commit, we added the mcopy_atomic_install_ptes() helper.
This helper does the job of setting up PTEs for an existing page, to map
it into a given VMA. It deals with both the anon and shmem cases, as
well as the shared and private cases.
In other words, shmem_mcopy_atomic_pte()
Enable test_uffdio_minor for test_type == TEST_SHMEM, and modify the
test slightly to pass in / check for the right feature flags.
Signed-off-by: Axel Rasmussen
---
tools/testing/selftests/vm/userfaultfd.c | 29
1 file changed, 25 insertions(+), 4 deletions(-)
diff
This is a preparatory commit. In the future, we want to be able to setup
alias mappings for area_src and area_dst in the shmem test, like we do
in the hugetlb_shared test. With a VMA obtained via
mmap(MAP_ANONYMOUS | MAP_SHARED), it isn't clear how to do this.
So, mmap() with an fd, so we can
Previously, we just allocated two shm areas: area_src and area_dst. With
this commit, change this so we also allocate area_src_alias, and
area_dst_alias.
area_*_alias and area_* (respectively) point to the same underlying
physical pages, but are different VMAs. In a future commit in this
series,
This patch allows shmem-backed VMAs to be registered for minor faults.
Minor faults are appropriately relayed to userspace in the fault path,
for VMAs with the relevant flag.
This commit doesn't hook up the UFFDIO_CONTINUE ioctl for shmem-backed
minor faults, though, so userspace doesn't yet have
With this change, userspace can resolve a minor fault within a
shmem-backed area with a UFFDIO_CONTINUE ioctl. The semantics for this
match those for hugetlbfs - we look up the existing page in the page
cache, and install PTEs for it.
This commit introduces a new helper:
Minimizing header file inclusion is desirable. In this case, we can do
so just by forward declaring the enumeration our signature relies upon.
Reviewed-by: Peter Xu
Signed-off-by: Axel Rasmussen
---
include/linux/hugetlb.h | 4 +++-
mm/hugetlb.c| 1 +
2 files changed, 4
Previously, we did a dance where we had one calling path in
userfaultfd.c (mfill_atomic_pte), but then we split it into two in
shmem_fs.h (shmem_{mcopy_atomic,mfill_zeropage}_pte), and then rejoined
into a single shared function in shmem.c (shmem_mfill_atomic_pte).
This is all a bit overly
Base
This series is based on (and therefore should apply cleanly to) the tag
"v5.12-rc7-mmots-2021-04-11-20-49", additionally with Peter's selftest cleanup
series applied first:
https://lore.kernel.org/patchwork/cover/1412450/
Changelog
=
v2->v3:
- Picked up {Reviewed,Acked}-by's.
On 4/15/21 2:10 PM, Johannes Weiner wrote:
On Thu, Apr 15, 2021 at 12:35:45PM -0400, Waiman Long wrote:
On 4/15/21 12:30 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:24PM -0400, Waiman Long wrote:
In memcg_slab_free_hook()/pcpu_memcg_free_hook(), obj_cgroup_uncharge()
is followed
On Thu, 2021-04-15 at 18:58 +0100, Valentin Schneider wrote:
> ...
> Further tweak find_busiest_queue() to ensure this doesn't happen.
> Also note
> find_busiest_queue() can now iterate over CPUs with a higher capacity
> than
> the local CPU's, so add a capacity check there.
>
> Signed-off-by:
On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> One thing worth mentioning here, I never hit the hub_ext_port_status -71
> problem if I resume by waking up from the keyboard connected to the hub.
I thought you said earlier that the port got into trouble while it was
suspending, not
Add bindings for the Microchip eXtended Image Sensor Controller.
Based on the atmel,isc.yaml binding.
Signed-off-by: Eugen Hristev
---
Changes in v5:
- fixed license clause to add BSD-2
Changes in v4:
- added '|' at description to preserve line breaks
.../bindings/media/microchip,xisc.yaml
Hi!
> This is the start of the stable review cycle for the 4.4.267 release.
> There are 38 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any problems here:
-Original Message-
From: Martin K. Petersen Subject: Re: [PATCH v2 1/3] hpsa: use __packed on
individual structs, not header-wide
> Some of the structs contain `atomic_t` values and are not intended to
> be sent to IO controller as is.
>
> The change adds __packed to every struct and
The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so
they need to select DRM_MIPI_DSI to prevent build errors.
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function
interfaces so it should select DRM_MIPI_DSI to prevent build errors.
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/analogix/anx7625.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
On Thu, 15 Apr 2021 14:43:47 +0200, Lukasz Majczak wrote:
> kabylake_ssp_fixup function uses snd_soc_dpcm to identify the
> codecs DAIs. The HW parameters are changed based on the codec DAI of the
> stream. The earlier approach to get snd_soc_dpcm was using container_of()
> macro on
On Thu, 15 Apr 2021 15:38:29 +0800, zhuguangqin...@gmail.com wrote:
> Coccinelle noticed:
> sound/soc/codecs/wcd934x.c:5041:7-32: ERROR: Threaded IRQ with no primary
> handler requested without IRQF_ONESHOT
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
On Wed, 14 Apr 2021 22:33:41 +0200, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller and to
> remove the of_device_id table forward declaration.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/3]
On Thu, 15 Apr 2021 15:46:44 +0800, Dinghao Liu wrote:
> There is a PM usage counter decrement after zynqmp_qspi_init_hw()
> without any refcount increment, which leads to refcount leak.Add
> a refcount increment to balance the refcount. Also set
> auto_runtime_pm to resume suspended spi
On Thu, Apr 15, 2021 at 02:17:58PM -0400, Josef Bacik wrote:
> There's a lot of larger things that need to
> be addressed in general to support the volume approach inside file systems
> that is going to require a lot of work inside of VFS. If you feel like
> tackling that work and then wiring up
syzbot suspects this issue was fixed by commit:
commit 61cf93700fe6359552848ed5e3becba6cd760efa
Author: Matthew Wilcox (Oracle)
Date: Mon Mar 8 14:16:16 2021 +
io_uring: Convert personality_idr to XArray
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16f91b9ad0
On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> +static inline
> +dma_addr_t page_pool_dma_addr_read(dma_addr_t dma_addr)
> +{
> + /* Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
> + * page. The page->dma_addr share area with
The new option for function tracing aims to save space on the ring
buffer and to make it more readable in the case when a single function
is called number of times consecutively:
while (cond)
do_func();
Instead of having an identical records for each call of the function
If the option is activated the function tracing record gets
consolidated in the cases when a single function is called number
of times consecutively. Instead of having an identical record for
each call of the function we will record only the first call
following by event showing the number of
On Tue, Apr 13, 2021 at 11:12 AM Peter Xu wrote:
>
> On Mon, Apr 12, 2021 at 09:40:22PM -0700, Axel Rasmussen wrote:
> > On Mon, Apr 12, 2021 at 4:17 PM Peter Xu wrote:
> > >
> > > On Thu, Apr 08, 2021 at 04:43:22PM -0700, Axel Rasmussen wrote:
> > > > +/*
> > > > + * Install PTEs, to map
On Fri, Apr 09, 2021 at 03:46:47PM +0900, Masahiro Yamada wrote:
> On Thu, Apr 8, 2021 at 12:25 AM Colin King wrote:
> >
> > From: Colin Ian King
> >
> > The for-loop iterates with a u8 loop counter i and compares this
> > with the loop upper limit of num_parents that is an int type.
> > There
The field is used to keep track of the consecutive (on the same CPU) calls
of a single function. This information is needed in order to consolidate
the function tracing record in the cases when a single function is called
number of times.
Signed-off-by: Yordan Karadzhov (VMware)
---
This patch only provides the implementation of the method.
Later we will used it in a combination with a new option for
function tracing.
Signed-off-by: Yordan Karadzhov (VMware)
---
kernel/trace/trace.c | 34 ++
kernel/trace/trace.h | 4
2 files changed,
The part of the code that prints the time of the trace record in
"int trace_print_context()" gets extracted in a static function. This
is done as a preparation for a following patch, in which we will define
a new ftrace event called "func_repeats". The new static method,
defined here, will be used
Currently the logic for dealing with the options for function tracing
has two different implementations. One is used when we set the flags
(in "static int func_set_flag()") and another used when we initialize
the tracer (in "static int function_trace_init()"). Those two
implementations are meant
The event aims to consolidate the function tracing record in the cases
when a single function is called number of times consecutively.
while (cond)
do_func();
This may happen in various scenarios (busy waiting for example).
The new ftrace event can be used to show
On 4/15/21 1:53 PM, Luis Chamberlain wrote:
On Wed, Aug 23, 2017 at 3:31 PM Jeff Mahoney wrote:
On 8/15/14 5:29 AM, Al Viro wrote:
On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote:
Christoph had noted that this seemed associated to the problem
that the btrfs uses different
On 4/15/21 1:53 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:27PM -0400, Waiman Long wrote:
Most kmem_cache_alloc() calls are from user context. With instrumentation
enabled, the measured amount of kmem_cache_alloc() calls from non-task
context was about 0.01% of the total.
The irq
On 4/15/21 11:09 AM, Paolo Bonzini wrote:
> On 07/04/21 20:00, Tom Lendacky wrote:
>> For the series:
>>
>> Acked-by: Tom Lendacky
>
> Shall I take this as a request (or permission, whatever :)) to merge it
> through the KVM tree?
Adding Herbert. Here's a link to the series:
On 4/15/21 1:00 PM, Borislav Petkov wrote:
> On Wed, Mar 24, 2021 at 12:04:09PM -0500, Brijesh Singh wrote:
>> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
>> index 06394b6d56b2..7a0138cb3e17 100644
>> --- a/arch/x86/mm/mem_encrypt.c
>> +++ b/arch/x86/mm/mem_encrypt.c
>> @@
The pull request you sent on Thu, 15 Apr 2021 17:55:06 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> acpi-5.12-rc8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7e25f40eab52c57ff6772d27d2aef3640a3237d7
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Thu, 15 Apr 2021 15:51:04 +0200 (CEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e7e3a53b30d6e6f54eef81400ddfe8b32224b77f
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Thu, 15 Apr 2021 15:58:51 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
> tags/gpio-fixes-for-v5.12-rc8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/33f0d9d94a0ef0814d23320c2536c4135d230114
Thank you!
--
The pull request you sent on Wed, 14 Apr 2021 22:28:04 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1df01322f00a0aedd4a589597ce9c0b680ae6068
Thank you!
--
Deet-doot-dot, I am a bot.
> From: Jakub Kicinski
> Sent: Thursday, April 15, 2021 10:44 AM
> ...
> On Wed, 14 Apr 2021 22:45:19 -0700 Dexuan Cui wrote:
> > + buf = dma_alloc_coherent(gmi->dev, length, _handle,
> > +GFP_KERNEL | __GFP_ZERO);
>
> No need for GFP_ZERO, dma_alloc_coherent()
On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote:
>
> > [ 15.428008]
> > ==
> > [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
> > crash_setup_memmap_entries+0x17e/0x3a0
>
> This looks like a genuine kernel bug on first
On Thu, Apr 15, 2021 at 01:08:29PM -0400, Waiman Long wrote:
> On 4/15/21 12:50 PM, Johannes Weiner wrote:
> > On Tue, Apr 13, 2021 at 09:20:25PM -0400, Waiman Long wrote:
> > > Before the new slab memory controller with per object byte charging,
> > > charging and vmstat data update happen only
On Wed, Apr 14, 2021 at 10:49:37AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyper-V provides GHCB protocol to write Synthetic Interrupt
> Controller MSR registers and these registers are emulated by
> Hypervisor rather than paravisor.
What is paravisor? Is that the VMPL0 to borrow AMD
On Thu, Apr 15, 2021 at 12:35:45PM -0400, Waiman Long wrote:
> On 4/15/21 12:30 PM, Johannes Weiner wrote:
> > On Tue, Apr 13, 2021 at 09:20:24PM -0400, Waiman Long wrote:
> > > In memcg_slab_free_hook()/pcpu_memcg_free_hook(), obj_cgroup_uncharge()
> > > is followed by
Em qui, 2021-04-15 às 18:14 +0100, Matthew Wilcox escreveu:
> On Thu, Apr 15, 2021 at 02:08:19PM -0300, Aline Santana Cordeiro
> wrote:
> > -const struct atomisp_format_bridge
> > *get_atomisp_format_bridge_from_mbus(
> > - u32 mbus_code);
> > +const struct atomisp_format_bridge*
> >
On 14/04/21 20:23, Ruifeng Zhang wrote:
> From: Ruifeng Zhang
>
> The arm topology still parse from the MPIDR, but it is incomplete. When
> the armv8.2 or above cpu runs kernel in EL1 with aarch32 mode, it will
> parse out the wrong topology.
>
Per my other email, isn't the problem that MPIDR
On 4/15/21 12:03 PM, Borislav Petkov wrote:
> On Wed, Mar 24, 2021 at 12:04:08PM -0500, Brijesh Singh wrote:
>> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> Also, why is all this SNP stuff landing in this file instead of in sev.c
> or so which is AMD-specific?
>
I don't
On 14/04/21 20:23, Ruifeng Zhang wrote:
> From: Ruifeng Zhang
>
> In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
> version, one of them is the kernel running on EL1 using aarch32.
> user(EL0) kernel(EL1)
> sc9863a_go aarch32
On Thu, Apr 15, 2021 at 08:26:21AM +, David Laight wrote:
> ...
> > Besides just FP, 128-bit, etc, I remain concerned about just basic
> > math operations. C has no way to describe the intent of integer
> > overflow, so the kernel was left with the only "predictable" result:
> > wrap around.
On Wed, 14 Apr 2021 21:56:39 +
David Laight wrote:
> From: Matthew Wilcox
> > Sent: 14 April 2021 22:36
> >
> > On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> > > (If others want to reproduce). First I could not reproduce on ARM32.
> > > Then I found out that
Hi Boris,
On 4/15/21 11:57 AM, Borislav Petkov wrote:
> On Wed, Mar 24, 2021 at 12:04:08PM -0500, Brijesh Singh wrote:
>> The lookup_page_in_rmptable() can be used by the host to read the RMP
>> entry for a given page. The RMP entry format is documented in PPR
>> section 2.1.5.2.
> I see
>
>
On Tue, Apr 13, 2021 at 1:15 PM Peter Xu wrote:
>
> On Mon, Apr 12, 2021 at 10:17:19PM -0700, Axel Rasmussen wrote:
> > Currently, the context (fds, mmap-ed areas, etc.) are global. Each test
> > mutates this state in some way, in some cases really "clobbering it"
> > (e.g., the events test
On Wed, Apr 14, 2021 at 5:43 PM Miguel Ojeda
wrote:
>
> On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
> wrote:
> >
> > -Oz in clang typically generates larger kernel code than -Os; LLVM
> > seems to aggressively emit libcalls even when the setup for a call
> > would be larger than the inlined
First thanks to you both, Alex and Bjorn!
I am in no way an expert on this topic, so I have to fully rely on your
feedback, concerning this issue.
If you should have any other solution approach, in form of patch-set, I
would be glad to test it out. Just let me know, what you think might
make
Wesley Cheng wrote:
>
>
> On 4/14/2021 11:26 PM, Felipe Balbi wrote:
>> Wesley Cheng writes:
>>
>>> If an error is received when issuing a start or update transfer
>>> command, the error handler will stop all active requests (including
>>> the current USB request), and call
Many other resource flag parsers already add this flag when the input
has bits 24 & 25 set, so update this one to do the same.
Some devices (like virtio-net) have more than one memory resource
(like MMIO32 and MMIO64) and without this flag it would be needed to
verify the address range to know
On Wed, Mar 24, 2021 at 12:04:09PM -0500, Brijesh Singh wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 06394b6d56b2..7a0138cb3e17 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -644,3 +644,44 @@ rmpentry_t
Le 4/15/21 à 12:54 AM, Alex Ghiti a écrit :
Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit :
On Sun, 11 Apr 2021 09:41:44 PDT (-0700), a...@ghiti.fr wrote:
This is a preparatory patch for relocatable kernel and sv48 support.
The kernel used to be linked at PAGE_OFFSET address therefore we
Consider the following topology:
DIE [ ]
MC [][]
0 1 2 3
capacity_orig_of(x \in {0-1}) < capacity_orig_of(x \in {2-3})
w/ CPUs 2-3 idle and CPUs 0-1 running CPU hogs (util_avg=1024).
When CPU2 goes through load_balance() (via periodic / NOHZ balance), it
Consider the following (hypothetical) asymmetric CPU capacity topology,
with some amount of capacity pressure (RT | DL | IRQ | thermal):
DIE [ ]
MC [][]
0 1 2 3
| CPU | capacity_orig | capacity |
|-+---+--|
| 0 | 870 |
Hi folks,
This is the misfit-specific bits I tore out of [1] and that I've been further
chewing on.
o Patch 1 pays attention to group vs CPU capacity checks. It's removing some
safeguard we had against downmigrations, so it had to grow fatter to
compensate for it.
o Patch 2 aligns running
This patch provides counters for SRv6 Behaviors as defined in [1],
section 6. For each SRv6 Behavior instance, counters defined in [1] are:
- the total number of packets that have been correctly processed;
- the total amount of traffic in bytes of all packets that have been
correctly
x86/crash: fix crash_setup_memmap_entries() KASAN vmalloc-out-of-bounds gripe
[ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
crash_setup_memmap_entries+0x17e/0x3a0
[ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187
(gdb) list *crash_setup_memmap_entries+0x17e
On Wed, Aug 23, 2017 at 3:31 PM Jeff Mahoney wrote:
>
> On 8/15/14 5:29 AM, Al Viro wrote:
> > On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote:
> >
> >> Christoph had noted that this seemed associated to the problem
> >> that the btrfs uses different assignments for st_dev than
On Tue, Apr 13, 2021 at 09:20:27PM -0400, Waiman Long wrote:
> Most kmem_cache_alloc() calls are from user context. With instrumentation
> enabled, the measured amount of kmem_cache_alloc() calls from non-task
> context was about 0.01% of the total.
>
> The irq disable/enable sequence used in
On 4/14/2021 11:26 PM, Felipe Balbi wrote:
> Wesley Cheng writes:
>
>> If an error is received when issuing a start or update transfer
>> command, the error handler will stop all active requests (including
>> the current USB request), and call dwc3_gadget_giveback() to notify
>> function
On Tue, 13 Apr 2021 17:08:04 -0700, Nathan Chancellor wrote:
> After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> set atomically"), LLVM's integrated assembler fails to build entry.S:
>
> :5:7: error: expected assembly-time absolute expression
> .org . - (664b-663b) +
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 104 +-
1 file changed, 75 insertions(+), 29 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
Andrii suggested to remove this abstraction layer and have the percpu
handling more explicit[1].
This patch also updates the tests that relied on the macros.
[1]
https://lore.kernel.org/bpf/caef4bzymj_zpdq8zi4dbntbojkrpu2tvopysbnrdd9fohtf...@mail.gmail.com/
Suggested-by: Andrii Nakryiko
Uses the already in-place infrastructure provided by the
'generic_map_*_batch' functions.
No tweak was needed as it transparently handles the percpu variant.
As arrays don't have delete operations, let it return a error to
user space (default behaviour).
Suggested-by: Jamal Hadi Salim
This patchset introduces batched operations for the per-cpu variant of
the array map.
It also removes the percpu macros from 'bpf_util.h'. This change was
suggested by Andrii in a earlier iteration of this patchset.
The tests were updated to reflect all the new changes.
v3 -> v4:
- Prefer
On 4/15/21 1:27 PM, Ali Saidi wrote:
While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock. The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is
On Wed, 14 Apr 2021 22:45:19 -0700 Dexuan Cui wrote:
> + buf = dma_alloc_coherent(gmi->dev, length, _handle,
> + GFP_KERNEL | __GFP_ZERO);
No need for GFP_ZERO, dma_alloc_coherent() zeroes the memory these days.
> +static int mana_gd_register_irq(struct
On 4/15/21 1:10 PM, Matthew Wilcox wrote:
On Tue, Apr 13, 2021 at 09:20:22PM -0400, Waiman Long wrote:
With memory accounting disable, the run time was 2.848s. With memory
accounting enabled, the run times with the application of various
patches in the patchset were:
Applied patches Run
401 - 500 of 1581 matches
Mail list logo
