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
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
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
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
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
16 Jul, 2014
1 commit
-
Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
all users to pass NET_NAME_UNKNOWN.Coccinelle patch:
@@
expression sizeof_priv, name, setup, txqs, rxqs, count;
@@(
-alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
+alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
|
-alloc_netdev_mq(sizeof_priv, name, setup, count)
+alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
|
-alloc_netdev(sizeof_priv, name, setup)
+alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
)v9: move comments here from the wrong commit
Signed-off-by: Tom Gundersen
Reviewed-by: David Herrmann
Signed-off-by: David S. Miller
12 May, 2014
1 commit
-
"dev" and "net" are NULL when alloc_netdev() is failed.
So just unlock and return an error.Signed-off-by: Daeseok Youn
Signed-off-by: Stefan Richter
28 Feb, 2014
1 commit
-
Commit 8408dc1c14c1 "firewire: net: use dev_printk API" introduced a
use-after-free in a failure path. fwnet_transmit_packet_failed(ptask)
may free ptask, then the dev_err() call dereferenced it. The fix is
straightforward; simply reorder the two calls.Reported-by: Dan Carpenter
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Stefan Richter
10 Jun, 2013
1 commit
-
FireWire upper layer drivers are converted from generic
struct driver.probe() and .remove()
to bus-specific
struct fw_driver.probe() and .remove().The new .probe() adds a const struct ieee1394_device_id *id argument,
indicating the entry in the driver's device identifiers table which
matched the fw_unit to be probed. This new argument is used by the
snd-firewire-speakers driver to look up device-specific parameters and
methods. There is at least one other FireWire audio driver currently in
development in which this will be useful too.The new .remove() drops the unused error return code.
Although all in-tree drivers are being converted to the new methods,
support for the old methods is left in place in this commit. This
allows public developer trees to merge this commit and then move to the
new fw_driver methods.Signed-off-by: Stefan Richter
Acked-by: Clemens Ladisch (for sound/firewire/)
Cc: Peter Hurley (for drivers/staging/fwserial/)
10 May, 2013
1 commit
-
Pull firewure updates from Stefan Richter:
- fix controller removal when controller is in suspended state
- fix video reception on VIA VT6306 with gstreamer, MythTV, and maybe dv4l
- fix a startup issue with Agere/LSI FW643-e2
- error logging improvements and other small updates* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: dump_stack() for PHY regs read/write failures
firewire: ohci: Improve bus reset error messages
firewire: ohci: Alias dev_* log functions
firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8
firewire: ohci: fix VIA VT6306 video reception
firewire: ohci: Check LPS before register access on pci removal
firewire: ohci: Fix double free_irq()
firewire: remove unnecessary alloc/OOM messages
firewire: sbp2: replace BUG_ON by WARN_ON
firewire: core: remove an always false test
firewire: Remove two unneeded checks for macros
29 Apr, 2013
1 commit
-
These are redundant to log messages from the mm core.
Signed-off-by: Stefan Richter
28 Mar, 2013
1 commit
-
Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
an 802.3 frame. Frames with a lower value in the ethernet type field
are Ethernet II.Also update all the users of this value that David Miller and
I could find to use the new constant.Also correct a bug in util.c. The comparison with ETH_P_802_3_MIN
should be >= not >.As suggested by Jesse Gross.
Compile tested only.
Cc: David Miller
Cc: Jesse Gross
Cc: Karsten Keil
Cc: John W. Linville
Cc: Johannes Berg
Cc: Bart De Schuymer
Cc: Stephen Hemminger
Cc: Patrick McHardy
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: linux-bluetooth@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
Cc: bridge@lists.linux-foundation.org
Cc: linux-wireless@vger.kernel.org
Cc: linux1394-devel@lists.sourceforge.net
Cc: linux-media@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: dev@openvswitch.org
Acked-by: Mauro Carvalho Chehab
Acked-by: Stefan Richter
Signed-off-by: Simon Horman
Signed-off-by: David S. Miller
27 Mar, 2013
6 commits
-
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller -
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.CC: Stephan Gatzka
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller -
Stefan Richter says:
| As far as I can tell, it would be best to ignore max_rec and sspd from ARP
| and NDP but keep using the respective information from firewire-core
| instead (handed over by fwnet_probe()).
|
| Why? As I noted earlier, RFC 2734:1999 and RFC 3146:2001 were apparently
| written with a too simplistic notion of IEEE 1394 bus topology, resulting
| in max_rec and sspd in ARP-1394 and NDP-1394 to be useless, IMO.
|
| Consider a bus like this:
|
| A ---- B ==== C
|
| A, B, C are all IP-over-1394 capable nodes. ---- is an S400 cable hop,
| and ==== is an S800 cable hop.
|
| In case of unicasts or multicasts in which node A is involved as
| transmitter or receiver, as well as in case of broadcasts, the speeds
| S100, S200, S400 work and speed S400 is optimal.
|
| In case of anything else, IOW in case of unicasts or multicasts in which
| only nodes B and C are involved, the speeds S100, S200, S400, S800 work
| and speed S800 is optimal.
|
| Clearly, node A should indicate sspd = S400 in its ARP or NDP packets.
| But which sspd should nodes B and C set there? Maybe they set S400, which
| would work but would waste half of the available bandwidth in the second
| case. Or maybe they set S800, which is OK in the second case but would
| prohibit any communication with node A if blindly taken for correct.
|
| On the other hand, firewire-core *always* gives us the correct and optimum
| peer-to-peer speed and asynchronous packet payload, no matter how simple
| or complex the bus topology is and no matter in which temporal order nodes
| join the bus and are discovered.CC: Stefan Richter
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller -
Allocate FIFO address before registering net_device.
This is preparation to change the pseudo hardware address format
for firewire devices to include the offset of the FIFO for receipt
of unicast datagrams, instead of mangling ARP/NDP messages in the
driver layer.Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller -
Send L2 multicast packet via GASP (Global asynchronous stream packet) by
seeing the multicast bit in the L2 hardware address, not by seeing upper-
layer protocol address.Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller
13 Mar, 2013
11 commits
-
Since those resources are allocated on ifup, relsase them on ifdown.
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
dev->broadcast_rcv_context is always non-NULL if dev->broadcast_state is
not FWNET_BROADCAST_ERROR.Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
…struction of context.
Clear dev->broadcast_rcv_context to NULL and set dev->broadcast_state
to FWNET_BROADCAST_ERROR after descruction of broadcast context.Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter -
fwnet_broadcast_start() try to register address handler at first
if it was not registered yet; dev->local_fifo ==
FWNET_NO_FIFO_ADDR.Since dev->local_info not changed if fw_core_add_address_hander()
has failed, we do not need to set dev->local_info to
FWNET_NO_FIFO_ADDR.Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: Stefan Richter
21 Jan, 2013
2 commits
-
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller -
It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless
the device has already checked it.Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller
03 Dec, 2012
2 commits
-
The variable card is initialized but never used
otherwise, so remove the unused variable.Signed-off-by: Wei Yongjun
Signed-off-by: Stefan Richter -
This patch fixes both the transmit and receive portion of sending
fragmented mutlicast and broadcast packets.The transmit section was broken because the offset for INTFRAG and
LASTFRAG packets were just miscalculated by IEEE1394_GASP_HDR_SIZE (which
was reserved with skb_push() in fwnet_send_packet).The receive section was broken because in fwnet_incoming_packet is a call
to fwnet_peer_find_by_node_id(). Called with generation == -1 it will
not find a peer and the partial datagrams are associated to a peer.[Stefan R: The fix to use context->card->generation is not perfect.
It relies on the IR tasklet which processes packets from the prior bus
generation to run before the self-ID-complete worklet which sets the
current card generation. Alas, there is no simple way of a race-free
implementation. Let's do it this way for now.]Signed-off-by: Stephan Gatzka
Cc: stable
Signed-off-by: Stefan Richter
23 Feb, 2012
1 commit
-
Change the log line prefix from "firewire_net: " to "net firewire0: "
etc. for the case that several RFC 2734 interfaces are being used in the
same machine.Note, the netdev_printk API is not very useful to firewire-net.
netdev_notice(net, "abc\n") would result in irritating messages like
"firewire_ohci 0000:0a:00.0: firewire0: abc". Nor would a dev_printk on
the fw_unit.device to which firewire-net is being bound be useful,
because there are generally multiple ones of those per interface (from
all RFC 2734 peers on the bus, the local node being only one of them).In the initialization message of each interface, log the PCI device
name of the card which is parent of the netdevice instead of the GUID
of the peer which was semi-randomly used to establish the netdevice.Signed-off-by: Stefan Richter