| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The comment for start_streaming that tells the developer with which vb2 state
buffers should be returned to vb2 gave the wrong state. Very confusing.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Recently WARN_ON() calls have been added to warn if the driver is not
properly returning buffers to vb2 in start_streaming (if it fails) or
stop_streaming(). Add comments before those WARN_ON calls that refer
to the videobuf2-core.h header that explains what drivers are supposed
to do in these situations. That should help point developers in the
right direction if they see these warnings.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
sg_alloc_table_from_pages() only allocates a sg_table, so it should just use
GFP_KERNEL, not gfp_flags. If gfp_flags contains __GFP_DMA32 then mm/sl[au]b.c
will call BUG_ON:
[ 358.027515] ------------[ cut here ]------------
[ 358.027546] kernel BUG at mm/slub.c:1416!
[ 358.027558] invalid opcode: 0000 [#1] PREEMPT SMP
[ 358.027576] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 btcx_risc altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core nouveau zr36067 videocodec v4l2_common videodev media x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci
[ 358.027712] CPU: 19 PID: 3654 Comm: cat Not tainted 3.16.0-rc6-telek #167
[ 358.027723] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014
[ 358.027741] task: ffff880897c7d960 ti: ffff88089b4d4000 task.ti: ffff88089b4d4000
[ 358.027753] RIP: 0010:[<ffffffff81196040>] [<ffffffff81196040>] new_slab+0x280/0x320
[ 358.027776] RSP: 0018:ffff88089b4d7ae8 EFLAGS: 00010002
[ 358.027787] RAX: ffff880897c7d960 RBX: 0000000000000000 RCX: ffff88089b4d7b50
[ 358.027798] RDX: 00000000ffffffff RSI: 0000000000000004 RDI: ffff88089f803b00
[ 358.027809] RBP: ffff88089b4d7bb8 R08: 0000000000000000 R09: 0000000100400040
[ 358.027821] R10: 0000160000000000 R11: ffff88109bc02c40 R12: 0000000000000001
[ 358.027832] R13: ffff88089f8000c0 R14: ffff88089f803b00 R15: ffff8810bfcf4be0
[ 358.027845] FS: 00007f83fe5c0700(0000) GS:ffff8810bfce0000(0000) knlGS:0000000000000000
[ 358.027858] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 358.027868] CR2: 0000000001dfd568 CR3: 0000001097d5a000 CR4: 00000000000407e0
[ 358.027878] Stack:
[ 358.027885] ffffffff81198860 ffff8810bfcf4be0 ffff880897c7d960 0000000000001b00
[ 358.027905] ffff880897c7d960 0000000000000000 ffff8810bfcf4bf0 0000000000000000
[ 358.027924] 0000000000000000 0000000100000100 ffffffff813ef84a 00000004ffffffff
[ 358.027944] Call Trace:
[ 358.027956] [<ffffffff81198860>] ? __slab_alloc+0x400/0x4e0
[ 358.027973] [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30
[ 358.027985] [<ffffffff81198f17>] __kmalloc+0x127/0x150
[ 358.027997] [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30
[ 358.028009] [<ffffffff813ef84a>] sg_kmalloc+0x1a/0x30
[ 358.028023] [<ffffffff813eff84>] __sg_alloc_table+0x74/0x180
[ 358.028035] [<ffffffff813ef830>] ? sg_kfree+0x20/0x20
[ 358.028048] [<ffffffff813f00af>] sg_alloc_table+0x1f/0x60
[ 358.028061] [<ffffffff813f0174>] sg_alloc_table_from_pages+0x84/0x1f0
[ 358.028077] [<ffffffffa007c3f9>] vb2_dma_sg_alloc+0x159/0x230 [videobuf2_dma_sg]
[ 358.028095] [<ffffffffa003d55a>] __vb2_queue_alloc+0x10a/0x680 [videobuf2_core]
[ 358.028113] [<ffffffffa003e110>] __reqbufs.isra.14+0x220/0x3e0 [videobuf2_core]
[ 358.028130] [<ffffffffa003e79d>] __vb2_init_fileio+0xbd/0x380 [videobuf2_core]
[ 358.028147] [<ffffffffa003f563>] __vb2_perform_fileio+0x5b3/0x6e0 [videobuf2_core]
[ 358.028164] [<ffffffffa003f871>] vb2_fop_read+0xb1/0x100 [videobuf2_core]
[ 358.028184] [<ffffffffa06dd2e5>] v4l2_read+0x65/0xb0 [videodev]
[ 358.028198] [<ffffffff811a243f>] vfs_read+0x8f/0x170
[ 358.028210] [<ffffffff811a30a1>] SyS_read+0x41/0xb0
[ 358.028224] [<ffffffff818f02e9>] system_call_fastpath+0x16/0x1b
[ 358.028234] Code: 66 90 e9 dc fd ff ff 0f 1f 40 00 41 8b 4d 68 e9 d5 fe ff ff 0f 1f 80 00 00 00 00 f0 41 80 4d 00 40 e9 03 ff ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 44 89 c6 4c 89 45 d0 e8 0c 82 ff ff 48
[ 358.028415] RIP [<ffffffff81196040>] new_slab+0x280/0x320
[ 358.028432] RSP <ffff88089b4d7ae8>
[ 358.032208] ---[ end trace 6443240199c706e4 ]---
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org # for v3.13 and up
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
|
|
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Pull ARM fixes from Russell King:
"Fixes for ARM, the most notable being the fix from Nathan Lynch to fix
the state of various registers during execve, to ensure that data
can't be leaked between two executables.
Fixes from Victor Kamensky for get_user() on big endian platforms,
since the addition of 8-byte get_user() support broke these fairly
badly.
A fix from Sudeep Holla for affinity setting when hotplugging CPU 0.
A fix from Stephen Boyd for a perf-induced sleep attempt while atomic.
Lastly, a correctness fix for emulation of the SWP instruction on
ARMv7+, and a fix for wrong carry handling when updating the
translation table base address on LPAE platforms"
* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 8149/1: perf: Don't sleep while atomic when enabling per-cpu interrupts
ARM: 8148/1: flush TLS and thumbee register state during exec
ARM: 8151/1: add missing exports for asm functions required by get_user macro
ARM: 8137/1: fix get_user BE behavior for target variable with size of 8 bytes
ARM: 8135/1: Fix in-correct barrier usage in SWP{B} emulation
ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs
ARM: 8132/1: LPAE: drop wrong carry flag correction after adding TTBR1_OFFSET
|
|
with strncpy
Using memset before strncpy just to ensure a trailing null character is
an unnecessary double writing of a string
Patch modified by Helge Deller to additionally reduce stack usage.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"some media bug fixes:
- a Kconfig dependency issue
- some fixes for af9033/it913x demod to be more reliable and address
a performance regression
- cx18: fix an oops on devices with tda8290 tuner
- two new USB IDs for af9035
- a couple fixes on smapp driver"
* tag 'media-v3.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] af9035: new IDs: add support for PCTV 78e and PCTV 79e
[media] af9033: feed clock to RF tuner
[media] it913x: init tuner on attach
[media] af9033: update IT9135 tuner inittabs
[media] Kconfig: do not select SPI bus on sub-driver auto-select
[media] cx18: fix kernel oops with tda8290 tuner
[media] smiapp: Set sub-device owner
[media] smiapp: Fix power count handling
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging / IIO fixes from Greg KH:
"Here are some IIO and Staging driver fixes for 3.17-rc6. They are all
pretty simple, and resolve reported issues"
* tag 'staging-3.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: vt6655: buffer overflow in ioctl
iio:magnetometer: bugfix magnetometers gain values
iio: adc: at91: don't use the last converted data register
iio: adc: xilinx-xadc: assign auxiliary channels address correctly
iio: meter: ade7758: Fix indio_dev->trig assignment
iio: inv_mpu6050: Fix indio_dev->trig assignment
iio: gyro: itg3200: Fix indio_dev->trig assignment
iio: st_sensors: Fix indio_dev->trig assignment
iio: hid_sensor_hub: Fix indio_dev->trig assignment
iio: adc: ad_sigma_delta: Fix indio_dev->trig assignment
iio: accel: bma180: Fix indio_dev->trig assignment
iio:trigger: modify return value for iio_trigger_get
iio:inkern: fix overwritten -EPROBE_DEFER in of_iio_channel_get_by_name
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes / quirks from Greg KH:
"Here are some USB and PHY fixes and quirks for 3.17-rc6. Nothing
major, just a few things that have been reported"
* tag 'usb-3.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters
USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter
USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter
USB: EHCI: unlink QHs even after the controller has stopped
phy: spear1340-miphy: fix driver dependencies
phy: spear1310-miphy: fix driver dependencies
phy: miphy365x: Fix off-by-one error
|
|
Pull SCSI target fixes from Nicholas Bellinger:
"Here are the target pending fixes for v3.17-rc6.
Included are Sagi's long overdue fixes related to iser-target
shutdown, along with a couple of fixes from Sebastian related to ALUA
Referrals changes that when in during the v3.14 time-frame.
Also included are a few iscsi-target fixes, most recently of which
where found during Joern's Coverity scanning of target code"
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
iscsi-target: avoid NULL pointer in iscsi_copy_param_list failure
iscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid
target: Fix inverted logic in SE_DEV_ALUA_SUPPORT_STATE_STORE
target: Fix user data segment multiplier in spc_emulate_evpd_b3()
iscsi-target: Ignore ICF_GOT_LAST_DATAOUT during Data-Out ITT lookup
Target/iser: Fix initiator_depth and responder_resources
Target/iser: Avoid calling rdma_disconnect twice
Target/iser: Don't put isert_conn inside disconnected handler
Target/iser: Get isert_conn reference once got to connected_handler
|
|
Pull drm fixes from Dave Airlie:
"A bunch of radeon fixes for oops on module unload, and problems with
resetting the dma engine, one nouveau fix for black boxes in rendering
on my mbp retina, one sti fix, and a couple of intel fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau: ltc/gf100-: fix cbc issues on certain boards
drm/bochs: add missing drm_connector_register call
drm/cirrus: add missing drm_connector_register call
drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page
drm/nouveau/runpm: fix module unload
drm/radeon/px: fix module unload
vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops
drm/radeon: don't reset dma on r6xx-evergreen init
drm/radeon: don't reset sdma on CIK init
drm/radeon: don't reset dma on NI/SI init
drm/radeon/dpm: fix resume on mullins
drm/radeon: Disable HDP flush before every CS again for < r600
drm/radeon: delete unused PTE_* defines
drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv
drm: sti: do not iterate over the info frame array
drm/i915: Fix SRC_COPY width on 830/845g
|
|
A mismatch between FB and LTC's idea of how big a large page is causes
issues such as black "holes" in rendering to occur on some boards
(those where LTC is configured for 64KiB large pages) when compression
is used.
Confirmed to fix at least the GK107 MBP.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
into drm-fixes
single fix for regression on rs4xx/rs690/rs740
* 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page
|
|
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Functions supplied in ip6_udp_tunnel.c are only needed when IPV6 is
selected. When IPV6 is not selected, those functions are stubbed out
in udp_tunnel.h.
==================================================================
net/ipv6/ip6_udp_tunnel.c:15:5: error: redefinition of 'udp_sock_create6'
int udp_sock_create6(struct net *net, struct udp_port_cfg *cfg,
In file included from net/ipv6/ip6_udp_tunnel.c:9:0:
include/net/udp_tunnel.h:36:19: note: previous definition of 'udp_sock_create6' was here
static inline int udp_sock_create6(struct net *net, struct udp_port_cfg *cfg,
==================================================================
Fixes: fd384412e udp_tunnel: Seperate ipv6 functions into its own file
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Andy Zhou <azhou@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
->u.generic_elem.len is a user controlled number between 0-255. We
should limit it to avoid memory corruption.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First round of IIO fixes for the 3.17 cycle.
* Fix an overwritten error return that can prevent deferred probing when
using of_iio_channel_get_by_name
* A series that deals with an incorrect reference count when the default
trigger is set within the main probe routine for a driver. Can result
in a double free if the trigger is changed.
* Fix a buglet with xilinx-xadc concerning setup of the address for an
aux channel.
* At91 adc driver could sometimes get a touchscreen reading rather than
the intended adc channel. This is fixed by using the channel data register
instead.
* Fix some ST magnetometer gain values that differ in production parts from
the prerelease ones used for driver development.
|
|
This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB-
SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The
US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI
chain to be accessed. Without it only the (single) device with SCSI ID 0
can be used.
The standalone converter sold by Entrega had model number U1-SC25. Xircom
acquired Entrega and re-branded the product line PortGear. The PortGear USB
to SCSI Converter (model PGSCSI) is internally identical to the Entrega
product, but later models may use a different USB ID. The Entrega-branded
units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and
Macintosh drivers also support 085A:0028.
Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac
(8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as
a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may
have initially used the same ID as the standalone U1-SC25 (1645:0007), but
later production used 085A:0026.
My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133
probably also exist.
This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows
driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I
couldn't find any mention of that actually existing in the wild; perhaps it
was cancelled before release?
Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Hi,
The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g.
iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM
Microsystems chips. Only the connectors differ; both have the same USB ID.
The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other
than 0.
I don't have one of these, but based on the other entries for Shuttle/
SCM-based converters this patch is very likely correct. I used 0x0000 and
0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
bcdDevice value the products use.
Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Adaptec USBConnect 2000 is another SCSI-USB converter which uses
Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is
required to use SCSI devices with ID other than 0.
I don't have a USBConnect 2000, but based on the other entries for Shuttle/
SCM-based converters this patch is very likely correct. I used 0x0000 and
0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
bcdDevice value the product uses.
Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Old code in ehci-hcd tries to expedite disabling endpoints after the
controller has stopped, by destroying the endpoint's associated QH
without first unlinking the QH. This was necessary back when the
driver wasn't so careful about keeping track of the controller's
state.
But now we are careful about it, and the driver knows that when the
controller isn't running, no unlinking delay is needed. Furthermore,
skipping the unlink step will trigger a BUG() in qh_destroy() when the
preceding QH is released, because the link pointer will be non-NULL.
Removing the lines that skip the unlinking step and go directly to
QH_STATE_IDLE fixes the problem.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus
Kishon writes:
misc fixes in PHY drivers
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2014-09-18
This series contains updates to ixgbe and ixgbevf.
Ethan Zhao cleans up ixgbe and ixgbevf by removing bd_number from the
adapter struct because it is not longer useful.
Mark fixes ixgbe where if a hardware transmit timestamp is requested,
an uninitialized workqueue entry may be scheduled. Added a check for
a PTP clock to avoid that.
Jacob provides a number of cleanups for ixgbe. Since we may call
ixgbe_acquire_msix_vectors() prior to registering our netdevice, we
should not use the netdevice specific printk and use e_dev_warn()
instead. Similar to how ixgbevf handles acquiring MSI-X vectors, we
can return an error code instead of relying on the flag being set.
This makes it more clear that we have failed to setup MSI-X mode and
will make it easier to consolidate MSI-X related code into a single
function. In the case of disabling DCB, it is not an error since we
still can function, we just have to let the user know. So use
e_dev_warn() instead of e_err(). Added warnings for other features
that are disabled when we are without MSI-X support. Cleanup flags
that are no longer used or needed.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://gitorious.org/linux-can/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2014-09-18
this is a pull request of 8 patches for current net.
A patch by Roger Quadros for the c_can driver fixes the swapped parameters of
the c_can_hw_raminit_ti() function. Oliver Hartkopp adds the missing PCI ids to
the peak_pci driver to support the single channel PCAN ExpressCard 34 adapter.
David Dueck converts the at91_can driver to use proper clock handling
functions. Then there are 5 patches by David Jander and me which fix several
mailbox related problems in the flexcan driver.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Or Gerlitz says:
====================
mlx4: CQE/EQE stride support
This series from Ido Shamay is intended for archs having
cache line larger then 64 bytes.
Since our CQE/EQEs are generally 64B in those systems, HW will write
twice to the same cache line consecutively, causing pipe locks due to
he hazard prevention mechanism. For elements in a cyclic buffer, writes
are consecutive, so entries smaller than a cache line should be
avoided, especially if they are written at a high rate.
Reduce consecutive writes to same cache line in CQs/EQs, by allowing the
driver to increase the distance between entries so that each will reside
in a different cache line.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This function derives the base address of the CQE from the CQE size,
and calculates the real CQE context segment in it from the factor
(this is like before). Before this change the code used the factor to
calculate the base address of the CQE as well.
The factor indicates in which segment of the cqe stride the cqe information
is located. For 32-byte strides, the segment is 0, and for 64 byte strides,
the segment is 1 (bytes 32..63). Using the factor was ok as long as we had
only 32 and 64 byte strides. However, with larger strides, the factor is zero,
and so cannot be used to calculate the base of the CQE.
The helper uses the same method of CQE buffer pulling made by all other
components that reads the CQE buffer (mlx4_ib driver and libmlx4).
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Enable mlx4 interrupt handler to work with EQE stride feature,
The feature may be enabled when cache line is bigger than 64B.
The EQE size will then be the cache line size, and the context
segment resides in [0-31] offset.
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This feature is intended for archs having cache line larger then 64B.
Since our CQE/EQEs are generally 64B in those systems, HW will write
twice to the same cache line consecutively, causing pipe locks due to
he hazard prevention mechanism. For elements in a cyclic buffer, writes
are consecutive, so entries smaller than a cache line should be
avoided, especially if they are written at a high rate.
Reduce consecutive writes to same cache line in CQs/EQs, by allowing the
driver to increase the distance between entries so that each will reside
in a different cache line. Until the introduction of this feature, there
were two types of CQE/EQE:
1. 32B stride and context in the [0-31] segment
2. 64B stride and context in the [32-63] segment
This feature introduces two additional types:
3. 128B stride and context in the [0-31] segment (128B cache line)
4. 256B stride and context in the [0-31] segment (256B cache line)
Modify the mlx4_core driver to query the device for the CQE/EQE cache
line stride capability and to enable that capability when the host
cache line size is larger than 64 bytes (supported cache lines are
128B and 256B).
The mlx4 IB driver and libmlx4 need not be aware of this change. The PF
context behaviour is changed to require this change in VF drivers
running on such archs.
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Since commit fb5d1e9e127a ("openvswitch: Build flow cmd netlink reply only if needed."),
the new flows are not notified to the listeners of OVS_FLOW_MCGROUP.
This commit fixes the problem by using the genl function, ie
genl_has_listerners() instead of netlink_has_listeners().
Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This function is the counterpart of the function netlink_has_listeners().
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
ptr used to be a non __percpu pointer (result of a this_cpu_ptr
assignment, 7d720c3e4f0c4 ("percpu: add __percpu sparse annotations to
net")). Since d25398df59b56 ("net: avoid reloads in SNMP_UPD_PO_STATS"),
that's no longer the case, SNMP_UPD_PO_STATS uses this_cpu_add and ptr
is now __percpu.
Silence sparse warnings by preserving the original type and
annotation, and remove the out-of-date comment.
warning: incorrect type in initializer (different address spaces)
expected unsigned long long *ptr
got unsigned long long [noderef] <asn:3>*<noident>
warning: incorrect type in initializer (different address spaces)
expected void const [noderef] <asn:3>*__vpp_verify
got unsigned long long *<noident>
warning: incorrect type in initializer (different address spaces)
expected void const [noderef] <asn:3>*__vpp_verify
got unsigned long long *<noident>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Tom Herbert says:
====================
net: foo-over-udp (fou)
This patch series implements foo-over-udp. The idea is that we can
encapsulate different IP protocols in UDP packets. The rationale for
this is that networking devices such as NICs and switches are usually
implemented with UDP (and TCP) specific mechanims for processing. For
instance, many switches and routers will implement a 5-tuple hash
for UDP packets to perform Equal Cost Multipath Routing (ECMP) or
RSS (on NICs). Many NICs also only provide rudimentary checksum
offload (basic TCP and UDP packet), with foo-over-udp we may be
able to leverage these NICs to offload checksums of tunneled packets
(using checksum unnecessary conversion and eventually remote checksum
offload)
An example encapsulation of IPIP over FOU is diagrammed below. As
illustrated, the packet overhead for FOU is the 8 byte UDP header.
+------------------+
| IPv4 hdr |
+------------------+
| UDP hdr |
+------------------+
| IPv4 hdr |
+------------------+
| TCP hdr |
+------------------+
| TCP payload |
+------------------+
Conceptually, FOU should be able to encapsulate any IP protocol.
The FOU header (UDP hdr.) is essentially an inserted header between the
IP header and transport, so in the case of TCP or UDP encapsulation
the pseudo header would be based on the outer IP header and its length
field must not include the UDP header.
* Receive
In this patch set the RX path for FOU is implemented in a new fou
module. To enable FOU for a particular protocol, a UDP-FOU socket is
opened to the port to receive FOU packets. The socket is mapped to the
IP protocol for the packets. The XFRM mechanism used to receive
encapsulated packets (udp_encap_rcv) for the port. Upon reception, the
UDP is removed and packet is reinjected in the stack for the
corresponding protocol associated with the socket (return -protocol
from udp_encap_rcv function).
GRO is provided with the appropriate fou_gro_receive and
fou_gro_complete. These routines need to know the encapsulation
protocol so we save that in udp_offloads structure with the port
and pass it in the napi_gro_cb structure.
* TX
This patch series implements FOU transmit encapsulation for IPIP, GRE, and
SIT. This done by some common infrastructure in ip_tunnel including an
ip_tunnel_encap to perform FOU encapsulation and common configuration
to enable FOU on IP tunnels. FOU is configured on existing tunnels and
does not create any new interfaces. The transmit and receive paths are
independent, so use of FOU may be assymetric between tunnel endpoints.
* Configuration
The fou module using netlink to configure FOU receive ports. The ip
command can be augmented with a fou subcommand to support this. e.g. to
configure FOU for IPIP on port 5555:
ip fou add port 5555 ipproto 4
GRE, IPIP, and SIT have been modified with netlink commands to
configure use of FOU on transmit. The "ip link" command will be
augmented with an encap subcommand (for supporting various forms of
secondary encapsulation). For instance, to configure an ipip tunnel
with FOU on port 5555:
ip link add name tun1 type ipip \
remote 192.168.1.1 local 192.168.1.2 ttl 225 \
encap fou encap-sport auto encap-dport 5555
* Notes
- This patch set does not implement GSO for FOU. The UDP encapsulation
code assumes TEB, so that will need to be reimplemented.
- When a packet is received through FOU, the UDP header is not
actually removed for the skbuf, pointers to transport header
and length in the IP header are updated (like in ESP/UDP RX). A
side effect is the IP header will now appear to have an incorrect
checksum by an external observer (e.g. tcpdump), it will be off
by sizeof UDP header. If necessary we could adjust the checksum
to compensate.
- Performance results are below. My expectation is that FOU should
entail little overhead (clearly there is some work to do :-) ).
Optimizing UDP socket lookup for encapsulation ports should help
significantly.
- I really don't expect/want devices to have special support for any
of this. Generic checksum offload mechanisms (NETIF_HW_CSUM
and use of CHECKSUM_COMPLETE) should be sufficient. RSS and flow
steering is provided by commonly implemented UDP hashing. GRO/GSO
seem fairly comparable with LRO/TSO already.
* Performance
Ran netperf TCP_RR and TCP_STREAM tests across various configurations.
This was performed on bnx2x and I disabled TSO/GSO on sender to get
fair comparison for FOU versus non-FOU. CPU utilization is reported
for receive in TCP_STREAM.
GRE
IPv4, FOU, UDP checksum enabled
TCP_STREAM
24.85% CPU utilization
9310.6 Mbps
TCP_RR
94.2% CPU utilization
155/249/460 90/95/99% latencies
1.17018e+06 tps
IPv4, FOU, UDP checksum disabled
TCP_STREAM
31.04% CPU utilization
9302.22 Mbps
TCP_RR
94.13% CPU utilization
154/239/419 90/95/99% latencies
1.17555e+06 tps
IPv4, no FOU
TCP_STREAM
23.13% CPU utilization
9354.58 Mbps
TCP_RR
90.24% CPU utilization
156/228/360 90/95/99% latencies
1.18169e+06 tps
IPIP
FOU, UDP checksum enabled
TCP_STREAM
24.13% CPU utilization
9328 Mbps
TCP_RR
94.23
149/237/429 90/95/99% latencies
1.19553e+06 tps
FOU, UDP checksum disabled
TCP_STREAM
29.13% CPU utilization
9370.25 Mbps
TCP_RR
94.13% CPU utilization
149/232/398 90/95/99% latencies
1.19225e+06 tps
No FOU
TCP_STREAM
10.43% CPU utilization
5302.03 Mbps
TCP_RR
51.53% CPU utilization
215/324/475 90/95/99% latencies
864998 tps
SIT
FOU, UDP checksum enabled
TCP_STREAM
30.38% CPU utilization
9176.76 Mbps
TCP_RR
96.9% CPU utilization
170/281/581 90/95/99% latencies
1.03372e+06 tps
FOU, UDP checksum disabled
TCP_STREAM
39.6% CPU utilization
9176.57 Mbps
TCP_RR
97.14% CPU utilization
167/272/548 90/95/99% latencies
1.03203e+06 tps
No FOU
TCP_STREAM
11.2% CPU utilization
4636.05 Mbps
TCP_RR
59.51% CPU utilization
232/346/489 90/95/99% latencies
813199 tps
v2:
- Removed encap IP tunnel ioctls, configuration is done by netlink
only.
- Don't export fou_create and fou_destroy, they are currently
intended to be called within fou module only.
- Filled on tunnel netlink structures and functions for new values.
v3:
- Fixed change logs for some of the patches.
- Remove inline from fou_gro_receive and fou_gro_complete, let
compiler decide on these.
v4:
- Don't need to cast void in fou_from_sock
- Removed incorrest htons for port in fou_destroy
- Some minor cleanup for readability
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Added netlink attrs to configure FOU encapsulation for GRE, netlink
handling of these flags, and properly adjust MTU for encapsulation.
ip_tunnel_encap is called from ip_tunnel_xmit to actually perform FOU
encapsulation.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add netlink handling for IP tunnel encapsulation parameters and
and adjustment of MTU for encapsulation. ip_tunnel_encap is called
from ip_tunnel_xmit to actually perform FOU encapsulation.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Added netlink handling of IP tunnel encapulation paramters, properly
adjust MTU for encapsulation. Added ip_tunnel_encap call to
ipip6_tunnel_xmit to actually perform FOU encapsulation.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch changes IP tunnel to support (secondary) encapsulation,
Foo-over-UDP. Changes include:
1) Adding tun_hlen as the tunnel header length, encap_hlen as the
encapsulation header length, and hlen becomes the grand total
of these.
2) Added common netlink define to support FOU encapsulation.
3) Routines to perform FOU encapsulation.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Implement fou_gro_receive and fou_gro_complete, and populate these
in the correponsing udp_offloads for the socket. Added ipproto to
udp_offloads and pass this from UDP to the fou GRO routine in proto
field of napi_gro_cb structure.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch provides a receive path for foo-over-udp. This allows
direct encapsulation of IP protocols over UDP. The bound destination
port is used to map to an IP protocol, and the XFRM framework
(udp_encap_rcv) is used to receive encapsulated packets. Upon
reception, the encapsulation header is logically removed (pointer
to transport header is advanced) and the packet is reinjected into
the receive path with the IP protocol indicated by the mapping.
Netlink is used to configure FOU ports. The configuration information
includes the port number to bind to and the IP protocol corresponding
to that port.
This should support GRE/UDP
(http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02),
as will as the other IP tunneling protocols (IPIP, SIT).
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Want to be able to use these in foo-over-udp offloads, etc.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
linux/log2.h was included twice.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
I cannot move a macvlan interface created on top of a bonding interface
to a different namespace:
% ip netns add dummy0
% ip link add link bond0 mac0 type macvlan
% ip link set mac0 netns dummy0
RTNETLINK answers: Invalid argument
%
The problem seems to be that commit f9399814927a ("bonding: Don't allow
bond devices to change network namespaces.") sets NETIF_F_NETNS_LOCAL
on bonding interfaces, and commit 797f87f83b60 ("macvlan: fix netdev
feature propagation from lower device") causes macvlan interfaces
to inherit its features from the lower device.
NETIF_F_NETNS_LOCAL should not be inherited from the lower device
by a macvlan.
Patch tested on 3.16.
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Acked-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
tc_u32_sel 'sel' in tc_u_knode expects to be the last element in the
structure and pads the structure with tc_u32_key fields for each key.
kzalloc(sizeof(*n) + s->nkeys*sizeof(struct tc_u32_key), GFP_KERNEL)
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
John W. Linville says:
====================
pull request: wireless 2014-09-17
Please pull this batch of fixes intended for the 3.17 stream...
Arend van Spriel sends a trio of minor brcmfmac fixes, including a
fix for a Kconfig/build issue, a fix for a crash (null reference),
and a regression fix related to event handling on a P2P interface.
Hante Meuleman follows-up with a brcmfmac fix for a memory leak.
Johannes Stezenbach brings an ath9k_htc fix for a regression related
to hardware decryption offload.
Marcel Holtmann delivers a one-liner to properly mark a device ID
table in rfkill-gpio.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
pfifo_fast and htb use skb lists, without needing their spinlocks.
(They instead use the standard qdisc lock)
We can use __skb_queue_head_init() instead of skb_queue_head_init()
to be consistent.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Yuval Mintz says:
====================
bnx2x: Support new Multi-function modes
This patch series adds support for 2 new Multi-function modes -
Unified Fabric Port [UFP] as well as nic partitioning 1.5 [NPAR1.5].
With the addition of the new multi-function modes, the series also
revises some of the storage-related multi-function macros.
[Do notice this series has several small issues with checkpatch]
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When using new Multi-function modes it's possible that due to incompatible
configuration management FW will fallback into an existing mode.
Notice that at the moment this fallback is exactly the same as the already
existing switch-independent multi-function mode, but we still use existing
infrastructure to hold this information [in case some small differences will
arise in the future].
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add support for a new multi-function mode based on the Unified Fabric Port
system specifications.
Support includes configuration of:
1. Outer vlan tags.
2. Bandwidth settings.
3. Virtual link enable/disable.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
