01 Apr, 2015
38 commits
-
In many places, the a6 field is typecasted to struct in6_addr. As the
fields are in union anyway, just add in6_addr type to the union and
get rid of the typecasting.Modifying the uapi header is okay, the union has still the same size.
Signed-off-by: Jiri Benc
Signed-off-by: David S. Miller -
In many places, the a6 field is typecasted to struct in6_addr. As the
fields are in union anyway, just add in6_addr type to the union and get rid
of the typecasting.Signed-off-by: Jiri Benc
Signed-off-by: David S. Miller -
Some lines in vxlan code are indented by 7 spaces instead of a tab.
Fixes: e4c7ed415387 ("vxlan: add ipv6 support")
Signed-off-by: Jiri Benc
Acked-by: Cong Wang
Signed-off-by: David S. Miller -
Ian Morris says:
====================
ipv6: coding style - comparisons with NULLThe following patches address some coding style issues only. No
functional changes and no changes detected by objdiff.The IPV6 code uses multiple different styles when comparing with NULL
(I.e. x == NULL and !x as well as x != NULL and x). Generally the
latter form is preferred according to checkpatch and so this changes
aligns the code to this style.
====================Signed-off-by: David S. Miller
-
The ipv6 code uses a mixture of coding styles. In some instances check for NULL
pointer is done as x != NULL and sometimes as x. x is preferred according to
checkpatch and this patch makes the code consistent by adopting the latter
form.No changes detected by objdiff.
Signed-off-by: Ian Morris
Signed-off-by: David S. Miller -
The ipv6 code uses a mixture of coding styles. In some instances check for NULL
pointer is done as x == NULL and sometimes as !x. !x is preferred according to
checkpatch and this patch makes the code consistent by adopting the latter
form.No changes detected by objdiff.
Signed-off-by: Ian Morris
Signed-off-by: David S. Miller -
Yuval Mintz says:
====================
bnx2x: link and protection changesThis patch series contains 2 small additions to link configuration,
as well as a safeguard against loading the device on a hardware at
a failed state.
====================Signed-off-by: David S. Miller
-
It's possible that due to errors [either on PCI or on device itself]
registers reads would fail, returning all-Fs.This adds a check as early as possible so that driver will not read junk
values and make incorrect probe decisions according to them; instead,
gracefully fail the probe.Signed-off-by: Yuval Mintz
Signed-off-by: Ariel Elior
Signed-off-by: David S. Miller -
Number of link changes are now being stored in shared memory [by all possible
link owners], for management use [as well as possible debug information for
dumps].Signed-off-by: Yaniv Rosner
Signed-off-by: Yuval Mintz
Signed-off-by: Ariel Elior
Signed-off-by: David S. Miller -
Enable controlling Post2, coeff, IPreDriver and IFir according to NVRAM setup.
Signed-off-by: Yaniv Rosner
Signed-off-by: Yuval Mintz
Signed-off-by: Ariel Elior
Signed-off-by: David S. Miller -
Signed-off-by: Mahesh Bandewar
Signed-off-by: Andy Gospodarek
Signed-off-by: David S. Miller -
While fixing a recent issue I noticed that we are doing some unnecessary
work inside the loop for ip_fib_net_exit. As such I am pulling out the
initialization to NULL for the locally stored fib_local, fib_main, and
fib_default.In addition I am restoring the original code for flushing the table as
there is no need to split up the fib_table_flush and hlist_del work since
the code for packing the tnodes with multiple key vectors was dropped.Signed-off-by: Alexander Duyck
Signed-off-by: David S. Miller -
This fixes the following warning:
BUG: sleeping function called from invalid context at mm/slub.c:1268
in_atomic(): 1, irqs_disabled(): 0, pid: 6, name: kworker/u8:0
INFO: lockdep is turned off.
CPU: 3 PID: 6 Comm: kworker/u8:0 Tainted: G W 4.0.0-rc5+ #895
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: netns cleanup_net
0000000000000006 ffff88011953fa68 ffffffff81a203b6 000000002c3a2c39
ffff88011952a680 ffff88011953fa98 ffffffff8109daf0 ffff8801186c6aa8
ffffffff81fbc9e5 00000000000004f4 0000000000000000 ffff88011953fac8
Call Trace:
[] dump_stack+0x4c/0x65
[] ___might_sleep+0x1c3/0x1cb
[] __might_sleep+0x78/0x80
[] slab_pre_alloc_hook+0x31/0x8f
[] __kmalloc+0x69/0x14e
[] ? kzalloc.constprop.20+0xe/0x10
[] kzalloc.constprop.20+0xe/0x10
[] fib_trie_table+0x27/0x8b
[] fib_trie_unmerge+0x37/0x2a6
[] ? arch_local_irq_save+0x9/0xc
[] fib_unmerge+0x2d/0xb3
[] fib4_rule_delete+0x1f/0x52
[] ? fib_rules_unregister+0x30/0xb2
[] fib_rules_unregister+0x7c/0xb2
[] fib4_rules_exit+0x15/0x18
[] ip_fib_net_exit+0x23/0xf2
[] fib_net_exit+0x32/0x36
[] ops_exit_list+0x45/0x57
[] cleanup_net+0x13c/0x1cd
[] process_one_work+0x255/0x4ad
[] ? process_one_work+0x161/0x4ad
[] worker_thread+0x1cd/0x2ab
[] ? process_scheduled_works+0x2f/0x2f
[] kthread+0xd4/0xdc
[] ? local_clock+0x19/0x22
[] ? __kthread_parkme+0x83/0x83
[] ret_from_fork+0x58/0x90
[] ? __kthread_parkme+0x83/0x83The issue was that as a part of exiting the default rules were being
deleted which resulted in the local trie being unmerged. By moving the
freeing of the FIB tables up we can avoid the unmerge since there is no
local table left when we call the fib4_rules_exit function.Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
Reported-by: Cong Wang
Signed-off-by: Alexander Duyck
Signed-off-by: David S. Miller -
…etooth/bluetooth-next
Johan Hedberg says:
====================
pull request: bluetooth-next 2015-03-27Here's another set of Bluetooth & 802.15.4 patches for 4.1:
- New API to control LE advertising data (i.e. peripheral role)
- mac802154 & at86rf230 cleanups
- Support for toggling quirks from debugfs (useful for testing)
- Memory leak fix for LE scanning
- Extra version info reading support for Broadcom controllersPlease let me know if there are any issues pulling. Thanks.
====================Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fixed two warnings in e1000e and igb, when switching to timespec64
some printf formats started to not match. In theses cases actually
the new type is __kernel_time_t which is __kernel_long_t which
unfortunately can be either "long" or "long long". So to solve
this I cases the arguments to "long long". -DaveMRichard Cochran says:
====================
ptp: get ready for 2038This series converts the core driver methods of the PTP Hardware Clock
(PHC) subsystem to use the 64 bit version of the timespec structure,
making the core API ready for the year 2038.In addition, I reviewed how each driver and device represents the time
value at the hardware register level. Most of the drivers are ready,
but a few will need some work before the year 2038, as shown:Patch Driver
------------------------------------------------
12 drivers/net/ethernet/intel/igb/igb_ptp.c
15 ? drivers/net/ethernet/sfc/ptp.c
16 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.cThe commit log messages document how each driver is ready or why it is
not ready. For patch 15, I could not easily find out the hardware
representation of the time value, and so the SFC maintainers will have
to review their low level code in order to resolve any remaining
issues.* ChangeLog
** V3
- dp83640: use timespec64 throughout per Arnd's suggestion
- tilegx: use timespec64 throughout per Chris' suggestion
- add Jeff's acked-bys
** V2
- use the new methods in the posix clock code right away (patch #3)
====================Signed-off-by: David S. Miller
-
All of the PHC drivers have been converted to the new methods. This patch
converts the three remaining callers within the core code and removes the
older methods for good. As a result, the core PHC code is ready for the
year 2038. However, some of the PHC drivers are not quite ready yet.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
The device has a 64 bit clock register, where each clock tick is 32
nanoseconds, and so with this patch the driver is ready for the year
2038.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
The device has a 64 bit clock register, where each clock tick is 16
nanoseconds, and so with this patch the driver is ready for the year
2038.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This device stores the number of seconds in a 32 bit register, and the
stored value is unsigned. Therefore this driver and device are ready
for the year 2038. However, more work will be needed prior to 2106.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This driver is 64 bit only, and so this driver and device are ready
for 2038. This patch changes the driver to the new PHC and also
carries the timespec64 parameter on out to the gxio_mpipe_get-
set_timestamp functions, making explicit the fact that the tv_sec
field is 64 bits wide.Not even compile tested.
Signed-off-by: Richard Cochran
Acked-by: Chris Metcalf
Signed-off-by: David S. Miller -
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This device stores the number of seconds in a 32 bit register. So
more work is needed on this driver before the year 2038 comes around.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This patch changes the driver to use the newer API.
Depending on how the hardware represents a time value, this driver may
or may not yet be ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Acked-by: Jeff Kirsher
Signed-off-by: David S. Miller -
For the 82576, the driver's clock is implemented using a timecounter,
and so with this patch that device is ready for the year 2038.However, in the case of the i210, the device stores the number of
seconds in a 32 bit register. Therefore, more work is needed on this
driver before the year 2038 comes around.Compile tested only.
Signed-off-by: Richard Cochran
Acked-by: Jeff Kirsher
Signed-off-by: David S. Miller -
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Acked-by: Jeff Kirsher
Signed-off-by: David S. Miller -
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Acked-by: Jeff Kirsher
Signed-off-by: David S. Miller -
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Acked-by: Jeff Kirsher
Signed-off-by: David S. Miller -
The device features a 64 bit nanoseconds register, and so with this
patch the driver is ready for the year 2038.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Acked-by: Sony Chacko
Signed-off-by: David S. Miller -
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.Compile tested only.
Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
The device uses 64 bit nanoseconds register, and so with this patch the
driver is ready for the year 2038.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This patch changes the posix clock code to prefer the new methods
whenever they are implemented by the PHC drivers.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
This patch changes the code to use the new method whenever implemented by
the PHC driver.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller -
Converting the PHC drivers over to the new methods is one step along the
way to making them ready for 2038. Once all the drivers are up to date,
then the old methods will be removed.Signed-off-by: Richard Cochran
Signed-off-by: David S. Miller
30 Mar, 2015
2 commits
-
A message sent to a node after a successful name table lookup may still
find that the destination socket has disappeared, because distribution
of name table updates is non-atomic. If so, the message will be rejected
back to the sender with error code TIPC_ERR_NO_PORT. If the source
socket of the message has disappeared in the meantime, the message
should be dropped.However, in the currrent code, the message will instead be subject to an
unwanted tertiary lookup, because the function tipc_msg_lookup_dest()
doesn't check if there is an error code present in the message before
performing the lookup. In the worst case, the message may now find the
old destination again, and be redirected once more, instead of being
dropped directly as it should be.A second bug in this function is that the "prev_node" field in the message
is not updated after successful lookup, something that may have
unpredictable consequences.The problems arising from those bugs occur very infrequently.
The third change in this function; the test on msg_reroute_msg_cnt() is
purely cosmetic, reflecting that the returned value never can be negative.This commit corrects the two bugs described above.
Signed-off-by: Jon Maloy
Signed-off-by: David S. Miller -
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2015-03-27This series contains updates to i40e and i40evf.
Jesse adds new device IDs to handle the new 20G speed for KR2.
Mitch provides a fix for an issue that shows up as a panic or memory
corruption when the device is brought down while under heavy stress.
This is resolved by delaying the releasing of resources until we
receive acknowledgment from the PF driver that the rings have indeed
been stopped. Also adds firmware version information to ethtool
reporting to align with ixgbevf behavior.Akeem increases the polling loop limiter, sine we found that in
certain circumstances the firmware can take longer to be ready after
a reset.
====================Signed-off-by: David S. Miller
