On 2020/08/31 9:51, Rustam Kovhaev wrote:
On Mon, Aug 31, 2020 at 09:16:32AM +0900, Toshiaki Makita wrote:
On 2020/08/30 22:13, Rustam Kovhaev wrote:
when register_netdevice(dev) fails we should check whether struct
veth_rq has been allocated via ndo_init callback and free it, because
, register_netdevice() always goto err_uninit and calls priv_destructor()
on failure after ndo_init() succeeded.
So I could not find such a code path.
Would you elaborate on it?
Thanks,
Toshiaki Makita
1Q defines this bit as DEI not CFI, so IMO this should be
vlan_dei.
Toshiaki Makita
for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c059ce01f643c0569a228ee%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
Toshiaki Makita
reply to this email with:
>> #syz fix: exact-commit-title
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c059ce01f643c0569a228ee%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
Toshiaki Makita
test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/089e082d0cb81b67d10569a2283f%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
Toshiaki Makita
t; #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/089e082d0cb81b67d10569a2283f%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
Toshiaki Makita
dr *), ) < 0) {
> + ret = errno;
Still errno is not inverted,
> + goto cleanup;
> + }
> +
> + if (addrlen != sizeof(sa)) {
> + ret = errno;
And not set here.
> + goto cleanup;
> + }
--
Toshiaki Makita
ret = errno;
Still errno is not inverted,
> + goto cleanup;
> + }
> +
> + if (addrlen != sizeof(sa)) {
> + ret = errno;
And not set here.
> + goto cleanup;
> + }
--
Toshiaki Makita
forgot to prepend '-'?
> + goto cleanup;
> + }
> +
> + if (addrlen != sizeof(sa)) {
> + ret = errno;
errno is not set?
> + goto cleanup;
> + }
--
Toshiaki Makita
ot to prepend '-'?
> + goto cleanup;
> + }
> +
> + if (addrlen != sizeof(sa)) {
> + ret = errno;
errno is not set?
> + goto cleanup;
> + }
--
Toshiaki Makita
54c55960c8de3392061254c97b6306a6d
> + ret = -LIBBPF_ERRNO__WRNGPID;
> + goto cleanup;
> + }
--
Toshiaki Makita
60c8de3392061254c97b6306a6d
> + ret = -LIBBPF_ERRNO__WRNGPID;
> + goto cleanup;
> + }
--
Toshiaki Makita
l patch and submit it. Should I use
> another email account? Are my emails being ignored because of that
> stupid disclaimer my employer attaches to my messages (outside my
> control)?
>
> Brandon
>
--
Toshiaki Makita
l patch and submit it. Should I use
> another email account? Are my emails being ignored because of that
> stupid disclaimer my employer attaches to my messages (outside my
> control)?
>
> Brandon
>
--
Toshiaki Makita
rding to MTU.
>
> If MTU is set to 1500, RX buffers are sized to be about 1536 bytes,
> so you wont be able to receive a 1700 bytes frame.
>
> I guess that you could add a specific veth attribute to precisely
> control MRU, that would not break existing applications.
Ok, I will propose a patch shortly. And thanks, your response time is
awesome !
But why do you want to configure MRU?
What is the problem with setting MTU instead.
Toshiaki Makita
ers are sized to be about 1536 bytes,
> so you wont be able to receive a 1700 bytes frame.
>
> I guess that you could add a specific veth attribute to precisely
> control MRU, that would not break existing applications.
Ok, I will propose a patch shortly. And thanks, your response time is
awesome !
But why do you want to configure MRU?
What is the problem with setting MTU instead.
Toshiaki Makita
n tag size.)
If vlan tag is opaque from kernel, e.g. forwarding vlan tagged frames
without configuring vlan_filtering in bridge, admin needs to set
env_hdr_len manually. This is why I'm proposing manual operation.
Regards,
Toshiaki Makita
n tag size.)
If vlan tag is opaque from kernel, e.g. forwarding vlan tagged frames
without configuring vlan_filtering in bridge, admin needs to set
env_hdr_len manually. This is why I'm proposing manual operation.
Regards,
Toshiaki Makita
http://marc.info/?t=14749669155=1=2
http://marc.info/?t=14749669153=1=2
http://marc.info/?t=14749669152=1=2
http://marc.info/?t=14749669154=1=2
http://marc.info/?t=14749669151=1=2
It needs jumbo frame support of NICs though.
Regards,
Toshiaki Makita
http://marc.info/?t=14749669155=1=2
http://marc.info/?t=14749669153=1=2
http://marc.info/?t=14749669152=1=2
http://marc.info/?t=14749669154=1=2
http://marc.info/?t=14749669151=1=2
It needs jumbo frame support of NICs though.
Regards,
Toshiaki Makita
On 2014/11/06 16:58, 박수현 wrote:
>> -Original Message-
>> From: Toshiaki Makita [mailto:makita.toshi...@lab.ntt.co.jp]
>> Sent: Thursday, November 06, 2014 4:07 PM
>> To: 박수현; Stephen Hemminger; David S. Miller
>> Cc: bri...@lists.linux-foundation.org; net...@
On 2014/11/06 16:58, 박수현 wrote:
-Original Message-
From: Toshiaki Makita [mailto:makita.toshi...@lab.ntt.co.jp]
Sent: Thursday, November 06, 2014 4:07 PM
To: 박수현; Stephen Hemminger; David S. Miller
Cc: bri...@lists.linux-foundation.org; net...@vger.kernel.org; linux-
ker
r_data is non NULL.
Thanks,
Toshiaki Makita
>
> crash dump snippet:
>
> <1>BUG: unable to handle kernel NULL pointer dereference at 0021
> <1>IP: [] br_handle_frame+0xe6/0x270
>
> <0>Code: 4c 0f 44 f0 89 f8 66 33 15 32 52 24 00 66 33 05 29 52
is non NULL.
Thanks,
Toshiaki Makita
crash dump snippet:
1BUG: unable to handle kernel NULL pointer dereference at 0021
1IP: [814179f6] br_handle_frame+0xe6/0x270
0Code: 4c 0f 44 f0 89 f8 66 33 15 32 52 24 00 66 33 05 29 52 24 00 09 c2 89
f0 66 33 05 22 52 24 00 80
eply was directed
> back onto the external network and VM never updated it's ARP cache. This patch
> will notify the bridge command, after a fdb has been updated to identify such
> port toggling.
>
> Signed-off-by: Jon Maxwell
Acked-by: Toshiaki Makita
--
To unsubscribe from this
the external network and VM never updated it's ARP cache. This patch
will notify the bridge command, after a fdb has been updated to identify such
port toggling.
Signed-off-by: Jon Maxwell jmaxwel...@gmail.com
Acked-by: Toshiaki Makita makita.toshi...@lab.ntt.co.jp
--
To unsubscribe from this list
.
thank you for rewriting :)
Thanks,
Toshiaki Makita
>
> $ diff -Naur br_fdb.c br_fdb.c.patch
> --- br_fdb.c2014-05-17 12:43:23.346319609 +1000
> +++ br_fdb.c.patch2014-05-17 16:54:46.280235728 +1000
> @@ -487,6 +487,7 @@
> {
> struct hlist_head
. This is the revised patch. It should
retain the original behaviour except for the notify after the fdb update.
Please let me know if you have any further input?
I have no more comments except for style problems (bracket position,
indentation, type mismatch).
thank you for rewriting :)
Thanks,
Toshiaki
ies fdb entry before updating existing entry. Is this on purpose?
I think we should notify the updated fdb entry.
Similar code fdb_add_entry() does after updating it.
Also, isn't it better to move update of dst into "if" block?
if (source != fdb->dst) {
fdb->dst = sour
() does after updating it.
Also, isn't it better to move update of dst into if block?
if (source != fdb-dst) {
fdb-dst = source;
modified = true;
}
...
if (modified) ...
Thanks,
Toshiaki Makita
--
To unsubscribe from this list: send
On Tue, 2014-03-18 at 18:10 -0700, Luis R. Rodriguez wrote:
> On Tue, Mar 18, 2014 at 6:04 PM, Toshiaki Makita
> wrote:
> > (2014/03/19 9:50), Luis R. Rodriguez wrote:
> >> On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
> >> wrote:
> >>> nit,
>
On Tue, 2014-03-18 at 18:10 -0700, Luis R. Rodriguez wrote:
On Tue, Mar 18, 2014 at 6:04 PM, Toshiaki Makita
makita.toshi...@lab.ntt.co.jp wrote:
(2014/03/19 9:50), Luis R. Rodriguez wrote:
On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
makita.toshi...@lab.ntt.co.jp wrote:
nit
(2014/03/19 9:50), Luis R. Rodriguez wrote:
> On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
> wrote:
>> nit,
>> If the last detached port happens to have the same addr as
>> random_init_addr, this seems to call br_stp_change_bridge_id() even
>> though bridge_i
, addr))
> return false; /* no change */
>
> + if (ether_addr_equal(addr, br_mac_zero))
> + addr = br->random_init_addr;
> +
> br_stp_change_bridge_id(br, addr);
> return true;
> }
nit,
If the last detached port happens to
,
If the last detached port happens to have the same addr as
random_init_addr, this seems to call br_stp_change_bridge_id() even
though bridge_id is not changed.
Shouldn't the assignment of random_init_addr be done before the check of
no change?
Toshiaki Makita
--
To unsubscribe from this list
(2014/03/19 9:50), Luis R. Rodriguez wrote:
On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
makita.toshi...@lab.ntt.co.jp wrote:
nit,
If the last detached port happens to have the same addr as
random_init_addr, this seems to call br_stp_change_bridge_id() even
though bridge_id
her_addr_equal() cannot.
br_stp_recalculate_bridge_id() is searching the smallest address among
its ports. This change breaks it.
Thanks,
Toshiaki Makita
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
br_stp_recalculate_bridge_id() is searching the smallest address among
its ports. This change breaks it.
Thanks,
Toshiaki Makita
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
39 matches
Mail list logo
