To queue a new batch we have a kfree_rcu_monitor() function that
checks "monitor_todo" var. and invokes kfree_rcu_drain_unlock()
to start a new batch after a GP. Get rid of open-coded case by
switching it to the separate function.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 8
Before attempting of starting a new batch a "monitor_todo" var.
is set to "false" and set back to "true" when a previous RCU
batch is still in progress.
Drop it to "false" only when a new batch has been successfully
queued, if not, it stays active anyway. There is no reason in
setting it force and
On 4/15/21 8:07 AM, Igor Matheus Andrade Torrente wrote:
Fixes a race condition - for lack of a more precise term - between
em28xx_v4l2_open and em28xx_v4l2_init, by detaching the v4l2_dev,
media_pad and vdev structs from the em28xx_v4l2, and managing the
lifetime of those objects more dynamicaly
On Thu, Apr 15, 2021 at 04:56:00PM +, codrin.ciubota...@microchip.com wrote:
> Are there any plans for refactoring DPCM? any ideas ongoing? I also have
> some changes for PCM dmaengine, in the same 'style', similar to what I
> sent some time ago...
> I can adjust to different ideas, if there
On Wed, Apr 14, 2021 at 2:53 PM Andy Shevchenko
wrote:
>
> We have open coded dev_set_name() implementation, replace that
> with a direct call.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/base/power/wakeup_stats.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dr
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 completed
successfully which isn’t ordered.
Make include/config/foo/bar.h fake deps files generation simpler.
* delete .h suffix
those aren't header files, shorten filenames,
* delete tolower()
Linux filesystems can deal with both upper and lowercase
filenames very well,
* put everything in 1 directory
Pres
On 2021-04-14 14:09, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-04-13 16:11:44)
Make sure main link is in connection state before start aux
read/write operation to avoid unnecessary long delay due to
main link had been unplugged.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_a
> On Apr 15, 2021, at 10:00 AM, Dave Hansen wrote:
>
> On 4/15/21 9:24 AM, Andy Lutomirski wrote:
>> In the patches, *as submitted*, if you trip the XFD #NM *once* and you
>> are the only thread on the system to do so, you will eat the cost of a
>> WRMSR on every subsequent context switch.
>
On 2021-04-14 14:22, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-04-14 14:02:50)
Initialize audio_comp when audio starts and wait for audio_comp at
dp_display_disable(). This will take care of both dongle unplugged
and display off (suspend) cases.
Changes in v2:
-- add dp_display_start_audio
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 ti
On Wed, 14 Apr 2021 22:45:19 -0700 Dexuan Cui wrote:
> + buf = dma_alloc_coherent(gmi->dev, length, &dma_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 gdma_q
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 compl
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 'callo
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
Signed-of
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
Signed
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
b/tools/testing/sel
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) + (662b-6
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 drive
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 this
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 s
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
0xf
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 processe
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 and
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 |
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
should
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
coul
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 *lookup_page_in_rmptabl
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 whi
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 dwc3_gadget_giveback(
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 sens
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
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 mremap
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
>
> Tabl
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. Un
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 en
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 ha
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 aa
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 ca
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*
> > +get_atomis
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 mod_objcg_state()/mod_memcg_
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 spe
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 wh
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
> 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, &dma_handle,
> > +GFP_KERNEL | __GFP_ZERO);
>
> No need for GFP_ZERO, dma_alloc_coherent()
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.
ht
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!
--
Deet-d
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 bot
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
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
>> @@
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:
https://lore.kernel.
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 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
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 repeated
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)
---
kernel/trace
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, 38
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 is
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 repea
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 dst_add
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
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
w
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 to
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 page->compound
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
start
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 b
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 controller
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 for-next
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] spi:
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 snd_pcm_hw_para
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"
[drivers/gpu/drm/bridge
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"
[drivers/gpu/drm/bridge/lonti
-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 uni
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:
https://gitlab.
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
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
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: Val
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 b
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.
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 insertions(+
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 complex
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: mcopy_atomic_install_ptes.
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, w
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
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 crea
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() duplic
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 --gi
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
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
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;
> > unsigne
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
ind
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 changed,
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 kmem_cache
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 address
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 and
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 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 TH
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 an
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 & HRTIMER_ACTIVE_SO
+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 brea
901 - 1000 of 1574 matches
Mail list logo
