aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-02-14RDMA/ocrdma: Fix load time panic during GID table initDevesh Sharma1-1/+1
We should use rdma_vlan_dev_real_dev() instead of using vlan_dev_real_dev() when building the GID table for a vlan interface. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-14RDMA/ocrdma: Fix traffic class shiftDevesh Sharma1-1/+1
Use correct value for obtaining traffic class from device response for Query QP request. Signed-off-by: Devesh Sharma <[email protected]> Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-14IB/iser: Fix use after free in iser_snd_completion()Dan Carpenter1-1/+2
We use "tx_desc" again after we free it. Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-14IB/iser: Avoid dereferencing iscsi_iser conn object when not bound to iser ↵Roi Dayan1-3/+7
connection Fix a possible NULL pointer dereference in disconnection flow. This can happen if the target disconnected/rejected the connection request, e.g before the binding stage between iscsi connection to the transport connection. Signed-off-by: Alex Tabachnik <[email protected]> Signed-off-by: Roi Dayan <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-14IB/usnic: Fix smatch endianness errorUpinder Malhi1-1/+8
Error reported at http://marc.info/?l=linux-rdma&m=138995755801039&w=2 Fix short to int cast for big endian systems. Signed-off-by: Upinder Malhi <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-14arm64: KVM: Add VGIC device control for arm64Christoffer Dall2-0/+10
This fixes the build breakage introduced by c07a0191ef2de1f9510f12d1f88e3b0b5cd8d66f and adds support for the device control API and save/restore of the VGIC state for ARMv8. The defines were simply missing from the arm64 header files and uaccess.h must be implicitly imported from somewhere else on arm. Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2014-02-14x86/efi: Check status field to validate BGRT headerMatt Fleming1-1/+1
Madper reported seeing the following crash, BUG: unable to handle kernel paging request at ffffffffff340003 IP: [<ffffffff81d85ba4>] efi_bgrt_init+0x9d/0x133 Call Trace: [<ffffffff81d8525d>] efi_late_init+0x9/0xb [<ffffffff81d68f59>] start_kernel+0x436/0x450 [<ffffffff81d6892c>] ? repair_env_string+0x5c/0x5c [<ffffffff81d68120>] ? early_idt_handlers+0x120/0x120 [<ffffffff81d685de>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81d6871e>] x86_64_start_kernel+0x13e/0x14d This is caused because the layout of the ACPI BGRT header on this system doesn't match the definition from the ACPI spec, and so we get a bogus physical address when dereferencing ->image_address in efi_bgrt_init(). Luckily the status field in the BGRT header clearly marks it as invalid, so we can check that field and skip BGRT initialisation. Reported-by: Madper Xie <[email protected]> Suggested-by: Toshi Kani <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Josh Triplett <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-02-14EDAC: Correct workqueue setup pathBorislav Petkov1-4/+7
We're using edac_mc_workq_setup() both on the init path, when we load an edac driver and when we change the polling period (edac_mc_reset_delay_period) through /sys/.../edac_mc_poll_msec. On that second path we don't need to init the workqueue which has been initialized already. Thanks to Tejun for workqueue insights. Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: <[email protected]>
2014-02-14EDAC: Poll timeout cannot be zero, p2Borislav Petkov3-7/+9
Sanitize code even more to accept unsigned longs only and to not allow polling intervals below 1 second as this is unnecessary and doesn't make much sense anyway for polling errors. Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: Doug Thompson <[email protected]> Cc: <[email protected]>
2014-02-14x86/efi: Fix 32-bit falloutBorislav Petkov4-3/+19
We do not enable the new efi memmap on 32-bit and thus we need to run runtime_code_page_mkexec() unconditionally there. Fix that. Reported-and-tested-by: Lejun Zhu <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-02-14video: Kconfig: Allow more broad selection of the imxfb framebuffer driver.Denis Carikli1-1/+1
Without that patch, a user can't select the imxfb driver when the i.MX25 and/or the i.MX27 device tree board are selected and that no boards that selects IMX_HAVE_PLATFORM_IMX_FB are compiled in. Cc: Eric Bénard <[email protected]> Cc: Jean-Christophe Plagniol-Villard <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Tomi Valkeinen <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Denis Carikli <[email protected]> Acked-by: Shawn Guo <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Acked-by: Sascha Hauer <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2014-02-14video: exynos: Fix S6E8AX0 LCD driver build errorSachin Kamat1-1/+2
Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver. Else we get the following errors due to missing symbols: drivers/built-in.o: In function `s6e8ax0_probe': :(.text+0x51aec): undefined reference to `lcd_device_register' :(.text+0x51c44): undefined reference to `lcd_device_unregister' Signed-off-by: Sachin Kamat <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2014-02-14ipv4: ipconfig.c: add parentheses in an if statementFX Le Bail1-1/+1
Even if the 'time_before' macro expand with parentheses, the look is bad. Signed-off-by: Francois-Xavier Le Bail <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13IB/mlx5: Remove dependency on X86Eli Cohen2-2/+2
Remove Kconfig dependency of mlx5_ib/mlx5_core on X86, since there is no such dependency in reality. Signed-off-by: Eli Cohen <[email protected]> Signed-off-by: Michael Neuling <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13mlx5: Add include of <linux/slab.h> because of kzalloc()/kfree() useRoland Dreier1-0/+2
On some architectures (for example, arm), we don't end up indirectly pulling in the declaration of kzalloc() and kfree(), and so building anything that includes <linux/mlx5/driver.h> breaks. Fix this by adding an explicit include to get the declaration. Reported-by: kbuild test robot <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13hwmon: (ntc_thermistor) Avoid math overflowDoug Anderson1-3/+3
The ntc thermistor code was doing math whose temporary result might have overflowed 32-bits. We need some casts in there to make it safe. In one example I found: - pullup_uV: 1800000 - result of iio_read_channel_raw: 3226 - 1800000 * 3226 => 0x15a1cbc80 Signed-off-by: Doug Anderson <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Guenter Roeck <[email protected]>
2014-02-13net:phy:dp83640: Move all HW initialization to dp83640_config_initStefan Sørensen1-5/+8
phy_init_hw not does a full PHY reset after the driver probe has finished, so any hw initialization done in the probe will be lost. Part of the timestamping functionality of the dp83640 is set up in the probe and with that lost, enabling timestamping will cause a PHY lockup, requiring a hard reset / power cycle to recover. This patch moves all the HW initialization in dp83640_probe to dp83640_config_init. Signed-off-by: Stefan Sørensen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13drivers: net: cpsw: fix buggy loop conditionHeiko Schocher1-3/+3
Commit 0cd8f9cc0654c06adde353c6532114c5f53a18e8 ("drivers: net: cpsw: enable promiscuous mode support") Enable promiscuous mode support for CPSW. Introduced a crash on an am335x based board (similiar to am335x-evm). Reason is buggy end condition in for loop in cpsw_set_promiscious() for (i = 0; i <= priv->data.slaves; i++) should be for (i = 0; i < priv->data.slaves; i++) Fix this ... Signed-off-by: Heiko Schocher <[email protected]> Cc: Mugunthan V N <[email protected]> Cc: David S. Miller <[email protected]> Cc: Sebastian Siewior <[email protected]> Cc: Daniel Mack <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: Markus Pargmann <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Mugunthan V N <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13vhost: fix a theoretical race in device cleanupMichael S. Tsirkin1-0/+6
vhost_zerocopy_callback accesses VQ right after it drops a ubuf reference. In theory, this could race with device removal which waits on the ubuf kref, and crash on use after free. Do all accesses within rcu read side critical section, and synchronize on release. Since callbacks are always invoked from bh, synchronize_rcu_bh seems enough and will help release complete a bit faster. Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13vhost: fix ref cnt checking deadlockMichael S. Tsirkin1-21/+20
vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing resources. In the end no one initiates freeing resources until the last reference is gone (which is on VM shotdown so might happen after a looooong time). Let's do what we probably should have done straight away: switch from kref to plain atomic, documenting the semantics, return the refcount value atomically after decrement, then use that to avoid the deadlock. Reported-by: Qin Chuanyu <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13USB2NET: Fix Default to 'y' for SR9800 Device Driver, setting to 'n'Liu Junliang1-1/+0
Signed-off-by: Liu Junliang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13USB2NET: SR9800: use %zu for size_tJingoo Han1-1/+1
Use %zu for size_t in order to avoid the following build warning in printks. drivers/net/usb/sr9800.c: In function 'sr9800_bind' drivers/net/usb/sr9800.c:826:2: warning: format '%ld' expects argument of type 'long int' but argument 5 has type 'size_t' [-Wformat] Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: sched: Cleanup PIE commentsVijay Subramanian1-5/+16
Fix incorrect comment reported by Norbert Kiesel. Edit another comment to add more details. Also add references to algorithm (IETF draft and paper) to top of file. Signed-off-by: Vijay Subramanian <[email protected]> CC: Mythili Prabhu <[email protected]> CC: Norbert Kiesel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: cpsw: catch of_get_phy_mode failing and propagate errorUwe Kleine-König1-0/+5
It's wrong if the device tree doesn't provide a phy-mode property for the cpsw slaves as it is documented to be required in Documentation/devicetree/bindings/net/cpsw.txt. Anyhow it's nice to catch that problem, still more as it used to work without this property up to commit 388367a5a9fb (drivers: net: cpsw: use cpsw-phy-sel driver to configure phy mode) which is in v3.13-rc1. Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Mugunthan V N <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: qmi_wwan: add support for Cinterion PXS8 and PHS8Aleksander Morgado1-0/+1
When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a QMI port and a WWAN interface. CC: Hans-Christoph Schemmel <[email protected]> CC: Christian Schmiedl <[email protected]> CC: Nicolaus Colberg <[email protected]> CC: David McCullough <[email protected]> Signed-off-by: Aleksander Morgado <[email protected]> Acked-by: Bjørn Mork <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13Merge tag 'linux-can-fixes-for-3.14-20140212' of ↵David S. Miller1-0/+2
git://gitorious.org/linux-can/linux-can linux-can-fixes-for-3.14-20140212 Marc Kleine-Budde says: ==================== this is a pull request with one patch for net/master, for the current release cycle. Olivier Sobrie noticed and fixed that the kvaser_usb driver doesn't check the number of channels value from the hardware, which may result in writing over the bounds of an array in the driver. ==================== Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: axienet: Fix compilation warningsMichal Simek1-4/+8
Warning log: xilinx_axienet_main.c: In function 'axienet_start_xmit_done': xilinx_axienet_main.c:617:16: warning: operation on 'lp->tx_bd_ci' may be undefined [-Wsequence-point] xilinx_axienet_main.c: In function 'axienet_start_xmit': xilinx_axienet_main.c:703:18: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point] xilinx_axienet_main.c:719:17: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point] xilinx_axienet_main.c: In function 'axienet_recv': xilinx_axienet_main.c:792:16: warning: operation on 'lp->rx_bd_ci' may be undefined [-Wsequence-point] xilinx_axienet_main.c: In function 'axienet_of_probe': xilinx_axienet_main.c:1501:21: warning: unused variable 'rc' [-Wunused-variable] Signed-off-by: Michal Simek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: axienet: Fix compilation errorMichal Simek1-0/+1
Add missing header to fix compilation error. drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1575:22: error: undefined identifier 'irq_of_parse_and_map' drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1576:22: error: undefined identifier 'irq_of_parse_and_map' Signed-off-by: Michal Simek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13IB/qib: Add missing serdes init sequenceMike Marciniszyn1-0/+5
Research has shown that commit a77fcf895046 ("IB/qib: Use a single txselect module parameter for serdes tuning") missed a key serdes init sequence. This patch add that sequence. Cc: <[email protected]> Reviewed-by: Dennis Dalessandro <[email protected]> Signed-off-by: Mike Marciniszyn <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13RDMA/cxgb4: Add missing neigh_release in LE-Workaround pathKumar Sanghvi1-0/+1
Signed-off-by: Kumar Sanghvi <[email protected]> Signed-off-by: Hariprasad Shenai <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13IB: Report using RoCE IP based gids in port capsMoni Shoua3-3/+4
For userspace RoCE UD QPs we need to know the GID format that the kernel uses, e.g when working over older kernels. For that end, add a new port capability IB_PORT_IP_BASED_GIDS and report it when query port is issued. Signed-off-by: Moni Shoua <[email protected]> Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13IB/mlx4: Build the port IBoE GID table properly under bondingMoni Shoua1-4/+37
When scanning netdevices we need to check a few more conditions and cases to build the IBoE GID table properly. For example, under bonding we must make sure that when a port is down, the bond IP address isn't programmed as a GID, since doing so will cause failure with IB core flows that selects ports by GID. Signed-off-by: Moni Shoua <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13IB/mlx4: Do IBoE GID table resets per-portMoni Shoua1-17/+18
The IBoE code used to reset the GID table did it for all Ethernet ports of the device. Since the whole architecture of generating GIDs and responding to events is port-based, this is inefficient and can lead to wrong content in the GID table. Change the reset flow to be per-port. Signed-off-by: Moni Shoua <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13IB/mlx4: Do IBoE locking earlier when initializing the GID tableMoni Shoua1-3/+3
Updating the GID table under IBoE requires read/write from/to shared data structures. These data structures are protected with the device iboe lock. The flows that modify the GID table start from 1. Initializing the GID table 2. NETDEV events 3. INET or INET6 events This patch makes sure that the flow of initializing the GID table is consistent with the other two flows w.r.t on what step the lock is taken. Signed-off-by: Moni Shoua <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13IB/mlx4: Move rtnl locking to the right placeMoni Shoua1-2/+2
On the one hand, the invocation of netdev_master_upper_dev_get() within mlx4_ib_scan_netdevs() must be done with rtnl lock held. On the other hand, it's wrong to call rtnl_lock() from within this function since it's also called by our netdev notifier callback. Therefore move the locking to mlx4_ib_add() so that both cases are covered. Signed-off-by: Moni Shoua <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13IB/mlx4: Make sure GID index 0 is always occupiedMoni Shoua1-24/+68
Make sure that for Ethernet ports, the port GID table index 0 is always occupied with a default GID of the relevant IPv6 link-local adderss. This provides better user experience for legacy applications that don't use the RDMA CM and were working on index 0 prior to the IP addressing change. Also, as GIDs are generated from IP addresses of the network devices that are associated with the port, it's basically possible that the GID table will be empty if no IP address was assigned. This doesn't comply with the IB spec section 4.1.1 "GID usage and properties". Signed-off-by: Moni Shoua <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2014-02-13net: ip, ipv6: handle gso skbs in forwarding pathFlorian Westphal3-4/+101
Marcelo Ricardo Leitner reported problems when the forwarding link path has a lower mtu than the incoming one if the inbound interface supports GRO. Given: Host <mtu1500> R1 <mtu1200> R2 Host sends tcp stream which is routed via R1 and R2. R1 performs GRO. In this case, the kernel will fail to send ICMP fragmentation needed messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu checks in forward path. Instead, Linux tries to send out packets exceeding the mtu. When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does not fragment the packets when forwarding, and again tries to send out packets exceeding R1-R2 link mtu. This alters the forwarding dstmtu checks to take the individual gso segment lengths into account. For ipv6, we send out pkt too big error for gso if the individual segments are too big. For ipv4, we either send icmp fragmentation needed, or, if the DF bit is not set, perform software segmentation and let the output path create fragments when the packet is leaving the machine. It is not 100% correct as the error message will contain the headers of the GRO skb instead of the original/segmented one, but it seems to work fine in my (limited) tests. Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid sofware segmentation. However it turns out that skb_segment() assumes skb nr_frags is related to mss size so we would BUG there. I don't want to mess with it considering Herbert and Eric disagree on what the correct behavior should be. Hannes Frederic Sowa notes that when we would shrink gso_size skb_segment would then also need to deal with the case where SKB_MAX_FRAGS would be exceeded. This uses sofware segmentation in the forward path when we hit ipv4 non-DF packets and the outgoing link mtu is too small. Its not perfect, but given the lack of bug reports wrt. GRO fwd being broken this is a rare case anyway. Also its not like this could not be improved later once the dust settles. Acked-by: Herbert Xu <[email protected]> Reported-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: core: introduce netif_skb_dev_featuresFlorian Westphal2-11/+18
Will be used by upcoming ipv4 forward path change that needs to determine feature mask using skb->dst->dev instead of skb->dev. Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13bonding: Fix deadlock in bonding driver when using netpolldingtianhong1-0/+7
The bonding driver take write locks and spin locks that are shared by the tx path in enslave processing and notification processing, If the netconsole is in use, the bonding can call printk which puts us in the netpoll tx path, if the netconsole is attached to the bonding driver, result in deadlock. So add protection for these place, by checking the netpoll_block_tx state, we can defer the sending of the netconsole frames until a later time using the retransmit feature of netpoll_send_skb that is triggered on the return code NETDEV_TX_BUSY. Cc: Jay Vosburgh <[email protected]> Cc: Veaceslav Falico <[email protected]> Cc: Andy Gospodarek <[email protected]> Signed-off-by: Ding Tianhong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13Documentation/networking: delete orphaned 3c505.txt file.Paul Gortmaker1-45/+0
In the commit 0e245dbaac9fa1c2fd0f4e2af7b9f6d874083a8b ("drivers/net: delete the 3Com 3c505/3c507 intel i825xx support") we clobbered the 3c505 driver (over a year ago) along with other abandoned ISA drivers. However, this orphaned README file escaped detection at that time, and has lived on until today. Get rid of it now. Signed-off-by: Paul Gortmaker <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13sctp: optimize the sctp_sysctl_net_registerwangweidong1-7/+10
Here, when the net is init_net, we needn't to kmemdup the ctl_table again. So add a check for net. Also we can save some memory. Signed-off-by: Wang Weidong <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13sctp: fix a missed .data initializationwangweidong1-0/+1
As commit 3c68198e75111a90("sctp: Make hmac algorithm selection for cookie generation dynamic"), we miss the .data initialization. If we don't use the net_namespace, the problem that parts of the sysctl configuration won't be isolation and won't occur. In sctp_sysctl_net_register(), we register the sysctl for each net, in the for(), we use the 'table[i].data' as check condition, so when the 'i' is the index of sctp_hmac_alg, the data is NULL, then break. So add the .data initialization. Acked-by: Neil Horman <[email protected]> Signed-off-by: Wang Weidong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: correct error path in rtnl_newlink()Cong Wang1-7/+12
I saw the following BUG when ->newlink() fails in rtnl_newlink(): [ 40.240058] kernel BUG at net/core/dev.c:6438! this is due to free_netdev() is not supposed to be called before netdev is completely unregistered, therefore it is not correct to call free_netdev() here, at least for ops->newlink!=NULL case, many drivers call it in ->destructor so that rtnl_unlock() will take care of it, we probably don't need to do anything here. Cc: David S. Miller <[email protected]> Cc: Eric Dumazet <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13macvlan: unregister net device when netdev_upper_dev_link() failsCong Wang1-2/+3
rtnl_newlink() doesn't unregister it for us on failure. Cc: Patrick McHardy <[email protected]> Cc: David S. Miller <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13jfs: set i_ctime when setting ACLDave Kleikamp1-0/+2
This fixes a regression in 3.14-rc1 where xfstests generic/307 fails. jfs sets the ctime on the inode when writing an xattr. Previously, jfs went ahead and stored an acl that can be completely represented in the traditional permission bits, so the ctime was always set in the xattr code. The new code doesn't bother storing the acl in that case, thus the ctime isn't getting set. Signed-off-by: Dave Kleikamp <[email protected]> Reported-by: Michael L. Semon <[email protected]>
2014-02-13tipc: fix message corruption bug for deferred packetsErik Hugne2-0/+8
If a packet received on a link is out-of-sequence, it will be placed on a deferred queue and later reinserted in the receive path once the preceding packets have been processed. The problem with this is that it will be subject to the buffer adjustment from link_recv_buf_validate twice. The second adjustment for 20 bytes header space will corrupt the packet. We solve this by tagging the deferred packets and bail out from receive buffer validation for packets that have already been subjected to this. Signed-off-by: Erik Hugne <[email protected]> Reviewed-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13net: stmmac:sti: Add STi SOC glue driver.Srinivas Kandagatla6-0/+408
STi series SOCs have a glue layer on top of the synopsis gmac IP, this glue layer needs to be configured before the gmac driver starts using the IP. This patch adds a support to this glue layer which is configured via stmmac setup, init, exit callbacks. Signed-off-by: Srinivas Kandagatla <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13tick: Clear broadcast pending bit when switching to oneshotThomas Gleixner1-0/+1
AMD systems which use the C1E workaround in the amd_e400_idle routine trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU. The reason is that the idle routine of those AMD systems switches the cpu into forced broadcast mode early on before the newly brought up CPU can switch over to high resolution / NOHZ mode. The timer related CPU1 bringup looks like this: clockevent_register_device(local_apic); tick_setup(local_apic); ... idle() tick_broadcast_on_off(FORCE); tick_broadcast_oneshot_control(ENTER) cpumask_set(cpu, broadcast_oneshot_mask); halt(); Now the broadcast interrupt on CPU0 sets CPU1 in the broadcast_pending_mask and wakes CPU1. So CPU1 continues: local_apic_timer_interrupt() tick_handle_periodic(); softirq() tick_init_highres(); cpumask_clr(cpu, broadcast_oneshot_mask); tick_broadcast_oneshot_control(ENTER) WARN_ON(cpumask_test(cpu, broadcast_pending_mask); So while we remove CPU1 from the broadcast_oneshot_mask when we switch over to highres mode, we do not clear the pending bit, which then triggers the warning when we go back to idle. The reason why this is only visible on C1E affected AMD systems is that the other machines enter the deep sleep states via acpi_idle/intel_idle and exit the broadcast mode before executing the remote triggered local_apic_timer_interrupt. So the pending bit is already cleared when the switch over to highres mode is clearing the oneshot mask. The solution is simple: Clear the pending bit together with the mask bit when we switch over to highres mode. Stanislaw came up independently with the same patch by enforcing the C1E workaround and debugging the fallout. I picked mine, because mine has a changelog :) Reported-by: poma <[email protected]> Debugged-by: Stanislaw Gruszka <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Olaf Hering <[email protected]> Cc: Dave Jones <[email protected]> Cc: Justin M. Forbes <[email protected]> Cc: Josh Boyer <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] # 3.10+ Signed-off-by: Thomas Gleixner <[email protected]>
2014-02-13net: fix macvtap type name in KconfigJan Luebbe1-1/+1
The netlink kind (and iproute2 type option) is actually called 'macvtap', not 'macvlan'. Signed-off-by: Jan Luebbe <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-02-13hostap: fix "hostap: proc: Use remove_proc_subtree()"Russell King - ARM Linux1-1/+1
remove_proc_subtree() doesn't work here as local->ddev has already been removed, and NULLed out. Use proc_remove() instead. Signed-off-by: Russell King <[email protected]> Tested-by: Russell King <[email protected]> Signed-off-by: John W. Linville <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.