Hi,
> On 08/09/17 13:10, Nikolay Aleksandrov wrote:
>> On 08/09/17 05:06, Kosuke Tatsukawa wrote:
>>> Hi,
>>>
>>>> On 7.09.2017 01:47, Kosuke Tatsukawa wrote:
>>>>> Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in
Hi,
> On 08/09/17 13:10, Nikolay Aleksandrov wrote:
>> On 08/09/17 05:06, Kosuke Tatsukawa wrote:
>>> Hi,
>>>
>>>> On 7.09.2017 01:47, Kosuke Tatsukawa wrote:
>>>>> Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in
Hi,
> On 7.09.2017 01:47, Kosuke Tatsukawa wrote:
>> Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in
>> balance-alb mode") tried to fix transmit dynamic load balancing in
>> balance-alb mode, which wasn't working after commit 8b426dc54cf4
>&
Hi,
> On 7.09.2017 01:47, Kosuke Tatsukawa wrote:
>> Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in
>> balance-alb mode") tried to fix transmit dynamic load balancing in
>> balance-alb mode, which wasn't working after commit 8b426dc54cf4
>&
ynamic_lb used to have the default value of 1 for balance-alb, but
> now the value is set to 0 except in balance-tlb.
>
> Re-enable transmit dyanmic load balancing by initializing tlb_dynamic_lb
> for balance-alb similar to balance-tlb.
>
> Signed-off-by: Kosuke Tatsukaw
ynamic_lb used to have the default value of 1 for balance-alb, but
> now the value is set to 0 except in balance-tlb.
>
> Re-enable transmit dyanmic load balancing by initializing tlb_dynamic_lb
> for balance-alb similar to balance-tlb.
>
> Signed-off-by: Kosuke Tatsukawa
>
balance-alb with tlb_dynamic_lb set to 0
is not an intended usage, so there is little use making it writable at
this moment.
Fixes: 8b426dc54cf4 ("bonding: remove hardcoded value")
Reported-by: Reinis Rozitis <r...@roze.lv>
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
Cc: sta...@vge
balance-alb with tlb_dynamic_lb set to 0
is not an intended usage, so there is little use making it writable at
this moment.
Fixes: 8b426dc54cf4 ("bonding: remove hardcoded value")
Reported-by: Reinis Rozitis
Signed-off-by: Kosuke Tatsukawa
Cc: sta...@vger.kernel.org # v4.12+
---
drivers/net/bon
alance-tlb.
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
Cc: sta...@vger.kernel.org
---
drivers/net/bonding/bond_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 14ff622
alance-tlb.
Signed-off-by: Kosuke Tatsukawa
Cc: sta...@vger.kernel.org
---
drivers/net/bonding/bond_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 14ff622..181839d 100644
--- a/drivers/n
@@ -557,6 +566,9 @@ static int write_packet(struct usb_device *udev,
> registers, /* buffer */
=
I think you also want to change the argument to usb_control_msg() from
"registers" to "buf" in write_packet()
ev,
> registers, /* buffer */
=
I think you also want to change the argument to usb_control_msg() from
"registers" to "buf" in write_packet().
> size,
&g
Matt Fleming wrote:
> On Thu, 03 Dec, at 11:58:33PM, Kosuke Tatsukawa wrote:
>> The kernel panics early in boot on a x86_64 server if the eXecute
>> Disable (XD) bit is set to disabled in the uEFI firmware. The message
>> in the kernel log bu
Matt Fleming wrote:
> On Thu, 03 Dec, at 11:58:33PM, Kosuke Tatsukawa wrote:
>> The kernel panics early in boot on a x86_64 server if the eXecute
>> Disable (XD) bit is set to disabled in the uEFI firmware. The message
>> in the kernel log bu
without
_PAGE_NX if the nx capability is unavailable instead of returning an
error.
Signed-off-by: Kosuke Tatsukawa
---
arch/x86/mm/pageattr.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index a3137a4..3417c26 100644
to x86_configure_nx()
before that.
Signed-off-by: Kosuke Tatsukawa
---
arch/x86/kernel/setup.c | 18 +-
arch/x86/mm/ioremap.c |3 +++
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 29db25f..c8b2cdb 100644
to disabled.
Kosuke Tatsukawa (2):
x86: Fix kernel panic when booting with XD disabled in uEFI firmware
x86: Fix error in kernel_map_pages_in_pgd() when booting with XD disabled
---
arch/x86/kernel/setup.c | 18 +-
arch/x86/mm/ioremap.c |3 +++
arch/x86/mm/pageattr.c |6
without
_PAGE_NX if the nx capability is unavailable instead of returning an
error.
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
arch/x86/mm/pageattr.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index a
to x86_configure_nx()
before that.
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
arch/x86/kernel/setup.c | 18 +-
arch/x86/mm/ioremap.c |3 +++
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
to disabled.
Kosuke Tatsukawa (2):
x86: Fix kernel panic when booting with XD disabled in uEFI firmware
x86: Fix error in kernel_map_pages_in_pgd() when booting with XD disabled
---
arch/x86/kernel/setup.c | 18 +-
arch/x86/mm/ioremap.c |3 +++
arch/x86/mm/pageattr.c |6
J. Bruce Fields wrote:
> On Fri, Oct 23, 2015 at 04:14:10AM +0000, Kosuke Tatsukawa wrote:
>> J. Bruce Fields wrote:
>> > On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote:
>> >> Tatsukawa Kosuke wrote:
>> >> > J. Bruce Fields wrote:
>
J. Bruce Fields wrote:
> On Fri, Oct 23, 2015 at 04:14:10AM +0000, Kosuke Tatsukawa wrote:
>> J. Bruce Fields wrote:
>> > On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote:
>> >> Tatsukawa Kosuke wrote:
>> >> > J. Bruce Fields wrote:
>
J. Bruce Fields wrote:
> On Fri, Oct 16, 2015 at 02:28:10AM +0000, Kosuke Tatsukawa wrote:
>> Tatsukawa Kosuke wrote:
>> > J. Bruce Fields wrote:
>> >> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote:
>> >>> Tatsukawa Kosuke wrote:
>
Peter Zijlstra wrote:
> On Thu, Oct 22, 2015 at 08:01:37AM +0000, Kosuke Tatsukawa wrote:
>
> Its somewhat unfortunate you chose the whole wait_woken() thing, its
> 'rare'.
Yes. I first noticed this lack of memory barrier before
waitqueue_active() issue in drivers/tty/n_tty.c whi
the memory barrier. Hopefully, the comment will make people using
waitqueue_active a little more cautious.
Signed-off-by: Kosuke Tatsukawa
---
include/linux/wait.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index
Peter Zijlstra wrote:
> On Fri, Oct 09, 2015 at 12:35:59AM +0000, Kosuke Tatsukawa wrote:
>> This patch adds a comment before waitqueue_active noting that a memory
>> barrier is required.
>>
>> Besides the original problem in drivers/tty/n_tty.c which caused a
>>
the memory barrier. Hopefully, the comment will make people using
waitqueue_active a little more cautious.
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
include/linux/wait.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/linux/wait.h b/i
Peter Zijlstra wrote:
> On Fri, Oct 09, 2015 at 12:35:59AM +0000, Kosuke Tatsukawa wrote:
>> This patch adds a comment before waitqueue_active noting that a memory
>> barrier is required.
>>
>> Besides the original problem in drivers/tty/n_tty.c which caused a
>>
Peter Zijlstra wrote:
> On Thu, Oct 22, 2015 at 08:01:37AM +0000, Kosuke Tatsukawa wrote:
>
> Its somewhat unfortunate you chose the whole wait_woken() thing, its
> 'rare'.
Yes. I first noticed this lack of memory barrier before
waitqueue_active() issue in drivers/tty/n_tty.c whi
J. Bruce Fields wrote:
> On Fri, Oct 16, 2015 at 02:28:10AM +0000, Kosuke Tatsukawa wrote:
>> Tatsukawa Kosuke wrote:
>> > J. Bruce Fields wrote:
>> >> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote:
>> >>> Tatsukawa Kosuke wrote:
>
Tatsukawa Kosuke wrote:
> J. Bruce Fields wrote:
>> On Thu, Oct 15, 2015 at 11:44:20AM +0000, Kosuke Tatsukawa wrote:
>>> Tatsukawa Kosuke wrote:
>>> > J. Bruce Fields wrote:
>>> >> Thanks for the detailed investigation.
>>> >>
>>
J. Bruce Fields wrote:
> On Thu, Oct 15, 2015 at 11:44:20AM +0000, Kosuke Tatsukawa wrote:
>> Tatsukawa Kosuke wrote:
>> > J. Bruce Fields wrote:
>> >> Thanks for the detailed investigation.
>> >>
>> >> I think it would be worth ad
Tatsukawa Kosuke wrote:
> J. Bruce Fields wrote:
>> On Wed, Oct 14, 2015 at 03:57:13AM +0000, Kosuke Tatsukawa wrote:
>>> J. Bruce Fields wrote:
>>> > On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote:
>>> >> J. Bruce Fields wrote:
>
Tatsukawa Kosuke wrote:
> J. Bruce Fields wrote:
>> On Wed, Oct 14, 2015 at 03:57:13AM +0000, Kosuke Tatsukawa wrote:
>>> J. Bruce Fields wrote:
>>> > On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote:
>>> >> J. Bruce Fields wrote:
>
J. Bruce Fields wrote:
> On Thu, Oct 15, 2015 at 11:44:20AM +0000, Kosuke Tatsukawa wrote:
>> Tatsukawa Kosuke wrote:
>> > J. Bruce Fields wrote:
>> >> Thanks for the detailed investigation.
>> >>
>> >> I think it would be worth ad
Tatsukawa Kosuke wrote:
> J. Bruce Fields wrote:
>> On Thu, Oct 15, 2015 at 11:44:20AM +0000, Kosuke Tatsukawa wrote:
>>> Tatsukawa Kosuke wrote:
>>> > J. Bruce Fields wrote:
>>> >> Thanks for the detailed investigation.
>>> >>
>>
J. Bruce Fields wrote:
> On Wed, Oct 14, 2015 at 03:57:13AM +0000, Kosuke Tatsukawa wrote:
>> J. Bruce Fields wrote:
>> > On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote:
>> >> J. Bruce Fields wrote:
>> >> > On Fri, Oct 09, 201
J. Bruce Fields wrote:
> On Wed, Oct 14, 2015 at 03:57:13AM +0000, Kosuke Tatsukawa wrote:
>> J. Bruce Fields wrote:
>> > On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote:
>> >> J. Bruce Fields wrote:
>> >> > On Fri, Oct 09, 201
J. Bruce Fields wrote:
> On Mon, Oct 12, 2015 at 10:41:06AM +0000, Kosuke Tatsukawa wrote:
>> J. Bruce Fields wrote:
>> > On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote:
>> >> Neil Brown wrote:
>> >> > Kosuke Tatsukawa writes:
>
J. Bruce Fields wrote:
> On Mon, Oct 12, 2015 at 10:41:06AM +0000, Kosuke Tatsukawa wrote:
>> J. Bruce Fields wrote:
>> > On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote:
>> >> Neil Brown wrote:
>> >> >
J. Bruce Fields wrote:
> On Fri, Oct 09, 2015 at 06:29:44AM +0000, Kosuke Tatsukawa wrote:
>> Neil Brown wrote:
>> > Kosuke Tatsukawa writes:
>> >
>> >> There are several places in net/sunrpc/svcsock.c which calls
>> >> waitqueue_activ
J. Bruce Fields wrote:
> On Fri, Oct 09, 2015 at 06:29:44AM +0000, Kosuke Tatsukawa wrote:
>> Neil Brown wrote:
>> > Kosuke Tatsukawa <ta...@ab.jp.nec.com> writes:
>> >
>> >> There are several places in net/sunrpc/svcsock.c which calls
>> >
Jens Axboe wrote:
> On 10/08/2015 06:35 PM, Kosuke Tatsukawa wrote:
>> blk_mq_tag_update_depth() seems to be missing a memory barrier which
>> might cause the waker to not notice the waiter and fail to send a
>> wake_up as in the following figure.
>>
>
makes sense to just always do the wakeup.
The stall problem is resolved if smp_mb() is added both before the
waitqueue_active() in __receive_buf(), and before the line containing
input_available_p() in n_tty_read().
---
Kosuke TATSUKAWA | 3rd IT Platform Department
| IT Platform Divis
David Sterba wrote:
> On Fri, Oct 09, 2015 at 12:35:48AM +0000, Kosuke Tatsukawa wrote:
>> This patch removes the call to waitqueue_active() leaving just wake_up()
>> behind. This fixes the problem because the call to spin_lock_irqsave()
>> in wake_up() will be an ACQUIRE ope
de
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
v2:
Paolo Bonzini wrote:
> On 09/10/2015 11:04, Kosuke Tatsukawa wrote:
>> smp_store_mb() called from set_current_state(), which is called from
>> prepare_to_wait() should prevent reordering such as below from
>> happening. wait_event*() also calls set_current_state() ins
Paolo Bonzini wrote:
> On 09/10/2015 02:35, Kosuke Tatsukawa wrote:
>> async_pf_executekvm_vcpu_block
>>
>> spin_lock(>async_pf.lock);
>> if (waitqueue_active(>
Neil Brown wrote:
> Kosuke Tatsukawa writes:
>
>> There are several places in net/sunrpc/svcsock.c which calls
>> waitqueue_active() without calling a memory barrier. Add a memory
>> barrier just as in wq_has_sleeper().
>>
>> I found this issue when I was l
Paolo Bonzini wrote:
> On 09/10/2015 02:35, Kosuke Tatsukawa wrote:
>> async_pf_executekvm_vcpu_block
>>
>> spin_lock(>async_pf.lock);
>> if (waitqueue_active(>
Neil Brown wrote:
> Kosuke Tatsukawa <ta...@ab.jp.nec.com> writes:
>
>> There are several places in net/sunrpc/svcsock.c which calls
>> waitqueue_active() without calling a memory barrier. Add a memory
>> barrier just as in wq_has_sleeper().
>>
>> I f
Jens Axboe wrote:
> On 10/08/2015 06:35 PM, Kosuke Tatsukawa wrote:
>> blk_mq_tag_update_depth() seems to be missing a memory barrier which
>> might cause the waker to not notice the waiter and fail to send a
>> wake_up as in the following figure.
>>
>
makes sense to just always do the wakeup.
The stall problem is resolved if smp_mb() is added both before the
waitqueue_active() in __receive_buf(), and before the line containing
input_available_p() in n_tty_read().
---
Kosuke TATSUKAWA | 3rd IT Platform Department
| IT Platform Divis
David Sterba wrote:
> On Fri, Oct 09, 2015 at 12:35:48AM +0000, Kosuke Tatsukawa wrote:
>> This patch removes the call to waitqueue_active() leaving just wake_up()
>> behind. This fixes the problem because the call to spin_lock_irqsave()
>> in wake_up() will be an ACQUIRE ope
de
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp
Paolo Bonzini wrote:
> On 09/10/2015 11:04, Kosuke Tatsukawa wrote:
>> smp_store_mb() called from set_current_state(), which is called from
>> prepare_to_wait() should prevent reordering such as below from
>> happening. wait_event*() also calls set_current_state() ins
Josef Bacik wrote:
> On 10/08/2015 05:35 PM, Kosuke Tatsukawa wrote:
>> btrfs_bio_counter_sub() seems to be missing a memory barrier which might
>> cause the waker to not notice the waiter and miss sending a wake_up as
>> in the following figure.
>>
&g
*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
v2:
- Fixed compiler warnings caused by type mismatch
v1:
- https
/async_pf.c
Hopefully, the comment will make people using waitqueue_active a little
more cautious.
Signed-off-by: Kosuke Tatsukawa
---
include/linux/wait.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 1e1bf9f..e385564
de
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
vir
sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
sound/core/seq/oss/seq_oss_readq.c |6 ++
sound/core/seq/oss/seq_oss_writeq.c |4 +---
2 fil
calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
net/sunrpc
, but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c |3 +--
the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
fs/btrfs/dev-replace.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index e54dd59..ecb3e71 100644
--- a
_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
drivers/misc/mei
ueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
drivers/media/usb/cpia2/cpia2_usb.c |
l/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa
---
block/blk-mq-tag.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index ed96474..7a6b6e2 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -75,6 +75,10 @@ void blk_mq
*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
v2:
- Fixed compiler warnings caused b
de
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp
sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
sound/core/seq/oss/seq_oss_readq.c |6 ++
sound/core/seq/oss/seq_oss_wr
, but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
drivers/net/wireless/brcm80211/brcmf
calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.
/async_pf.c
Hopefully, the comment will make people using waitqueue_active a little
more cautious.
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
include/linux/wait.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/wait.h b/include/linux/
_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
dri
the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
fs/btrfs/dev-replace.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index e54d
ueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
drivers/
l/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <ta...@ab.jp.nec.com>
---
block/blk-mq-tag.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index ed96474..7a6b6e2 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@
Josef Bacik wrote:
> On 10/08/2015 05:35 PM, Kosuke Tatsukawa wrote:
>> btrfs_bio_counter_sub() seems to be missing a memory barrier which might
>> cause the waker to not notice the waiter and miss sending a wake_up as
>> in the following figure.
>>
&g
d the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.
Latency measurement using a ping-pong test over a pty doesn't show any
visible
d the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.
Latency measurement using a ping-pong test over a pty doesn't show any
visible
CPUs.
The program always stalled during the first run when I used a server
with the following CPU.
Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz
2-sockets x 16-cores x 2-threads
Best regards.
---
Kosuke TATSUKAWA | 3rd IT Platform Department
| IT Platform Division, NEC Corpora
Peter-san,
thank you for the reply.
In message <560be5fe.50...@hurleysoftware.com> Peter Hurley
wrote:
> On 09/28/2015 09:59 PM, Kosuke Tatsukawa wrote:
>> My colleague ran into a program stall on a x86_64 server, where
>> n_tty_read() was waiting for data even if there w
CPUs.
The program always stalled during the first run when I used a server
with the following CPU.
Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz
2-sockets x 16-cores x 2-threads
Best regards.
---
Kosuke TATSUKAWA | 3rd IT Platform Department
| IT Platform Division, NEC Corpora
Peter-san,
thank you for the reply.
In message <560be5fe.50...@hurleysoftware.com> Peter Hurley
<pe...@hurleysoftware.com> wrote:
> On 09/28/2015 09:59 PM, Kosuke Tatsukawa wrote:
>> My colleague ran into a program stall on a x86_64 server, where
>> n_tty_read(
d the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.
Latency measurement using a ping-pong test over a pty doesn't show any
visible
d the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.
Latency measurement using a ping-pong test over a pty doesn't show any
visible
86 matches
Mail list logo
