From: Eric Dumazet
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too large
From: Eric Dumazet
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too large
From: Eric Dumazet
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too large
From: Eric Dumazet
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream.
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too larg
From: Eric Dumazet
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream.
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too larg
From: Eric Dumazet
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream.
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too larg
From: Eric Dumazet
[ Upstream commit e114e1e8ac9d31f25b9dd873bab5d80c1fc482ca ]
Whenever cookie_init_timestamp() has been used to encode
ECN,SACK,WSCALE options, we can not remove the TS option in the SYNACK.
Otherwise, tcp_synack_options() will still advertize options like WSCALE
that we can n
From: Eric Dumazet
[ Upstream commit e114e1e8ac9d31f25b9dd873bab5d80c1fc482ca ]
Whenever cookie_init_timestamp() has been used to encode
ECN,SACK,WSCALE options, we can not remove the TS option in the SYNACK.
Otherwise, tcp_synack_options() will still advertize options like WSCALE
that we can n
From: Eric Dumazet
[ Upstream commit e114e1e8ac9d31f25b9dd873bab5d80c1fc482ca ]
Whenever cookie_init_timestamp() has been used to encode
ECN,SACK,WSCALE options, we can not remove the TS option in the SYNACK.
Otherwise, tcp_synack_options() will still advertize options like WSCALE
that we can n
From: Eric Dumazet
[ Upstream commit e114e1e8ac9d31f25b9dd873bab5d80c1fc482ca ]
Whenever cookie_init_timestamp() has been used to encode
ECN,SACK,WSCALE options, we can not remove the TS option in the SYNACK.
Otherwise, tcp_synack_options() will still advertize options like WSCALE
that we can n
From: Eric Dumazet
[ Upstream commit e114e1e8ac9d31f25b9dd873bab5d80c1fc482ca ]
Whenever cookie_init_timestamp() has been used to encode
ECN,SACK,WSCALE options, we can not remove the TS option in the SYNACK.
Otherwise, tcp_synack_options() will still advertize options like WSCALE
that we can n
From: Eric Dumazet
commit 7c6d2ecbda83150b2036a2b36b21381ad4667762 upstream.
Recent change in virtio_net_hdr_to_skb() broke some packetdrill tests.
When --mss=XXX option is set, packetdrill always provide gso_type & gso_size
for its inbound packets, regardless of packet size.
if (packe
From: Eric Dumazet
commit 7c6d2ecbda83150b2036a2b36b21381ad4667762 upstream.
Recent change in virtio_net_hdr_to_skb() broke some packetdrill tests.
When --mss=XXX option is set, packetdrill always provide gso_type & gso_size
for its inbound packets, regardless of packet size.
if (packe
From: Eric Dumazet
[ Upstream commit 7c6d2ecbda83150b2036a2b36b21381ad4667762 ]
Recent change in virtio_net_hdr_to_skb() broke some packetdrill tests.
When --mss=XXX option is set, packetdrill always provide gso_type & gso_size
for its inbound packets, regardless of packet size.
if (pa
From: Eric Dumazet
[ Upstream commit 7c6d2ecbda83150b2036a2b36b21381ad4667762 ]
Recent change in virtio_net_hdr_to_skb() broke some packetdrill tests.
When --mss=XXX option is set, packetdrill always provide gso_type & gso_size
for its inbound packets, regardless of packet size.
if (pa
From: Eric Dumazet
[ Upstream commit df4953e4e997e273501339f607b77953772e3559 ]
syzbot managed to set up sfq so that q->scaled_quantum was zero,
triggering an infinite loop in sfq_dequeue()
More generally, we must only accept quantum between 1 and 2^18 - 7,
meaning scaled_quantum must be in [1,
From: Eric Dumazet
[ Upstream commit df4953e4e997e273501339f607b77953772e3559 ]
syzbot managed to set up sfq so that q->scaled_quantum was zero,
triggering an infinite loop in sfq_dequeue()
More generally, we must only accept quantum between 1 and 2^18 - 7,
meaning scaled_quantum must be in [1,
From: Eric Dumazet
[ Upstream commit df4953e4e997e273501339f607b77953772e3559 ]
syzbot managed to set up sfq so that q->scaled_quantum was zero,
triggering an infinite loop in sfq_dequeue()
More generally, we must only accept quantum between 1 and 2^18 - 7,
meaning scaled_quantum must be in [1,
From: Eric Dumazet
[ Upstream commit df4953e4e997e273501339f607b77953772e3559 ]
syzbot managed to set up sfq so that q->scaled_quantum was zero,
triggering an infinite loop in sfq_dequeue()
More generally, we must only accept quantum between 1 and 2^18 - 7,
meaning scaled_quantum must be in [1,
From: Eric Dumazet
[ Upstream commit df4953e4e997e273501339f607b77953772e3559 ]
syzbot managed to set up sfq so that q->scaled_quantum was zero,
triggering an infinite loop in sfq_dequeue()
More generally, we must only accept quantum between 1 and 2^18 - 7,
meaning scaled_quantum must be in [1,
From: Eric Dumazet
[ Upstream commit df4953e4e997e273501339f607b77953772e3559 ]
syzbot managed to set up sfq so that q->scaled_quantum was zero,
triggering an infinite loop in sfq_dequeue()
More generally, we must only accept quantum between 1 and 2^18 - 7,
meaning scaled_quantum must be in [1,
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jonathan Corbet
commit edcd591c77a48da753456f92daf8bb50fe9bac93 upstream.
Commit:
412758cb2670 ("jump label, locking/static_keys: Update docs")
introduced a typo that might as well get fix
On Sun, Dec 02, 2018 at 12:02:54PM +0300, Alexey Dobriyan wrote:
> Empty function will be inlined so asmlinkage doesn't do anything.
Yes, that is an example of a perfect explanation to have in the
commit message :) Ack from me after that addition.
Acked-by: Joey Pabalinas
--
Cheers,
Joey Pabal
On Sat, Dec 01, 2018 at 09:33:38PM -1000, Joey Pabalinas wrote:
> On Sat, Nov 24, 2018 at 12:35:30PM +0300, Alexey Dobriyan wrote:
> > -static inline asmlinkage void dump_stack(void)
> > +static inline void dump_stack(void)
>
> Why is it "silly"? An explanation
On Sat, Nov 24, 2018 at 12:35:30PM +0300, Alexey Dobriyan wrote:
> -static inline asmlinkage void dump_stack(void)
> +static inline void dump_stack(void)
Why is it "silly"? An explanation in the commit message would be useful.
> Signed-off-by: Alexey Dobriyan
> ---
>
Signed-off-by: Alexey Dobriyan
---
include/linux/printk.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -269,7 +269,7 @@ static inline void show_regs_print_info(const char *log_lvl)
{
}
-static inline asmlinkage void du
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit b9b312a7a451e9c098921856e7cfbc201120e1a7 ]
syzkaller reported crashes in IPv6 stack [1]
Xin Long found that lo MTU was set to silly values.
IPv6 stack reacts
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit b9b312a7a451e9c098921856e7cfbc201120e1a7 ]
syzkaller reported crashes in IPv6 stack [1]
Xin Long found that lo MTU was set to silly values.
IPv6 stack reacts
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit b9b312a7a451e9c098921856e7cfbc201120e1a7 ]
syzkaller reported crashes in IPv6 stack [1]
Xin Long found that lo MTU was set to silly values.
IPv6 stack reacts
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit b9b312a7a451e9c098921856e7cfbc201120e1a7 ]
syzkaller reported crashes in IPv6 stack [1]
Xin Long found that lo MTU was set to silly values.
IPv6 stack reacts
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Christoph Hellwig
commit f723fa4e69920f6a5dd5fa0d10ce90e2f14d189c upstream.
Intel AHCI controllers that also hide NVMe devices in their bar
can't use MSI interrupts, so disable them.
Reported
4.13-stable review patch. If anyone has any objections, please let me know.
--
From: Christoph Hellwig
commit f723fa4e69920f6a5dd5fa0d10ce90e2f14d189c upstream.
Intel AHCI controllers that also hide NVMe devices in their bar
can't use MSI interrupts, so disable them.
Reported
For the interested, I moved the video I did of my low-jitter inspired
configurations, of Doom 3, which was a very jitter sensitive game.
A quick summary: By removing and reducing unecessary code, and
codepaths, such as reducing the HZ to 90, choosing low-jitter components
in configuration, and
On Fri, Jan 6, 2017 at 4:45 AM, Thadeu Lima de Souza Cascardo
wrote:
> The polling functions were checking for a NULL uart_state, which is
> indexed from uart_driver->state. It should be always allocated and
> non-NULL when the tty_driver is registered, and line should not be
> larger than the tty
The polling functions were checking for a NULL uart_state, which is
indexed from uart_driver->state. It should be always allocated and
non-NULL when the tty_driver is registered, and line should not be
larger than the tty_driver->num anyways.
Signed-off-by: Thadeu Lima de Souza Cascardo
---
driv
: Kill a silly warning
At the moment, intel_bts will WARN() out if there is more than one
event writing to the same ring buffer, via SET_OUTPUT, and will only
send data from one event to a buffer.
There is no reason to have this warning in, so kill it.
Signed-off-by: Alexander Shishkin
Signed-off
At the moment, intel_bts will WARN() out if there is more than one
event writing to the same ring buffer, via SET_OUTPUT, and will only
send data from one event to a buffer.
There is no reason to have this warning in, so kill it.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/bts.c
At the moment, intel_bts will WARN() out if there is more than one
event writing to the same ring buffer, via SET_OUTPUT, and will only
send data from one event to a buffer.
There is no reason to have this warning in, so kill it.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/bts.c
On Sun, Aug 21, 2016 at 12:53:15PM +0300, Jan Varho wrote:
> On Mon, Jun 13, 2016 at 6:48 PM, Theodore Ts'o wrote:
> > +static inline void maybe_reseed_primary_crng(void)
> > +{
> > + if (crng_init > 2 &&
> > + time_after(jiffies, primary_crng.init_time +
> > CRNG_RESEED_INTERVAL)
On Mon, Jun 13, 2016 at 6:48 PM, Theodore Ts'o wrote:
> +static inline void maybe_reseed_primary_crng(void)
> +{
> + if (crng_init > 2 &&
> + time_after(jiffies, primary_crng.init_time +
> CRNG_RESEED_INTERVAL))
> + crng_reseed(&primary_crng, &input_pool);
> +}
Hi,
On Thu, Jul 28, 2016 at 6:41 AM, Theodore Ts'o wrote:
> On Thu, Jul 28, 2016 at 09:24:08AM +0200, Heiko Carstens wrote:
>>
>> Oh, I just realized that Linus pulled your changes. Actually I was hoping
>> we could get this fixed before the broken code would be merged.
>> Could you please make sure t
On Wed, 2016-07-27 at 23:46 -0400, Theodore Ts'o wrote:
> On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> >
> > it looks like your patch "random: make /dev/urandom scalable for silly
> > userspace programs" within linux-next seems to be a
On Thu, Jul 28, 2016 at 09:24:08AM +0200, Heiko Carstens wrote:
>
> Oh, I just realized that Linus pulled your changes. Actually I was hoping
> we could get this fixed before the broken code would be merged.
> Could you please make sure the bug fix gets included as soon as possible?
Yes, I'll sen
On Thu, Jul 28, 2016 at 07:55:48AM +0200, Heiko Carstens wrote:
> On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote:
> > On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> > > it looks like your patch "random: make /dev/urandom scalable for si
On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> > it looks like your patch "random: make /dev/urandom scalable for silly
> > userspace programs" within linux-next seems to be a bit b
On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote:
> it looks like your patch "random: make /dev/urandom scalable for silly
> userspace programs" within linux-next seems to be a bit broken:
>
> It causes this allocation failure and subsequent crash on s390 wi
Hi Ted,
it looks like your patch "random: make /dev/urandom scalable for silly
userspace programs" within linux-next seems to be a bit broken:
It causes this allocation failure and subsequent crash on s390 with fake
NUMA enabled:
[0.533195] SLUB: Unable to allocate memory on no
On a system with a 4 socket (NUMA) system where a large number of
application threads were all trying to read from /dev/urandom, this
can result in the system spending 80% of its time contending on the
global urandom spinlock. The application should have used its own
PRNG, but let's try to help it
On Mon, May 30, 2016 at 08:03:59AM +0200, Stephan Mueller wrote:
> > static int rand_initialize(void)
> > {
> > +#ifdef CONFIG_NUMA
> > + int i;
> > + int num_nodes = num_possible_nodes();
> > + struct crng_state *crng;
> > +
> > + crng_node_pool = kmalloc(num_nodes * sizeof(void *),
> >
Am Montag, 30. Mai 2016, 01:39:22 schrieb Theodore Ts'o:
Hi Theodore,
> On a system with a 4 socket (NUMA) system where a large number of
> application threads were all trying to read from /dev/urandom, this
> can result in the system spending 80% of its time contending on the
> global urandom sp
On a system with a 4 socket (NUMA) system where a large number of
application threads were all trying to read from /dev/urandom, this
can result in the system spending 80% of its time contending on the
global urandom spinlock. The application should have used its own
PRNG, but let's try to help it
On a system with a 4 socket (NUMA) system where a large number of
application threads were all trying to read from /dev/urandom, this
can result in the system spending 80% of its time contending on the
global urandom spinlock. The application should have used its own
PRNG, but let's try to help it
Am Montag, 2. Mai 2016, 09:48:57 schrieb Theodore Ts'o:
Hi Theodore,
> On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote:
> > > - entropy pool draining: when having a timer-based reseeding on a quiet
> > > system, the entropy pool can be drained during the expiry of the timer.
> > > S
On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote:
> > - entropy pool draining: when having a timer-based reseeding on a quiet
> > system, the entropy pool can be drained during the expiry of the timer. So,
> > I
> > tried to handle that by increasing the timer by, say, 100 seconds f
On Mon, May 02, 2016 at 09:00:22AM +0200, Stephan Mueller wrote:
> - reseed avalanche: I see that you added a time-based reseed code too (I am
> glad about that one). What I fear is that there is a reseed avalanche when
> the
> various RNGs are seeded initially closely after each other (and thus
Am Montag, 2. Mai 2016, 02:26:52 schrieb Theodore Ts'o:
Hi Theodore,
I have not digested the patch set yet, but I have the following questions to
your patch set.
> On a system with a 4 socket (NUMA) system where a large number of
> application processes were all trying to read from /dev/urandom
On a system with a 4 socket (NUMA) system where a large number of
application processes were all trying to read from /dev/urandom, this
can result in the system spending 80% of its time contending on the
global urandom spinlock. The application have used its own PRNG, but
let's try to help it from
rid of the silly for_each_cpu() lookups
CQM is a strict per package facility. Use the proper cpumasks to lookup the
readers.
Signed-off-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Cc: Andi Kleen
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: Harish Chegondi
Cc: Jacob Pan
CQM is a strict per package facility. Use the proper cpumasks to lookup the
readers.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_intel_cqm.c | 34 ++---
1 file changed, 12 insertions(+), 22 deletions(-)
Index: b/arch/x86/kernel/cpu/perf_event_inte
CQM is a strict per package facility. Use the proper cpumasks to lookup the
readers.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_intel_cqm.c | 34 ++---
1 file changed, 12 insertions(+), 22 deletions(-)
Index: b/arch/x86/kernel/cpu/perf_event_inte
On Thu, 18 Feb 2016, Thomas Gleixner wrote:
On Wed, 17 Feb 2016, Thomas Gleixner wrote:
On Wed, 17 Feb 2016, Vikas Shivappa wrote:
Please stop top posting, finally!
But we have an extra static - static to avoid having it in the stack..
It's not about the cpu mask on the stack. The reason
On Wed, 17 Feb 2016, Thomas Gleixner wrote:
> On Wed, 17 Feb 2016, Vikas Shivappa wrote:
>
> Please stop top posting, finally!
>
> > But we have an extra static - static to avoid having it in the stack..
>
> It's not about the cpu mask on the stack. The reason was that with cpumask off
> stack c
On Wed, 17 Feb 2016, Vikas Shivappa wrote:
Please stop top posting, finally!
> But we have an extra static - static to avoid having it in the stack..
It's not about the cpu mask on the stack. The reason was that with cpumask off
stack cpumask_and_mask() requires an allocation, which then can't b
On Wed, 17 Feb 2016, Thomas Gleixner wrote:
On Wed, 17 Feb 2016, Vikas Shivappa wrote:
Yes, please resend the rapl one. perf_uncore is a different trainwreck which I
fixed already:
lkml.kernel.org/r/20160217132903.767990...@linutronix.de
Ok , will resend the rapl separately.
the fix
On Wed, 17 Feb 2016, Thomas Gleixner wrote:
> On Wed, 17 Feb 2016, Vikas Shivappa wrote:
> > > - cpumask_set_cpu(cpu, &cqm_cpumask);
> > > + /* First online cpu in package becomes the reader */
> > > + reader = cpumask_any_and(topology_core_cpumask(cpu), &cqm_cpumask);
> > > + if (reader >= nr_cpu
On Wed, 17 Feb 2016, Vikas Shivappa wrote:
> > - cpumask_set_cpu(cpu, &cqm_cpumask);
> > + /* First online cpu in package becomes the reader */
> > + reader = cpumask_any_and(topology_core_cpumask(cpu), &cqm_cpumask);
> > + if (reader >= nr_cpu_ids)
> > + cpumask_set_cpu(cpu, &cqm
<--
Subject: x86/perf/cqm: Get rid of the silly for_each_cpu lookups
From: Thomas Gleixner
Date: Sun, 14 Feb 2016 23:09:06 +0100
CQM is a strict per package facility. Use the proper cpumasks to lookup the
readers.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_intel_cqm.c |
rsion below.
>
> Thanks,
>
> tglx
>
> 8<--
>
> Subject: x86/perf/cqm: Get rid of the silly for_each_cpu lookups
> From: Thomas Gleixner
> Date: Sun, 14 Feb 2016 23:09:06 +0100
>
> CQM is a strict per package facility. Use the proper cpumas
On Wed, 17 Feb 2016, Thomas Gleixner wrote:
> CQM is a strict per package facility. Use the proper cpumasks to lookup the
> readers.
Sorry for the noise. PEBKAC: quilt refresh missing. Correct version below.
Thanks,
tglx
8<--
Subject: x86/perf/cqm: Get rid of
CQM is a strict per package facility. Use the proper cpumasks to lookup the
readers.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_intel_cqm.c | 34 ++---
1 file changed, 12 insertions(+), 22 deletions(-)
--- a/arch/x86/kernel/cpu/perf_event_intel_c
From: Vineet Gupta
3.12-stable review patch. If anyone has any objections, please let me know.
===
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 800a6b04727c..44881abcfb06 100644
--- a/MAINTAINERS
+++ b/MAINTAIN
3.13.11-ckt33 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Vineet Gupta
commit 30b9dbee895ff0d5cbf155bd1ef3f0f5992bca6f upstream.
Signed-off-by: Kamal Mostafa
---
MAINTAINERS | 2 +-
1 file c
3.16.7-ckt22 -stable review patch. If anyone has any objections, please let me
know.
--
From: Vineet Gupta
commit 30b9dbee895ff0d5cbf155bd1ef3f0f5992bca6f upstream.
Cc: Vineet Gupta
Signed-off-by: Luis Henriques
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 del
4.2.8-ckt1 -stable review patch. If anyone has any objections, please let me
know.
--
From: Vineet Gupta
commit 30b9dbee895ff0d5cbf155bd1ef3f0f5992bca6f upstream.
Signed-off-by: Kamal Mostafa
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This commit loosens rcutree.rcu_fanout_leaf range checks
and replaces a panic() with a fallback to compile-time values.
This fallback is accompanied by a WARN_ON(), and both occur when the
rcutree.rcu_fanout_leaf value is too small to accommodate the number of
CPUs. For example, given the current
On Wed, 16 Sep 2015 21:04:31 -0400
Chuck Ebbert wrote:
> I sent a patch to fix that part on August 25:
> https://lkml.org/lkml/2015/8/25/288
>
> Did I send it to the wrong person?
Well, at that date, I think that the relevant text was only to be found in
the tip tree. So the logical targets fo
On Tue, 08 Sep 2015 12:05:04 -0400
Jason Baron wrote:
>
>
> On 09/07/2015 03:18 PM, Jonathan Corbet wrote:
> > 412758cb2670 (jump label, locking/static_keys: Update docs) introduced a
> > typo that might as well get fixed.
> >
> > Signed-off-by: Jonathan Corbet
> > ---
> > Documentation/stat
* Jason Baron wrote:
> On 09/07/2015 03:18 PM, Jonathan Corbet wrote:
> > 412758cb2670 (jump label, locking/static_keys: Update docs) introduced a
> > typo that might as well get fixed.
> >
> > Signed-off-by: Jonathan Corbet
> > ---
> > Documentation/static-keys.txt | 2 +-
> > include/linux/
On 09/07/2015 03:18 PM, Jonathan Corbet wrote:
> 412758cb2670 (jump label, locking/static_keys: Update docs) introduced a
> typo that might as well get fixed.
>
> Signed-off-by: Jonathan Corbet
> ---
> Documentation/static-keys.txt | 2 +-
> include/linux/jump_label.h| 2 +-
> 2 files chan
a silly typo
Commit:
412758cb2670 ("jump label, locking/static_keys: Update docs")
introduced a typo that might as well get fixed.
Signed-off-by: Jonathan Corbet
Cc: Andrew Morton
Cc: Jason Baron
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
* Jonathan Corbet wrote:
> 412758cb2670 (jump label, locking/static_keys: Update docs) introduced a
> typo that might as well get fixed.
>
> Signed-off-by: Jonathan Corbet
> ---
> Documentation/static-keys.txt | 2 +-
> include/linux/jump_label.h| 2 +-
> 2 files changed, 2 insertions(+),
412758cb2670 (jump label, locking/static_keys: Update docs) introduced a
typo that might as well get fixed.
Signed-off-by: Jonathan Corbet
---
Documentation/static-keys.txt | 2 +-
include/linux/jump_label.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/
On Thu, 2014-06-12 at 16:09 +0200, Thomas Gleixner wrote:
> Fair enough. Still the timespec is silly. Here is an updated version.
Makes sense, thanks. I've applied this (mac80211-next)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
ight, once settimeofday() is called the timestamps from before/during
> it can't really be correlated any more.
>
> This is part of the userspace API already, but might it have been better
> to expose the monotonic clock, since userspace can also get at it? Not
> sure.
&
On Thu, 2014-06-12 at 10:57 +0200, Thomas Gleixner wrote:
> > > Right, but isn't that odd? Suddenly your delay measurement here might be
> > > minutes, hours, or years if you settimeofday() between timestamping and
> > > calculating the delta. That seems very strange to me, why would that be
> > >
On Thu, 12 Jun 2014, Johannes Berg wrote:
> On Thu, 2014-06-12 at 10:35 +0200, Johannes Berg wrote:
> > +netdev, Stephen
>
> Well, stupid me. Fixing that netdev address.
>
> > On Thu, 2014-06-12 at 10:19 +0200, Thomas Gleixner wrote:
> > > On Thu, 12 Jun 2014, Johannes Berg wrote:
> > >
> > > >
On Thu, 2014-06-12 at 10:35 +0200, Johannes Berg wrote:
> +netdev, Stephen
Well, stupid me. Fixing that netdev address.
> On Thu, 2014-06-12 at 10:19 +0200, Thomas Gleixner wrote:
> > On Thu, 12 Jun 2014, Johannes Berg wrote:
> >
> > > On Wed, 2014-06-11 at 23:59 +, Thomas Gleixner wrote:
>
+netdev, Stephen
On Thu, 2014-06-12 at 10:19 +0200, Thomas Gleixner wrote:
> On Thu, 12 Jun 2014, Johannes Berg wrote:
>
> > On Wed, 2014-06-11 at 23:59 +, Thomas Gleixner wrote:
> >
> > > + msrmnt = ktime_to_ms(net_timedelta(skb_arv));
> >
> > This is probably more of a question about net_
On Thu, 12 Jun 2014, Johannes Berg wrote:
> On Wed, 2014-06-11 at 23:59 +, Thomas Gleixner wrote:
>
> > + msrmnt = ktime_to_ms(net_timedelta(skb_arv));
>
> This is probably more of a question about net_timedelta(), but is
> ktime_get_real() really appropriate for duration measurements? Isn
On Wed, 2014-06-11 at 23:59 +, Thomas Gleixner wrote:
> + msrmnt = ktime_to_ms(net_timedelta(skb_arv));
This is probably more of a question about net_timedelta(), but is
ktime_get_real() really appropriate for duration measurements? Isn't
that non-monotonic?
johannes
--
To unsubscribe f
Converting time from one format to another seems to give coders a warm
and fuzzy feeling.
Use the proper interfaces.
Signed-off-by: Thomas Gleixner
Cc: Johannes Berg
Cc: "John W. Linville"
Cc: linux-wirel...@vger.kernel.org
---
net/mac80211/status.c |7 ++-
net/mac80211/tx.c |
On Tuesday 31 December 2013, Gene Heskett wrote:
>On Tuesday 31 December 2013, Roger Heflin wrote:
>>rescue boot it, change the /boot mount line in /etc/fstab to add
>>noauto (like noauto,defaults...or whatever else you already have) and
>>change the last column to 0 to disable fsck on it.
>>
>>It
On Tuesday 31 December 2013, Roger Heflin wrote:
>rescue boot it, change the /boot mount line in /etc/fstab to add
>noauto (like noauto,defaults...or whatever else you already have) and
>change the last column to 0 to disable fsck on it.
>
>It should boot then, and you have the machine fully up wer
rescue boot it, change the /boot mount line in /etc/fstab to add
noauto (like noauto,defaults...or whatever else you already have) and
change the last column to 0 to disable fsck on it.
It should boot then, and you have the machine fully up were you can do
better debugging.
ie mount /boot may giv
Greetings;
I can't build a bootable 3.12.6 kernel, it seems to die quite fast with a
trace blaming binfmt-some-hex-number. Or fail well into the boot waiting
for / to come available. But if I choose a shell at that failure, it
isn't / that is not shown in a blkid report, it is /boot, named "u
3.5.7.14 -stable review patch. If anyone has any objections, please let me
know.
--
From: Alan Cox
commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.
If we set mantis->fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsi
On Mon, Jun 03, 2013 at 04:02:29PM -0700, Kent Overstreet wrote:
> The cmpxcgh() was just to ensure the debug check didn't race, which was
> a bit excessive. The caller is supposed to do the appropriate
> synchronization, which means percpu_ref_kill() can just do a simple
> store.
>
> Signed-off-b
The cmpxcgh() was just to ensure the debug check didn't race, which was
a bit excessive. The caller is supposed to do the appropriate
synchronization, which means percpu_ref_kill() can just do a simple
store.
Signed-off-by: Kent Overstreet
---
lib/percpu-refcount.c | 19 ---
1 fi
3.2.46-rc1 review patch. If anyone has any objections, please let me know.
--
From: Alan Cox
commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.
If we set mantis->fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsing real
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Alan Cox
commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.
If we set mantis->fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsing real
1 - 100 of 187 matches
Mail list logo
