26 Apr, 2018
1 commit
-
[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ]
At least some JMicron controllers issue buggy oversized DMA reads when
fetching context descriptors, always fetching 0x20 bytes at once for
descriptors which are only 0x10 bytes long. This is often harmless, but
can cause page faults on modern systems with IOMMUs:DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set
firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_readThis works around the problem by always leaving 0x10 padding bytes at
the end of descriptor buffer pages, which should be harmless to do
unconditionally for controllers in case others have the same behavior.Signed-off-by: Hector Martin
Reviewed-by: Clemens Ladisch
Signed-off-by: Stefan Richter
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
16 Jun, 2017
2 commits
-
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.An spatch similar to the one for skb_put_zero() converts many
of the places using it:@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger
Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller
23 Mar, 2017
1 commit
-
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
Signed-off-by: Greg Kroah-Hartman
01 Mar, 2017
1 commit
-
Pull IDR rewrite from Matthew Wilcox:
"The most significant part of the following is the patch to rewrite the
IDR & IDA to be clients of the radix tree. But there's much more,
including an enhancement of the IDA to be significantly more space
efficient, an IDR & IDA test suite, some improvements to the IDR API
(and driver changes to take advantage of those improvements), several
improvements to the radix tree test suite and RCU annotations.The IDR & IDA rewrite had a good spin in linux-next and Andrew's tree
for most of the last cycle. Coupled with the IDR test suite, I feel
pretty confident that any remaining bugs are quite hard to hit. 0-day
did a great job of watching my git tree and pointing out problems; as
it hit them, I added new test-cases to be sure not to be caught the
same way twice"Willy goes on to expand a bit on the IDR rewrite rationale:
"The radix tree and the IDR use very similar data structures.Merging the two codebases lets us share the memory allocation pools,
and results in a net deletion of 500 lines of code. It also opens up
the possibility of exposing more of the features of the radix tree to
users of the IDR (and I have some interesting patches along those
lines waiting for 4.12)It also shrinks the size of the 'struct idr' from 40 bytes to 24 which
will shrink a fair few data structures that embed an IDR"* 'idr-4.11' of git://git.infradead.org/users/willy/linux-dax: (32 commits)
radix tree test suite: Add config option for map shift
idr: Add missing __rcu annotations
radix-tree: Fix __rcu annotations
radix-tree: Add rcu_dereference and rcu_assign_pointer calls
radix tree test suite: Run iteration tests for longer
radix tree test suite: Fix split/join memory leaks
radix tree test suite: Fix leaks in regression2.c
radix tree test suite: Fix leaky tests
radix tree test suite: Enable address sanitizer
radix_tree_iter_resume: Fix out of bounds error
radix-tree: Store a pointer to the root in each node
radix-tree: Chain preallocated nodes through ->parent
radix tree test suite: Dial down verbosity with -v
radix tree test suite: Introduce kmalloc_verbose
idr: Return the deleted entry from idr_remove
radix tree test suite: Build separate binaries for some tests
ida: Use exceptional entries for small IDAs
ida: Move ida_bitmap to a percpu variable
Reimplement IDR and IDA using the radix tree
radix-tree: Add radix_tree_iter_delete
...
28 Feb, 2017
1 commit
-
Fix typos and add the following to the scripts/spelling.txt:
intialization||initialization
The "inintialization" in drivers/acpi/spcr.c is a different pattern but
I fixed it as well in this commit.Link: http://lkml.kernel.org/r/1481573103-11329-16-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Feb, 2017
1 commit
-
It is a relatively common idiom (8 instances) to first look up an IDR
entry, and then remove it from the tree if it is found, possibly doing
further operations upon the entry afterwards. If we change idr_remove()
to return the removed object, all of these users can save themselves a
walk of the IDR tree.Signed-off-by: Matthew Wilcox
15 Nov, 2016
1 commit
-
Several cases of bug fixes in 'net' overlapping other changes in
'net-next-.Signed-off-by: David S. Miller
03 Nov, 2016
2 commits
-
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter -
The IP-over-1394 driver firewire-net lacked input validation when
handling incoming fragmented datagrams. A maliciously formed fragment
with a respectively large datagram_offset would cause a memcpy past the
datagram buffer.So, drop any packets carrying a fragment with offset + length larger
than datagram_size.In addition, ensure that
- GASP header, unfragmented encapsulation header, or fragment
encapsulation header actually exists before we access it,
- the encapsulated datagram or fragment is of nonzero size.Reported-by: Eyal Itkin
Reviewed-by: Eyal Itkin
Fixes: CVE 2016-8633
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter
31 Oct, 2016
1 commit
-
Mostly simple overlapping changes.
For example, David Ahern's adjacency list revamp in 'net-next'
conflicted with an adjacency list traversal bug fix in 'net'.Signed-off-by: David S. Miller
30 Oct, 2016
1 commit
-
The maximum unicast datagram size /without/ link fragmentation is
4096 - 4 = 4092 (max IEEE 1394 async payload size at >= S800 bus speed,
minus unfragmented encapssulation header). Max broadcast datagram size
without fragmentation is 8 bytes less than that (due to GASP header).The maximum datagram size /with/ link fragmentation is 0xfff = 4095
for unicast and broadcast. This is because the RFC 2734 fragment
encapsulation header field for datagram size is only 12 bits wide.Fixes: 5d48f00d836a('firewire: net: fix maximum possible MTU')
Signed-off-by: Stefan Richter
Signed-off-by: David S. Miller
27 Oct, 2016
2 commits
-
firewire-net, like the older eth1394 driver, reduced the initial MTU to
less than 1500 octets if the local link layer controller's asynchronous
packet reception limit was lower.This is bogus, since this reception limit does not have anything to do
with the transmission limit. Neither did this reduction affect the TX
path positively, nor could it prevent link fragmentation at the RX path.Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
of 1024 - 16 = 1008. RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
which would result in an initial MTU of 512 - 16 = 496. On such cards,
IPv6 could only be employed if the MTU was manually increased to 1280 or
more, i.e. IPv6 would not work without intervention from userland.We now always initialize the MTU to 1500, which is the default according
to RFC 2734 and RFC 3146.On a VIA VT6316 based CardBus card which was affected by this, changing
the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
RX remains unaffected.CC: netdev@vger.kernel.org
CC: linux1394-devel@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
Signed-off-by: David S. Miller -
Commit b3e3893e1253 ("net: use core MTU range checking in misc drivers")
mistakenly introduced an upper limit for firewire-net's MTU based on the
local link layer controller's reception capability. Revert this. Neither
RFC 2734 nor our implementation impose any particular upper limit.Actually, to be on the safe side and to make the code explicit, set
ETH_MAX_MTU = 65535 as upper limit now.(I replaced sizeof(struct rfc2734_header) by the equivalent
RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)Fixes: b3e3893e1253('net: use core MTU range checking in misc drivers')
CC: netdev@vger.kernel.org
CC: linux1394-devel@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
Acked-by: Jarod Wilson
Signed-off-by: David S. Miller
21 Oct, 2016
1 commit
-
firewire-net:
- set min/max_mtu
- remove fwnet_change_mtunes:
- set max_mtu
- clean up nes_netdev_change_mtuxpnet:
- set min/max_mtu
- remove xpnet_dev_change_mtuhippi:
- set min/max_mtu
- remove hippi_change_mtubatman-adv:
- set max_mtu
- remove batadv_interface_change_mtu
- initialization is a little async, not 100% certain that max_mtu is set
in the optimal place, don't have hardware to test withrionet:
- set min/max_mtu
- remove rionet_change_mtuslip:
- set min/max_mtu
- streamline sl_change_mtuum/net_kern:
- remove pointless ndo_change_mtuhsi/clients/ssi_protocol:
- use core MTU range checking
- remove now redundant ssip_pn_set_mtuipoib:
- set a default max MTU value
- Note: ipoib's actual max MTU can vary, depending on if the device is in
connected mode or not, so we'll just set the max_mtu value to the max
possible, and let the ndo_change_mtu function continue to validate any new
MTU change requests with checks for CM or not. Note that ipoib has no
min_mtu set, and thus, the network core's mtu > 0 check is the only lower
bounds here.mptlan:
- use net core MTU range checking
- remove now redundant mpt_lan_change_mtufddi:
- min_mtu = 21, max_mtu = 4470
- remove now redundant fddi_change_mtu (including export)fjes:
- min_mtu = 8192, max_mtu = 65536
- The max_mtu value is actually one over IP_MAX_MTU here, but the idea is to
get past the core net MTU range checks so fjes_change_mtu can validate a
new MTU against what it supports (see fjes_support_mtu in fjes_hw.c)hsr:
- min_mtu = 0 (calls ether_setup, max_mtu is 1500)f_phonet:
- min_mtu = 6, max_mtu = 65541u_ether:
- min_mtu = 14, max_mtu = 15412phonet/pep-gprs:
- min_mtu = 576, max_mtu = 65530
- remove redundant gprs_set_mtuCC: netdev@vger.kernel.org
CC: linux-rdma@vger.kernel.org
CC: Stefan Richter
CC: Faisal Latif
CC: linux-rdma@vger.kernel.org
CC: Cliff Whickman
CC: Robin Holt
CC: Jes Sorensen
CC: Marek Lindner
CC: Simon Wunderlich
CC: Antonio Quartulli
CC: Sathya Prakash
CC: Chaitra P B
CC: Suganath Prabu Subramani
CC: MPT-FusionLinux.pdl@broadcom.com
CC: Sebastian Reichel
CC: Felipe Balbi
CC: Arvid Brodin
CC: Remi Denis-Courmont
Signed-off-by: Jarod Wilson
Signed-off-by: David S. Miller
09 Oct, 2016
1 commit
-
There is no check if ioremap_nocache() returns a valid pointer.
Potentially it can lead to null pointer dereference.Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Signed-off-by: Stefan Richter (renamed goto labels)
05 May, 2016
1 commit
-
Replace all trans_start updates with netif_trans_update helper.
change was done via spatch:struct net_device *d;
@@
- d->trans_start = jiffies
+ netif_trans_update(d)Compile tested only.
Cc: user-mode-linux-devel@lists.sourceforge.net
Cc: linux-xtensa@linux-xtensa.org
Cc: linux1394-devel@lists.sourceforge.net
Cc: linux-rdma@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: MPT-FusionLinux.pdl@broadcom.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-can@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-hams@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: devel@driverdev.osuosl.org
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: linux-bluetooth@vger.kernel.org
Signed-off-by: Florian Westphal
Acked-by: Felipe Balbi
Acked-by: Mugunthan V N
Acked-by: Antonio Quartulli
Signed-off-by: David S. Miller
25 Mar, 2016
1 commit
-
Pull firewire leftover from Stefan Richter:
"Occurrences of timeval were supposed to be eliminated last round, now
remove a last forgotten one"* tag 'firewire-update2' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: nosy: Replace timeval with timespec64
23 Mar, 2016
1 commit
-
Firewire was using is_compat_task to check whether it was in a compat
ioctl or a non-compat ioctl. Use is_compat_syscall instead so it works
properly on all architectures.Signed-off-by: Andy Lutomirski
Cc: Clemens Ladisch
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Mar, 2016
1 commit
-
'struct timeval' uses a 32 bit field for its 'seconds' value which
will overflow in year 2038 and beyond. This patch replaces the use
of timeval in nosy.c with timespec64 which doesn't suffer from y2038
issue. The code is correct as is - since it is only using the
microseconds portion of timeval. However, this patch does the
replacement as part of a larger effort to remove all instances of
'struct timeval' from the kernel (that would help identify cases
where the code is actually broken).Signed-off-by: Tina Ruchandani
Reviewed-by: Arnd Bergmann
Signed-off-by: Stefan Richter
20 Mar, 2016
1 commit
-
Pull firewire updates from Stefan Richter:
"IEEE 1394 subsystem patches:- move away from outmoded timekeeping API
- error reporting fix
- documentation bits"* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ABI documentation: libhinawa uses firewire-cdev
firewire: ABI documentation: jujuutils were renamed to linux-firewire-utils
firewire: ohci: propagate return code from soft_reset to probe and resume
firewire: nosy: Replace timeval with timespec64
12 Nov, 2015
1 commit
-
Pull firewire fix from Stefan Richter:
"Work around JMicron initialization quirk, which ffected isochronous
transmission, e.g. audio via FFADO or ALSA"* tag 'firewire-update' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: fix JMicron JMB38x IT context discovery
07 Nov, 2015
1 commit
-
…d avoiding waking kswapd
__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts. They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve". __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".Over time, callers had a requirement to not block when fallback options
were available. Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative. High priority users continue to use
__GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim. __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.This patch then converts a number of sites
o __GFP_ATOMIC is used by callers that are high priority and have memory
pools for those requests. GFP_ATOMIC uses this flag.o Callers that have a limited mempool to guarantee forward progress clear
__GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
into this category where kswapd will still be woken but atomic reserves
are not used as there is a one-entry mempool to guarantee progress.o Callers that are checking if they are non-blocking should use the
helper gfpflags_allow_blocking() where possible. This is because
checking for __GFP_WAIT as was done historically now can trigger false
positives. Some exceptions like dm-crypt.c exist where the code intent
is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
flag manipulations.o Callers that built their own GFP flags instead of starting with GFP_KERNEL
and friends now also need to specify __GFP_KSWAPD_RECLAIM.The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL. They may
now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
05 Nov, 2015
3 commits
-
software_reset() may fail
- due to unresponsive chip with -EBUSY (-16), or
- due to ejected or unseated card with -ENODEV (-19).
Let the PCI probe and resume routines log the actual error code instead
of hardwired -EBUSY.Signed-off-by: Stefan Richter
-
32 bit systems using 'struct timeval' will break in the year 2038, so
we replace the code appropriately. However, this driver is not broken
in 2038 since we are using only the microseconds portion of the
current time.This patch replaces timeval with timespec64.
Signed-off-by: Amitoj Kaur Chawla
Reviewed-by: Arnd Bergmann
Signed-off-by: Stefan Richter -
Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
controllers: Often or even most of the time, the controller is
initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts
(IT contexts), applications like audio output are impossible.However, OHCI-1394 demands that at least 4 IT contexts are implemented
by the link layer controller, and indeed JMicron JMB38x do implement
four of them. Only their IsoXmitIntMask register is unreliable at early
access.With my own JMB381 single function controller I found:
- I can reproduce the problem with a lower probability than Craig's.
- If I put a loop around the section which clears and reads
IsoXmitIntMask, then either the first or the second attempt will
return the correct initial mask of 0x0000000f. I never encountered
a case of needing more than a second attempt.
- Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
before the first write, the subsequent read will return the correct
result.
- If I merely ignore a wrong read result and force the known real
result, later isochronous transmit DMA usage works just fine.So let's just fix this chip bug up by the latter method. Tested with
JMB381 on kernel 3.13 and 4.3.Since OHCI-1394 generally requires 4 IT contexts at a minium, this
workaround is simply applied whenever the initial read of IsoXmitIntMask
returns 0, regardless whether it's a JMicron chip or not. I never heard
of this issue together with any other chip though.I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
and JMB388 combo controllers exactly the same as on the JMB381 single-
function controller, but so far I haven't had a chance to let an owner
of a combo chip run a patched kernel.Strangely enough, IsoRecvIntMask is always reported correctly, even
though it is probed right before IsoXmitIntMask.Reported-by: Clifford Dunn
Reported-by: Craig Moore
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter
01 Jun, 2015
1 commit
-
'0' is now used as the default cmd_per_lun value,
so there's no need to explicitly set it to '1' in the
host template.Signed-off-by: Hannes Reinecke
Reviewed-by: Christoph Hellwig
Signed-off-by: James Bottomley
04 Mar, 2015
1 commit
-
Conflicts:
drivers/net/ethernet/rocker/rocker.cThe rocker commit was two overlapping changes, one to rename
the ->vport member to ->pport, and another making the bitmask
expression use '1ULL' instead of plain '1'.Signed-off-by: David S. Miller
03 Mar, 2015
1 commit
-
Now that there are no more users kill dev_rebuild_header and all of it's
implementations.This is long overdue.
Signed-off-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
03 Feb, 2015
1 commit
-
The kernel was using the vendor ID 0xd00d1e, which was inherited from
the old ieee1394 driver stack. However, this ID was not registered, and
invalid.Instead, use the vendor/model IDs that are now officially assigned to
the kernel:
https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments[stefanr:
- The vendor ID 001f11 is Openmoko, Inc.'s identifier, registered at
IEEE Registration Authority.
- The range of model IDs 023900...0239ff are the Linux kernel 1394
subsystem's identifiers, registered at Openmoko.
- Model ID 023901 is picked by the subsystem developers as
firewire-core's model ID.]Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter
31 Jan, 2015
1 commit
-
[Bart van Asche:] SCSI core never sets cmd->sc_data_direction to
DMA_BIDIRECTIONAL; scsi_bidi_cmnd(cmd) should be used instead to
test for a bidirectional command.[Christoph Hellwig:] Bidirectional commands won't ever be queued
anyway, unless a LLD or transport driver sets QUEUE_FLAG_BIDI.So, simply remove the respective queuecommand check in the SBP-2
transport driver.Signed-off-by: Stefan Richter
22 Jan, 2015
1 commit
-
Remove the function ar_prev_buffer_index() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
Signed-off-by: Stefan Richter
11 Dec, 2014
4 commits
-
firewire-core uses fw_card.lock to protect topology data and transaction
data. firewire-sbp2 uses fw_card.lock for entirely unrelated purposes.Introduce a sbp2_target.lock to firewire-sbp2 and replace all
fw_card.lock uses in the driver. fw_card.lock is now entirely private
to firewire-core. This has no immediate advantage apart from making it
clear in the code that firewire-sbp2 does not interact with the core
via the core lock.Signed-off-by: Stefan Richter
-
Users of card->lock Calling context
------------------------------------------------------------------------
sbp2_status_write AR-req handler, tasklet
complete_transaction AR-resp or AT-req handler, tasklet
sbp2_send_orb among else scsi host .queuecommand, which may
be called in some sort of atomic context
sbp2_cancel_orbs sbp2_send_management_orb/
sbp2_{login,reconnect,remove},
worklet or process
sbp2_scsi_abort, scsi eh thread
sbp2_allow_block sbp2_login, worklet
sbp2_conditionally_block among else complete_command_orb, tasklet
sbp2_conditionally_unblock sbp2_{login,reconnect}, worklet
sbp2_unblock sbp2_{login,remove}, worklet or processDrop the IRQ flags saving from sbp2_cancel_orbs,
sbp2_conditionally_unblock, and sbp2_unblock.
It was already omitted in sbp2_allow_block.Signed-off-by: Stefan Richter
-
The assertion in the comment in sbp2_allow_block() is no longer true.
Or maybe it never was true. At least now, the sole caller of
sbp2_allow_block(), sbp2_login, can run concurrently to one of
sbp2_unblock()'s callers, sbp2_remove.sbp2_login is performed by sbp2_logical_unit.work.
sbp2_remove is performed by fw_device.work.
sbp2_remove cancels sbp2_logical_unit.work, but only after it called
sbp2_unblock.Signed-off-by: Stefan Richter
-
fw_csr_string() truncates and terminates target strings like strlcpy()
does. Unlike strlcpy(), it returns the target strlen, not the source
strlen, hence users of fw_csr_string() are unable to detect truncation.Point this behavior out in the kerneldoc comment.
Signed-off-by: Stefan Richter
Reviewed-by: Takashi Sakamoto
19 Nov, 2014
1 commit
-
vm_map_ram() is intended for short-lived objects, so using it for the AR
buffers could fragment address space, especially on a 32-bit machine.
For an allocation that lives as long as the device, vmap() is the better
choice.Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter
14 Nov, 2014
1 commit
-
Found by the UC-KLEE tool: A user could supply less input to
firewire-cdev ioctls than write- or write/read-type ioctl handlers
expect. The handlers used data from uninitialized kernel stack then.This could partially leak back to the user if the kernel subsequently
generated fw_cdev_event_'s (to be read from the firewire-cdev fd)
which notably would contain the _u64 closure field which many of the
ioctl argument structures contain.The fact that the handlers would act on random garbage input is a
lesser issue since all handlers must check their input anyway.The fix simply always null-initializes the entire ioctl argument buffer
regardless of the actual length of expected user input. That is, a
runtime overhead of memset(..., 40) is added to each firewirew-cdev
ioctl() call. [Comment from Clemens Ladisch: This part of the stack is
most likely to be already in the cache.]Remarks:
- There was never any leak from kernel stack to the ioctl output
buffer itself. IOW, it was not possible to read kernel stack by a
read-type or write/read-type ioctl alone; the leak could at most
happen in combination with read()ing subsequent event data.
- The actual expected minimum user input of each ioctl from
include/uapi/linux/firewire-cdev.h is, in bytes:
[0x00] = 32, [0x05] = 4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16,
[0x01] = 36, [0x06] = 20, [0x0b] = 4, [0x10] = 20, [0x15] = 20,
[0x02] = 20, [0x07] = 4, [0x0c] = 0, [0x11] = 0, [0x16] = 8,
[0x03] = 4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12,
[0x04] = 20, [0x09] = 24, [0x0e] = 4, [0x13] = 40, [0x18] = 4.Reported-by: David Ramos
Cc:
Signed-off-by: Stefan Richter
07 Aug, 2014
1 commit
-
Pull networking updates from David Miller:
"Highlights:1) Steady transitioning of the BPF instructure to a generic spot so
all kernel subsystems can make use of it, from Alexei Starovoitov.2) SFC driver supports busy polling, from Alexandre Rames.
3) Take advantage of hash table in UDP multicast delivery, from David
Held.4) Lighten locking, in particular by getting rid of the LRU lists, in
inet frag handling. From Florian Westphal.5) Add support for various RFC6458 control messages in SCTP, from
Geir Ola Vaagland.6) Allow to filter bridge forwarding database dumps by device, from
Jamal Hadi Salim.7) virtio-net also now supports busy polling, from Jason Wang.
8) Some low level optimization tweaks in pktgen from Jesper Dangaard
Brouer.9) Add support for ipv6 address generation modes, so that userland
can have some input into the process. From Jiri Pirko.10) Consolidate common TCP connection request code in ipv4 and ipv6,
from Octavian Purdila.11) New ARP packet logger in netfilter, from Pablo Neira Ayuso.
12) Generic resizable RCU hash table, with intial users in netlink and
nftables. From Thomas Graf.13) Maintain a name assignment type so that userspace can see where a
network device name came from (enumerated by kernel, assigned
explicitly by userspace, etc.) From Tom Gundersen.14) Automatic flow label generation on transmit in ipv6, from Tom
Herbert.15) New packet timestamping facilities from Willem de Bruijn, meant to
assist in measuring latencies going into/out-of the packet
scheduler, latency from TCP data transmission to ACK, etc"* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1536 commits)
cxgb4 : Disable recursive mailbox commands when enabling vi
net: reduce USB network driver config options.
tg3: Modify tg3_tso_bug() to handle multiple TX rings
amd-xgbe: Perform phy connect/disconnect at dev open/stop
amd-xgbe: Use dma_set_mask_and_coherent to set DMA mask
net: sun4i-emac: fix memory leak on bad packet
sctp: fix possible seqlock seadlock in sctp_packet_transmit()
Revert "net: phy: Set the driver when registering an MDIO bus device"
cxgb4vf: Turn off SGE RX/TX Callback Timers and interrupts in PCI shutdown routine
team: Simplify return path of team_newlink
bridge: Update outdated comment on promiscuous mode
net-timestamp: ACK timestamp for bytestreams
net-timestamp: TCP timestamping
net-timestamp: SCHED timestamp on entering packet scheduler
net-timestamp: add key to disambiguate concurrent datagrams
net-timestamp: move timestamp flags out of sk_flags
net-timestamp: extend SCM_TIMESTAMPING ancillary data struct
cxgb4i : Move stray CPL definitions to cxgb4 driver
tcp: reduce spurious retransmits due to transient SACK reneging
qlcnic: Initialize dcbnl_ops before register_netdev
...