New: Cannot change MTU on bridged interface
Subsystems (3)
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 18 lines · On Sat, 11 Jun 2011 10:59:18 GMT [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=37202
Summary: Cannot change MTU on bridged interface Product: Networking Version: 2.5 Kernel Version: 3.0.0-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [email protected] ReportedBy: [email protected] Regression: No
Quoted 6 lines
Without bridge, setting mtu on eth0 works as expected. When eth0 is added to bridge 'br0' and this command is executed,
ip link set eth0 mtu 4000
results in:
erk.
Is this a new bug in 3.0-rc or have earlier kernels crashed in this manner?
Thanks.
Quoted 87 lines
Modules linked in: fuse ip6table_filter ip6_tables ebtable_nat ebtables bridgestp llc sunrpc ipv6
kvm_intelkvm uinputsnd_hda_codec_hdmisnd_hda_codec_realteksnd_hda_intelsnd_hda_codecsnd_hwdepsnd_seqi915drm_kms_helpersnd_seq_devicedrmiTCO_wdti2c_algo_biti2c_i801ata_genericpata_acpiusblpi2c_coree1000exhci_hcdvideoiTCO_vendor_supportusb_storagesnd_pcmserio_rawjoydevpata_jmicronpcspkr microcodesnd_timersnd soundcoresnd_page_alloc[last unloaded:scsi_wait_scan]Pid: 4247, comm: ip Not tainted 3.0.0-rc2 #4 Gigabyte Technology Co., Ltd. H57M-USB3/H57M-USB3
RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff8801e419d680 EFLAGS: 00010202 RAX: 0000000000000640 RBX: 0000000000000640 RCX: ffff880212874788 RDX: ffffffffa0347e00 RSI: ffffffffa0345c21 RDI: ffff880212874fb0 RBP: ffff8801e419d6a8 R08: 0000000000000000 R09: ffffffff81666030 R10: ffffffff81a7a3a0 R11: 0000000000000001 R12: ffff880212874000 R13: ffff880212874780 R14: 00000000ffffffea R15: ffffffffa00e4030 FS: 00007effa3ca6720(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 00000001e401b000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ip (pid: 4247, threadinfo ffff8801e419c000, task ffff8801f5f14560) Stack: ffffffffa033b1a6 ffff880212874000 00000000ffffffed ffff8801f50af400 ffff880211dc4000 ffff8801e419d6c8 ffffffff813ba810 0000000000000007 ffff880212874780 ffff8801e419d6f8 ffffffffa033e2b4 ffff880211dc4000 Call Trace: [<ffffffffa033b1a6>] ? br_change_mtu+0x61/0x81 [bridge] [<ffffffff813ba810>] dev_set_mtu+0x45/0x75 [<ffffffffa033e2b4>] br_device_event+0x7c/0x16c [bridge] [<ffffffff8146f921>] notifier_call_chain+0x37/0x63 [<ffffffff8106d934>] raw_notifier_call_chain+0x14/0x16 [<ffffffff813ba107>] call_netdevice_notifiers+0x4a/0x4f [<ffffffff813ba838>] dev_set_mtu+0x6d/0x75 [<ffffffff813c8da2>] do_setlink+0x1ee/0x739 [<ffffffff810e8052>] ? set_pte_at+0xe/0x12 [<ffffffff8122e1de>] ? nla_parse+0x4f/0xc3 [<ffffffff813c9f45>] rtnl_newlink+0x252/0x48d [<ffffffff813c9db7>] ? rtnl_newlink+0xc4/0x48d [<ffffffff8103d040>] ? need_resched+0x23/0x2d [<ffffffff813af3e3>] ? sock_rmalloc+0x33/0x95 [<ffffffff813c9afe>] rtnetlink_rcv_msg+0x1eb/0x201 [<ffffffff8103d040>] ? need_resched+0x23/0x2d [<ffffffff813c9913>] ? __rtnl_unlock+0x17/0x17 [<ffffffff813dd9a8>] netlink_rcv_skb+0x45/0x90 [<ffffffff813c94c4>] rtnetlink_rcv+0x26/0x2d [<ffffffff813dd4b3>] netlink_unicast+0xf1/0x15a [<ffffffff813dd7a1>] netlink_sendmsg+0x285/0x2a3 [<ffffffff8110c558>] ? fatal_signal_pending+0x12/0x29 [<ffffffff813a9e7d>] __sock_sendmsg+0x6a/0x76 [<ffffffff813aa764>] sock_sendmsg+0xa8/0xc1 [<ffffffff810cf7b0>] ? filemap_fault+0x20b/0x36c [<ffffffff810cde20>] ? unlock_page+0x2a/0x2f [<ffffffff810e8a1a>] ? __do_fault+0x34d/0x384 [<ffffffff8103d040>] ? need_resched+0x23/0x2d [<ffffffff8103d058>] ? should_resched+0xe/0x2e [<ffffffff8103d040>] ? need_resched+0x23/0x2d [<ffffffff8103d058>] ? should_resched+0xe/0x2e [<ffffffff813b406e>] ? copy_from_user+0x2f/0x31 [<ffffffff813b445e>] ? verify_iovec+0x54/0xa6 [<ffffffff813aaa1a>] __sys_sendmsg+0x1ee/0x272 [<ffffffff810eb570>] ? handle_mm_fault+0x149/0x15e [<ffffffff8146c5b6>] ? _raw_spin_lock+0xe/0x10 [<ffffffff8146f8ab>] ? do_page_fault+0x321/0x360 [<ffffffff810efda4>] ? do_brk+0x242/0x296 [<ffffffff813ac02f>] sys_sendmsg+0x42/0x60 [<ffffffff81472d42>] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [< (null)>] (null) RSP <ffff8801e419d680> CR2: 0000000000000000 ---[ end trace 29a99239194ab188 ]---Bridge creation is managed by Fedora14 standard configs. eth0 is the only interface added to the bridge.
eth0 is
03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
Subsystem: Intel Corporation Gigabit CT Desktop Adapter [8086:a01f] Kernel driver in use: e1000e
Kernel modules: e1000e
Andrew Morton wrote, at 06/14/2011 07:37 AM:
Quoted 29 lines
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 22 lines · On Sat, 11 Jun 2011 10:59:18 GMT [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=37202
Summary: Cannot change MTU on bridged interface Product: Networking Version: 2.5 Kernel Version: 3.0.0-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [email protected] ReportedBy: [email protected] Regression: NoWithout bridge, setting mtu on eth0 works as expected. When eth0 is added to bridge 'br0' and this command is executed,
ip link set eth0 mtu 4000
This bug has been fixed.
commit 6407d74c5106bb362b4087693688afd34942b094
Author: Alexander Holler <[email protected]> Date: Tue Jun 7 00:51:35 2011 -0700
bridge: provide a cow_metrics method for fake_ops
Like in commit 0972ddb237 (provide cow_metrics() methods to blackhole dst_ops), we must provide a cow_metrics for bridges fake_dst_ops as well.
This fixes a regression coming from commits 62fa8a846d7d (net: Implement read-only protection and COW'ing of metrics.) and 33eb9873a28 (bridge:
initialize fake_rtable metrics)
ip link set mybridge mtu 1234
Signature · 3 lines
Best Regards ----- Shan Wei