- 24 Apr, 2014 40 commits
-
-
Alexander Stein authored
slc_xmit is called within softirq context and locks sl->lock, but slcan_write_wakeup is not softirq context, so we need to use spin_[un]lock_bh! Detected using kernel lock debugging mechanism. Signed-off-by:
Alexander Stein <alexander.stein@systec-electronic.com> Acked-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
When trying to set a data bitrate on non CAN FD devices the 'ip' tool answers with: RTNETLINK answers: Unknown error 524 Rename '-ENOTSUPP' to '-EOPNOTSUPP' so that 'ip' answers correctly: RTNETLINK answers: Operation not supported Signed-off-by: -
Oliver Hartkopp authored
When accessing the SJA1000 controller registers in the indirect access mode, writing the register number and reading/writing the data has to be an atomic attempt. As the sja1000_isa driver is an old style driver with a fixed number of instances the locking variable depends on the same index like all the other configuration elements given on the module command line. As a positive side effect dev->dev_id is populated by the instance index, which was missing in 3e66d013 ("can: populate netdev::dev_id for udev discrimination"). Reported-by:
-
Wolfgang Grandegger authored
Coverity complains that c_can_pci_probe() calls pci_enable_msi() without checking the result: CID 712278 (#1 of 1): Unchecked return value (CHECKED_RETURN) 3. check_return: Calling pci_enable_msi_block without checking return value (as is done elsewhere 88 out of 105 times). 88 pci_enable_msi(pdev); This is CID 712278. Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Reported-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Wolfram Sang authored
Commit 6439fbce (can: c_can: fix error checking of priv->instance in probe()) found the warning but applied a suboptimal solution. Since, both pdev->id and of_alias_get_id() return integers, it makes sense to convert the variable to an integer and avoid the cast. Signed-off-by:
Wolfram Sang <wsa@sang-engineering.com> Signed-off-by:
-
Thomas Gleixner authored
It's suffcient to kill the TXIE bit in the message control register even if the documentation of C and D CAN says that it's not allowed to do that while MSGVAL is set. Reality tells a different story and this change gives us another 2% of CPU back for not waiting on I/O. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
Thomas Gleixner authored
Mark suggested to use one IF for the softirq and the other for the xmit function to avoid the xmit lock. That requires to write the frame into the interface first, then handle the echo skb and store the dlc before committing the TX request to the message ram. We use an atomic to handle the active buffers instead of reading the MSGVAL register as thats way faster especially on PCH/x86. Suggested-by:
Mark <mark5@del-llc.com> Signed-off-by:
-
Thomas Gleixner authored
Instead of obfuscating the code by artificial 16 bit splits use the proper 32 bit assignments and split the result when writing to the interface. Signed-off-by:
-
Thomas Gleixner authored
Remove the MASK from the TX transfer side. Make the code readable and get rid of the annoying IFX_WRITE_XXX_16BIT macros which are just obfuscating the code. Signed-off-by:
-
Thomas Gleixner authored
Sigh! Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Alexander reported that the new optimized handling of the RX fifo causes random packet loss on Intel PCH C_CAN hardware. After a few fruitless debugging sessions I got hold of a PCH (eg20t) afflicted system. That machine does not have the CAN interface wired up, but it was possible to reproduce the issue with the HW loopback mode. As Alexander observed correctly, clearing the NewDat flag along with reading out the message buffer causes that issue on C_CAN, while D_CAN handles that correctly. Instead of restoring the original message buffer handling horror the following workaround solves the issue: transfer buffer to IF without clearing the NewDat handle the message clear NewDat bit That's similar to the original code but conditional for C_CAN. I really wonder why all user manuals (C_CAN, Intel PCH and some more) recommend to clear the NewDat bit right away. The knows it all Oracle operated by Gurgle does not unearth any useful information either. I simply cannot believe that we are the first to uncover that HW issue. Reported-and-tested-by: -
Thomas Gleixner authored
The RX buffer split causes packet loss in the hardware: What happens is: RX Packet 1 --> message buffer 1 (newdat bit is not cleared) RX Packet 2 --> message buffer 2 (newdat bit is not cleared) RX Packet 3 --> message buffer 3 (newdat bit is not cleared) RX Packet 4 --> message buffer 4 (newdat bit is not cleared) RX Packet 5 --> message buffer 5 (newdat bit is not cleared) RX Packet 6 --> message buffer 6 (newdat bit is not cleared) RX Packet 7 --> message buffer 7 (newdat bit is not cleared) RX Packet 8 --> message buffer 8 (newdat bit is not cleared) Clear newdat bit in message buffer 1 Clear newdat bit in message buffer 2 Clear newdat bit in message buffer 3 Clear newdat bit in message buffer 4 Clear newdat bit in message buffer 5 Clear newdat bit in message buffer 6 Clear newdat bit in message buffer 7 Clear newdat bit in message buffer 8 Now if during that clearing of newdat bits, a new message comes in, the HW gets confused and drops it. It does not matter how many of them you clear. I put a delay between clear of buffer 1 and buffer 2 which was long enough that the message should have been queued either in buffer 1 or buffer 9. But it did not show up anywhere. The next message ended up in buffer 1. So the hardware lost a packet of course without telling it via one of the error handlers. That does not happen on all clear newdat bit events. I see one of 10k packets dropped in the scenario which allows us to reproduce. But the trace looks always the same. Not splitting the RX Buffer avoids the packet loss but can cause reordering. It's hard to trigger, but it CAN happen. With that mode we use the HW as it was probably designed for. We read from the buffer 1 upwards and clear the buffer as we get the message. That's how all microcontrollers use it. So I assume that the way we handle the buffers was never really tested. According to the public documentation it should just work :) Let the user decide which evil is the lesser one. [ Oliver Hartkopp: Provided a sane config option and help text and made me switch to favour potential and unlikely reordering over packet loss ] Signed-off-by:
-
Thomas Gleixner authored
The driver handles pointlessly TWO interrupts per packet. The reason is that it enables the status interrupt which fires for each rx and tx packet and it enables the per message object interrupts as well. The status interrupt merily acks or in case of D_CAN ignores the TX/RX state and then the message object interrupt fires. The message objects interrupts are only useful if all message objects have hardware filters activated. But we don't have that and its not simple to implement in that driver without rewriting it completely. So we can ditch the message object interrupts and handle the RX/TX right away from the status interrupt. Instead of TWO we handle ONE. Note: We must keep the TXIE/RXIE bits in the message buffers because the status interrupt alone is not reliable enough in corner cases. If we ever have the need for HW filtering, then this code needs a complete overhaul and we can think about it then. For now we prefer a lower interrupt load. Signed-off-by:
-
Thomas Gleixner authored
On D_CAN the RXOK, TXOK and LEC bits are cleared/set on read of the status register. No need to update them. Signed-off-by:
-
Thomas Gleixner authored
Instead of writing to the message object we can simply clear the NewDat bit with the get method. Signed-off-by:
-
Thomas Gleixner authored
If the allocation of the error skb fails, we still want to see the error statistics. Signed-off-by:
-
Thomas Gleixner authored
Reading the LEC type with return (mode & ENABLED) && (status & LEC_MASK); is not guaranteed to return (status & LEC_MASK) if the enabled bit in mode is set. It's guaranteed to return 0 or !=0. Remove the inline function and call unconditionally into the berr_handling code and return early when the reporting is disabled. Signed-off-by:
-
Thomas Gleixner authored
If the allocation of an error skb fails, the state change handling returns w/o doing any work. That leaves the interface in a wreckaged state as the internal status is wrong. Split the interface handling and the skb handling. Signed-off-by:
-
Thomas Gleixner authored
There is no guarantee that the skb is in the same state after calling net_receive_skb(). 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. The whole can subsystem is full of this. Copy and paste .... Signed-off-by:
-
Thomas Gleixner authored
The state change handler is called with device interrupts disabled already. So no point in disabling them again when we enter bus off state. But what's worse is that we reenable the interrupts at the end of NAPI poll unconditionally. So c_can_start() which is called from the restart timer can trigger interrupts which confuse the hell out of the half reinitialized driver/hw. Remove the pointless device interrupt disable in the BUS_OFF handler and prevent reenabling the device interrupts at the end of the poll routine when the current state is BUS_OFF. Signed-off-by:
-
Thomas Gleixner authored
c_can_start() enables interrupts way too early. The first enabling happens when setting the control mode in c_can_chip_config() and then again at the end of the function. But that happens before napi_enable() and that means that an interrupt which comes in will disable interrupts again and call napi_schedule, which ignores the request and the later napi_enable() is not making thinks work either. So the interface is up with all device interrupts disabled. Move the device interrupt after napi_enable() and add it to the other callsites of c_can_start() in c_can_set_mode() and c_can_power_up() Signed-off-by:
-
Thomas Gleixner authored
All type checks in c_can.c are != BOSCH_D_CAN so nobody noticed so far that the pci code does not update the type information. Signed-off-by:
-
David S. Miller authored
net/netfilter/nfnetlink.c: In function ‘nfnetlink_rcv’: net/netfilter/nfnetlink.c:371:14: warning: unused variable ‘net’ [-Wunused-variable] Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Eric W. Biederman says: ==================== netlink: Preventing abuse when passing file descriptors. Andy Lutomirski when looking at the networking stack noticed that it is possible to trick privilged processes into calling write on a netlink socket and send netlink messages they did not intend. In particular from time to time there are suid applications that will write to stdout or stderr without checking exactly what kind of file descriptors those are and can be tricked into acting as a limited form of suid cat. In other conversations the magic string CVE-2014-0181 has been used to talk about this issue. This patchset cleans things up a bit, adds some clean abstractions that when used prevent this kind of problem and then finally changes all of the handlers of netlink messages that I could find that call capable to use netlink_ns_capable or an appropriate wrapper. The abstraction netlink_ns_capable verifies that the original creator of the netlink socket a message is sent from had the necessary capabilities as well as verifying that the current sender of a netlink packet has the necessary capabilities. The idea is to prevent file descriptor passing of any form from resulting in a file descriptor that can do more than it can for the creator of the file descriptor. ==================== Signed-off-by: -
Eric W. Biederman authored
It is possible by passing a netlink socket to a more privileged executable and then to fool that executable into writing to the socket data that happens to be valid netlink message to do something that privileged executable did not intend to do. To keep this from happening replace bare capable and ns_capable calls with netlink_capable, netlink_net_calls and netlink_ns_capable calls. Which act the same as the previous calls except they verify that the opener of the socket had the desired permissions as well. Reported-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
netlink_net_capable - The common case use, for operations that are safe on a network namespace netlink_capable - For operations that are only known to be safe for the global root netlink_ns_capable - The general case of capable used to handle special cases __netlink_ns_capable - Same as netlink_ns_capable except taking a netlink_skb_parms instead of the skbuff of a netlink message. Signed-off-by:
-
Eric W. Biederman authored
sk_net_capable - The common case, operations that are safe in a network namespace. sk_capable - Operations that are not known to be safe in a network namespace sk_ns_capable - The general case for special cases. Signed-off-by:
-
Eric W. Biederman authored
The permission check in sock_diag_put_filterinfo is wrong, and it is so removed from it's sources it is not clear why it is wrong. Move the computation into packet_diag_dump and pass a bool of the result into sock_diag_filterinfo. This does not yet correct the capability check but instead simply moves it to make it clear what is going on. Reported-by:
-
Eric W. Biederman authored
netlink_capable is a static internal function in af_netlink.c and we have better uses for the name netlink_capable. Signed-off-by:
-
Claudiu Manoil authored
This fixes a seg fault on 'ethtool -A' entry if the interface is down. Obviously we need to have the phy device initialized / "connected" (see of_phy_connect()) to be able to advertise pause frame capabilities. Fixes: 23402bddSigned-off-by:
Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by:
-
David S. Miller authored
Shahed Shaikh says: ==================== qlcnic: Bug fixes This patch series contains following fixes - * Fix memory leak caused because of issuing mailbox command which can not wait for its completion. * Reset firmware API lock which might be in inconsistent state. ==================== Signed-off-by: -
Rajesh Borundia authored
o In case QLC_83XX_MBX_CMD_NO_WAIT command type the calling function does not free the memory as it does not wait for response. So free it when get a response from adapter after sending the command. Signed-off-by:
Rajesh Borundia <rajesh.borundia@qlogic.com> Signed-off-by:
Shahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by:
-
Sony Chacko authored
Some firmware versions fails to reset the lock during initialization. Force reset firmware API lock during driver probe to ensure lock availability. Signed-off-by:
Sony Chacko <sony.chacko@qlogic.com> Signed-off-by:
-
Jiri Pirko authored
There are two breaks missing there. The result is that userspace receives multiple messages which might be confusing. Introduced-by: 3d249d4c "net: introduce ethernet teaming device" Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Jean Delvare authored
I was told that the Cadence macb driver is also useful on Microblaze. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: David S. Miller <davem@davemloft.net> Cc: Michal Simek <monstr@monstr.eu> Cc: Mark Brown <broonie@kernel.org> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Zi Shen Lim authored
Redefine some macros that were conditioned upon SMC_DEBUG level. By allowing compiler to verify parameters used by these macros unconditionally, we can flag compilation failures. Compiler will still optimize out the unused code path depending on SMC_DEBUG, so this is a net gain. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Zi Shen Lim <zlim.lnx@gmail.com> Signed-off-by:
-
