Add a new config ARCH_HAS_VM_GET_PAGE_PROT, which when subscribed enables a
given platform to define its own vm_get_page_prot() but still utilizing the
generic protection_map[] array.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Catalin Marinas
protection_map[] is an array based construct that translates given vm_flags
combination. This array contains page protection map, which is populated by
the platform via [__S000 .. __S111] and [__P000 .. __P111] exported macros.
Primary usage for protection_map[] is for vm_get_page_prot(), which is
Excerpts from Laurent Dufour's message of April 2, 2022 12:06 am:
> RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32bits
> mode (MSR[SF] unset).
>
> The change in MSR is done in enter_rtas() in a relatively complex way,
> since the MSR value could be hardcoded.
>
> Furthermore, a
+Daniel, Thomas, Viresh
Subject: Re: rcu_sched self-detected stall on CPU
Excerpts from Michael Ellerman's message of April 9, 2022 12:42 am:
> Michael Ellerman writes:
>> "Paul E. McKenney" writes:
>>> On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
Hi
I can
On 4/12/22 17:57, Christophe Leroy wrote:
>
>
> Le 12/04/2022 à 06:38, Anshuman Khandual a écrit :
>> This defines and exports a platform specific custom vm_get_page_prot() via
>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. While here, this also localizes
>> arch_vm_get_page_prot() as
On 4/12/22 17:59, Christophe Leroy wrote:
>
>
> Le 12/04/2022 à 06:38, Anshuman Khandual a écrit :
>> There are no platforms left which subscribe ARCH_HAS_FILTER_PGPROT. Hence
>> drop generic arch_filter_pgprot() and also config ARCH_HAS_FILTER_PGPROT.
>>
>> Cc: Andrew Morton
>> Cc:
On 4/12/22 18:00, Christophe Leroy wrote:
>
>
> Le 12/04/2022 à 06:38, Anshuman Khandual a écrit :
>> There are no platforms left which use arch_vm_get_page_prot(). Just drop
>> generic arch_vm_get_page_prot().
>>
>> Cc: Andrew Morton
>> Cc: linux...@kvack.org
>> Cc:
On Tue, Apr 12, 2022 at 4:30 PM wrote:
> From: Minghao Chi
>
> Using pm_runtime_resume_and_get is more appropriate
> for simplifing code
>
> Reported-by: Zeal Robot
> Signed-off-by: Minghao Chi
>
Acked-by: Shengjiu Wang
Best regards
Wang Shengjiu
> ---
> sound/soc/fsl/fsl_esai.c | 6
On Tue, 12 Apr 2022 14:15:53 +0200 Jakob Koschel wrote:
> - struct list_head *head = >rss_context.list;
> + struct list_head *head = *pos = >rss_context.list;
ENOTBUILT, please wait with the reposting. Since you posted two
versions today I guess that's 2x 24h? :)
On Tue, 12 Apr 2022 08:30:00 +, cgel@gmail.com wrote:
> From: Minghao Chi
>
> Using pm_runtime_resume_and_get is more appropriate
> for simplifing code
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl: using
On Tue, Apr 12, 2022 at 04:47:47PM +1000, Michael Ellerman wrote:
> Christophe Leroy writes:
> > Hi Ariel
> >
> > Le 09/04/2022 à 15:47, Ariel Marcovitch a écrit :
> >> Hi Christophe, did you get the chance to look at this?
> >
> > I tested something this morning, it works for me, see below
> >
>
The 'perf bench numa' testcase fails on systems with more than 1K CPUs.
Testcase: perf bench numa mem -p 1 -t 3 -P 512 -s 100 -zZ0qcm --thp 1
Snippet of code:
<<>>
perf: bench/numa.c:302: bind_to_node: Assertion `!(ret)' failed.
Aborted (core dumped)
<<>>
bind_to_node function uses
Perf numa bench test fails with error:
Testcase:
./perf bench numa mem -p 2 -t 1 -P 1024 -C 0,8 -M 1,0 -s 20 -zZq
--thp 1 --no-data_rand_walk
Failure snippet:
<<>>
Running 'numa/mem' benchmark:
# Running main, "perf bench numa numa-mem -p 2 -t 1 -P 1024 -C 0,8
-M 1,0 -s 20 -zZq --thp 1
The perf benchmark for collections: numa hits failure in system
configuration with CPU's more than 1024. These benchmarks uses
"sched_getaffinity" and "sched_setaffinity" in the code to
work with affinity.
Example snippet from numa benchmark:
<<>>
perf: bench/numa.c:302: bind_to_node: Assertion
> On 09-Apr-2022, at 10:48 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Sat, Apr 09, 2022 at 12:28:01PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Apr 06, 2022 at 11:21:09PM +0530, Athira Rajeev escreveu:
>>> The perf benchmark for collections: numa, futex and epoll
>>> hits failure
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: 83d8a0d166119de813cad27ae7d61f54f9aea707 Automatic merge of
'master' into merge (2022-04-11 23:56)
elapsed time: 1324m
configs tested: 125
configs skipped: 3
The following configs have been
On Tue, Apr 12, 2022 at 04:53:06PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > On Sun, Apr 10, 2022 at 09:33:43PM +1000, Michael Ellerman wrote:
> >> Zhouyi Zhou writes:
> >> > On Fri, Apr 8, 2022 at 10:07 PM Paul E. McKenney
> >> > wrote:
> >> >> On Fri, Apr 08, 2022 at
On Tue, 2022-04-12 at 13:37 +0200, Jakob Koschel wrote:
>
> > On 12. Apr 2022, at 13:27, Russell King (Oracle)
> > wrote:
> >
> > On Tue, Apr 12, 2022 at 12:58:17PM +0200, Jakob Koschel wrote:
> > > We know that "dev > dst->last_switch" in the "else" block.
> > > In other words, that "dev -
Le 17/03/2022 à 16:38, Mans Rullgard a écrit :
> In some cases, the TXE flag is apparently set without any error
> indication in the buffer descriptor status. When this happens, tx
> stalls until the tx_restart() function is called via the device
> watchdog which can take a long time.
Is there
Le 12/04/2022 à 06:38, Anshuman Khandual a écrit :
> There are no platforms left which use arch_vm_get_page_prot(). Just drop
> generic arch_vm_get_page_prot().
>
> Cc: Andrew Morton
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Reviewed-by: Catalin Marinas
> Signed-off-by:
Le 12/04/2022 à 06:38, Anshuman Khandual a écrit :
> There are no platforms left which subscribe ARCH_HAS_FILTER_PGPROT. Hence
> drop generic arch_filter_pgprot() and also config ARCH_HAS_FILTER_PGPROT.
>
> Cc: Andrew Morton
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
>
Le 12/04/2022 à 06:38, Anshuman Khandual a écrit :
> This defines and exports a platform specific custom vm_get_page_prot() via
> subscribing ARCH_HAS_VM_GET_PAGE_PROT. While here, this also localizes
> arch_vm_get_page_prot() as __vm_get_page_prot() and moves it near
> vm_get_page_prot().
>
>
In preparation to limit the scope of the list iterator variable to the
list traversal loop, use a dedicated pointer to iterate through the
list [1].
Since that variable should not be used past the loop iteration, a
separate variable is used to 'remember the current location within the
loop'.
To
In preparation to limit the scope of the list iterator variable to the
list traversal loop, use a dedicated pointer to iterate through the
list [1].
Since that variable should not be used past the loop iteration, a
separate variable is used to 'remember the current location within the
loop'.
To
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
In preparation to limit the scope of a list iterator to the list
traversal loop, use a dedicated pointer pointing to the location
where the element should be inserted [1].
Before, the code implicitly used the head when no element was found
when using >list. The new 'pos' variable is set to the
In preparation to limit the scope of a list iterator to the list
traversal loop, use a dedicated pointer pointing to the location
where the element should be inserted [1].
Before, the code implicitly used the head when no element was found
when using >list. The new 'pos' variable is set to the
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based on the head element, either with
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
Since "found" and "p_ent" need to be equal, "found" should be used
consistently to limit the scope of "p_ent" to the list traversal
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable [1].
Link:
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
From: Vladimir Oltean
To avoid bugs and speculative execution exploits due to type-confused
pointers at the end of a list_for_each_entry() loop, one measure is to
restrict code to not use the iterator variable outside the loop block.
In the case of mv88e6xxx_port_vlan(), this isn't a problem,
From: Vladimir Oltean
We know that "dev > dst->last_switch" in the "else" block.
In other words, that "dev - dst->last_switch" is > 0.
dsa_port_bridge_num_get(dp) can be 0, but the check
"if (bridge_num + dst->last_switch != dev) continue", rewritten as
"if (bridge_num != dev -
From: Vladimir Oltean
sja1105_first_entry_longer_than() does not make use of the full struct
sja1105_gate_entry *e, just of e->interval which is set from the passed
entry_time.
This means that if there is a gate conflict, we have allocated e for
nothing, just to free it later. Reorder the
When the list iterator loop does not exit early the list iterator variable
contains a type-confused pointer to a 'bogus' list element computed based
on the head [1].
Often a 'found' variable is used to ensure the list iterator
variable is only accessed after the loop body if the loop did exit
From: Vladimir Oltean
When passed a non-head list element, list_add_tail() actually adds the
new element to its left, which is what we want. Despite the slightly
confusing name, use the dedicated function which does the same thing as
the open-coded list_add(pos->prev).
Suggested-by: Jakub
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
From: Vladimir Oltean
The link below explains that there is a desire to syntactically change
list_for_each_entry() and list_for_each() such that it becomes
impossible to use the iterator variable outside the scope of the loop.
Although sja1105_insert_gate_entry() makes legitimate use of the
> On 12. Apr 2022, at 13:27, Russell King (Oracle)
> wrote:
>
> On Tue, Apr 12, 2022 at 12:58:17PM +0200, Jakob Koschel wrote:
>> We know that "dev > dst->last_switch" in the "else" block.
>> In other words, that "dev - dst->last_switch" is > 0.
>>
>> dsa_port_bridge_num_get(dp) can be 0,
On Tue, Apr 12, 2022 at 12:58:17PM +0200, Jakob Koschel wrote:
> We know that "dev > dst->last_switch" in the "else" block.
> In other words, that "dev - dst->last_switch" is > 0.
>
> dsa_port_bridge_num_get(dp) can be 0, but the check
> "if (bridge_num + dst->last_switch != dev) continue",
In preparation to limit the scope of the list iterator variable to the
list traversal loop, use a dedicated pointer to iterate through the
list [1].
Since that variable should not be used past the loop iteration, a
separate variable is used to 'remember the current location within the
loop'.
To
In preparation to limit the scope of the list iterator variable to the
list traversal loop, use a dedicated pointer to iterate through the
list [1].
Since that variable should not be used past the loop iteration, a
separate variable is used to 'remember the current location within the
loop'.
To
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
In preparation to limit the scope of a list iterator to the list
traversal loop, use a dedicated pointer pointing to the location
where the element should be inserted [1].
Before, the code implicitly used the head when no element was found
when using >list. The new 'pos' variable is set to the
In preparation to limit the scope of a list iterator to the list
traversal loop, use a dedicated pointer pointing to the location
where the element should be inserted [1].
Before, the code implicitly used the head when no element was found
when using >list. The new 'pos' variable is set to the
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based on the head element, either with
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
Since "found" and "p_ent" need to be equal, "found" should be used
consistently to limit the scope of "p_ent" to the list traversal
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable [1].
Link:
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
To avoid bugs and speculative execution exploits due to type-confused
pointers at the end of a list_for_each_entry() loop, one measure is to
restrict code to not use the iterator variable outside the loop block.
In the case of mv88e6xxx_port_vlan(), this isn't a problem, as we never
let the loops
We know that "dev > dst->last_switch" in the "else" block.
In other words, that "dev - dst->last_switch" is > 0.
dsa_port_bridge_num_get(dp) can be 0, but the check
"if (bridge_num + dst->last_switch != dev) continue", rewritten as
"if (bridge_num != dev - dst->last_switch) continue", aka
"if
When passed a non-head list element, list_add_tail() actually adds the
new element to its left, which is what we want. Despite the slightly
confusing name, use the dedicated function which does the same thing as
the open-coded list_add(pos->prev).
Suggested-by: Jakub Kicinski
Signed-off-by:
When the list iterator loop does not exit early the list iterator variable
contains a type-confused pointer to a 'bogus' list element computed based
on the head [1].
Often a 'found' variable is used to ensure the list iterator
variable is only accessed after the loop body if the loop did exit
The link below explains that there is a desire to syntactically change
list_for_each_entry() and list_for_each() such that it becomes
impossible to use the iterator variable outside the scope of the loop.
Although sja1105_insert_gate_entry() makes legitimate use of the
iterator pointer when it
sja1105_first_entry_longer_than() does not make use of the full struct
sja1105_gate_entry *e, just of e->interval which is set from the passed
entry_time.
This means that if there is a gate conflict, we have allocated e for
nothing, just to free it later. Reorder the memory allocation and the
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found
From: Minghao Chi
Using pm_runtime_resume_and_get is more appropriate
for simplifing code
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
---
sound/soc/fsl/fsl_esai.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c
https://bugzilla.kernel.org/show_bug.cgi?id=215803
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |RESOLVED
"Paul E. McKenney" writes:
> On Sun, Apr 10, 2022 at 09:33:43PM +1000, Michael Ellerman wrote:
>> Zhouyi Zhou writes:
>> > On Fri, Apr 8, 2022 at 10:07 PM Paul E. McKenney
>> > wrote:
>> >> On Fri, Apr 08, 2022 at 06:02:19PM +0800, Zhouyi Zhou wrote:
>> >> > On Fri, Apr 8, 2022 at 3:23 PM
Christophe Leroy writes:
> Hi Ariel
>
> Le 09/04/2022 à 15:47, Ariel Marcovitch a écrit :
>> Hi Christophe, did you get the chance to look at this?
>
> I tested something this morning, it works for me, see below
>
>>
>> On 23/03/2022 21:06, Mike Rapoport wrote:
>>> Hi Catalin,
>>>
>>> On Wed,
Sasha Levin writes:
> From: Kefeng Wang
>
> [ Upstream commit ffa0b64e3be58519ae472ea29a1a1ad681e32f48 ]
>
> mpe: On 64-bit Book3E vmalloc space starts at 0x8000.
This cherry-pick is good, but can you also pick up the immediately
following commit:
1ff5c8e8c835 ("Revert "powerpc:
On Wed, Apr 06, 2022 at 08:25:32PM -0400, Konrad Rzeszutek Wilk wrote:
> > diff --git a/arch/powerpc/platforms/pseries/svm.c
> > b/arch/powerpc/platforms/pseries/svm.c
> > index c5228f4969eb2..3b4045d508ec8 100644
> > --- a/arch/powerpc/platforms/pseries/svm.c
> > +++
68 matches
Mail list logo
