- 04 Feb, 2015 16 commits
-
-
Al Viro authored
just advance the msg.msg_iter and be done with that. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: kvm@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Cc: Michael S. Tsirkin <mst@redhat.com> Cc: kvm@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
With that, all ->sendmsg() instances are converted to iov_iter primitives and are agnostic wrt the kind of iov_iter they are working with. So's the last remaining ->recvmsg() instance that wasn't kind-agnostic yet. All ->sendmsg() and ->recvmsg() advance ->msg_iter by the amount actually copied and none of them modifies the underlying iovec, etc. Cc: linux-crypto@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
This one needs to copy the same data from user potentially more than once. Sadly, MTU changes can trigger that ;-/ Cc: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
That takes care of the majority of ->sendmsg() instances - most of them via memcpy_to_msg() or assorted getfrag() callbacks. One place where we still keep memcpy_fromiovecend() is tipc - there we potentially read the same data over and over; separate patch, that... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
patch is actually smaller than it seems to be - most of it is unindenting the inner loop body in tcp_sendmsg() itself... the bit in tcp_input.c is going to get reverted very soon - that's what memcpy_from_msg() will become, but not in this commit; let's keep it reasonably contained... There's one potentially subtle change here: in case of short copy from userland, mainline tcp_send_syn_data() discards the skb it has allocated and falls back to normal path, where we'll send as much as possible after rereading the same data again. This patch trims SYN+data skb instead - that way we don't need to copy from the same place twice. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
... instead of storing its ->mgs_iter.iov there Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Use iov_iter_kvec() there, get rid of set_fs() games - now that rxrpc_send_data() uses iov_iter primitives, it'll handle ITER_KVEC just fine. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Convert skb_add_data() to iov_iter; allows to get rid of the explicit messing with iovec in its only caller - skb_add_data() will keep advancing ->msg_iter for us, so there's no need to similate that manually. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Switch from passing msg->iov_iter.iov to passing msg itself Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Switch from passing msg->iov_iter.iov to passing msg itself Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Switch from passing msg->iov_iter.iov to passing msg itself Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
As it is, zero msg_iovlen means that the first iovec in the kernel array of iovecs is left uninitialized, so checking if its ->iov_base is NULL is random. Since the real users of that thing are doing sendto(fd, NULL, 0, ...), they are getting msg_iovlen = 1 and msg_iov[0] = {NULL, 0}, which is what this test is trying to catch. As suggested by davem, let's just check that msg_iovlen was 1 and msg_iov[0].iov_base was NULL - _that_ is well-defined and it catches what we want to catch. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
- 29 Jan, 2015 10 commits
-
-
David S. Miller authored
Merge tag 'linux-can-next-for-3.20-20150128' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2015-28-01 this is a pull request of 12 patches for net-next/master. There are 3 patches by Ahmed S. Darwish, which update the kvaser_usb driver and add support for the USBcan-II based adapters. Stéphane Grosjean contributes 7 patches for the peak_usb driver, which add support for the CANFD USB adapters. I contribute 2 patches which clean up the peak_usb driver structure a bit. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kevin Hao authored
Since commit cd1e6504 ("of/device: Don't register disabled devices"), the disabled device will not be registered at all. So we don't need to do the check again in the platform device driver. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salam Noureddine authored
When many pf_packet listeners are created on a lot of interfaces the current implementation using global packet type lists scales poorly. This patch adds per net_device packet type lists to fix this problem. The patch was originally written by Eric Biederman for linux-2.6.29. Tested on linux-3.16. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Salam Noureddine <noureddine@arista.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nicolas Dichtel authored
When IFLA_LINK_NETNSID is used, the netdevice should be built in this link netns and moved at the end to another netns (pointed by the socket netns or IFLA_NET_NS_[PID|FD]). Existing user of the newlink handler will use the netns argument (src_net) to find a link netdevice or to check some other information into the link netns. For example, to find a netdevice, two information are required: an ifindex (usually from IFLA_LINK) and a netns (this link netns). Note: when using IFLA_LINK_NETNSID and IFLA_NET_NS_[PID|FD], a user may create a netdevice that stands in netnsX and with its link part in netnsY, by sending a rtnl message from netnsZ. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
TIME_WAIT sockets are not owning any skb. ip_send_unicast_reply() and tcp_v6_send_response() both use regular sockets. We can safely remove a test in sch_fq and save one cache line miss, as sk_state is far away from sk_pacing_rate. Tested at Google for about one year. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
NET_ACT_CONNMARK fails to build if NF_CONNTRACK_MARK is disabled, and d7924450 ("act_connmark: Add missing dependency on NF_CONNTRACK_MARK") fixed that case, but missed the cased where NF_CONNTRACK is a loadable module. This adds the second dependency to ensure that NET_ACT_CONNMARK can only be built-in if NF_CONNTRACK is also part of the kernel rather than a loadable module. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Christoph Hellwig authored
The sock_iocb structure is allocate on stack for each read/write-like operation on sockets, and contains various fields of which only the embedded msghdr and sometimes a pointer to the scm_cookie is ever used. Get rid of the sock_iocb and put a msghdr directly on the stack and pass the scm_cookie explicitly to netlink_mmap_sendmsg. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
The if block was supposed to have curly braces. In the current code we complain about dropped rx packets when we shouldn't. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jesse Gross authored
Currently, it isn't possible to request checksums on the outer UDP header of tunnels - the TUNNEL_CSUM flag is ignored. This adds support for requesting that UDP checksums be computed on transmit and properly reported if they are present on receive. Signed-off-by: Jesse Gross <jesse@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-nextDavid S. Miller authored
NFC: 3.20 first pull request This is the first NFC pull request for 3.20. With this one we have: - Secure element support for the ST Micro st21nfca driver. This depends on a few HCI internal changes in order for example to support more than one secure element per controller. - ACPI support for NXP's pn544 HCI driver. This controller is found on many x86 SoCs and is typically enumerated on the ACPI bus there. - A few st21nfca and st21nfcb fixes. Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 28 Jan, 2015 14 commits
-
-
Stephane Grosjean authored
Add support for the following new PEAK-System technik CANFD USB adapters: PCAN-USB FD single CANFD channel USB adapter PCAN-USB Pro FD dual CANFD channels USB adapter Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Acked-by: Andri Yngvason <andri.yngvason@marel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Stephane Grosjean authored
Add a common function that pushes the skb in the network queue with adding timestamps information, converted from time values read from the PEAK USB adapters. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Stephane Grosjean authored
Add support for the following new PEAK-System technik CANFD USB adapters: PCAN-USB FD single CANFD channel USB adapter PCAN-USB Pro FD dual CANFD channels USB adapter The communication protocol has been developed using some mechanisms that did exist in the PCAN-USB Pro, thus, this patch also changes some previously static functions and data into global ones. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Stephane Grosjean authored
Upgrade PEAK-System USB adapters core to the new data structures (names) and callbacks added for the support of the CANFD extension. This specific patch includes changes that deal with the new struct canfd_frame. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Stephane Grosjean authored
Upgrade PEAK-System USB adapters core to the new data structures (names) and callbacks added for the support of the CANFD extension. This specific patch does the mandatory changes to support new data bittiming specs. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Stephane Grosjean authored
Add the definition of a new callback that enable any PEAK-System CAN USB adapter to grant read access to its Bus Error Counters value. This ability is not supported by all the PEAK-System adapters, thus, for those, the callback pointer will be initiaized to NULL, which is correct regarding the linux-can device driver specs. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Stephane Grosjean authored
Export the ctrlmode_supported value from the core file to each adapter specific file. This has been mandatory for supporting the new CANFD extension. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
A "struct peak_usb_adapter" describes a certain USB adapter, as this doesn't change during runtime, this patch marks all USB adapter definitions as const. Acked-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch converts the list "static struct peak_usb_adapter *peak_usb_adapters_list[]" to be used with ARRAY_SIZE not with a NULL termination, as the size is known during compile time. Acked-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Ahmed S. Darwish authored
CAN to USB interfaces sold by the Swedish manufacturer Kvaser are divided into two major families: 'Leaf', and 'USBcanII'. From an Operating System perspective, the firmware of both families behave in a not too drastically different fashion. This patch adds support for the USBcanII family of devices to the current Kvaser Leaf-only driver. CAN frames sending, receiving, and error handling paths has been tested using the dual-channel "Kvaser USBcan II HS/LS" dongle. It should also work nicely with other products in the same category. List of new devices supported by this driver update: - Kvaser USBcan II HS/HS - Kvaser USBcan II HS/LS - Kvaser USBcan Rugged ("USBcan Rev B") - Kvaser Memorator HS/HS - Kvaser Memorator HS/LS - Scania VCI2 (if you have the Kvaser logo on top) Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Acked-by: Andri Yngvason <andri.yngvason@marel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Ahmed S. Darwish authored
Replace most of the can interface's state and error counters handling with the new can-dev can_change_state() mechanism. Suggested-by: Andri Yngvason <andri.yngvason@marel.com> Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Acked-by: Andri Yngvason <andri.yngvason@marel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Ahmed S. Darwish authored
Update all of the can interface's state and error counters before trying any skb allocation that can actually fail with -ENOMEM. Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com> Acked-by: Andri Yngvason <andri.yngvason@marel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
David S. Miller authored
Andy Shevchenko says: ==================== stmmac: Enable Intel Quark SoC X1000 Ethernet support This is third version of the patch series [1] to bring network card support to Intel Quark SoC. The series has been tested on Intel Galileo board. Changelog v3: - rebase on top of recent net-next - rework an approach to get the custom configuration - rework an approach how to get unique bus_id - improve DMI lookup function [1] http://www.spinics.net/lists/netdev/msg296010.html ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kweh, Hock Leong authored
In Intel Quark SoC X1000, both of the Ethernet controllers support MSI interrupt handling. This patch enables them to use MSI interrupt servicing in stmmac_pci for Intel Quark X1000. Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-