On Mon, Jul 27, 2020 at 12:31:49PM -0400, Alan Stern wrote:
> On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> > On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > > Given a type "T", an object x of type pointer-to-T, and a function
> > > "func" that takes various argu
Greg Kroah-Hartman writes:
> From: Gabriel Krisman Bertazi
>
> [ Upstream commit 087615bf3acdafd0ba7c7c9ed5286e7b7c80fe1b ]
>
> The HST path selector needs this information to perform path
> prediction. For request-based mpath, struct request's io_start_time_ns
> is used, while for bio-based, us
Greg Kroah-Hartman writes:
> From: Gabriel Krisman Bertazi
>
> [ Upstream commit 087615bf3acdafd0ba7c7c9ed5286e7b7c80fe1b ]
>
> The HST path selector needs this information to perform path
> prediction. For request-based mpath, struct request's io_start_time_ns
> is used, while for bio-based, us
On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > Given a type "T", an object x of type pointer-to-T, and a function
> > "func" that takes various arguments and returns a pointer-to-T, the
> > accepted API for calling f
On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > Given a type "T", an object x of type pointer-to-T, and a function
> > "func" that takes various arguments and returns a pointer-to-T, the
> > accepted API for calling f
On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> Given a type "T", an object x of type pointer-to-T, and a function
> "func" that takes various arguments and returns a pointer-to-T, the
> accepted API for calling func once would be to create once_func() as
> follows:
>
> T *once_func(
On Fri, Jul 17, 2020 at 10:28:18PM -0700, Eric Biggers wrote:
> I'm still not sure this is the best API.
I cast my vote for something along the following lines. It's simple,
easily understood and easily used. The approach has two variants: One
that returns an integer and one that returns a point
From: Gabriel Krisman Bertazi
[ Upstream commit 087615bf3acdafd0ba7c7c9ed5286e7b7c80fe1b ]
The HST path selector needs this information to perform path
prediction. For request-based mpath, struct request's io_start_time_ns
is used, while for bio-based, use the start_time stored in dm_io.
Signed
From: Sergey Organov
[ Upstream commit 340746398b67e3ce5019698748ebaa7adf048114 ]
Fix support for external PTP-aware devices such as DSA or PTP PHY:
Make sure we never time stamp tx packets when hardware time stamping
is disabled.
Check for PTP PHY being in use and then pass ioctls related to
From: Gabriel Krisman Bertazi
[ Upstream commit 087615bf3acdafd0ba7c7c9ed5286e7b7c80fe1b ]
The HST path selector needs this information to perform path
prediction. For request-based mpath, struct request's io_start_time_ns
is used, while for bio-based, use the start_time stored in dm_io.
Signed
On Fri, Jul 17, 2020 at 06:02:47PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 01:51:38PM -0400, Alan Stern wrote:
> > On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > ...
> > > > + /* on s
On 21/07/2020 04:26, zhukeqian wrote:
Hi Steven,
Hi Keqian,
On 2019/8/2 22:50, Steven Price wrote:
This series add support for paravirtualized time for arm64 guests and
KVM hosts following the specification in Arm's document DEN 0057A:
https://developer.arm.com/docs/den0057/
To meet mipi hi speed transmission, decrease hs_trail time to pass mipi
test.
Signed-off-by: David Lu
---
drivers/media/i2c/ov8856.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
index 4ca27675cc5a..1f1835b14a24
Set ramdisk_execute_command to "/init" at compile time. The command
line can still override it, but this saves a few instructions and
removes a NULL check.
Signed-off-by: Christoph Hellwig
---
init/main.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/ini
Committer: Ingo Molnar
CommitterDate: Sat, 25 Jul 2020 21:47:42 +02:00
locking/lockdep: Fix overflow in presentation of average lock-time
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense values with more than 2 billion acquisitons. E.g.
acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg
--
: Ingo Molnar
CommitterDate: Sat, 25 Jul 2020 15:49:41 +02:00
x86/xen/time: Set the X86_FEATURE_TSC_KNOWN_FREQ flag in xen_tsc_khz()
If the TSC frequency is known from the pvclock page,
the TSC frequency does not need to be recalibrated.
We can avoid recalibration by setting
wrote:
> > > > The compressed kernel currently contains bogus run-time relocations in
> > > > the startup code in head_{32,64}.S, which are generated by the linker,
> > > > but must not actually be processed at run-time.
> > > >
> > > > This gen
> > On Sat, Jul 04, 2020 at 11:40:55PM -0700, Andrei Vagin wrote:
> > > > > On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote:
> > > > > > Allocate the time namespace page among VVAR pages and add the logic
> > > > > > to han
gt; On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote:
> > > > > Allocate the time namespace page among VVAR pages and add the logic
> > > > > to handle faults on VVAR properly.
> > > > >
> > > > > If a task belongs to a time nam
Catalin Marinas writes:
> On Thu, Jul 23, 2020 at 10:25:35PM +0200, Thomas Gleixner wrote:
>> Andrei Vagin writes:
>> > On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote:
>> >
>> > I don't think that we need to handle this case in the kernel. Users
>> > must understand what they are
On Thu, Jul 23, 2020 at 08:58:51PM +0800, Hsin-Hsiung Wang wrote:
> Add the enable time for LDOs.
> This patch is preparing for adding mt6359p regulator support.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, Jul 23, 2020 at 10:25:35PM +0200, Thomas Gleixner wrote:
> Andrei Vagin writes:
> > On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote:
> >
> > I don't think that we need to handle this case in the kernel. Users
> > must understand what they are doing and have to write code so
Andrei Vagin writes:
> On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote:
>
> I don't think that we need to handle this case in the kernel. Users
> must understand what they are doing and have to write code so that avoid
> these sort of situations. In general, I would say that in mos
On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote:
> On Mon, Jul 13, 2020 at 06:57:43PM -0700, Andrei Vagin wrote:
> > On Sat, Jul 04, 2020 at 11:40:55PM -0700, Andrei Vagin wrote:
> > > On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote:
> > > &g
Add the enable time for LDOs.
This patch is preparing for adding mt6359p regulator support.
Signed-off-by: Hsin-Hsiung Wang
---
drivers/regulator/mt6359-regulator.c | 65 +++-
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/regulator
On Mon, Jul 13, 2020 at 06:57:43PM -0700, Andrei Vagin wrote:
> On Sat, Jul 04, 2020 at 11:40:55PM -0700, Andrei Vagin wrote:
> > On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote:
> > > Allocate the time namespace page among VVAR pages and add the logic
> > &g
On Fri, Jul 03, 2020 at 07:26:12PM +0530, Raviteja Narayanam wrote:
> There are few issues on Zynq SOC observed in the stress tests causing
> timeout errors. Even though all the data is received, timeout error
> is thrown. This is due to an IP bug in which the COMP bit in ISR is
> not set at end of
On 7/21/20 12:12 PM, Hayato Ohhashi wrote:
> If the TSC frequency is known from the pvclock page,
> the TSC frequency does not need to be recalibrated.
> We can avoid recalibration by setting X86_FEATURE_TSC_KNOWN_FREQ.
>
> Signed-off-by: Hayato Ohhashi
Reviewed-by: Boris Ostrovsky
From: "Steven Rostedt (Red Hat)"
Add the functions kbuffer_subbuf_timestamp() and kbuffer_ptr_delta() to get
the timing data stored in the ring buffer that is used to produced the time
stamps of the records.
This is useful for tools like trace-cmd to be able to display the content o
Set ramdisk_execute_command to "/init" at compile time. The command
line can still override it, but this saves a few instructions and
removes a NULL check.
Signed-off-by: Christoph Hellwig
---
init/main.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/ini
/time.c b/arch/x86/xen/time.c
index c8897aad13cd..91f5b330dcc6 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -39,6 +39,7 @@ static unsigned long xen_tsc_khz(void)
struct pvclock_vcpu_time_info *info =
&HYPERVISOR_shared_info->vcpu_info[
Hi Steven,
On 2019/8/2 22:50, Steven Price wrote:
> This series add support for paravirtualized time for arm64 guests and
> KVM hosts following the specification in Arm's document DEN 0057A:
>
> https://developer.arm.com/docs/den0057/a
>
> It implements support for st
On Mon, Jul 20, 2020 at 06:48:50PM +0200, pet...@infradead.org wrote:
> On Mon, Jul 20, 2020 at 09:04:34AM -0700, Paul E. McKenney wrote:
> > 2. If we were to say "unlock" instead of "release", consistency
> > would demand that we also say "lock" instead of "acquire".
> > But "lock" is sub
On Mon, Jul 20, 2020 at 09:04:34AM -0700, Paul E. McKenney wrote:
> 2.If we were to say "unlock" instead of "release", consistency
> would demand that we also say "lock" instead of "acquire".
> But "lock" is subtlely different than "acquire", and there is
> a history of people
ent I want to read.
: This document describes the ideas underlying the LKMM. It is meant
: for people who want to understand how the model was designed. It does
: not go into the details of the code in the .bell and .cat files;
: rather, it explains in English what the code expresses symbol
at.
>
> For another, you appear to be confusing the LKMM with the kernel's API,
> and reference documents with programming guides (or recipes). I'm sure
> that you aren't doing this deliberately and are well aware of these
> distinctions, but that's the impre
From: Anson Huang
[ Upstream commit b45fd13be340e4ed0a2a9673ba299eb2a71ba829 ]
After finishing using cpu node got from of_get_cpu_node(), of_node_put()
needs to be called.
Signed-off-by: Anson Huang
Signed-off-by: Daniel Lezcano
Link:
https://lore.kernel.org/r/1585232945-23368-1-git-send-ema
Set ramdisk_execute_command to "/init" at compile time. The command
line can still override it, but this saves a few instructions and
removes a NULL check.
Signed-off-by: Christoph Hellwig
---
init/main.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/ini
From: Anson Huang
[ Upstream commit b45fd13be340e4ed0a2a9673ba299eb2a71ba829 ]
After finishing using cpu node got from of_get_cpu_node(), of_node_put()
needs to be called.
Signed-off-by: Anson Huang
Signed-off-by: Daniel Lezcano
Link:
https://lore.kernel.org/r/1585232945-23368-1-git-send-ema
From: Alex Deucher
commit 3168470142e0a82b5732c04ed4c031a9322ae170 upstream.
Prevents a warning in the MST create connector case.
v2: create global fake encoders rather per connector fake encoders
to avoid running out of encoder indices.
v3: use the actual number of crtcs on the asic rather th
On Mon, Jul 20, 2020 at 04:39:11PM +0100, Matthew Wilcox wrote:
> Honestly, even the term "release semantics" trips me up _every_ time.
> It's a barrier to understanding because I have to translate it into "Oh,
> he means it's like an unlock". Why can'
; : for people who want to understand how the model was designed. It does
> : not go into the details of the code in the .bell and .cat files;
> : rather, it explains in English what the code expresses symbolically.
>
> I don't want to know how the model was designed. I want to
> > That
> > file was specifically written for non-experts to help them overcome the
> > learning curve. It tries to define the vocabulary as terms are
> > introduced and to avoid using obscure syntax.
>
> It tries to teach people about what a memory model is at t
On Mon, Jul 20, 2020 at 12:07:31PM +1000, Dave Chinner wrote:
> The whole serialisation/atomic/ordering APIs have fallen badly off
> the macro cliff, to the point where finding out something as simple
> as the order of parameters passed to cmpxchg and what semantics it
> provides requires macro-spe
On Fri, Jul 17, 2020 at 10:28:18PM -0700, Eric Biggers wrote:
> What do people think about the following instead? (Not proofread / tested
> yet,
> so please comment on the high-level approach, not minor mistakes :-) )
No huge long macros, please.
We don't accept people writing long complex stat
s.
> That
> file was specifically written for non-experts to help them overcome the
> learning curve. It tries to define the vocabulary as terms are
> introduced and to avoid using obscure syntax.
It tries to teach people about what a memory model is at the same
time it tries to defin
On 7/17/20 6:29 AM, Tero Kristo wrote:
> Certain watchdogs require the watchdog only to be pinged within a
> specific time window, pinging too early or too late cause the watchdog
> to fire. In cases where this sort of watchdog has been started before
> kernel comes up, we must adjust
On Fri, Jul 17, 2020 at 10:28:18PM -0700, Eric Biggers wrote:
> /**
> * INIT_ONCE() - do one-time initialization
> * @done: pointer to a 'bool' flag that tracks whether initialization has been
> * done yet or not. Must be false by default.
> * @mutex: poi
On Sat, Jul 18, 2020 at 12:00:01PM +1000, Dave Chinner wrote:
> Recipes are aimed at people who simply don't understand any of that
> goobledegook. This won't help them -write correct code-.
Indeed. Perhaps this writeup belongs in a different document (with a
pointer from the recipes file), and
> This is one of the reasons that the LKMM documetnation is so damn
> difficult to read and understand: just understanding the vocabulary
> it uses requires a huge learning curve, and it's not defined
> anywhere. Understanding the syntax of examples requires a huge
> learning curve, because it's no
> > > > The compressed kernel currently contains bogus run-time relocations in
> > > > the startup code in head_{32,64}.S, which are generated by the linker,
> > > > but must not actually be processed at run-time.
> > > >
> > > > This generates
This adds an option '--graph-opts nosleep-time' which allow us
only to measure on-CPU time. This option is function_graph tracer
only.
Signed-off-by: Changbin Du
---
v3: switch to uniform option --graph-opts.
v2: option name '--nosleep-time' -> '--graph-no
On Fri, 17 Jul 2020 at 21:17, Nick Desaulniers wrote:
>
> On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar wrote:
> >
> > On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> > > The compressed kernel currently contains bogus run-time relocations in
> >
t; > +If that doesn't apply, you'll have to implement one-time init yourself.
> > > > +
> > > > +The simplest implementation just uses a mutex and an 'inited' flag.
> > > > +This implementation should be used where feasible:
> > >
>
On Fri, Jul 17, 2020 at 06:38:39PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > > +If that doesn't apply, you'll have to implement one-time init
On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more lightwe
On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more lightwe
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The "one-time init" pattern is implemented incorrectly in various places
> in the kernel. And when people do try to implement it correctly, it is
> unclear what to use. Try to
On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more lightwe
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > +If that doesn't apply, you'll have to implement one-time init yourself.
> > +
> > +The simplest implementation just uses a mutex
On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > +the more lightweight READ_ONCE(). (smp_store_release() is still
> > > +required.)
On Fri, Jul 17, 2020 at 01:51:38PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> ...
> > > + /* on success, pairs with smp_load_acquire() above and below */
> > > + if (c
On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > +There are also cases in which the smp_load_acquire() can be replaced by
> > +the more lightweight READ_ONCE(). (smp_store_release() is still
> > +required.) Specifically, if all initialized memory is transitively
> > +reachable
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > +If that doesn't apply, you'll have to implement one-time init yourself.
> > +
> > +The simplest implementation just uses a mutex
entries out of the .got section
> x86/boot/compressed: Force hidden visibility for all symbol references
> x86/boot/compressed: Get rid of GOT fixup code
>
> Arvind Sankar (4):
> x86/boot: Add .text.* to setup.ld
> x86/boot: Remove run-time relocations from .head.text code
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > +If that doesn't apply, you'll have to implement one-time init yourself.
> > +
> > +The simplest implementation just uses a mutex
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The "one-time init" pattern is implemented incorrectly in various places
> in the kernel. And when people do try to implement it correctly, it is
> unclear what to use. Try to
The assembly code in head_{32,64}.S, while meant to be
position-independent, generates run-time relocations because it uses
instructions such as
lealgdt(%edx), %eax
which make the assembler and linker think that the code is using %edx as
an index into gdt, and hence gdt needs to be
The BFD linker generates run-time relocations for z_input_len and
z_output_len, even though they are absolute symbols.
This is fixed for binutils-2.35 [1]. Work around this for earlier
versions by defining two variables input_len and output_len in addition
to the symbols, and use them via
Add a linker script check that there are no run-time relocations, and
remove the old one that tries to check via looking for specially-named
sections in the object files.
Drop the tests for -fPIE compiler option and -pie linker option, as they
are available in all supported gcc and binutils
references
x86/boot/compressed: Get rid of GOT fixup code
Arvind Sankar (4):
x86/boot: Add .text.* to setup.ld
x86/boot: Remove run-time relocations from .head.text code
x86/boot: Remove run-time relocations from head_{32,64}.S
x86/boot: Check that there are no run-time relocations
arch
On Fri, Jul 17, 2020 at 8:17 PM Nick Desaulniers
wrote:
>
> On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar wrote:
> >
> > On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> > > The compressed kernel currently contains bogus run-time relocations in
>
On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar wrote:
>
> On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> > The compressed kernel currently contains bogus run-time relocations in
> > the startup code in head_{32,64}.S, which are generated by the linker,
> &g
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
...
> > + /* on success, pairs with smp_load_acquire() above and below */
> > + if (cmpxchg_release(&foo, NULL, p) != NULL) {
>
> Why do we have cmpxc
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> +If that doesn't apply, you'll have to implement one-time init yourself.
> +
> +The simplest implementation just uses a mutex and an 'inited' flag.
> +This implementation should be used where feasibl
This adds an option '--graph-opts nosleep-time' which allow us
only to measure on-CPU time. This option is function_graph tracer
only.
Signed-off-by: Changbin Du
---
v3: switch to uniform option --graph-opts.
v2: option name '--nosleep-time' -> '--graph-no
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
...
> +Note that when the cmpxchg_release() fails due to another task already
> +having done it, a second smp_load_acquire() is required, since we still
> +need to acquire the data that the other task released.
When people talk about r
On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> The compressed kernel currently contains bogus run-time relocations in
> the startup code in head_{32,64}.S, which are generated by the linker,
> but must not actually be processed at run-time.
>
> This generate
Certain watchdogs require the watchdog only to be pinged within a
specific time window, pinging too early or too late cause the watchdog
to fire. In cases where this sort of watchdog has been started before
kernel comes up, we must adjust the watchdog keepalive window to match
the actually running
mpxchg_release() to cmpxchg() with the goal of it
> +acting as both ACQUIRE and RELEASE, but that doesn't work here because
> +cmpxchg() only guarantees memory ordering if it succeeds.
> +
> +Because of the above subtlety, the version with the mutex instead of
> +cmpxchg_release()
On Fri, Jul 17, 2020 at 6:48 AM Eric Biggers wrote:
>
> From: Eric Biggers
...
> This is motivated by the discussion at
> https://lkml.kernel.org/linux-fsdevel/2020071300.205104-1-ebigg...@kernel.org/T/#u
...
> +In where cases where taking the mutex in the "already initialized" case
"In case
From: Eric Biggers
The "one-time init" pattern is implemented incorrectly in various places
in the kernel. And when people do try to implement it correctly, it is
unclear what to use. Try to give some proper guidance.
This is motivated by the discussion at
https://lkml.kernel
Jakub Kicinski writes:
> On Thu, 16 Jul 2020 23:38:13 +0300 Sergey Organov wrote:
>> > Applied, and added to the stable queue, thanks!
>>
>> Thanks, and I've also got a no-brainer patch that lets this bug fix
>> compile as-is with older kernels, where there were no phy_has_hwtstamp()
>> functi
On Thu, 16 Jul 2020 23:38:13 +0300 Sergey Organov wrote:
> > Applied, and added to the stable queue, thanks!
>
> Thanks, and I've also got a no-brainer patch that lets this bug fix
> compile as-is with older kernels, where there were no phy_has_hwtstamp()
> function. Dunno how to properly handle
Jakub Kicinski writes:
> On Tue, 14 Jul 2020 19:28:02 +0300 Sergey Organov wrote:
>> Fix support for external PTP-aware devices such as DSA or PTP PHY:
>>
>> Make sure we never time stamp tx packets when hardware time stamping
>> is disabled.
>>
>> Check
On Tue, 14 Jul 2020 19:28:02 +0300 Sergey Organov wrote:
> Fix support for external PTP-aware devices such as DSA or PTP PHY:
>
> Make sure we never time stamp tx packets when hardware time stamping
> is disabled.
>
> Check for PTP PHY being in use and then pass ioctls related
Hi Peter, Ahemd,
On Wed, Jul 15, 2020 at 05:58:50PM +0200, Peter Zijlstra wrote:
[...]
> > > diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> > > index fa3f800d7d76..ea007928d681 100644
> > > --- a/kernel/time/sched_clock.c
> >
arwish
Signed-off-by: Leo Yan
---
kernel/time/sched_clock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 0acaadc3156c..0deaf4b79fb4 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -70,7 +70,
...@hirez.programming.kicks-ass.net
> > Link:
> > https://lkml.kernel.org/r/20200715092345.ga231...@debian-buster-darwi.lab.linutronix.de
> > References: 1809bfa44e10 ("timers, sched/clock: Avoid deadlock during read
> > from NMI")
> > Signed-off-by: Ahmed S. Da
Initializing with 0 makes it much easier to identify time stamps from
otherwise uninitialized clock.
Initialization of PTP clock with current kernel time makes little sense as
PTP time scale differs from UTC time scale that kernel time represents.
It only leads to confusion when no actual PTP
PPS feature could be useful even when hardware time stamping
of network packets is not in use, so remove offending check
for this condition from fec_ptp_enable_pps().
Signed-off-by: Sergey Organov
---
drivers/net/ethernet/freescale/fec_ptp.c | 5 -
1 file changed, 5 deletions(-)
diff --git
> References: 1809bfa44e10 ("timers, sched/clock: Avoid deadlock during read
> from NMI")
> Signed-off-by: Ahmed S. Darwish
> ---
> kernel/time/sched_clock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/time/sched_clock.c
5745.gd117...@hirez.programming.kicks-ass.net
Link:
https://lkml.kernel.org/r/20200715092345.ga231...@debian-buster-darwi.lab.linutronix.de
References: 1809bfa44e10 ("timers, sched/clock: Avoid deadlock during read from
NMI")
Signed-off-by: Ahmed S. Darwish
---
kernel/time/sched_clock.c |
On Wed, Jul 15, 2020 at 11:00 AM Sedat Dilek wrote:
>
> On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
> >
> > Add a linker script check that there are no run-time relocations, and
> > remove the old one that tries to check via looking for specially-named
> >
On Wed, Jul 15, 2020 at 11:03 AM Ard Biesheuvel wrote:
>
> On Wed, 15 Jul 2020 at 11:58, Sedat Dilek wrote:
> >
> > On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
> > >
> > > The BFD linker generates run-time relocations for z_input_len and
>
On Wed, 15 Jul 2020 at 11:58, Sedat Dilek wrote:
>
> On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
> >
> > The BFD linker generates run-time relocations for z_input_len and
> > z_output_len, even though they are absolute symbols.
> >
> > This is fixe
On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
>
> Add a linker script check that there are no run-time relocations, and
> remove the old one that tries to check via looking for specially-named
> sections in the object files.
>
> Drop the tests for -fPIE compiler opti
On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
>
> The BFD linker generates run-time relocations for z_input_len and
> z_output_len, even though they are absolute symbols.
>
> This is fixed for binutils-2.35 [1]. Work around this for earlier
> versions by defining two v
On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
>
> The assembly code in head_{32,64}.S, while meant to be
> position-independent, generates run-time relocations because it uses
> instructions such as
> lealgdt(%edx), %eax
> which make the assembler and linker t
1201 - 1300 of 10747 matches
Mail list logo
