aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2019-11-15bpf: Add bpf_arch_text_poke() helperAlexei Starovoitov1-0/+8
Add bpf_arch_text_poke() helper that is used by BPF trampoline logic to patch nops/calls in kernel text into calls into BPF trampoline and to patch calls/nops inside BPF programs too. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Song Liu <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2019-11-15bpf: Support doubleword alignment in bpf_jit_binary_allocIlya Leoshkevich1-2/+4
Currently passing alignment greater than 4 to bpf_jit_binary_alloc does not work: in such cases it silently aligns only to 4 bytes. On s390, in order to load a constant from memory in a large (>512k) BPF program, one must use lgrl instruction, whose memory operand must be aligned on an 8-byte boundary. This patch makes it possible to request 8-byte alignment from bpf_jit_binary_alloc, and also makes it issue a warning when an unsupported alignment is requested. Signed-off-by: Ilya Leoshkevich <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2019-11-15i2c: remove helpers for ref-counting clientsWolfram Sang1-3/+0
There are no in-tree users of these helpers anymore, and there shouldn't. Most use cases went away once the driver model started to refcount for us. There have been users like the media subsystem, but they all switched to better refcounting methods meanwhile. Media did this in 2008. Last user (IPMI) left 2018. Remove this cruft. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Tested-by: Luca Ceresoli <[email protected]> Reviewed-by: Luca Ceresoli <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]>
2019-11-15ptp: Introduce strict checking of external time stamp options.Richard Cochran1-1/+3
User space may request time stamps on rising edges, falling edges, or both. However, the particular mode may or may not be supported in the hardware or in the driver. This patch adds a "strict" flag that tells drivers to ensure that the requested mode will be honored. Signed-off-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-15ptp: Validate requests to enable time stamping of external signals.Richard Cochran1-0/+1
Commit 415606588c61 ("PTP: introduce new versions of IOCTLs") introduced a new external time stamp ioctl that validates the flags. This patch extends the validation to ensure that at least one rising or falling edge flag is set when enabling external time stamps. Signed-off-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-15net: dsa: ocelot: add tagger for Ocelot/Felix switchesVladimir Oltean1-0/+2
While it is entirely possible that this tagger format is in fact more generic than just these 2 switch families, I don't have that knowledge. The Seville switch in NXP T1040 has a similar frame format, but there are enough differences (e.g. DEST field starts at bit 57 instead of 56) that calling this file tag_vitesse.c is a bit of a stretch at the moment. The frame format has been listed in a comment so that people who add support for further Vitesse switches can rework this tagger while keeping compatibility with Felix. The "ocelot" name was chosen instead of "felix" because even the Ocelot switch can act as a DSA device when it is used in NPI mode, and the Felix tagger format is almost identical. Currently it is only used for the Felix switch embedded in the NXP LS1028A chip. The ABI for this tagger should be considered "not stable" at the moment. The DSA tag is always placed before the Ethernet header and therefore, we are using the long prefix for RX tags to avoid putting the DSA master port in promiscuous mode. Once there will be an API in DSA for drivers to request DSA masters to be in promiscuous mode unconditionally, we will switch to the "no prefix" extraction frame header, which will save 16 padding bytes for each RX frame. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-15net: mscc: ocelot: publish ocelot_sys.h to include/soc/msccVladimir Oltean1-0/+144
The Felix DSA driver needs to write to SYS_RAM_INIT_RAM_INIT for its own chip initialization process. Also update the MAINTAINERS file such that the headers exported by the ocelot driver are under the same maintainers' umbrella as the driver itself. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-15net: mscc: ocelot: publish structure definitions to include/soc/mscc/ocelot.hVladimir Oltean1-0/+539
We will be registering another switch driver based on ocelot, which lives under drivers/net/dsa. Make sure the Felix DSA front-end has the necessary abstractions to implement a new Ocelot driver instantiation. This includes the function prototypes for implementing DSA callbacks. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-15net/smc: introduce bookkeeping of SMCD link groupsUrsula Braun1-0/+2
If the ism module is unloaded return control from exit routine only, if all link groups are freed. If an IB device is thrown away return control from device removal only, if all link groups belonging to this device are freed. A counters for the total number of SMCD link groups per ISM device is introduced. ism module unloading continues only if the total number of SMCD link groups for all ISM devices is zero. ISM device removal continues only it the total number of SMCD link groups per ISM device has decreased to zero. Signed-off-by: Ursula Braun <[email protected]> Signed-off-by: Karsten Graul <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-15net/smc: immediate termination for SMCD link groupsUrsula Braun1-0/+2
SMCD link group termination is called when peer signals its shutdown of its corresponding link group. For regular shutdowns no connections exist anymore. For abnormal shutdowns connections must be killed and their DMBs must be unregistered immediately. That means the SMCR method to delay the link group freeing several seconds does not fit. This patch adds immediate termination of a link group and its SMCD connections and makes sure all SMCD link group related cleanup steps are finished. Signed-off-by: Ursula Braun <[email protected]> Signed-off-by: Karsten Graul <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-15new helper: lookup_positive_unlocked()Al Viro1-0/+1
Most of the callers of lookup_one_len_unlocked() treat negatives are ERR_PTR(-ENOENT). Provide a helper that would do just that. Note that a pinned positive dentry remains positive - it's ->d_inode is stable, etc.; a pinned _negative_ dentry can become positive at any point as long as you are not holding its parent at least shared. So using lookup_one_len_unlocked() needs to be careful; lookup_positive_unlocked() is safer and that's what the callers end up open-coding anyway. Signed-off-by: Al Viro <[email protected]>
2019-11-15fs/namei.c: pull positivity check into follow_managed()Al Viro1-0/+5
There are 4 callers; two proceed to check if result is positive and fail with ENOENT if it isn't; one (in handle_lookup_down()) is guaranteed to yield positive and one (in lookup_fast()) is _preceded_ by positivity check. However, follow_managed() on a negative dentry is a (fairly cheap) no-op on anything other than autofs. And negative autofs dentries are never hashed, so lookup_fast() is not going to run into one of those. Moreover, successful follow_managed() on a _positive_ dentry never yields a negative one (and we significantly rely upon that in callers of lookup_fast()). In other words, we can easily transpose the positivity check and the call of follow_managed() in lookup_fast(). And that allows to fold the positivity check *into* follow_managed(), simplifying life for the code downstream of its calls. Signed-off-by: Al Viro <[email protected]>
2019-11-15pipe: Allow pipes to have kernel-reserved slotsDavid Howells1-1/+5
Split pipe->ring_size into two numbers: (1) pipe->ring_size - indicates the hard size of the pipe ring. (2) pipe->max_usage - indicates the maximum number of pipe ring slots that userspace orchestrated events can fill. This allows for a pipe that is both writable by the general kernel notification facility and by userspace, allowing plenty of ring space for notifications to be added whilst preventing userspace from being able to pin too much unswappable kernel space. Signed-off-by: David Howells <[email protected]>
2019-11-15jbd2: make jbd2_handle_buffer_credits() handle reserved handlesJan Kara1-2/+6
The helper jbd2_handle_buffer_credits() doesn't correctly handle reserved handles which can lead to crashes. Fix it getting of journal pointer to work for reserved handles as well. Fixes: a9a8344ee171 ("ext4, jbd2: Provide accessor function for handle credits") Reported-by: Eric Biggers <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2019-11-15y2038: itimer: change implementation to timespec64Arnd Bergmann1-8/+8
There is no 64-bit version of getitimer/setitimer since that is not actually needed. However, the implementation is built around the deprecated 'struct timeval' type. Change the code to use timespec64 internally to reduce the dependencies on timeval and associated helper functions. Minor adjustments in the code are needed to make the native and compat version work the same way, and to keep the range check working after the conversion. Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: move itimer reset into itimer.cArnd Bergmann1-4/+5
Preparing for a change to the itimer internals, stop using the do_setitimer() symbol and instead use a new higher-level interface. The do_getitimer()/do_setitimer functions can now be made static, allowing the compiler to potentially produce better object code. Reviewed-by: Thomas Gleixner <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: itimer: compat handling to itimer.cArnd Bergmann1-11/+4
The structure is only used in one place, moving it there simplifies the interface and helps with later changes to this code. Rename it to match the other time32 structures in the process. Reviewed-by: Thomas Gleixner <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: time: avoid timespec usage in settimeofday()Arnd Bergmann1-1/+1
The compat_get_timeval() and timeval_valid() interfaces are deprecated and getting removed along with the definition of struct timeval itself. Change the two implementations of the settimeofday() system call to open-code these helpers and completely avoid references to timeval. The timeval_valid() call is not needed any more here, only a check to avoid overflowing tv_nsec during the multiplication, as there is another range check in do_sys_settimeofday64(). Tested-by: [email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: elfcore: Use __kernel_old_timeval for process timesArnd Bergmann1-4/+4
We store elapsed time for a crashed process in struct elf_prstatus using 'timeval' structures. Once glibc starts using 64-bit time_t, this becomes incompatible with the kernel's idea of timeval since the structure layout no longer matches on 32-bit architectures. This changes the definition of the elf_prstatus structure to use __kernel_old_timeval instead, which is hardcoded to the currently used binary layout. There is no risk of overflow in y2038 though, because the time values are all relative times, and can store up to 68 years of process elapsed time. There is a risk of applications breaking at build time when they use the new kernel headers and expect the type to be exactly 'timeval' rather than a structure that has the same fields as before. Those applications have to be modified to deal with 64-bit time_t anyway. Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: make ns_to_compat_timeval use __kernel_old_timevalArnd Bergmann1-2/+2
This gets us one step closer to removing 'struct timeval' from the kernel. We still keep __kernel_old_timeval for interfaces that we cannot fix otherwise, and ns_to_compat_timeval() is provably safe for interfaces that are legitimate users of __kernel_old_timeval on native kernels, so this is an obvious change. Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: socket: use __kernel_old_timespec instead of timespecArnd Bergmann1-2/+5
The 'timespec' type definition and helpers like ktime_to_timespec() or timespec64_to_timespec() should no longer be used in the kernel so we can remove them and avoid introducing y2038 issues in new code. Change the socket code that needs to pass a timespec to user space for backward compatibility to use __kernel_old_timespec instead. This type has the same layout but with a clearer defined name. Slightly reformat tcp_recv_timestamp() for consistency after the removal of timespec64_to_timespec(). Acked-by: Deepa Dinamani <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: socket: remove timespec reference in timestampingArnd Bergmann1-0/+7
In order to remove the 'struct timespec' definition and the timespec64_to_timespec() helper function, change over the in-kernel definition of 'struct scm_timestamping' to use the __kernel_old_timespec replacement and open-code the assignment. Acked-by: Deepa Dinamani <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: syscalls: change remaining timeval to __kernel_old_timevalArnd Bergmann1-5/+5
All of the remaining syscalls that pass a timeval (gettimeofday, utime, futimesat) can trivially be changed to pass a __kernel_old_timeval instead, which has a compatible layout, but avoids ambiguity with the timeval type in user space. Acked-by: Christian Brauner <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: rusage: use __kernel_old_timevalArnd Bergmann1-2/+2
There are two 'struct timeval' fields in 'struct rusage'. Unfortunately the definition of timeval is now ambiguous when used in user space with a libc that has a 64-bit time_t, and this also changes the 'rusage' definition in user space in a way that is incompatible with the system call interface. While there is no good solution to avoid all ambiguity here, change the definition in the kernel headers to be compatible with the kernel ABI, using __kernel_old_timeval as an unambiguous base type. In previous discussions, there was also a plan to add a replacement for rusage based on 64-bit timestamps and nanosecond resolution, i.e. 'struct __kernel_timespec'. I have patches for that as well, if anyone thinks we should do that. Reviewed-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: uapi: change __kernel_time_t to __kernel_old_time_tArnd Bergmann11-24/+24
This is mainly a patch for clarification, and to let us remove the time_t definition from the kernel to prevent new users from creeping in that might not be y2038-safe. All remaining uses of 'time_t' or '__kernel_time_t' are part of the user API that cannot be changed by that either have a replacement or that do not suffer from the y2038 overflow. Acked-by: Deepa Dinamani <[email protected]> Acked-by: Christian Brauner <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: ipc: remove __kernel_time_t reference from headersArnd Bergmann3-16/+15
There are two structures based on time_t that conflict between libc and kernel: timeval and timespec. Both are now renamed to __kernel_old_timeval and __kernel_old_timespec. For time_t, the old typedef is still __kernel_time_t. There is nothing wrong with that name, but it would be nice to not use that going forward as this type is used almost only in deprecated interfaces because of the y2038 overflow. In the IPC headers (msgbuf.h, sembuf.h, shmbuf.h), __kernel_time_t is only used for the 64-bit variants, which are not deprecated. Change these to a plain 'long', which is the same type as __kernel_time_t on all 64-bit architectures anyway, to reduce the number of users of the old type. Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15y2038: add __kernel_old_timespec and __kernel_old_time_tArnd Bergmann2-0/+6
The 'struct timespec' definition can no longer be part of the uapi headers because it conflicts with a a now incompatible libc definition. Also, we really want to remove it in order to prevent new uses from creeping in. The same namespace conflict exists with time_t, which should also be removed. __kernel_time_t could be used safely, but adding 'old' in the name makes it clearer that this should not be used for new interfaces. Add a replacement __kernel_old_timespec structure and __kernel_old_time_t along the lines of __kernel_old_timeval. Acked-by: Deepa Dinamani <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-11-15regulator: da9062: refactor buck modes into headerChristoph Fritz1-0/+16
This patch refactors buck modes into a header file so that device trees can make use of these mode constants. The new header filename uses da9063 because DA9063 was the earlier chip and its driver code will want updating at some point in a similar manner. Signed-off-by: Christoph Fritz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-11-15KVM: x86: deliver KVM IOAPIC scan request to target vCPUsNitesh Narayan Lal1-0/+2
In IOAPIC fixed delivery mode instead of flushing the scan requests to all vCPUs, we should only send the requests to vCPUs specified within the destination field. This patch introduces kvm_get_dest_vcpus_mask() API which retrieves an array of target vCPUs by using kvm_apic_map_get_dest_lapic() and then based on the vcpus_idx, it sets the bit in a bitmap. However, if the above fails kvm_get_dest_vcpus_mask() finds the target vCPUs by traversing all available vCPUs. Followed by setting the bits in the bitmap. If we had different vCPUs in the previous request for the same redirection table entry then bits corresponding to these vCPUs are also set. This to done to keep ioapic_handled_vectors synchronized. This bitmap is then eventually passed on to kvm_make_vcpus_request_mask() to generate a masked request only for the target vCPUs. This would enable us to reduce the latency overhead on isolated vCPUs caused by the IPI to process due to KVM_REQ_IOAPIC_SCAN. Suggested-by: Marcelo Tosatti <[email protected]> Signed-off-by: Nitesh Narayan Lal <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2019-11-15KVM: remember position in kvm->vcpus arrayRadim Krčmář1-8/+3
Fetching an index for any vcpu in kvm->vcpus array by traversing the entire array everytime is costly. This patch remembers the position of each vcpu in kvm->vcpus array by storing it in vcpus_idx under kvm_vcpu structure. Signed-off-by: Radim Krčmář <[email protected]> Signed-off-by: Nitesh Narayan Lal <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2019-11-15perf/core: Provide a kernel-internal interface to pause perf_eventLike Xu1-0/+5
Exporting perf_event_pause() as an external accessor for kernel users (such as KVM) who may do both disable perf_event and read count with just one time to hold perf_event_ctx_lock. Also the value could be reset optionally. Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Like Xu <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2019-11-15perf/core: Provide a kernel-internal interface to recalibrate event periodLike Xu1-0/+5
Currently, perf_event_period() is used by user tools via ioctl. Based on naming convention, exporting perf_event_period() for kernel users (such as KVM) who may recalibrate the event period for their assigned counter according to their requirements. The perf_event_period() is an external accessor, just like the perf_event_{en,dis}able() and should thus use perf_event_ctx_lock(). Suggested-by: Kan Liang <[email protected]> Signed-off-by: Like Xu <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2019-11-15x86/hyperv: Initialize clockevents earlier in CPU onliningMichael Kelley2-3/+5
Hyper-V has historically initialized stimer-based clockevents late in the process of onlining a CPU because clockevents depend on stimer interrupts. In the original Hyper-V design, stimer interrupts generate a VMbus message, so the VMbus machinery must be running first, and VMbus can't be initialized until relatively late. On x86/64, LAPIC timer based clockevents are used during early initialization before VMbus and stimer-based clockevents are ready, and again during CPU offlining after the stimer clockevents have been shut down. Unfortunately, this design creates problems when offlining CPUs for hibernation or other purposes. stimer-based clockevents are shut down relatively early in the offlining process, so clockevents_unbind_device() must be used to fallback to the LAPIC-based clockevents for the remainder of the offlining process. Furthermore, the late initialization and early shutdown of stimer-based clockevents doesn't work well on ARM64 since there is no other timer like the LAPIC to fallback to. So CPU onlining and offlining doesn't work properly. Fix this by recognizing that stimer Direct Mode is the normal path for newer versions of Hyper-V on x86/64, and the only path on other architectures. With stimer Direct Mode, stimer interrupts don't require any VMbus machinery. stimer clockevents can be initialized and shut down consistent with how it is done for other clockevent devices. While the old VMbus-based stimer interrupts must still be supported for backward compatibility on x86, that mode of operation can be treated as legacy. So add a new Hyper-V stimer entry in the CPU hotplug state list, and use that new state when in Direct Mode. Update the Hyper-V clocksource driver to allocate and initialize stimer clockevents earlier during boot. Update Hyper-V initialization and the VMbus driver to use this new design. As a result, the LAPIC timer is no longer used during boot or CPU onlining/offlining and clockevents_unbind_device() is not called. But retain the old design as a legacy implementation for older versions of Hyper-V that don't support Direct Mode. Signed-off-by: Michael Kelley <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Dexuan Cui <[email protected]> Reviewed-by: Dexuan Cui <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-11-15mmc: sdio: fix wl1251 vendor idH. Nikolaus Schaller1-0/+2
v4.11-rc1 did introduce a patch series that rearranged the sdio quirks into a header file. Unfortunately this did forget to handle SDIO_VENDOR_ID_TI differently between wl1251 and wl1271 with the result that although the wl1251 was found on the sdio bus, the firmware did not load any more and there was no interface registration. This patch defines separate constants to be used by sdio quirks and drivers. Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by: H. Nikolaus Schaller <[email protected]> Cc: <[email protected]> # v4.11+ Signed-off-by: Ulf Hansson <[email protected]>
2019-11-15mmc: host: omap-hsmmc: remove init_card pdata callback from pdataH. Nikolaus Schaller1-3/+0
Now as we have removed the last user (pandora_wl1251_init_card) of this callback, we can remove it from the hsmmc code. Suggested-by: Ulf Hansson <[email protected]> Signed-off-by: H. Nikolaus Schaller <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2019-11-14ftrace: Add modify_ftrace_direct()Steven Rostedt (VMware)1-0/+6
Add a new function modify_ftrace_direct() that will allow a user to update an existing direct caller to a new trampoline, without missing hits due to unregistering one and then adding another. Link: https://lore.kernel.org/r/[email protected] Suggested-by: Alexei Starovoitov <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2019-11-14libnvdimm: Trivial comment fixIra Weiny1-1/+1
Signed-off-by: Ira Weiny <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]>
2019-11-15Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie1-1/+1
into drm-next Two minor cleanups / fixes for -next. Signed-off-by: Dave Airlie <[email protected]> From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m=20=28VMware=29?= Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-14vsock: prevent transport modules unloadingStefano Garzarella1-0/+2
This patch adds 'module' member in the 'struct vsock_transport' in order to get/put the transport module. This prevents the module unloading while sockets are assigned to it. We increase the module refcnt when a socket is assigned to a transport, and we decrease the module refcnt when the socket is destructed. Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock/vmci: register vmci_transport only when VMCI guest/host are activeStefano Garzarella1-0/+2
To allow other transports to be loaded with vmci_transport, we register the vmci_transport as G2H or H2G only when a VMCI guest or host is active. To do that, this patch adds a callback registered in the vmci driver that will be called when the host or guest becomes active. This callback will register the vmci_transport in the VSOCK core. Cc: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock: add multi-transports supportStefano Garzarella1-6/+12
This patch adds the support of multiple transports in the VSOCK core. With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Major changes: - vsock core module can be loaded regardless of the transports - vsock_core_init() and vsock_core_exit() are renamed to vsock_core_register() and vsock_core_unregister() - vsock_core_register() has a feature parameter (H2G, G2H, DGRAM) to identify which directions the transport can handle and if it's support DGRAM (only vmci) - each stream socket is assigned to a transport when the remote CID is set (during the connect() or when we receive a connection request on a listener socket). The remote CID is used to decide which transport to use: - remote CID <= VMADDR_CID_HOST will use guest->host transport; - remote CID == local_cid (guest->host transport) will use guest->host transport for loopback (host->guest transports don't support loopback); - remote CID > VMADDR_CID_HOST will use host->guest transport; - listener sockets are not bound to any transports since no transport operations are done on it. In this way we can create a listener socket, also if the transports are not loaded or with VMADDR_CID_ANY to listen on all transports. - DGRAM sockets are handled as before, since only the vmci_transport provides this feature. Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock: add vsock_create_connected() called by transportsStefano Garzarella1-4/+1
All transports call __vsock_create() with the same parameters, most of them depending on the parent socket. In order to simplify the VSOCK core APIs exposed to the transports, this patch adds the vsock_create_connected() callable from transports to create a new socket when a connection request is received. We also unexported the __vsock_create(). Suggested-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock: handle buffer_size sockopts in the coreStefano Garzarella2-22/+8
virtio_transport and vmci_transport handle the buffer_size sockopts in a very similar way. In order to support multiple transports, this patch moves this handling in the core to allow the user to change the options also if the socket is not yet assigned to any transport. This patch also adds the '.notify_buffer_size' callback in the 'struct virtio_transport' in order to inform the transport, when the buffer_size is changed by the user. It is also useful to limit the 'buffer_size' requested (e.g. virtio transports). Acked-by: Dexuan Cui <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock: add 'struct vsock_sock *' param to vsock_core_get_transport()Stefano Garzarella1-1/+1
Since now the 'struct vsock_sock' object contains a pointer to the transport, this patch adds a parameter to the vsock_core_get_transport() to return the right transport assigned to the socket. This patch modifies also the virtio_transport_get_ops(), that uses the vsock_core_get_transport(), adding the 'struct vsock_sock *' parameter. Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock/virtio: add transport parameter to the virtio_transport_reset_no_sock()Stefano Garzarella1-1/+2
We are going to add 'struct vsock_sock *' parameter to virtio_transport_get_ops(). In some cases, like in the virtio_transport_reset_no_sock(), we don't have any socket assigned to the packet received, so we can't use the virtio_transport_get_ops(). In order to allow virtio_transport_reset_no_sock() to use the '.send_pkt' callback from the 'vhost_transport' or 'virtio_transport', we add the 'struct virtio_transport *' to it and to its caller: virtio_transport_recv_pkt(). We moved the 'vhost_transport' and 'virtio_transport' definition, to pass their address to the virtio_transport_recv_pkt(). Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock: add 'transport' member in the struct vsock_sockStefano Garzarella1-0/+1
As a preparation to support multiple transports, this patch adds the 'transport' member at the 'struct vsock_sock'. This new field is initialized during the creation in the __vsock_create() function. This patch also renames the global 'transport' pointer to 'transport_single', since for now we're only supporting a single transport registered at run-time. Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock: remove include/linux/vm_sockets.h fileStefano Garzarella3-15/+2
This header file now only includes the "uapi/linux/vm_sockets.h". We can include directly it when needed. Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14vsock: remove vm_sockets_get_local_cid()Stefano Garzarella1-2/+0
vm_sockets_get_local_cid() is only used in virtio_transport_common.c. We can replace it calling the virtio_transport_get_ops() and using the get_local_cid() callback registered by the transport. Reviewed-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Jorgen Hansen <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-14Merge tag 'mlx5-updates-2019-11-12' of ↵David S. Miller4-2/+23
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2019-11-12 1) Merge mlx5-next for devlink reload and flowtable offloads dependencies 2) Devlink reload support 3) TC Flowtable offloads 4) Misc cleanup ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-14dt-bindings: net: dp83869: Add TI dp83869 phyDan Murphy1-0/+42
Add dt bindings for the TI dp83869 Gigabit ethernet phy device. Signed-off-by: Dan Murphy <[email protected]> CC: Rob Herring <[email protected]> Signed-off-by: David S. Miller <[email protected]>