- 21 7月, 2015 11 次提交
-
-
由 Joachim Eastwood 提交于
Commit 803f8fc4 ("stmmac: move driver data setting into stmmac_dvr_probe") mistakenly set priv and not priv->dev as driver data. This meant that the remove, resume and suspend callbacks that fetched and tried to use this data would most likely explode. Fix the issue by using the correct variable. Fixes: 803f8fc4 ("stmmac: move driver data setting into stmmac_dvr_probe") Signed-off-by: NJoachim Eastwood <manabian@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Shaohui Xie 提交于
We store c45 PHY's id information in c45_ids, so it should be used to check the matching between PHY driver and PHY device for c45 PHY. Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Reinhard Speyerer 提交于
Sierra Wireless MC7305/MC7355 with USB ID 1199:9041 also provide a second QMI/network interface like the MC73xx with USB ID 1199:68c0 on USB interface #10 when used in the appropriate USB configuration. Add the corresponding QMI_FIXED_INTF entry to the qmi_wwan driver. Please note that the second QMI/network interface is not working for early MC73xx firmware versions like 01.08.x as the device does not respond to QMI messages on the second /dev/cdc-wdm port. Signed-off-by: NReinhard Speyerer <rspmn@arcor.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sergei Shtylyov 提交于
The TCCR.TSRQn bit may get clearead after TCCR gets read, so that TCCR write would get skipped. We don't need to check this bit before setting. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Karicheri, Muralidharan 提交于
The keystone qmss will raise interrupt when packet arrive at the receive queue. Only control available to avoid interrupt from happening is to keep the free descriptor queue (FDQ) empty in the receive side. So the filling of descriptors into the FDQ has to happen after request_irq() call is made as part of knav_queue_enable_notify(). So move the function netcp_rxpool_refill() after this call. Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 dingtianhong 提交于
The "follow" fail_over_mac policy is useful for multiport devices that either become confused or incur a performance penalty when multiple ports are programmed with the same MAC address, but the same MAC address still may happened by this steps for this policy: 1) echo +eth0 > /sys/class/net/bond0/bonding/slaves bond0 has the same mac address with eth0, it is MAC1. 2) echo +eth1 > /sys/class/net/bond0/bonding/slaves eth1 is backup, eth1 has MAC2. 3) ifconfig eth0 down eth1 became active slave, bond will swap MAC for eth0 and eth1, so eth1 has MAC1, and eth0 has MAC2. 4) ifconfig eth1 down there is no active slave, and eth1 still has MAC1, eth2 has MAC2. 5) ifconfig eth0 up the eth0 became active slave again, the bond set eth0 to MAC1. Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same MAC address, it will break this policy for ACTIVE_BACKUP mode. This patch will fix this problem by finding the old active slave and swap them MAC address before change active slave. Signed-off-by: NDing Tianhong <dingtianhong@huawei.com> Tested-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Florian Fainelli 提交于
7445E0 contains an ECO which disconnected the internal SF2 pseudo-PHY which was known to conflict with the external pseudo-PHY of BCM53125 switches. This motivated the need to utilize the internal SF2 MDIO controller via indirect register reads/writes to control external Broadcom switches due to this address conflict (both responded at address 30d). For 7445E0, the internal pseudo-PHY of the SF2 switch got disconnected, and as a consequence this prevents the internal SF2 MDIO bus controller from reading data (reads back everything as 0) since the MDI line is tied low. Fix this by making the indirect register reads and writes conditional to 7445D0, on 7445E0 we can utilize the SWITCH_MDIO controller (backed by mdio-unimac and not the DSA created slave MII bus). We utilize of_machine_is_compatible() here since this is the only way for use to differentiate between these two chips in a way that does not violate layers or becomes (too) vendor-specific. Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nikolay Aleksandrov 提交于
If the bond is enslaving a device with different type it will be setup by it, but if after being setup the enslave fails the bond doesn't switch back its type and also keeps pointers to foreign structures that can be long gone. Thus revert back any type changes if the enslave failed and the bond had to change its type. Example: Before patch: $ echo lo > bond0/bonding/slaves -bash: echo: write error: Cannot assign requested address $ ip l sh bond0 20: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/loopback 16:54:78:34:bd:41 brd 00:00:00:00:00:00 $ echo +eth1 > bond0/bonding/slaves $ ip l sh bond0 20: bond0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff (notice the MASTER flag is gone) After patch: $ echo lo > bond0/bonding/slaves -bash: echo: write error: Cannot assign requested address $ ip l sh bond0 21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 6e:66:94:f6:07:fc brd ff:ff:ff:ff:ff:ff $ echo +eth1 > bond0/bonding/slaves $ ip l sh bond0 21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com> Fixes: e36b9d16 ("bonding: clean muticast addresses when device changes type") Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nikolay Aleksandrov 提交于
When the bonding is being unloaded and the netdevice notifier is unregistered it executes NETDEV_UNREGISTER for each device which should remove the bond's proc entry but if the device enslaved is not of ARPHRD_ETHER type and is in front of the bonding, it may execute bond_release_and_destroy() first which would release the last slave and destroy the bond device leaving the proc entry and thus we will get the following error (with dynamic debug on for bond_netdev_event to see the events order): [ 908.963051] eql: event: 9 [ 908.963052] eql: IFF_SLAVE [ 908.963054] eql: event: 2 [ 908.963056] eql: IFF_SLAVE [ 908.963058] eql: event: 6 [ 908.963059] eql: IFF_SLAVE [ 908.963110] bond0: Releasing active interface eql [ 908.976168] bond0: Destroying bond bond0 [ 908.976266] bond0 (unregistering): Released all slaves [ 908.984097] ------------[ cut here ]------------ [ 908.984107] WARNING: CPU: 0 PID: 1787 at fs/proc/generic.c:575 remove_proc_entry+0x112/0x160() [ 908.984110] remove_proc_entry: removing non-empty directory 'net/bonding', leaking at least 'bond0' [ 908.984111] Modules linked in: bonding(-) eql(O) 9p nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev qxl drm_kms_helper snd_hda_codec_generic aesni_intel ttm aes_x86_64 glue_helper pcspkr lrw gf128mul ablk_helper cryptd snd_hda_intel virtio_console snd_hda_codec psmouse serio_raw snd_hwdep snd_hda_core 9pnet_virtio 9pnet evdev joydev drm virtio_balloon snd_pcm snd_timer snd soundcore i2c_piix4 i2c_core pvpanic acpi_cpufreq parport_pc parport processor thermal_sys button autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sr_mod cdrom ata_generic virtio_blk virtio_net floppy ata_piix e1000 libata ehci_pci virtio_pci scsi_mod uhci_hcd ehci_hcd virtio_ring virtio usbcore usb_common [last unloaded: bonding] [ 908.984168] CPU: 0 PID: 1787 Comm: rmmod Tainted: G W O 4.2.0-rc2+ #8 [ 908.984170] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 908.984172] 0000000000000000 ffffffff81732d41 ffffffff81525b34 ffff8800358dfda8 [ 908.984175] ffffffff8106c521 ffff88003595af78 ffff88003595af40 ffff88003e3a4280 [ 908.984178] ffffffffa058d040 0000000000000000 ffffffff8106c59a ffffffff8172ebd0 [ 908.984181] Call Trace: [ 908.984188] [<ffffffff81525b34>] ? dump_stack+0x40/0x50 [ 908.984193] [<ffffffff8106c521>] ? warn_slowpath_common+0x81/0xb0 [ 908.984196] [<ffffffff8106c59a>] ? warn_slowpath_fmt+0x4a/0x50 [ 908.984199] [<ffffffff81218352>] ? remove_proc_entry+0x112/0x160 [ 908.984205] [<ffffffffa05850e6>] ? bond_destroy_proc_dir+0x26/0x30 [bonding] [ 908.984208] [<ffffffffa057540e>] ? bond_net_exit+0x8e/0xa0 [bonding] [ 908.984217] [<ffffffff8142f407>] ? ops_exit_list.isra.4+0x37/0x70 [ 908.984225] [<ffffffff8142f52d>] ? unregister_pernet_operations+0x8d/0xd0 [ 908.984228] [<ffffffff8142f58d>] ? unregister_pernet_subsys+0x1d/0x30 [ 908.984232] [<ffffffffa0585269>] ? bonding_exit+0x23/0xdba [bonding] [ 908.984236] [<ffffffff810e28ba>] ? SyS_delete_module+0x18a/0x250 [ 908.984241] [<ffffffff81086f99>] ? task_work_run+0x89/0xc0 [ 908.984244] [<ffffffff8152b732>] ? entry_SYSCALL_64_fastpath+0x16/0x75 [ 908.984247] ---[ end trace 7c006ed4abbef24b ]--- Thus remove the proc entry manually if bond_release_and_destroy() is used. Because of the checks in bond_remove_proc_entry() it's not a problem for a bond device to change namespaces (the bug fixed by the Fixes commit) but since commit f9399814 ("bonding: Don't allow bond devices to change network namespaces.") that can't happen anyway. Reported-by: NCarol Soto <clsoto@linux.vnet.ibm.com> Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com> Fixes: a64d49c3 ("bonding: Manage /proc/net/bonding/ entries from the netdev events") Tested-by: NCarol L Soto <clsoto@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vivien Didelot 提交于
The mv88e6xxx_priv_state structure contains an fid_mask, where 1 means the FID is free to use, 0 means the FID is in use. This patch fixes the bit clear in mv88e6xxx_leave_bridge() when assigning a new FID to a port. Example scenario: I have 7 ports, port 5 is CPU, port 6 is unused (no PHY). After setting the ports 0, 1 and 2 in bridge br0, and ports 3 and 4 in bridge br1, I have the following fid_mask: 0b111110010110 (0xf96). Indeed, br0 uses FID 0, and br1 uses FID 3. After setting nomaster for port 0, I get the wrong fid_mask: 0b10 (0x2). With this patch we correctly get 0b111110010100 (0xf94), meaning port 0 uses FID 1, br0 uses FID 0, and br1 uses FID 3. Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael S. Tsirkin 提交于
ANY_LAYOUT is a compatibility feature. It's implied for VERSION_1 devices, and non-transitional devices might not offer it. Change code to behave accordingly. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 7月, 2015 1 次提交
-
-
由 Sergei Shtylyov 提交于
First, dma_sync_single_for_cpu() shouldn't have been called in the first place (it's a streaming DMA API), dma_unmap_single() should have been called instead. Second, dma_unmap_single() call after handing the buffer to napi_gro_receive() makes little sense. Moreover desc->dptr might not be valid at this point. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 7月, 2015 10 次提交
-
-
由 Stefan Agner 提交于
The regulators power and transceiver are optional. If those are not present, the pointer (or error pointer) is correctly handled by the driver, hence we can use devm_regulator_get_optional safely, which avoids regulators getting created. Signed-off-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Stefan Agner 提交于
If a valid power regulator or a dummy regulator is used (which happens to be the case when no regulator is specified), restart_work is queued no matter whether the device was running or not at suspend time. Since work queues get initialized in the ndo_open callback, resuming leads to a NULL pointer exception. Reverse exactly the steps executed at suspend time: - Enable the power regulator in any case - Enable the transceiver regulator if the device was running, even in case we have a power regulator - Queue restart_work only in case the device was running Fixes: bf66f373 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: NStefan Agner <stefan@agner.ch> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Konstantin Khlebnikov 提交于
Inet6addr notifier is atomic and runs in bh context without RTNL when ipv6 receives router advertisement packet and performs autoconfiguration. Proper fix still in discussion. Let's at least plug the bug. v1: http://lkml.kernel.org/r/20150514135618.14062.1969.stgit@buzz v2: http://lkml.kernel.org/r/20150703125840.24121.91556.stgit@buzzSigned-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 WANG Cong 提交于
In tx path rcu_read_lock_bh() is held, so we need rcu_deference_bh(). This fixes the following warning: =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc1+ #1007 Not tainted ------------------------------- drivers/net/ipvlan/ipvlan.h:106 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by dhclient/1076: #0: (rcu_read_lock_bh){......}, at: [<ffffffff817e8d84>] rcu_lock_acquire+0x0/0x26 stack backtrace: CPU: 2 PID: 1076 Comm: dhclient Not tainted 4.1.0-rc1+ #1007 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff8800d381bac8 ffffffff81a4154f 000000003c1a3c19 ffff8800d4d0a690 ffff8800d381baf8 ffffffff810b849f ffff880117d41148 ffff880117d40000 ffff880117d40068 0000000000000156 ffff8800d381bb18 Call Trace: [<ffffffff81a4154f>] dump_stack+0x4c/0x65 [<ffffffff810b849f>] lockdep_rcu_suspicious+0x107/0x110 [<ffffffff8165a522>] ipvlan_port_get_rcu+0x47/0x4e [<ffffffff8165ad14>] ipvlan_queue_xmit+0x35/0x450 [<ffffffff817ea45d>] ? rcu_read_unlock+0x3e/0x5f [<ffffffff810a20bf>] ? local_clock+0x19/0x22 [<ffffffff810b4781>] ? __lock_is_held+0x39/0x52 [<ffffffff8165b64c>] ipvlan_start_xmit+0x1b/0x44 [<ffffffff817edf7f>] dev_hard_start_xmit+0x2ae/0x467 [<ffffffff817ee642>] __dev_queue_xmit+0x50a/0x60c [<ffffffff817ee7a7>] dev_queue_xmit_sk+0x13/0x15 [<ffffffff81997596>] dev_queue_xmit+0x10/0x12 [<ffffffff8199b41c>] packet_sendmsg+0xb6b/0xbdf [<ffffffff810b5ea7>] ? mark_lock+0x2e/0x226 [<ffffffff810a1fcc>] ? sched_clock_cpu+0x9e/0xb7 [<ffffffff817d56f9>] sock_sendmsg_nosec+0x12/0x1d [<ffffffff817d7257>] sock_sendmsg+0x29/0x2e [<ffffffff817d72cc>] sock_write_iter+0x70/0x91 [<ffffffff81199563>] __vfs_write+0x7e/0xa7 [<ffffffff811996bc>] vfs_write+0x92/0xe8 [<ffffffff811997d7>] SyS_write+0x47/0x7e [<ffffffff81a4d517>] system_call_fastpath+0x12/0x6f Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.") Cc: Mahesh Bandewar <maheshb@google.com> Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com> Acked-by: NMahesh Bandewar <maheshb@google.com> Acked-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Konstantin Khlebnikov 提交于
All structures used in traffic forwarding are rcu-protected: ipvl_addr, ipvl_dev and ipvl_port. Thus we can unhash addresses without synchronization. We'll anyway hash it back into the same bucket: in worst case lockless lookup will scan hash once again. Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Konstantin Khlebnikov 提交于
Add missing kfree_rcu(addr, rcu); Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Konstantin Khlebnikov 提交于
They are unused after commit f631c44b ("ipvlan: Always set broadcast bit in multicast filter"). Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tilman Schmidt 提交于
The line discipline read and write methods are optional so the dummy methods in ser_gigaset are unnecessary and can be removed. Signed-off-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tilman Schmidt 提交于
Commit 79901317 ("n_tty: Don't flush buffer when closing ldisc"), first merged in kernel release 3.10, caused the following regression in the Gigaset M101 driver: Before that commit, when closing the N_TTY line discipline in preparation to switching to N_GIGASET_M101, receive_room would be reset to a non-zero value by the call to n_tty_flush_buffer() in n_tty's close method. With the removal of that call, receive_room might be left at zero, blocking data reception on the serial line. The present patch fixes that regression by setting receive_room to an appropriate value in the ldisc open method. Fixes: 79901317 ("n_tty: Don't flush buffer when closing ldisc") Signed-off-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Fabio Estevam 提交于
This reverts commit 6c3e921b. commit 6c3e921b ("net: fec: Ensure clocks are enabled while using mdio bus") prevents the kernel to boot on mx6 boards, so let's revert it. Reported-by: NTyler Baker <tyler.baker@linaro.org> Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 15 7月, 2015 14 次提交
-
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Bernd Krumboeck <b.krumboeck@gmail.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Thomas Körper <thomas.koerper@esd.eu> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Anant Gole <anantgole@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Andreas Larsson <andreas@gaisler.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Cc: Aaron Wu <Aaron.wu@analog.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Marc Kleine-Budde 提交于
There is no guarantee that the skb is in the same state after calling net_receive_skb() or netif_rx(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Dan Carpenter 提交于
The > should be >=. I also added spaces around the '-' operations so the code is a little more consistent and matches the condition better. Fixes: f53c3fe8 ('xen-netback: Introduce TX grant mapping') Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Chris Mason 提交于
Commit 1c8ba6d0 moved around the setup code for broadcomm chips, and also added btbcm_read_verbose_config() to read extra information about the hardware. It's returning errors on some macbooks: Bluetooth: hci0: BCM: Read verbose config info failed (-16) Which makes us error out of the setup function. Since this probe isn't critical to operate the chip, this patch just changes things to carry on when it fails. Signed-off-by: NChris Mason <clm@fb.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # v4.1
-
- 13 7月, 2015 4 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit dec4f799. Jörg Otte reports a NULL pointder dereference due to this commit, as 'crtc_state' very much can be NULL: crtc_state = state->base.state ? intel_atomic_get_crtc_state(state->base.state, intel_crtc) : NULL; So the change to test 'crtc_state->base.active' cannot possibly be correct as-is. There may be some other minimal fix (like just checking crtc_state for NULL), but I'm just reverting it now for the rc2 release, and people like Daniel Vetter who actually know this code will figure out what the right solution is in the longer term. Reported-and-bisected-by: NJörg Otte <jrg.otte@gmail.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Oliver Hartkopp 提交于
Commit 514ac99c "can: fix multiple delivery of a single CAN frame for overlapping CAN filters" requires the skb->tstamp to be set to check for identical CAN skbs. Without timestamping to be required by user space applications this timestamp was not generated which lead to commit 36c01245 "can: fix loss of CAN frames in raw_rcv" - which forces the timestamp to be set in all CAN related skbuffs by introducing several __net_timestamp() calls. This forces e.g. out of tree drivers which are not using alloc_can{,fd}_skb() to add __net_timestamp() after skbuff creation to prevent the frame loss fixed in mainline Linux. This patch removes the timestamp dependency and uses an atomic counter to create an unique identifier together with the skbuff pointer. Btw: the new skbcnt element introduced in struct can_skb_priv has to be initialized with zero in out-of-tree drivers which are not using alloc_can{,fd}_skb() too. Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 J.D. Schroeder 提交于
The previous change 3973c526 (net: can: c_can: Disable pins when CAN interface is down) causes a slight glitch on the pinctrl settings when used. Since commit ab78029e (drivers/pinctrl: grab default handles from device core), the device core will automatically set the default pins. This causes the pins to be momentarily set to the default and then to the sleep state in register_c_can_dev(). By adding an optional "enable" state, boards can set the default pin state to be disabled and avoid the glitch when the switch from default to sleep first occurs. If the "enable" state is not available c_can_pinctrl_select_state() falls back to using the "default" pinctrl state. [Roger Q] - Forward port to v4.2 and use pinctrl_get_select(). Signed-off-by: NJ.D. Schroeder <jay.schroeder@garmin.com> Signed-off-by: NRoger Quadros <rogerq@ti.com> Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Sergei Shtylyov 提交于
All the error messages in the driver but the ones from devm_clk_get() failures use similar format. Make those two messages consitent with others. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-