* Re: [PATCH -next] net: stmmac: fix return value check in socfpga_dwmac_parse_data()
From: David Miller @ 2014-09-13 20:43 UTC (permalink / raw)
To: weiyj_lk; +Cc: peppe.cavallaro, yongjun_wei, netdev
In-Reply-To: <1410477177-5681-1-git-send-email-weiyj_lk@163.com>
From: weiyj_lk@163.com
Date: Fri, 12 Sep 2014 07:12:57 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function devm_ioremap_resource() returns
> ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] openvswitch: refactor ovs flow extract API.
From: David Miller @ 2014-09-13 20:47 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1410478084-1436-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Thu, 11 Sep 2014 16:28:04 -0700
> @@ -250,7 +251,7 @@ void ovs_dp_process_received_packet(struct vport *p, struct sk_buff *skb)
> stats = this_cpu_ptr(dp->stats_percpu);
>
> /* Extract flow from 'skb' into 'key'. */
> - error = ovs_flow_extract(skb, p->port_no, &key);
> + error = ovs_flow_key_extract(skb, &key);
> if (unlikely(error)) {
> kfree_skb(skb);
> return;
...
> @@ -611,5 +604,35 @@ int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct sw_flow_key *key)
> }
> }
>
> + OVS_CB(skb)->pkt_key = key;
> return 0;
Wow, have you really been putting pointers to kernel stack variables
into the SKB control block all this time?
That's error prone as well as asking for trouble.
Please adjust the code to not do this.
^ permalink raw reply
* Re: [PATCH net-next v2] r8152: support VLAN
From: David Miller @ 2014-09-13 20:49 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-37-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Fri, 12 Sep 2014 10:43:11 +0800
> Support hw VLAN for tx and rx. And enable them by default.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/2] r8169: fix rx vlan
From: David Miller @ 2014-09-13 20:53 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1394712342-15778-38-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Fri, 12 Sep 2014 11:35:10 +0800
> There are two issues for hw rx vlan. The patches are
> used to fix them.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: change tag_protocol to an enum
From: David Miller @ 2014-09-13 21:04 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, kernel, alexander.duyck
In-Reply-To: <1410495489-7050-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 11 Sep 2014 21:18:09 -0700
> Now that we introduced an additional multiplexing/demultiplexing layer
> with commit 3e8a72d1dae37 ("net: dsa: reduce number of protocol hooks")
> that lives within the DSA code, we no longer need to have a given switch
> driver tag_protocol be an actual ethertype value, instead, we can
> replace it with an enum: dsa_tag_protocol.
>
> Do this replacement in the drivers, which allows us to get rid of the
> cpu_to_be16()/htons() dance, and remove ETH_P_BRCMTAG since we do not
> need it anymore.
>
> Suggested-by: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v2:
> - removed now obsolete comment about the former ETH_P_BRCMTAG we did
> introduce earlier
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v4 2/9] net: filter: keep original BPF program around
From: David Miller @ 2014-09-13 21:05 UTC (permalink / raw)
To: dborkman; +Cc: eric.dumazet, ast, netdev, xemul
In-Reply-To: <54128E1B.7020407@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Fri, 12 Sep 2014 08:09:31 +0200
>> [PATCH] net: filter: fix possible use after free
>>
>> If kmemdup() fails, we free fp->orig_prog and return -ENOMEM
>>
>> sk_attach_filter()
>> -> sk_filter_uncharge(sk, fp)
>> -> sk_filter_release(fp)
>> -> call_rcu(&fp->rcu, sk_filter_release_rcu)
>> -> sk_filter_release_rcu()
>> -> sk_release_orig_filter()
>> fprog = fp->orig_prog; // not NULL, but points to freed memory
>> kfree(fprog->filter); // use after free, potential corruption
>> kfree(fprog); // double free or corruption
>>
>> Note: This was fixed in 3.17+ with commit 278571baca2a
>> ("net: filter: simplify socket charging")
>>
>> Found by AddressSanitizer
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Fixes: a3ea269b8bcdb ("net: filter: keep original BPF program around")
>
> Thanks Eric!
>
> Acked-by: Daniel Borkmann <dborkman@redhat.com>
Queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] net: filter: constify detection of pkt_type_offset
From: David Miller @ 2014-09-13 21:08 UTC (permalink / raw)
To: hannes
Cc: netdev, eric.dumazet, markos.chandras, schwidefsky, dborkman,
alexei.starovoitov, kda
In-Reply-To: <3e68956a7e5b8bb9de226bfcc09092c6852a0a0a.1410523297.git.hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 12 Sep 2014 14:04:43 +0200
> Currently we have 2 pkt_type_offset functions doing the same thing and
> spread across the architecture files. Remove those and replace them
> with a PKT_TYPE_OFFSET macro helper which gets the constant value from a
> zero sized sk_buff member right in front of the bitfield with offsetof.
> This new offset marker does not change size of struct sk_buff.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Markos Chandras <markos.chandras@imgtec.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Daniel Borkmann <dborkman@redhat.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
>
> v2) Incorporated Daniel's feedback. I first misinterpreted the feedback
> as something not related to pkt_type_offset.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/8] be2net: patch set
From: David Miller @ 2014-09-13 21:12 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1410523761-1744-1-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 12 Sep 2014 17:39:13 +0530
> Patch 1 fixes some minor issues with log messages in be2net.
>
> Patch 2 replaces strcpy() calls with strlcpy() to avoid possible buffer
> overflow.
>
> Patch 3 improves the RX buffer posting scheme for jumbo frames.
>
> Patch 4 replaces the use of v0 of SET_FLOW_CONTROL cmd with v1 to receive
> a definitive completion status from FW.
>
> Patch 5 adds support for ethtool "-m" ethtool option.
>
> Patch 6 fixes port-type reporting via ethtool get_settings for QSFP/SFP+
> interfaces.
>
> Patch 7 fixes the usage of MODIFY_EQD FW cmd to target a max of 8 EQs on
> Lancer chip.
>
> Patch 8 enables PCIe error reporting even for VFs.
>
> Pls consider applying this patch set to net-next. Thanks.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] bonding: fix div by zero while enslaving and transmitting
From: David Miller @ 2014-09-13 21:17 UTC (permalink / raw)
To: nikolay; +Cc: netdev, eric.dumazet, andy, j.vosburgh, vfalico
In-Reply-To: <1410536298-8022-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Fri, 12 Sep 2014 17:38:18 +0200
> The problem is that the slave is first linked and slave_cnt is
> incremented afterwards leading to a div by zero in the modes that use it
> as a modulus. What happens is that in bond_start_xmit()
> bond_has_slaves() is used to evaluate further transmission and it becomes
> true after the slave is linked in, but when slave_cnt is used in the xmit
> path it is still 0, so fetch it once and transmit based on that. Since
> it is used only in round-robin and XOR modes, the fix is only for them.
> Thanks to Eric Dumazet for pointing out the fault in my first try to fix
> this.
...
> Fixes: 278b208375 ("bonding: initial RCU conversion")
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> ---
> v2: Based on Eric's feedback change the fix to fetch the value once in a
> local variable in the affected modes and to act based on that.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] bridge: Two small fixes to vlan filtering code.
From: David Miller @ 2014-09-13 21:22 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, shemminger, makita.toshiaki, vyasevic
In-Reply-To: <1410553577-17519-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Fri, 12 Sep 2014 16:26:15 -0400
> This series corrects 2 small issues that I've ran across recently
> while doing more work with vlan filtering changes.
Series applied and patch #1 queue up for -stable.
^ permalink raw reply
* Re: [PATCH] net: DSA: Marvell mv88e6171 switch driver
From: David Miller @ 2014-09-13 21:27 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev, leitec
In-Reply-To: <1410559124-10495-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 12 Sep 2014 23:58:44 +0200
> This is the Marvell driver with some cleanups by Claudio Leite
> and myself.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, I took care of the tag_protocol conflict.
^ permalink raw reply
* Re: [Patch v4 net-next 00/12] net: fec: imx6sx multiqueue support
From: David Miller @ 2014-09-13 21:32 UTC (permalink / raw)
To: Frank.Li
Cc: b38611, netdev, lznuaa, shawn.guo, linux-arm-kernel, devicetree,
linux
In-Reply-To: <1410555657-10744-1-git-send-email-Frank.Li@freescale.com>
From: <Frank.Li@freescale.com>
Date: Sat, 13 Sep 2014 05:00:45 +0800
> From: Frank Li <Frank.Li@freescale.com>
>
> These patches enable i.MX6SX multi queue support.
> i.MX6SX support 3 queue and AVB feature.
>
> Change from v3 to v4
> - use "unsigned int" instead of "unsigned"
>
> Change from v2 to v3
> - fixed alignment requirement for ARM and NO-ARM platform
>
> Change from v1 to v2.
> - Change num_tx_queue to unsigned int
> - Avoid block non-dt platform
> - remove call netif_set_real_num_rx_queues
> - seperate multi queue patch two part, one is tx and rx handle, with fixed queue 0
> then other one is initilized multiqueue
> - use two difference alignment for tx and rx path
Series applied, thanks Frank.
^ permalink raw reply
* Re: [PATCHv2] net/macb: Add hardware revision information during probe
From: David Miller @ 2014-09-13 21:34 UTC (permalink / raw)
To: alexandre.belloni
Cc: linux-arm-kernel, nicolas.ferre, linux-kernel, netdev, voice.shen
In-Reply-To: <1410566269-16445-1-git-send-email-alexandre.belloni@free-electrons.com>
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date: Sat, 13 Sep 2014 01:57:49 +0200
> From: Bo Shen <voice.shen@atmel.com>
>
> Print the IP revision when probing.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> Changes in v2:
> - condense information on one line
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] netdevice: Support DSA tagging when DSA is built as a module
From: David Miller @ 2014-09-13 21:37 UTC (permalink / raw)
To: alexander.duyck; +Cc: netdev, f.fainelli, kernel
In-Reply-To: <20140913061142.28675.38168.stgit@ahduyck-workstation.home>
From: alexander.duyck@gmail.com
Date: Fri, 12 Sep 2014 23:12:46 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change corrects an error seen when DSA tagging is built as a module.
> Without this change it is not possible to get XDSA tagged frames as the
> test for tagging is stripped by the #ifdef check.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>
> v2: Just working out some kinks in my stgit config so that this patch is
> attributed to my intel.com address instead of my gmail.com address.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: bpf: correctly handle errors in sk_attach_filter()
From: David Miller @ 2014-09-13 21:38 UTC (permalink / raw)
To: sasha.levin
Cc: ast, keescook, hannes, dborkman, spender, netdev, linux-kernel
In-Reply-To: <1410581190-31922-1-git-send-email-sasha.levin@oracle.com>
From: Sasha Levin <sasha.levin@oracle.com>
Date: Sat, 13 Sep 2014 00:06:30 -0400
> Commit "net: bpf: make eBPF interpreter images read-only" has changed bpf_prog
> to be vmalloc()ed but never handled some of the errors paths of the old code.
>
> On error within sk_attach_filter (which userspace can easily trigger), we'd
> kfree() the vmalloc()ed memory, and leak the internal bpf_work_struct.
>
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Applied.
^ permalink raw reply
* [PATCH 001/001] IEEE 802.15.4: Add module parameter to mrf24j40 to allow use of external transmitters/receivers
From: Walter Mack @ 2014-09-14 1:37 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, linux-zigbee-devel,
netdev
Cc: linux-kernel
enhance module drivers/net/ieee802154/mrf24j40.c to allow designs that
use external transmitters/receivers.
Designs that use Microchip's MRF24J40 with external receivers and
transmitters require the chip to
be specifically programmed for this, by setting the "test mode register"
to 0xf.
In my testing, without this flag, I could only receive over a distance
of a few feet. Setting this flag allows
distances well above 100 feet.
The patch adds a module parameter module_param(ext_rx_tx, bool, 0). When
setting the parameter to true,
the driver configures the "test mode" register of the mrf24j40 device to
work with external tranmitters and receivers.
patch applies to kernel version:3.16.0-rc4csi-git-dirty, git: commit
cd3de83f147601356395b57a8673e9c5ff1e59d1
(I'm doing a patch submission the first time. If I'm doing this wrong, I
would appreciate feedback for how to do this better next time).
Signed-off-by: Walter J. Mack <wmack@componentsw.com>
---
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 4048062..18cff47 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -26,6 +26,10 @@
#include <net/mac802154.h>
#include <net/ieee802154.h>
+static bool ext_rx_tx = false ;
+module_param(ext_rx_tx, bool, 0);
+MODULE_PARM_DESC(ext_rx_tx, " turn on statemachine to manage external
tx/rx");
+
/* MRF24J40 Short Address Registers */
#define REG_RXMCR 0x00 /* Receive MAC control */
#define REG_PANIDL 0x01 /* PAN ID (low) */
@@ -63,6 +67,8 @@
#define REG_SLPCON1 0x220
#define REG_WAKETIMEL 0x222 /* Wake-up Time Match Value Low */
#define REG_WAKETIMEH 0x223 /* Wake-up Time Match Value High */
+#define REG_TESTMODE 0x22f /* test mode and state machine control
register */
+
#define REG_RX_FIFO 0x300 /* Receive FIFO */
/* Device configuration: Only channels 11-26 on page 0 are supported. */
@@ -669,6 +675,10 @@ static int mrf24j40_probe(struct spi_device *spi)
write_short_reg(devrec, REG_RFCTL, 0x0);
udelay(192);
+ if ( false != ext_rx_tx ){
+ write_long_reg(devrec, REG_TESTMODE, 0x0f);
+ }
+
/* Set RX Mode. RXMCR<1:0>: 0x0 normal, 0x1 promisc, 0x2 error */
ret = read_short_reg(devrec, REG_RXMCR, &val);
if (ret)
^ permalink raw reply related
* Re: [PATCHv3 net-next 2/3] sunvnet: allow admin to set sunvnet MTU
From: David L Stevens @ 2014-09-14 2:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140913.162101.515634682549373073.davem@davemloft.net>
On 09/13/2014 04:21 PM, David Miller wrote:
> I personally find this scheme where we pretend that the device can
> have an arbitrary MTU, when in fact the effective MTU is a product of
> the sub-ports, quite ugly.
I wouldn't say I like it, either, but the problem is that without it, we
are tied to the least common denominator. Anything that doesn't support
v1.6 of the VIO protocol is stuck at the low MTU and low throughput, and
since Solaris itself is limited to 16000, Linux, which can do 64K-1, is
also limited to 16000. On my hardware, the original we'd be tied to is
about 1Gbps, the 16000 is about 5.4Gbps, and the full linux-linux is about
8Gbps. So, a big penalty.
I think of it as an Ethernet connected to a virtual switch, and the ICMP
errors are for PMTUD are analogous to IGMP snooping. This is not an Ethernet
device alone-- those don't negotiate per-destination link MTUs. But nothing forces
anyone to mix MTUs; the ICMP errors simply allow it.
> In fact, that ugly ICMP stuff in the next patch is absolutely required
> to avoid bogus behavior possible after this patch. You have to
> combine #2 and #3 otherwise you are adding an intermediate regression.
I disagree here. It's not any more bogus for the admin to set an MTU value
of what s/he wants when the others have not been. It *always* happens that
way. Ordinary Ethernet comes up at 1500 and one of them must be increased
first. At that time, the others don't match, and it is the admin's responsibility
to make sure they match.
> Logic wise, at the very least you should limit the MTU setting to the
> largest MTU of all of the individual ports.
We can't directly do that, because the MTU for the port is negotiated at
probe time. That'll be 1500 IP data (always) and we have to raise one of them
first, so one of them has to be set at a higher value than the negotiated
MTU at some point, at least until it is reset and re-negotiated. But we
don't know until we try a higher value if all the links can use it, and we
can't prevent another link from joining later that has a lower MTU, but we
can't then lower our on MTU for the whole device.
I think in ordinary Ethernet, there is nothing at all enforcing a particular
MTU-- it is set to what the admin wants, regardless of what other hosts use.
That's the effect we ought to have here, despite the one-to-many p2p links
where we can know in advance what the link MTUs are, and that's what patch #2
does. I don't think we should try too hard to prevent a value an admin wants --
it will just get in the way of the admin, where it doesn't in ordinary Ethernet.
On the other hand, if the link MTU is lower, we shouldn't quietly drop packets, thus the ICMP
errors that allow both.
+-DLS
^ permalink raw reply
* Re: [PATCH net-next 3/3] sunvnet: generate ICMP PTMUD messages for smaller port MTUs
From: David L Stevens @ 2014-09-14 2:18 UTC (permalink / raw)
To: Sergei Shtylyov, David Miller; +Cc: netdev
In-Reply-To: <5414A6DF.1060301@cogentembedded.com>
On 09/13/2014 04:19 PM, Sergei Shtylyov wrote:
> Patch spoiled as well...
Yes, it was mangled by my mailer. I think PATCHv3, the latest I sent, is
ok, but please try that. And, of course, let me know if it doesn't work.
+-DLS
^ permalink raw reply
* Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: David L Stevens @ 2014-09-14 2:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140913.161842.2265200935397549583.davem@davemloft.net>
On 09/13/2014 04:18 PM, David Miller wrote:
> From: David L Stevens <david.stevens@oracle.com>
> Is this really applicable to devices other than sunvnet? Just keep
> this attribute in the sunvnet driver "struct vnet_port" private state.
Yes, I'll move it.
>
>> + /* v1.6 and higher, ACK with desired, supported mode, or NACK */
>> + if (vio->ver.major <= 1 && vio->ver.minor >= 6) {
> ...
>> + if (vio->ver.major <= 1 && vio->ver.minor < 2)
> ...
>> + /* for version < 1.2, VIO_DRING_MODE = 0x3 and no bitmask */
>> + if ((vio->ver.major <= 1 && vio->ver.minor < 2) &&
> ...
>> + if (vio->ver.major == 1 && vio->ver.minor < 3) {
> ...
>> + } else if (vio->ver.major == 1 && vio->ver.minor == 3) {
> ...
>> + } else {
> ...
>> + }
> ...
>> + /* for version >= 1.6, ACK packet mode we support */
>> + if (vio->ver.major <= 1 && vio->ver.minor >= 6) {
>
> These version tests give me a headache, and some of them accept
> impossible things like major version zero. If we only have major
> version 1 and later in our version lists, testing things like "major
> <= 1" makes no sense at all.
>
> That last test quoted above definitely looks wrong, it should
> be testing "major >= 1" if anything if it is trying to test
> "version >= 1.6"
Yes, that'd break at > v2.0 -- good catch.
> Sadly, I expect that we'll have more and more of these version tests
> over time. So why not make some generic helpers in the VIO or LDC
> layer?
>
> static inline bool vio_version_before(struct vio_driver_state *vio,
> u16 major, u16 minor)
> {
> u32 have = (u32)vio->major << 16 | vio->minor;
> u32 want = (u32)major << 16 | minor;
>
> return have < want;
> }
> static inline bool vio_version_after_eq(struct vio_driver_state *vio,
> u16 major, u16 minor)
> {
> u32 have = (u32)vio->major << 16 | vio->minor;
> u32 want = (u32)major << 16 | minor;
>
> return have >= want;
> }
>
> Something like that.
Sure. I was thinking about something like:
#define VIO_VER(major, minor) (((major)<<16)|(minor))
change the version struct to a 32-bit int, and do things like:
if (vio->ver > VIO_VER(1,6)) {
unless you have a preference. (?)
+-DLS
^ permalink raw reply
* Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: David Miller @ 2014-09-14 3:01 UTC (permalink / raw)
To: david.stevens; +Cc: netdev
In-Reply-To: <5414FFDD.9050509@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Sat, 13 Sep 2014 22:39:25 -0400
>
>
> On 09/13/2014 04:18 PM, David Miller wrote:
>> From: David L Stevens <david.stevens@oracle.com>
>
>> static inline bool vio_version_before(struct vio_driver_state *vio,
>> u16 major, u16 minor)
>> {
>> u32 have = (u32)vio->major << 16 | vio->minor;
>> u32 want = (u32)major << 16 | minor;
>>
>> return have < want;
>> }
>> static inline bool vio_version_after_eq(struct vio_driver_state *vio,
>> u16 major, u16 minor)
>> {
>> u32 have = (u32)vio->major << 16 | vio->minor;
>> u32 want = (u32)major << 16 | minor;
>>
>> return have >= want;
>> }
>>
>> Something like that.
>
> Sure. I was thinking about something like:
>
> #define VIO_VER(major, minor) (((major)<<16)|(minor))
>
> change the version struct to a 32-bit int, and do things like:
>
> if (vio->ver > VIO_VER(1,6)) {
>
> unless you have a preference. (?)
I hate wasting space in a structure just to avoid some harmless
casting in a helper function that is simply trying to optimize
a comparison.
That's why I suggested the inline helpers above, which arguments
are strongly typed.
^ permalink raw reply
* Re: [PATCH 001/001] IEEE 802.15.4: Add module parameter to mrf24j40 to allow use of external transmitters/receivers
From: Marcel Holtmann @ 2014-09-14 3:04 UTC (permalink / raw)
To: Walter Mack
Cc: Network Development, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <5414F163.6010309-9FD5hQ8esnfjYInlWOmUBg@public.gmane.org>
Hi Walter,
> enhance module drivers/net/ieee802154/mrf24j40.c to allow designs that use external transmitters/receivers.
>
> Designs that use Microchip's MRF24J40 with external receivers and transmitters require the chip to
> be specifically programmed for this, by setting the "test mode register" to 0xf.
>
> In my testing, without this flag, I could only receive over a distance of a few feet. Setting this flag allows
> distances well above 100 feet.
>
> The patch adds a module parameter module_param(ext_rx_tx, bool, 0). When setting the parameter to true,
> the driver configures the "test mode" register of the mrf24j40 device to work with external tranmitters and receivers.
>
> patch applies to kernel version:3.16.0-rc4csi-git-dirty, git: commit cd3de83f147601356395b57a8673e9c5ff1e59d1
>
> (I'm doing a patch submission the first time. If I'm doing this wrong, I would appreciate feedback for how to do this better next time).
comments do not belong in the commit message. And please send patches for IEEE 802.15.4 drivers to linux-wpan-u79uwXL29TY76Z2rM5mHXA@public.gmane.org mailing list.
> Signed-off-by: Walter J. Mack <wmack-9FD5hQ8esnfjYInlWOmUBg@public.gmane.org>
>
> ---
> diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
> index 4048062..18cff47 100644
> --- a/drivers/net/ieee802154/mrf24j40.c
> +++ b/drivers/net/ieee802154/mrf24j40.c
> @@ -26,6 +26,10 @@
> #include <net/mac802154.h>
> #include <net/ieee802154.h>
>
> +static bool ext_rx_tx = false ;
please fix the coding style here and not need for variable initialization.
> +module_param(ext_rx_tx, bool, 0);
The last parameter is the mode. You might want to use 0444 here at least.
> +MODULE_PARM_DESC(ext_rx_tx, " turn on statemachine to manage external tx/rx");
> +
> /* MRF24J40 Short Address Registers */
> #define REG_RXMCR 0x00 /* Receive MAC control */
> #define REG_PANIDL 0x01 /* PAN ID (low) */
> @@ -63,6 +67,8 @@
> #define REG_SLPCON1 0x220
> #define REG_WAKETIMEL 0x222 /* Wake-up Time Match Value Low */
> #define REG_WAKETIMEH 0x223 /* Wake-up Time Match Value High */
> +#define REG_TESTMODE 0x22f /* test mode and state machine control register */
> +
> #define REG_RX_FIFO 0x300 /* Receive FIFO */
>
> /* Device configuration: Only channels 11-26 on page 0 are supported. */
> @@ -669,6 +675,10 @@ static int mrf24j40_probe(struct spi_device *spi)
> write_short_reg(devrec, REG_RFCTL, 0x0);
> udelay(192);
>
> + if ( false != ext_rx_tx ){
> + write_long_reg(devrec, REG_TESTMODE, 0x0f);
> + }
> +
You need to read the coding style document and follow it.
> /* Set RX Mode. RXMCR<1:0>: 0x0 normal, 0x1 promisc, 0x2 error */
> ret = read_short_reg(devrec, REG_RXMCR, &val);
> if (ret)
Regards
Marcel
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: Raghuram Kothakota @ 2014-09-14 3:30 UTC (permalink / raw)
To: David L Stevens; +Cc: David Miller, netdev
In-Reply-To: <54146A42.1050703@oracle.com>
I have a question around bumping the sunvnet vio_version to 1.6.
Each of the versions from 1.0, have a specific feature or behavior defined in the
protocol, if a given version is negotiated then peers will assume the Guest
can handle all those feature/enhancement automatically. If a given feature
is not supported or implemented, it may be best to handle those cases gracefully.
For example, if version 1.3 or higher is negotiated, then Guest is assumed to
support vlan packet processing. If 1.5 or later is negotiated, then it is assumed
that the Guest will handle the physical link state notice messages. Ideally these
enhancements are implemented, as beyond this it would be harder to differentiate
if a given guest has the support for them. If not, validate to ensure they are
handled gracefully. For example, ensure a physical link state notification message
doesn't cause any functional issues such as logging unnecessary warning messages
or taking an adverse action such as resetting the channel etc.
-Raghuram
On Sep 13, 2014, at 9:01 AM, David L Stevens <david.stevens@oracle.com> wrote:
> This patch upgrades the sunvnet driver to support VIO protocol version 1.6.
> In particular, it adds per-port MTU negotiation, allowing MTUs other than
> ETH_FRAMELEN with ports using newer VIO protocol versions.
>
> Signed-off-by: David L Stevens <david.stevens@oracle.com>
> ---
> arch/sparc/include/asm/vio.h | 19 ++++++-
> arch/sparc/kernel/viohs.c | 14 ++++-
> drivers/net/ethernet/sun/sunvnet.c | 103 +++++++++++++++++++++++++++++------
> drivers/net/ethernet/sun/sunvnet.h | 1 +
> 4 files changed, 115 insertions(+), 22 deletions(-)
>
> diff --git a/arch/sparc/include/asm/vio.h b/arch/sparc/include/asm/vio.h
> index 5c0ebe7..da13e3b 100644
> --- a/arch/sparc/include/asm/vio.h
> +++ b/arch/sparc/include/asm/vio.h
> @@ -65,6 +65,7 @@ struct vio_dring_register {
> u16 options;
> #define VIO_TX_DRING 0x0001
> #define VIO_RX_DRING 0x0002
> +#define VIO_RX_DRING_DATA 0x0004
> u16 resv;
> u32 num_cookies;
> struct ldc_trans_cookie cookies[0];
> @@ -80,6 +81,8 @@ struct vio_dring_unregister {
> #define VIO_PKT_MODE 0x01 /* Packet based transfer */
> #define VIO_DESC_MODE 0x02 /* In-band descriptors */
> #define VIO_DRING_MODE 0x03 /* Descriptor rings */
> +/* in vers >= 1.2, VIO_DRING_MODE is 0x04 and transfer mode is a bitmask */
> +#define VIO_NEW_DRING_MODE 0x04
>
> struct vio_dring_data {
> struct vio_msg_tag tag;
> @@ -209,10 +212,20 @@ struct vio_net_attr_info {
> u8 addr_type;
> #define VNET_ADDR_ETHERMAC 0x01
> u16 ack_freq;
> - u32 resv1;
> + u8 plnk_updt;
> +#define PHYSLINK_UPDATE_NONE 0x00
> +#define PHYSLINK_UPDATE_STATE 0x01
> +#define PHYSLINK_UPDATE_STATE_ACK 0x02
> +#define PHYSLINK_UPDATE_STATE_NACK 0x03
> + u8 options;
> + u16 resv1;
> u64 addr;
> u64 mtu;
> - u64 resv2[3];
> + u16 cflags;
> +#define VNET_LSO_IPV4_CAPAB 0x0001
> + u16 ipv4_lso_maxlen;
> + u32 resv2;
> + u64 resv3[2];
> };
>
> #define VNET_NUM_MCAST 7
> @@ -368,6 +381,8 @@ struct vio_driver_state {
> char *name;
>
> struct vio_driver_ops *ops;
> +
> + u64 rmtu; /* remote MTU */
> };
>
> #define viodbg(TYPE, f, a...) \
> diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c
> index f8e7dd5..446438b 100644
> --- a/arch/sparc/kernel/viohs.c
> +++ b/arch/sparc/kernel/viohs.c
> @@ -426,6 +426,13 @@ static int process_dreg_info(struct vio_driver_state *vio,
> if (vio->dr_state & VIO_DR_STATE_RXREG)
> goto send_nack;
>
> + /* v1.6 and higher, ACK with desired, supported mode, or NACK */
> + if (vio->ver.major <= 1 && vio->ver.minor >= 6) {
> + if (!(pkt->options & VIO_TX_DRING))
> + goto send_nack;
> + pkt->options = VIO_TX_DRING;
> + }
> +
> BUG_ON(vio->desc_buf);
>
> vio->desc_buf = kzalloc(pkt->descr_size, GFP_ATOMIC);
> @@ -453,8 +460,11 @@ static int process_dreg_info(struct vio_driver_state *vio,
> pkt->tag.stype = VIO_SUBTYPE_ACK;
> pkt->dring_ident = ++dr->ident;
>
> - viodbg(HS, "SEND DRING_REG ACK ident[%llx]\n",
> - (unsigned long long) pkt->dring_ident);
> + viodbg(HS, "SEND DRING_REG ACK ident[%llx] "
> + "ndesc[%u] dsz[%u] opt[0x%x] ncookies[%u]\n",
> + (unsigned long long) pkt->dring_ident,
> + pkt->num_descr, pkt->descr_size, pkt->options,
> + pkt->num_cookies);
>
> len = (sizeof(*pkt) +
> (dr->ncookies * sizeof(struct ldc_trans_cookie)));
> diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
> index a4657a4..04c58b5 100644
> --- a/drivers/net/ethernet/sun/sunvnet.c
> +++ b/drivers/net/ethernet/sun/sunvnet.c
> @@ -15,6 +15,7 @@
> #include <linux/ethtool.h>
> #include <linux/etherdevice.h>
> #include <linux/mutex.h>
> +#include <linux/if_vlan.h>
>
> #include <asm/vio.h>
> #include <asm/ldc.h>
> @@ -39,6 +40,7 @@ MODULE_VERSION(DRV_MODULE_VERSION);
>
> /* Ordered from largest major to lowest */
> static struct vio_version vnet_versions[] = {
> + { .major = 1, .minor = 6 },
> { .major = 1, .minor = 0 },
> };
>
> @@ -65,6 +67,7 @@ static int vnet_send_attr(struct vio_driver_state *vio)
> struct vnet_port *port = to_vnet_port(vio);
> struct net_device *dev = port->vp->dev;
> struct vio_net_attr_info pkt;
> + int framelen = ETH_FRAME_LEN;
> int i;
>
> memset(&pkt, 0, sizeof(pkt));
> @@ -72,19 +75,40 @@ static int vnet_send_attr(struct vio_driver_state *vio)
> pkt.tag.stype = VIO_SUBTYPE_INFO;
> pkt.tag.stype_env = VIO_ATTR_INFO;
> pkt.tag.sid = vio_send_sid(vio);
> - pkt.xfer_mode = VIO_DRING_MODE;
> + if (vio->ver.major <= 1 && vio->ver.minor < 2)
> + pkt.xfer_mode = VIO_DRING_MODE;
> + else
> + pkt.xfer_mode = VIO_NEW_DRING_MODE;
> pkt.addr_type = VNET_ADDR_ETHERMAC;
> pkt.ack_freq = 0;
> for (i = 0; i < 6; i++)
> pkt.addr |= (u64)dev->dev_addr[i] << ((5 - i) * 8);
> - pkt.mtu = ETH_FRAME_LEN;
> + if (vio->ver.major == 1) {
> + if (vio->ver.minor > 3) {
> + if (vio->rmtu) {
> + vio->rmtu = min(VNET_MAXPACKET, vio->rmtu);
> + pkt.mtu = vio->rmtu;
> + } else {
> + vio->rmtu = VNET_MAXPACKET;
> + pkt.mtu = vio->rmtu;
> + }
> + } else if (vio->ver.minor == 3) {
> + pkt.mtu = framelen + VLAN_HLEN;
> + } else {
> + pkt.mtu = framelen;
> + }
> + if (vio->ver.minor >= 6)
> + pkt.options = VIO_TX_DRING;
> + }
>
> viodbg(HS, "SEND NET ATTR xmode[0x%x] atype[0x%x] addr[%llx] "
> - "ackfreq[%u] mtu[%llu]\n",
> + "ackfreq[%u] plnk_updt[0x%02x] opts[0x%02x] mtu[%llu] "
> + "cflags[0x%04x] lso_max[%u]\n",
> pkt.xfer_mode, pkt.addr_type,
> - (unsigned long long) pkt.addr,
> - pkt.ack_freq,
> - (unsigned long long) pkt.mtu);
> + (unsigned long long)pkt.addr,
> + pkt.ack_freq, pkt.plnk_updt, pkt.options,
> + (unsigned long long)pkt.mtu, pkt.cflags, pkt.ipv4_lso_maxlen);
> +
>
> return vio_ldc_send(vio, &pkt, sizeof(pkt));
> }
> @@ -92,18 +116,52 @@ static int vnet_send_attr(struct vio_driver_state *vio)
> static int handle_attr_info(struct vio_driver_state *vio,
> struct vio_net_attr_info *pkt)
> {
> - viodbg(HS, "GOT NET ATTR INFO xmode[0x%x] atype[0x%x] addr[%llx] "
> - "ackfreq[%u] mtu[%llu]\n",
> + u64 localmtu;
> + u8 xfer_mode;
> +
> + viodbg(HS, "GOT NET ATTR xmode[0x%x] atype[0x%x] addr[%llx] "
> + "ackfreq[%u] plnk_updt[0x%02x] opts[0x%02x] mtu[%llu] "
> + " (rmtu[%llu]) cflags[0x%04x] lso_max[%u]\n",
> pkt->xfer_mode, pkt->addr_type,
> - (unsigned long long) pkt->addr,
> - pkt->ack_freq,
> - (unsigned long long) pkt->mtu);
> + (unsigned long long)pkt->addr,
> + pkt->ack_freq, pkt->plnk_updt, pkt->options,
> + (unsigned long long)pkt->mtu, vio->rmtu, pkt->cflags,
> + pkt->ipv4_lso_maxlen);
>
> pkt->tag.sid = vio_send_sid(vio);
>
> - if (pkt->xfer_mode != VIO_DRING_MODE ||
> + xfer_mode = pkt->xfer_mode;
> + /* for version < 1.2, VIO_DRING_MODE = 0x3 and no bitmask */
> + if ((vio->ver.major <= 1 && vio->ver.minor < 2) &&
> + xfer_mode == VIO_DRING_MODE)
> + xfer_mode = VIO_NEW_DRING_MODE;
> +
> + /* MTU negotiation:
> + * < v1.3 - ETH_FRAME_LEN exactly
> + * = v1.3 - ETH_FRAME_LEN + VLAN_HLEN exactly
> + * > v1.4 - MIN(pkt.mtu, VNET_MAX_PACKET, vio->rmtu) and change
> + * pkt->mtu for ACK
> + */
> + if (vio->ver.major == 1 && vio->ver.minor < 3) {
> + localmtu = ETH_FRAME_LEN;
> + } else if (vio->ver.major == 1 && vio->ver.minor == 3) {
> + localmtu = ETH_FRAME_LEN + VLAN_HLEN;
> + } else {
> + localmtu = vio->rmtu ? vio->rmtu : VNET_MAXPACKET;
> + localmtu = min(pkt->mtu, localmtu);
> + pkt->mtu = localmtu;
> + }
> + vio->rmtu = localmtu;
> +
> + /* for version >= 1.6, ACK packet mode we support */
> + if (vio->ver.major <= 1 && vio->ver.minor >= 6) {
> + pkt->xfer_mode = VIO_NEW_DRING_MODE;
> + pkt->options = VIO_TX_DRING;
> + }
> +
> + if (!(xfer_mode | VIO_NEW_DRING_MODE) ||
> pkt->addr_type != VNET_ADDR_ETHERMAC ||
> - pkt->mtu != ETH_FRAME_LEN) {
> + pkt->mtu != localmtu) {
> viodbg(HS, "SEND NET ATTR NACK\n");
>
> pkt->tag.stype = VIO_SUBTYPE_NACK;
> @@ -112,7 +170,14 @@ static int handle_attr_info(struct vio_driver_state *vio,
>
> return -ECONNRESET;
> } else {
> - viodbg(HS, "SEND NET ATTR ACK\n");
> + viodbg(HS, "SEND NET ATTR ACK xmode[0x%x] atype[0x%x] "
> + "addr[%llx] ackfreq[%u] plnk_updt[0x%02x] opts[0x%02x] "
> + "mtu[%llu] (rmtu[%llu]) cflags[0x%04x] lso_max[%u]\n",
> + pkt->xfer_mode, pkt->addr_type,
> + (unsigned long long)pkt->addr,
> + pkt->ack_freq, pkt->plnk_updt, pkt->options,
> + (unsigned long long)pkt->mtu, vio->rmtu, pkt->cflags,
> + pkt->ipv4_lso_maxlen);
>
> pkt->tag.stype = VIO_SUBTYPE_ACK;
>
> @@ -208,7 +273,7 @@ static int vnet_rx_one(struct vnet_port *port, unsigned int len,
> int err;
>
> err = -EMSGSIZE;
> - if (unlikely(len < ETH_ZLEN || len > ETH_FRAME_LEN)) {
> + if (unlikely(len < ETH_ZLEN || len > port->vio.rmtu)) {
> dev->stats.rx_length_errors++;
> goto out_dropped;
> }
> @@ -528,8 +593,10 @@ static void vnet_event(void *arg, int event)
> vio_link_state_change(vio, event);
> spin_unlock_irqrestore(&vio->lock, flags);
>
> - if (event == LDC_EVENT_RESET)
> + if (event == LDC_EVENT_RESET) {
> + vio->rmtu = 0;
> vio_port_up(vio);
> + }
> return;
> }
>
> @@ -986,8 +1053,8 @@ static int vnet_port_alloc_tx_bufs(struct vnet_port *port)
> void *dring;
>
> for (i = 0; i < VNET_TX_RING_SIZE; i++) {
> - void *buf = kzalloc(ETH_FRAME_LEN + 8, GFP_KERNEL);
> - int map_len = (ETH_FRAME_LEN + 7) & ~7;
> + void *buf = kzalloc(VNET_MAXPACKET + 8, GFP_KERNEL);
> + int map_len = (VNET_MAXPACKET + 7) & ~7;
>
> err = -ENOMEM;
> if (!buf)
> diff --git a/drivers/net/ethernet/sun/sunvnet.h b/drivers/net/ethernet/sun/sunvnet.h
> index de5c2c6..243ae69 100644
> --- a/drivers/net/ethernet/sun/sunvnet.h
> +++ b/drivers/net/ethernet/sun/sunvnet.h
> @@ -11,6 +11,7 @@
> */
> #define VNET_TX_TIMEOUT (5 * HZ)
>
> +#define VNET_MAXPACKET 1518ULL /* ETH_FRAMELEN + VLAN_HDR */
> #define VNET_TX_RING_SIZE 512
> #define VNET_TX_WAKEUP_THRESH(dr) ((dr)->pending / 4)
>
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: Raghuram Kothakota @ 2014-09-14 3:43 UTC (permalink / raw)
To: David Miller; +Cc: david.stevens, netdev
In-Reply-To: <20140913.230120.511140402106277600.davem@davemloft.net>
On Sep 13, 2014, at 8:01 PM, David Miller <davem@davemloft.net> wrote:
> From: David L Stevens <david.stevens@oracle.com>
> Date: Sat, 13 Sep 2014 22:39:25 -0400
>
>>
>>
>> On 09/13/2014 04:18 PM, David Miller wrote:
>>> From: David L Stevens <david.stevens@oracle.com>
>>
>>> static inline bool vio_version_before(struct vio_driver_state *vio,
>>> u16 major, u16 minor)
>>> {
>>> u32 have = (u32)vio->major << 16 | vio->minor;
>>> u32 want = (u32)major << 16 | minor;
>>>
>>> return have < want;
>>> }
>>> static inline bool vio_version_after_eq(struct vio_driver_state *vio,
>>> u16 major, u16 minor)
>>> {
>>> u32 have = (u32)vio->major << 16 | vio->minor;
>>> u32 want = (u32)major << 16 | minor;
>>>
>>> return have >= want;
>>> }
>>>
>>> Something like that.
>>
>> Sure. I was thinking about something like:
>>
>> #define VIO_VER(major, minor) (((major)<<16)|(minor))
>>
>> change the version struct to a 32-bit int, and do things like:
>>
>> if (vio->ver > VIO_VER(1,6)) {
>>
>> unless you have a preference. (?)
>
> I hate wasting space in a structure just to avoid some harmless
> casting in a helper function that is simply trying to optimize
> a comparison.
>
> That's why I suggested the inline helpers above, which arguments
> are strongly typed.
IMO, it would be more readable if we introduce the helper functions
that check for a specific feature than a specific version number
and hide the version number detail inside that helper function. Otherwise,
it will be harder to follow each version number check and why it is
being done.
-Raghuram
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Freeing dst when the reference count <0 causes general protection fault, it could be a major security flaw as rogue app can modify dst to crash kernel.
From: Eric Dumazet @ 2014-09-14 3:54 UTC (permalink / raw)
To: shakil A Khan; +Cc: netdev, linux-kernel, edumazet, davem
In-Reply-To: <1723887.mNMu0nmDbO@localhost.localdomain>
On Sat, 2014-09-13 at 11:35 -0700, shakil A Khan wrote:
> On Saturday, September 13, 2014 04:50:22 AM Eric Dumazet wrote:
> > On Sat, 2014-09-13 at 01:27 -0700, Shakil A Khan wrote:
> > > Signed-off-by: Shakil A Khan <shakilk1729@gmail.com>
> > > ---
> > >
> > > net/core/dst.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/core/dst.c b/net/core/dst.c
> > > index a028409..6a848b0 100644
> > > --- a/net/core/dst.c
> > > +++ b/net/core/dst.c
> > > @@ -284,7 +284,10 @@ void dst_release(struct dst_entry *dst)
> > >
> > > int newrefcnt;
> > >
> > > newrefcnt = atomic_dec_return(&dst->__refcnt);
> > >
> > > - WARN_ON(newrefcnt < 0);
> > > +
> > > + if (WARN(newrefcnt < 0, "dst reference count less than zero"))
> > > + return;
> > > +
> > >
> > > if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt)
> > >
> > > call_rcu(&dst->rcu_head, dst_destroy_rcu);
> > >
> > > }
> >
> > A rogue application can not do trigger this, unless a major bug in the
> > kernel exists.
>
> Please check this kernel trace. It is able to crash the kernel.
>
> general protection fault: 0000 [#1] PREEMPT SMP
> Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry
> nfsv4 nfs fscache lockd sunrpc tun nbd ipmi_si ipmi_watchdog ipmi_devintf
> ipmi_msghandler xt_mark xt_owner ipt_MASQUERADE xt_physdev xt_state xt_LOG
> iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> nf_conntrack iptable_filter ip_tables xen_acpi_processor xen_pciback
> xen_netback xen_blkback xen_gntalloc xen_gntdev xenfs xen_privcmd bridge stp
> llc ipv6 ext4 jbd2 freq_table mperf coretemp crc32c_intel ghash_clmulni_intel
> microcode pcspkr sb_edac edac_core lpc_ich mfd_core i2c_i801 sg ioatdma igb
> dca i2c_algo_bit i2c_core ptp pps_core ext3 jbd mbcache sd_mod crc_t10dif
> aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 ahci
> libahci isci libsas scsi_transport_sas megaraid_sas wmi dm_mirror
> dm_region_hash dm_log dm_mod [last unloaded: iTCO_vendor_support]
> CPU: 6 PID: 15324 Comm: XXXX Not tainted 3.10.45-xen.322.17.41238 #1
> Hardware name: McAfee, Inc. ATD-6000/S4600LH...., BIOS
> SE5C600.86B.02.01.0002.082220131453 08/22/2013
> task: ffff882bc6255000 ti: ffff882bc61aa000 task.ti: ffff882bc61aa000
> RIP: e030:[<ffffffff8148473f>] [<ffffffff8148473f>] ipv4_dst_destroy+0x3b/0x77
> RSP: e02b:ffff882bc61abb48 EFLAGS: 00010296
> RAX: dead000000200200 RBX: ffff882bc625bc80 RCX: 0001338a9b7110db
> RDX: dead000000100100 RSI: ffffffff82267e30 RDI: 00000000000003f4
> RBP: ffff882bc61abb58 R08: 00000000d5d6df8b R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff820e5880 R14: ffff88070e584b80 R15: 0000000000000000
> FS: 00007f8d3fff2700(0000) GS:ffff88081e6c0000(0000) knlGS:0000000000000000
> CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000031d0e36ac0 CR3: 0000002db0165000 CR4: 0000000000042660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Stack:
> ffff882bc61abb58 ffff882bc625bc80 ffff882bc61abb88 ffffffff8145bfc5
> ffff882bc61abba8 ffff882bc625bc80 0000000000000000 ffff882bc625bc80
> ffff882bc61abba8 ffffffff8145c2c5 ffff88070e584b80 ffff882b991c2300
> Call Trace:
> [<ffffffff8145bfc5>] dst_destroy+0x29/0xbd
> [<ffffffff8145c2c5>] dst_release+0x58/0x67
> [<ffffffff814ad539>] tcp_v4_do_rcv+0x11b/0x287
> [<ffffffff81443e24>] __release_sock+0x7c/0xe7
> [<ffffffff81443ebd>] release_sock+0x2e/0x7c
> [<ffffffff81499cdf>] tcp_sendmsg+0xe0/0xd41
> [<ffffffff814bf369>] inet_sendmsg+0x7d/0xa0
> [<ffffffff8143d794>] sock_aio_write+0x159/0x17d
> [<ffffffff81005859>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
> [<ffffffff8116d12b>] do_sync_write+0x7f/0xa7
> [<ffffffff8116d392>] ? rw_verify_area+0x56/0xd5
> [<ffffffff8116d555>] vfs_write+0x144/0x170
> [<ffffffff8116d977>] SyS_write+0x54/0x8f
> [<ffffffff810d078f>] ? __audit_syscall_exit+0x20c/0x29c
> [<ffffffff8151e959>] system_call_fastpath+0x16/0x1b
> Code: fb 48 8d 87 b0 00 00 00 48 39 87 b0 00 00 00 74 4f 48 c7 c7 04 8f 3c 82
> e8 32 23 09 00 48 8b 93 b0 00 00 00 48 8b 83 b8 00 00 00 <48> 89 42 08 48 89
> 10 48 b9 00 01 10 00 00 00 ad de 48 89 8b b0
> RIP [<ffffffff8148473f>] ipv4_dst_destroy+0x3b/0x77
> RSP <ffff882bc61abb48>
> ---[ end trace d56f90482c47af91 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
>
> >
> > Instead of trying to hide the kernel bug, we need to fix it.
> There are two problems with this. First the list has somehow got out of
> sync in terms of number of delete and allocate, so we need to fix that.
> But at the same time refcount if <0 signifies its been already freed so we need
> not free up.
> We need fix for both and my patch targets later as my system works fine with
> this patch.
> >
> > Can you describe how this could trigger with a pristine kernel ?
> This is triggered with custom software to imitate malware traffic(Kernel was not
> having any custom patch whatsoever, it was a pristine kernel 3.10.45).
> Point is if an application can crash this, then it would be big security flaw
> not exactly similar but like SSL love bug, which can be exploited to bring
> down systems.
3.10.45 is old, you are a bit late, as we already spent a good amount of
time fixing all this about 3 months ago.
3.10.45 misses this fix :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f502361531e9eecb396cf99bdc9e9a59f7ebd7f
And this one :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f88649721268999bdff09777847080a52004f691
And also :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9709674e68646cee5a24e3000b3558d25412203a
All these should already be in 3.10.54
I suggest you try a 3.10.54 kernel. If it still crashes, then try a 3.16
kernel.
Then, we'll investigate, _if_ needed.
Thanks.
^ permalink raw reply
* [PATCH 1/1 v2] netdev: octeon_mgmt: ISO C90 forbids mixed declarations and code
From: Heinrich Schuchardt @ 2014-09-14 5:02 UTC (permalink / raw)
To: David Daney
Cc: David S. Miller, Luka Perkov, Willem de Bruijn, Russell King,
netdev, linux-kernel, Heinrich Schuchardt, Joe Perches
Revised patch takes into account comments by Joe and David.
Compiling with OCTEON_MGMT_ETHERNET gives a warning
drivers/net/ethernet/octeon/octeon_mgmt.c:295:4:
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
The patch cleans up the code.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Joe Perches <joe@perches.com>
CC: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/octeon/octeon_mgmt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 979c698..6cc68b1 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -290,9 +290,10 @@ static void octeon_mgmt_clean_tx_buffers(struct octeon_mgmt *p)
/* Read the hardware TX timestamp if one was recorded */
if (unlikely(re.s.tstamp)) {
struct skb_shared_hwtstamps ts;
+ u64 ns;
memset(&ts, 0, sizeof(ts));
/* Read the timestamp */
- u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
+ ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
/* Remove the timestamp from the FIFO */
cvmx_write_csr(CVMX_MIXX_TSCTL(p->port), 0);
/* Tell the kernel about the timestamp */
--
2.1.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox