<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net, branch v3.12.4</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/net?h=v3.12.4</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/net?h=v3.12.4'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-12-08T15:29:16Z</updated>
<entry>
<title>rt2800: add support for radio chip RF3070</title>
<updated>2013-12-08T15:29:16Z</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2013-09-25T13:34:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f8bf6d2085715c4326f255ad93ce32e9c4c9c550'/>
<id>urn:sha1:f8bf6d2085715c4326f255ad93ce32e9c4c9c550</id>
<content type='text'>
commit 3b9b74baa1af2952d719735b4a4a34706a593948 upstream.

Add support for new RF chip ID: 3070. It seems to be the same as 5370,
maybe vendor just put wrong value on the eeprom, but add this id anyway
since devices with it showed on the marked.

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>team: fix master carrier set when user linkup is enabled</title>
<updated>2013-12-08T15:29:15Z</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2013-11-28T17:01:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=34923f1eccdbd8c143b664edd933ce2840a50378'/>
<id>urn:sha1:34923f1eccdbd8c143b664edd933ce2840a50378</id>
<content type='text'>
[ Upstream commit f5e0d34382e18f396d7673a84df8e3342bea7eb6 ]

When user linkup is enabled and user sets linkup of individual port,
we need to recompute linkup (carrier) of master interface so the change
is reflected. Fix this by calling __team_carrier_check() which does the
needed work.

Please apply to all stable kernels as well. Thanks.

Reported-by: Jan Tluka &lt;jtluka@redhat.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: smc91: fix crash regression on the versatile</title>
<updated>2013-12-08T15:29:15Z</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2013-11-28T13:33:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2c9681ebe69e09a73aa4e7e06107deb59dd43c65'/>
<id>urn:sha1:2c9681ebe69e09a73aa4e7e06107deb59dd43c65</id>
<content type='text'>
[ Upstream commit a0c20fb02592d372e744d1d739cda3e1b3defaae ]

After commit e9e4ea74f06635f2ffc1dffe5ef40c854faa0a90
"net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data"
The Versatile SMSC LAN91C111 is crashing like this:

------------[ cut here ]------------
kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599!
Internal error: Oops - BUG: 0 [#1] ARM
Modules linked in:
CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24
task: c6ccfaa0 ti: c6cd0000 task.ti: c6cd0000
PC is at smc_hardware_send_pkt+0x198/0x22c
LR is at smc_hardware_send_pkt+0x24/0x22c
pc : [&lt;c01be324&gt;]    lr : [&lt;c01be1b0&gt;]    psr: 20000013
sp : c6cd1d08  ip : 00000001  fp : 00000000
r10: c02adb08  r9 : 00000000  r8 : c6ced802
r7 : c786fba0  r6 : 00000146  r5 : c8800000  r4 : c78d6000
r3 : 0000000f  r2 : 00000146  r1 : 00000000  r0 : 00000031
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 06cf4000  DAC: 00000015
Process udhcpc (pid: 43, stack limit = 0xc6cd01c0)
Stack: (0xc6cd1d08 to 0xc6cd2000)
1d00:                   00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868
1d20: c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60
1d40: 00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000
1d60: c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000
1d80: c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000
1da0: c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000
1dc0: 00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000
1de0: 00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740
1e00: 01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff
1e20: 43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc
1e40: 00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88
1e60: c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e80: 00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0
1ea0: 00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08
1ec0: 00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000
1ee0: 00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000
1f00: 00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002
1f20: 06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c
1f40: 00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0
1f60: 00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0
1f80: 00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8
1fa0: c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000
1fc0: be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000
1fe0: 00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000
[&lt;c01be324&gt;] (smc_hardware_send_pkt+0x198/0x22c) from [&lt;c01be868&gt;] (smc_hard_start_xmit+0xc4/0x1e8)
[&lt;c01be868&gt;] (smc_hard_start_xmit+0xc4/0x1e8) from [&lt;c0208554&gt;] (dev_hard_start_xmit+0x460/0x4cc)
[&lt;c0208554&gt;] (dev_hard_start_xmit+0x460/0x4cc) from [&lt;c021d1d8&gt;] (sch_direct_xmit+0x94/0x18c)
[&lt;c021d1d8&gt;] (sch_direct_xmit+0x94/0x18c) from [&lt;c02087f8&gt;] (dev_queue_xmit+0x238/0x42c)
[&lt;c02087f8&gt;] (dev_queue_xmit+0x238/0x42c) from [&lt;c027ba74&gt;] (packet_sendmsg+0xbe8/0xd28)
[&lt;c027ba74&gt;] (packet_sendmsg+0xbe8/0xd28) from [&lt;c01f2870&gt;] (sock_sendmsg+0x84/0xa8)
[&lt;c01f2870&gt;] (sock_sendmsg+0x84/0xa8) from [&lt;c01f4628&gt;] (SyS_sendto+0xb8/0xdc)
[&lt;c01f4628&gt;] (SyS_sendto+0xb8/0xdc) from [&lt;c0013840&gt;] (ret_fast_syscall+0x0/0x2c)
Code: e3130002 1a000001 e3130001 0affffcd (e7f001f2)
---[ end trace 81104fe70e8da7fe ]---
Kernel panic - not syncing: Fatal exception in interrupt

This is because the macro operations in smc91x.h defined
for Versatile are missing SMC_outsw() as used in this
commit.

The Versatile needs and uses the same accessors as the other
platforms in the first if(...) clause, just switch it to using
that and we have one problem less to worry about.

This includes a hunk of a patch from Will Deacon fixin
the other 32bit platforms as well: Innokom, Ramses, PXA,
PCM027.

Checkpatch complains about spacing, but I have opted to
follow the style of this .h-file.

Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Nicolas Pitre &lt;nico@fluxnic.net&gt;
Cc: Eric Miao &lt;eric.y.miao@gmail.com&gt;
Cc: Jonathan Cameron &lt;jic23@cam.ac.uk&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl</title>
<updated>2013-12-08T15:29:15Z</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2013-11-27T06:32:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2650c2f88adb79a2ec693ccf65fd59f7389e79c9'/>
<id>urn:sha1:2650c2f88adb79a2ec693ccf65fd59f7389e79c9</id>
<content type='text'>
[ Upstream commit 7fe0ee099ad5e3dea88d4ee1b6f20246b1ca57c3 ]

Using iperf to send packets(GSO mode is on), a bug is triggered:

[  212.672781] kernel BUG at lib/dynamic_queue_limits.c:26!
[  212.673396] invalid opcode: 0000 [#1] SMP
[  212.673882] Modules linked in: 8139cp(O) nls_utf8 edd fuse loop dm_mod ipv6 i2c_piix4 8139too i2c_core intel_agp joydev pcspkr hid_generic intel_gtt floppy sr_mod mii button sg cdrom ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore sd_mod usb_common crc_t10dif crct10dif_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata scsi_mod [last unloaded: 8139cp]
[  212.676084] CPU: 0 PID: 4124 Comm: iperf Tainted: G           O 3.12.0-0.7-default+ #16
[  212.676084] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[  212.676084] task: ffff8800d83966c0 ti: ffff8800db4c8000 task.ti: ffff8800db4c8000
[  212.676084] RIP: 0010:[&lt;ffffffff8122e23f&gt;]  [&lt;ffffffff8122e23f&gt;] dql_completed+0x17f/0x190
[  212.676084] RSP: 0018:ffff880116e03e30  EFLAGS: 00010083
[  212.676084] RAX: 00000000000005ea RBX: 0000000000000f7c RCX: 0000000000000002
[  212.676084] RDX: ffff880111dd0dc0 RSI: 0000000000000bd4 RDI: ffff8800db6ffcc0
[  212.676084] RBP: ffff880116e03e48 R08: 0000000000000992 R09: 0000000000000000
[  212.676084] R10: ffffffff8181e400 R11: 0000000000000004 R12: 000000000000000f
[  212.676084] R13: ffff8800d94ec840 R14: ffff8800db440c80 R15: 000000000000000e
[  212.676084] FS:  00007f6685a3c700(0000) GS:ffff880116e00000(0000) knlGS:0000000000000000
[  212.676084] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  212.676084] CR2: 00007f6685ad6460 CR3: 00000000db714000 CR4: 00000000000006f0
[  212.676084] Stack:
[  212.676084]  ffff8800db6ffc00 000000000000000f ffff8800d94ec840 ffff880116e03eb8
[  212.676084]  ffffffffa041509f ffff880116e03e88 0000000f16e03e88 ffff8800d94ec000
[  212.676084]  00000bd400059858 000000050000000f ffffffff81094c36 ffff880116e03eb8
[  212.676084] Call Trace:
[  212.676084]  &lt;IRQ&gt;
[  212.676084]  [&lt;ffffffffa041509f&gt;] cp_interrupt+0x4ef/0x590 [8139cp]
[  212.676084]  [&lt;ffffffff81094c36&gt;] ? ktime_get+0x56/0xd0
[  212.676084]  [&lt;ffffffff8108cf73&gt;] handle_irq_event_percpu+0x53/0x170
[  212.676084]  [&lt;ffffffff8108d0cc&gt;] handle_irq_event+0x3c/0x60
[  212.676084]  [&lt;ffffffff8108fdb5&gt;] handle_fasteoi_irq+0x55/0xf0
[  212.676084]  [&lt;ffffffff810045df&gt;] handle_irq+0x1f/0x30
[  212.676084]  [&lt;ffffffff81003c8b&gt;] do_IRQ+0x5b/0xe0
[  212.676084]  [&lt;ffffffff8142beaa&gt;] common_interrupt+0x6a/0x6a
[  212.676084]  &lt;EOI&gt;
[  212.676084]  [&lt;ffffffffa0416a21&gt;] ? cp_start_xmit+0x621/0x97c [8139cp]
[  212.676084]  [&lt;ffffffffa0416a09&gt;] ? cp_start_xmit+0x609/0x97c [8139cp]
[  212.676084]  [&lt;ffffffff81378ed9&gt;] dev_hard_start_xmit+0x2c9/0x550
[  212.676084]  [&lt;ffffffff813960a9&gt;] sch_direct_xmit+0x179/0x1d0
[  212.676084]  [&lt;ffffffff813793f3&gt;] dev_queue_xmit+0x293/0x440
[  212.676084]  [&lt;ffffffff813b0e46&gt;] ip_finish_output+0x236/0x450
[  212.676084]  [&lt;ffffffff810e59e7&gt;] ? __alloc_pages_nodemask+0x187/0xb10
[  212.676084]  [&lt;ffffffff813b10e8&gt;] ip_output+0x88/0x90
[  212.676084]  [&lt;ffffffff813afa64&gt;] ip_local_out+0x24/0x30
[  212.676084]  [&lt;ffffffff813aff0d&gt;] ip_queue_xmit+0x14d/0x3e0
[  212.676084]  [&lt;ffffffff813c6fd1&gt;] tcp_transmit_skb+0x501/0x840
[  212.676084]  [&lt;ffffffff813c8323&gt;] tcp_write_xmit+0x1e3/0xb20
[  212.676084]  [&lt;ffffffff81363237&gt;] ? skb_page_frag_refill+0x87/0xd0
[  212.676084]  [&lt;ffffffff813c8c8b&gt;] tcp_push_one+0x2b/0x40
[  212.676084]  [&lt;ffffffff813bb7e6&gt;] tcp_sendmsg+0x926/0xc90
[  212.676084]  [&lt;ffffffff813e1d21&gt;] inet_sendmsg+0x61/0xc0
[  212.676084]  [&lt;ffffffff8135e861&gt;] sock_aio_write+0x101/0x120
[  212.676084]  [&lt;ffffffff81107cf1&gt;] ? vma_adjust+0x2e1/0x5d0
[  212.676084]  [&lt;ffffffff812163e0&gt;] ? timerqueue_add+0x60/0xb0
[  212.676084]  [&lt;ffffffff81130b60&gt;] do_sync_write+0x60/0x90
[  212.676084]  [&lt;ffffffff81130d44&gt;] ? rw_verify_area+0x54/0xf0
[  212.676084]  [&lt;ffffffff81130f66&gt;] vfs_write+0x186/0x190
[  212.676084]  [&lt;ffffffff811317fd&gt;] SyS_write+0x5d/0xa0
[  212.676084]  [&lt;ffffffff814321e2&gt;] system_call_fastpath+0x16/0x1b
[  212.676084] Code: ca 41 89 dc 41 29 cc 45 31 db 29 c2 41 89 c5 89 d0 45 29 c5 f7 d0 c1 e8 1f e9 43 ff ff ff 66 0f 1f 44 00 00 31 c0 e9 7b ff ff ff &lt;0f&gt; 0b eb fe 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 c7 47 40 00
[  212.676084] RIP  [&lt;ffffffff8122e23f&gt;] dql_completed+0x17f/0x190
------------[ cut here ]------------

When a skb has frags, bytes_compl plus skb-&gt;len nr_frags times in cp_tx().
It's not the correct value(actually, it should plus skb-&gt;len once) and it
will trigger the BUG_ON(bytes_compl &gt; num_queued - dql-&gt;num_completed).
So only increase bytes_compl when finish sending all frags. pkts_compl also
has a wrong value, fix it too.

It's introduced by commit 871f0d4c ("8139cp: enable bql").

Suggested-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>r8169: check ALDPS bit and disable it if enabled for the 8168g</title>
<updated>2013-12-08T15:29:15Z</updated>
<author>
<name>David Chang</name>
<email>dchang@suse.com</email>
</author>
<published>2013-11-27T07:48:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8b0a34fa49e2cca02beeafce2d96e9d8a53c85e3'/>
<id>urn:sha1:8b0a34fa49e2cca02beeafce2d96e9d8a53c85e3</id>
<content type='text'>
[ Upstream commit 1bac1072425c86f1ac85bd5967910706677ef8b3 ]

Windows driver will enable ALDPS function, but linux driver and firmware
do not have any configuration related to ALDPS function for 8168g.
So restart system to linux and remove the NIC cable, LAN enter ALDPS,
then LAN RX will be disabled.

This issue can be easily reproduced on dual boot windows and linux
system with RTL_GIGA_MAC_VER_40 chip.

Realtek said, ALDPS function can be disabled by configuring to PHY,
switch to page 0x0A43, reg0x10 bit2=0.

Signed-off-by: David Chang &lt;dchang@suse.com&gt;
Acked-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>via-velocity: fix netif_receive_skb use in irq disabled section.</title>
<updated>2013-12-08T15:29:14Z</updated>
<author>
<name>Francois Romieu</name>
<email>romieu@fr.zoreil.com</email>
</author>
<published>2013-11-25T23:40:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=df0c053e8ae401eab14447a729060bfa4f8c02ce'/>
<id>urn:sha1:df0c053e8ae401eab14447a729060bfa4f8c02ce</id>
<content type='text'>
[ Upstream commit bc9627e7e918a85e906c1a3f6d01d9b8ef911a96 ]

2fdac010bdcf10a30711b6924612dfc40daf19b8 ("via-velocity.c: update napi
implementation") overlooked an irq disabling spinlock when the Rx part
of the NAPI poll handler was converted from netif_rx to netif_receive_skb.

NAPI Rx processing can be taken out of the locked section with a pair of
napi_{disable / enable} since it only races with the MTU change function.

An heavier rework of the NAPI locking would be able to perform NAPI Tx
before Rx where I simply removed one of velocity_tx_srv calls.

References: https://bugzilla.redhat.com/show_bug.cgi?id=1022733
Fixes: 2fdac010bdcf (via-velocity.c: update napi implementation)
Signed-off-by: Francois Romieu &lt;romieu@fr.zoreil.com&gt;
Tested-by: Alex A. Schmidt &lt;aaschmidt1@gmail.com&gt;
Cc: Jamie Heilman &lt;jamie@audible.transient.net&gt;
Cc: Michele Baldessari &lt;michele@acksyn.org&gt;
Cc: Julia Lawall &lt;Julia.Lawall@lip6.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xen-netback: include definition of csum_ipv6_magic</title>
<updated>2013-12-08T15:29:14Z</updated>
<author>
<name>Andy Whitcroft</name>
<email>apw@canonical.com</email>
</author>
<published>2013-11-25T16:52:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d172c155ae6c542947f3ebe690ac61ffa9b654f2'/>
<id>urn:sha1:d172c155ae6c542947f3ebe690ac61ffa9b654f2</id>
<content type='text'>
[ Upstream commit ae5e8127b712313ec1b99356019ce9226fea8b88 ]

We are now using csum_ipv6_magic, include the appropriate header.
Avoids the following error:

    drivers/net/xen-netback/netback.c:1313:4: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
        tcph-&gt;check = ~csum_ipv6_magic(&amp;ipv6h-&gt;saddr,

Signed-off-by: Andy Whitcroft &lt;apw@canonical.com&gt;
Acked-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: rework recvmsg handler msg_name and msg_namelen logic</title>
<updated>2013-12-08T15:29:13Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-11-21T02:14:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0cefe287488ca07c0d7962a7b4d3fbb829d09917'/>
<id>urn:sha1:0cefe287488ca07c0d7962a7b4d3fbb829d09917</id>
<content type='text'>
[ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ]

This patch now always passes msg-&gt;msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size &lt;= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg-&gt;msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys-&gt;msg_namelen == 0)
	msg-&gt;msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller &lt;davem@davemloft.net&gt;
Suggested-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bonding: fix two race conditions in bond_store_updelay/downdelay</title>
<updated>2013-12-08T15:29:12Z</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@redhat.com</email>
</author>
<published>2013-11-13T16:07:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=accbc62ee04bb72ee23a96ec10b0a6a2e2260a55'/>
<id>urn:sha1:accbc62ee04bb72ee23a96ec10b0a6a2e2260a55</id>
<content type='text'>
[ Upstream commit b869ccfab1e324507fa3596e3e1308444fb68227 ]

This patch fixes two race conditions between bond_store_updelay/downdelay
and bond_store_miimon which could lead to division by zero as miimon can
be set to 0 while either updelay/downdelay are being set and thus miss the
zero check in the beginning, the zero div happens because updelay/downdelay
are stored as new_value / bond-&gt;params.miimon. Use rtnl to synchronize with
miimon setting.

CC: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
CC: Andy Gospodarek &lt;andy@greyhouse.net&gt;
CC: Veaceslav Falico &lt;vfalico@redhat.com&gt;
Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Acked-by: Veaceslav Falico &lt;vfalico@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>macvtap: limit head length of skb allocated</title>
<updated>2013-12-08T15:29:12Z</updated>
<author>
<name>Jason Wang</name>
<email>jasowang@redhat.com</email>
</author>
<published>2013-11-13T06:00:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ebee20ff2444c1b65885ab1869001922e0a1f969'/>
<id>urn:sha1:ebee20ff2444c1b65885ab1869001922e0a1f969</id>
<content type='text'>
[ Upstream commit 16a3fa28630331e28208872fa5341ce210b901c7 ]

We currently use hdr_len as a hint of head length which is advertised by
guest. But when guest advertise a very big value, it can lead to an 64K+
allocating of kmalloc() which has a very high possibility of failure when host
memory is fragmented or under heavy stress. The huge hdr_len also reduce the
effect of zerocopy or even disable if a gso skb is linearized in guest.

To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
head, which guarantees an order 0 allocation each time.

Cc: Stefan Hajnoczi &lt;stefanha@redhat.com&gt;
Cc: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
