* [PATCH] igb_main: mark expected switch fall-through
From: Gustavo A. R. Silva @ 2019-02-19 20:22 UTC (permalink / raw)
To: Jeff Kirsher, David S. Miller
Cc: intel-wired-lan, netdev, linux-kernel, Gustavo A. R. Silva,
Kees Cook
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
drivers/net/ethernet/intel/igb/igb_main.c: In function ‘__igb_notify_dca’:
drivers/net/ethernet/intel/igb/igb_main.c:6694:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (dca_add_requester(dev) == 0) {
^
drivers/net/ethernet/intel/igb/igb_main.c:6701:2: note: here
case DCA_PROVIDER_REMOVE:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
Notice that, in this particular case, the code comment is modified
in accordance with what GCC is expecting to find.
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 69b230c53fed..483f0977f70e 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6697,7 +6697,7 @@ static int __igb_notify_dca(struct device *dev, void *data)
igb_setup_dca(adapter);
break;
}
- /* Fall Through since DCA is disabled. */
+ /* Fall Through - since DCA is disabled. */
case DCA_PROVIDER_REMOVE:
if (adapter->flags & IGB_FLAG_DCA_ENABLED) {
/* without this a class_device is left
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] igb: e1000_82575: mark expected switch fall-through
From: Gustavo A. R. Silva @ 2019-02-19 20:27 UTC (permalink / raw)
To: Jeff Kirsher, David S. Miller
Cc: intel-wired-lan, netdev, linux-kernel, Gustavo A. R. Silva,
Kees Cook
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
drivers/net/ethernet/intel/igb/e1000_82575.c: In function ‘igb_get_invariants_82575’:
drivers/net/ethernet/intel/igb/e1000_82575.c:636:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (igb_sgmii_uses_mdio_82575(hw)) {
^
drivers/net/ethernet/intel/igb/e1000_82575.c:642:2: note: here
case E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
Notice that, in this particular case, the code comment is modified
in accordance with what GCC is expecting to find.
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index bafdcf70a353..3ec2ce0725d5 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -638,7 +638,7 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
dev_spec->sgmii_active = true;
break;
}
- /* fall through for I2C based SGMII */
+ /* fall through - for I2C based SGMII */
case E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES:
/* read media type from SFP EEPROM */
ret_val = igb_set_sfp_media_type_82575(hw);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 1/2] MIPS: eBPF: Always return sign extended 32b values
From: Paul Burton @ 2019-02-19 20:48 UTC (permalink / raw)
To: Paul Burton
Cc: linux-mips@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jiong Wang, Paul Burton,
stable@vger.kernel.org, linux-mips@vger.kernel.org
In-Reply-To: <20190215201321.15725-1-paul.burton@mips.com>
Hello,
Paul Burton wrote:
> The function prototype used to call JITed eBPF code (ie. the type of the
> struct bpf_prog bpf_func field) returns an unsigned int. The MIPS n64
> ABI that MIPS64 kernels target defines that 32 bit integers should
> always be sign extended when passed in registers as either arguments or
> return values.
>
> This means that when returning any value which may not already be sign
> extended (ie. of type REG_64BIT or REG_32BIT_ZERO_EX) we need to perform
> that sign extension in order to comply with the n64 ABI. Without this we
> see strange looking test failures from test_bpf.ko, such as:
>
> test_bpf: #65 ALU64_MOV_X:
> dst = 4294967295 jited:1 ret -1 != -1 FAIL (1 times)
>
> Although the return value printed matches the expected value, this is
> only because printf is only examining the least significant 32 bits of
> the 64 bit register value we returned. The register holding the expected
> value is sign extended whilst the v0 register was set to a zero extended
> value by our JITed code, so when compared by a conditional branch
> instruction the values are not equal.
>
> We already handle this when the return value register is of type
> REG_32BIT_ZERO_EX, so simply extend this to also cover REG_64BIT.
>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
> Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.")
> Cc: stable@vger.kernel.org # v4.13+
Series applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
^ permalink raw reply
* [PATCH iproute2, v2] ip-rule: fix json key "to_tbl" for unspecific rule action
From: Thomas Haller @ 2019-02-19 20:50 UTC (permalink / raw)
To: netdev; +Cc: stephen, Thomas Haller
In-Reply-To: <20190219101958.5c4bbd0d@shemminger-XPS-13-9360>
The key should not be called "to_tbl" because it is exactly
not a FR_ACT_TO_TBL action. Change it to "action".
# ip rule add blackhole
# ip -j rule | python -m json.tool
...
{
"priority": 0,
"src": "all",
"to_tbl": "blackhole"
},
This is an API break of JSON output as it was added in v4.17.0.
Still change it as the API is relatively new and unstable.
Fixes: 0dd4ccc56c0e ("iprule: add json support")
Signed-off-by: Thomas Haller <thaller@redhat.com>
---
ip/iprule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/iprule.c b/ip/iprule.c
index 2f58d8c2..4e9437de 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -459,7 +459,7 @@ int print_rule(struct nlmsghdr *n, void *arg)
} else if (frh->action == FR_ACT_NOP) {
print_null(PRINT_ANY, "nop", "nop", NULL);
} else if (frh->action != FR_ACT_TO_TBL) {
- print_string(PRINT_ANY, "to_tbl", "%s",
+ print_string(PRINT_ANY, "action", "%s",
rtnl_rtntype_n2a(frh->action, b1, sizeof(b1)));
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH bpf-next V2] bpf: add skb->queue_mapping write access from tc clsact
From: Daniel Borkmann @ 2019-02-19 20:59 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <155060238064.20881.2440076496977900559.stgit@firesoul>
On 02/19/2019 07:53 PM, Jesper Dangaard Brouer wrote:
> The skb->queue_mapping already have read access, via __sk_buff->queue_mapping.
>
> This patch allow BPF tc qdisc clsact write access to the queue_mapping via
> tc_cls_act_is_valid_access. Also handle that the value NO_QUEUE_MAPPING
> is not allowed.
>
> It is already possible to change this via TC filter action skbedit
> tc-skbedit(8). Due to the lack of TC examples, lets show one:
>
> # tc qdisc add dev ixgbe1 clsact
> # tc filter add dev ixgbe1 ingress matchall action skbedit queue_mapping 5
> # tc filter list dev ixgbe1 ingress
>
> The most common mistake is that XPS (Transmit Packet Steering) takes
> precedence over setting skb->queue_mapping. XPS is configured per DEVICE
> via /sys/class/net/DEVICE/queues/tx-*/xps_cpus via a CPU hex mask. To
> disable set mask=00.
>
> The purpose of changing skb->queue_mapping is to influence the selection of
> the net_device "txq" (struct netdev_queue), which influence selection of
> the qdisc "root_lock" (via txq->qdisc->q.lock) and txq->_xmit_lock. When
> using the MQ qdisc the txq->qdisc points to different qdiscs and associated
> locks, and HARD_TX_LOCK (txq->_xmit_lock), allowing for CPU scalability.
>
> Due to lack of TC examples, lets show howto attach clsact BPF programs:
>
> # tc qdisc add dev ixgbe2 clsact
> # tc filter add dev ixgbe2 egress bpf da obj XXX_kern.o sec tc_qmap2cpu
> # tc filter list dev ixgbe2 egress
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
From: David Summers @ 2019-02-19 21:09 UTC (permalink / raw)
To: Rob Herring, Vasily Khoruzhick
Cc: Stefan Wahren, Mark Rutland, devicetree, Johan Hedberg,
Maxime Ripard, netdev, Marcel Holtmann,
open list:BLUETOOTH DRIVERS, Chen-Yu Tsai, David S. Miller,
arm-linux
In-Reply-To: <CAL_JsqLROpJMoEPLXaAL_JG1SNufstMDmB4xy_V_p4=duHKPSA@mail.gmail.com>
On 19/02/2019 14:17, Rob Herring wrote:
> On Mon, Feb 18, 2019 at 4:28 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>> On Mon, Feb 18, 2019 at 2:08 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:
>>> Hi Vasily,
>> Hi Stefan,
>>
>>>> Vasily Khoruzhick <anarsoul@gmail.com> hat am 18. Februar 2019 um 22:24 geschrieben:
>>>>
>>>>
>>>> On Mon, Feb 18, 2019 at 1:10 PM Rob Herring <robh@kernel.org> wrote:
>>>>> On Fri, Jan 18, 2019 at 09:02:27AM -0800, Vasily Khoruzhick wrote:
>>>>>> Add binding document for bluetooth part of RTL8723BS/RTL8723CS
>>>>>>
>>>>>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>>>>>> ---
>>>>>> .../bindings/net/rtl8723bs-bluetooth.txt | 35 +++++++++++++++++++
>>>>>> 1 file changed, 35 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
>>>>>> new file mode 100644
>>>>>> index 000000000000..8357f242ae4c
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
>>>>>> @@ -0,0 +1,35 @@
>>>>>> +RTL8723BS/RTL8723CS Bluetooth
>>>>>> +---------------------
>>>>>> +
>>>>>> +RTL8723CS/RTL8723CS is WiFi + BT chip. WiFi part is connected over SDIO, while
>>>>>> +BT is connected over serial. It speaks H5 protocol with few extra commands
>>>>>> +to upload firmware and change module speed.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> + - compatible: should be one of the following:
>>>>>> + * "realtek,rtl8723bs-bt"
>>>>>> + * "realtek,rtl8723cs-bt"
>>>>>> +Optional properties:
>>>>>> +
>>>>>> + - device-wake-gpios: GPIO specifier, used to wakeup the BT module (active high)
>>>>>> + - enable-gpios: GPIO specifier, used to enable the BT module (active high)
>>>>>> + - host-wake-gpios: GPIO specifier, used to wakeup the host processor (active high)
>>>>>> + - firmware-postfix: firmware postfix to be used for firmware config
>>> sorry, i didn't noticed your great series before. David and i working at the same stuff but for the Asus Tinker Board.
>>>
>>> I created a similiar yet untested patch version for hci_h5 [1]. Maybe it's useful.
>> Looks good to me, but you may need to add firmware-postfix.
>>
>>> Just a comment about the binding. It's really necessary to add the reset-gpio? Can't we use the enable-gpio with inverse polarity for this?
>> Yes, we can use enable-gpio instead of reset-gpio on pine64 and pinebook.
> Then why do we have both? Reset and enable are distinct. The inverse
> of enable-gpios is typically powerdown-gpios, not reset-gpios.
>
> Rob
Both data sheets that I know:
http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/FN-Link_F23BDSM25-W1.pdf
http://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf
BT_RST_N BT Reset IN / BT_DIS# General Purpose I/O Pin
So from the datasheet there is only one pin. And from its name it sounds
like reset.
This said though the datasheets of these Realtek devices are a bit thin ....
^ permalink raw reply
* Re: [PATCH net V2] vhost: correctly check the return value of translate_desc() in log_used()
From: David Miller @ 2019-02-19 21:16 UTC (permalink / raw)
To: jasowang; +Cc: mst, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20190219065344.24923-1-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 19 Feb 2019 14:53:44 +0800
> When fail, translate_desc() returns negative value, otherwise the
> number of iovs. So we should fail when the return value is negative
> instead of a blindly check against zero.
>
> Detected by CoverityScan, CID# 1442593: Control flow issues (DEADCODE)
>
> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: qca8k: Enable delay for RGMII_ID mode
From: David Miller @ 2019-02-19 21:19 UTC (permalink / raw)
To: vkoul
Cc: linux-arm-msm, bjorn.andersson, netdev, niklas.cassel, andrew,
f.fainelli, michal.vokac
In-Reply-To: <20190219065943.22765-1-vkoul@kernel.org>
From: Vinod Koul <vkoul@kernel.org>
Date: Tue, 19 Feb 2019 12:29:43 +0530
> RGMII_ID specifies that we should have internal delay, so resurrect the
> delay addition routine but under the RGMII_ID mode.
>
> Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode")
> Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Applied, thanks.
^ permalink raw reply
* Re: [tipc-discussion][net 1/1] tipc: fix race condition causing hung sendto
From: David Miller @ 2019-02-19 21:21 UTC (permalink / raw)
To: tung.q.nguyen; +Cc: netdev, tipc-discussion
In-Reply-To: <20190219070310.23888-2-tung.q.nguyen@dektech.com.au>
From: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Date: Tue, 19 Feb 2019 14:03:10 +0700
> When sending multicast messages via blocking socket,
> if sending link is congested (tsk->cong_link_cnt is set to 1),
> the sending thread will be put into sleeping state. However,
> tipc_sk_filter_rcv() is called under socket spin lock but
> tipc_wait_for_cond() is not. So, there is no guarantee that
> the setting of tsk->cong_link_cnt to 0 in tipc_sk_proto_rcv() in
> CPU-1 will be perceived by CPU-0. If that is the case, the sending
> thread in CPU-0 after being waken up, will continue to see
> tsk->cong_link_cnt as 1 and put the sending thread into sleeping
> state again. The sending thread will sleep forever.
...
> This commit fixes it by adding memory barrier to tipc_sk_proto_rcv()
> and tipc_wait_for_cond().
>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
You really need to build test this stuff properly:
net/tipc/socket.c: In function ‘__tipc_shutdown’:
./include/linux/wait.h:1119:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
struct wait_queue_entry name = { \
^~~~~~
You can't put the smp_rmb(); before the DEFINE_WAIT_FUNC() in that
basic block.
^ permalink raw reply
* Re: [PATCH net-next] net: rose: add missing dev_put() on error in rose_bind
From: David Miller @ 2019-02-19 21:23 UTC (permalink / raw)
To: yuehaibing; +Cc: ralf, linux-kernel, netdev, linux-hams
In-Reply-To: <20190219080622.17312-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 19 Feb 2019 16:06:22 +0800
> when capable check failed, dev_put should
> be call before return -EACCES.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3] net: ns83820: code cleanup for ns83820_probe_phy()
From: David Miller @ 2019-02-19 21:25 UTC (permalink / raw)
To: maowenan
Cc: kernel-janitors, netdev, john.fastabend, hawk, jakub.kicinski,
daniel, ast, julia.lawall
In-Reply-To: <20190219090635.134457-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Tue, 19 Feb 2019 17:06:35 +0800
> This patch is to do code cleanup for ns83820_probe_phy().
> It deletes unused variable 'first' and commented out code.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> v2->v3: delte unused variable 'first'; change subject from
> "net: ns83820: drop pointless static qualifier in ns83820_probe_phy()" to
> "net: ns83820: code cleanup for ns83820_probe_phy()".
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth
From: Vasily Khoruzhick @ 2019-02-19 21:25 UTC (permalink / raw)
To: Rob Herring
Cc: David S. Miller, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Marcel Holtmann, Johan Hedberg, netdev, devicetree, arm-linux,
open list:BLUETOOTH DRIVERS
In-Reply-To: <CAL_Jsq+kqFrY3DoHG_TJCCSxVHRkin4OwM+F9qm6W0w5YfjPQQ@mail.gmail.com>
On Tue, Feb 19, 2019 at 6:14 AM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Feb 18, 2019 at 3:24 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> >
> > On Mon, Feb 18, 2019 at 1:10 PM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Fri, Jan 18, 2019 at 09:02:27AM -0800, Vasily Khoruzhick wrote:
> > > > Add binding document for bluetooth part of RTL8723BS/RTL8723CS
> > > >
> > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > ---
> > > > .../bindings/net/rtl8723bs-bluetooth.txt | 35 +++++++++++++++++++
> > > > 1 file changed, 35 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> > > > new file mode 100644
> > > > index 000000000000..8357f242ae4c
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/net/rtl8723bs-bluetooth.txt
> > > > @@ -0,0 +1,35 @@
> > > > +RTL8723BS/RTL8723CS Bluetooth
> > > > +---------------------
> > > > +
> > > > +RTL8723CS/RTL8723CS is WiFi + BT chip. WiFi part is connected over SDIO, while
> > > > +BT is connected over serial. It speaks H5 protocol with few extra commands
> > > > +to upload firmware and change module speed.
> > > > +
> > > > +Required properties:
> > > > +
> > > > + - compatible: should be one of the following:
> > > > + * "realtek,rtl8723bs-bt"
> > > > + * "realtek,rtl8723cs-bt"
> > > > +Optional properties:
> > > > +
> > > > + - device-wake-gpios: GPIO specifier, used to wakeup the BT module (active high)
> > > > + - enable-gpios: GPIO specifier, used to enable the BT module (active high)
> > > > + - host-wake-gpios: GPIO specifier, used to wakeup the host processor (active high)
> > > > + - firmware-postfix: firmware postfix to be used for firmware config
> > >
> > > How is this used?
> >
> > rtl8723bs-bt needs 2 firmware binaries -- one is actual firmware,
> > another is firmware config which is specific to the board. If
> > firmware-postfix is specified, driver appends it to the name of config
> > and requests board-specific config while loading firmware. I.e. if
> > 'pine64' is specified as firmware-postfix driver will load
> > rtl8723bs_config-pine64.bin.
>
> We already have 'firmware-name' defined and I'd prefer not to have
> another way to do things. The difference is just you have to give the
> full filename.
OK
> Also, on other chips with board specific config blobs, there's been
> some discussion of converting those to DT properties. That depends on
> you knowing what's in the blob and having a reasonable number of
> parameter to make properties.
We'd have to RE binary format of this config first.
> Rob
^ permalink raw reply
* Re: pull-request: ieee802154-next 2019-02-19
From: David Miller @ 2019-02-19 21:27 UTC (permalink / raw)
To: stefan; +Cc: linux-wpan, alex.aring, netdev
In-Reply-To: <20190219161123.24965-1-stefan@datenfreihafen.org>
From: Stefan Schmidt <stefan@datenfreihafen.org>
Date: Tue, 19 Feb 2019 17:11:23 +0100
> An update from ieee802154 for *net-next*
>
> Another quite quite cycle in the ieee802154 subsystem.
> Peter did a rework of the IP frag queue handling to make it use rbtree and get
> in line with the core IPv4 and IPv6 implementatiosn in the kernel.
>
> Please pull, or let me know if there are any problems.
Pulled, thanks Stefan.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: check that BPF programs run with preemption disabled
From: Daniel Borkmann @ 2019-02-19 20:58 UTC (permalink / raw)
To: Alexei Starovoitov, davem
Cc: peterz, jannh, paulmck, will.deacon, mingo, netdev, kernel-team
In-Reply-To: <799a8afa-fe19-21ad-e73e-b24199dd55c8@iogearbox.net>
On 01/31/2019 11:29 PM, Daniel Borkmann wrote:
> On 01/29/2019 02:21 AM, Alexei Starovoitov wrote:
>> From: Peter Zijlstra <peterz@infradead.org>
>>
>> Introduce cant_sleep() macro for annotation of functions that cannot sleep.
>>
>> Use it in BPF_PROG_RUN to catch execution of BPF programs
>> in preemptable context.
>>
>> Suggested-by: Jann Horn <jannh@google.com>
>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>
> (Just fyi, will let this sit in patchwork till the preemption fixes have been
> merged back from bpf into bpf-next as otherwise people will yell that they
> hit this frequently.)
Pushed out now, thanks!
^ permalink raw reply
* Re: Clang warnings in net/phonet
From: Arnd Bergmann @ 2019-02-19 21:50 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Remi Denis-Courmont, David S. Miller, Networking,
Linux Kernel Mailing List, Nick Desaulniers
In-Reply-To: <20190108025420.GA26093@flashbox>
On Tue, Jan 8, 2019 at 3:55 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> Hi all,
>
> When building the kernel with Clang, this warning comes up in net/phonet.
>
> net/phonet/pep.c:224:16: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
> ph->data[0] = oph->data[1]; /* CTRL id */
> ^ ~
> include/net/phonet/pep.h:66:3: note: array 'data' declared here
> u8 data[1];
> ^
>
> I have taken a look at the effected code but I can't really figure out
> the proper fix for this warning (my knowledge of C just isn't there
> yet). Nick had suggested changing 'u8 data[1]' to 'u8 *data' in
> 'struct pnpipehdr', which seems logical but I can't say for sure. Any
> advice would be appreciated :)
>
A pointer wouldn't work here, as this is a network header with a
fixed layout. Using a flexible array at the end of the structure works,
but unfortunately all indices change that way. Sending an experimental
patch.
Arnd
^ permalink raw reply
* Re: [PATCH bpf-next 3/9] bpf: add bpf helper bpf_skb_set_ecn
From: Daniel Borkmann @ 2019-02-19 21:53 UTC (permalink / raw)
To: brakmo, netdev
Cc: Martin Lau, Alexei Starovoitov, Daniel Borkmann --cc=Kernel Team
In-Reply-To: <e6522869-d79b-5da1-d44a-06f80dc72257@iogearbox.net>
On 02/19/2019 11:52 AM, Daniel Borkmann wrote:
[...]
> Looking at cg_skb_verifier_ops ... it seems there also a bug in the current
> code, namely that if we have a direct packet write, we don't make the skb
> writable; at that point skb->data is not private. The cg_skb_is_valid_access()
> allows to fetch PTR_TO_PACKET{,_END}, so we need a fix like the below for -bpf:
Ah, scratch that thought, I overlooked may_access_direct_pkt_data() prevents
writes for this prog type so not an issue.
> diff --git a/net/core/filter.c b/net/core/filter.c
> index f7d0004fc160..34fe6da0a236 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5796,6 +5796,12 @@ static bool sk_filter_is_valid_access(int off, int size,
> return bpf_skb_is_valid_access(off, size, type, prog, info);
> }
>
> +static int cg_skb_prologue(struct bpf_insn *insn_buf, bool direct_write,
> + const struct bpf_prog *prog)
> +{
> + return bpf_unclone_prologue(insn_buf, direct_write, prog, 0);
> +}
> +
> static bool cg_skb_is_valid_access(int off, int size,
> enum bpf_access_type type,
> const struct bpf_prog *prog,
> @@ -7595,6 +7601,7 @@ const struct bpf_verifier_ops cg_skb_verifier_ops = {
> .get_func_proto = cg_skb_func_proto,
> .is_valid_access = cg_skb_is_valid_access,
> .convert_ctx_access = bpf_convert_ctx_access,
> + .gen_prologue = cg_skb_prologue,
> };
>
> const struct bpf_prog_ops cg_skb_prog_ops = {
^ permalink raw reply
* [PATCH] phonet: fix building with clang
From: Arnd Bergmann @ 2019-02-19 21:53 UTC (permalink / raw)
To: Remi Denis-Courmont, David S. Miller
Cc: Nathan Chancellor, Rémi Denis-Courmont, netdev, linux-kernel,
Arnd Bergmann
clang warns about overflowing the data[] member in the struct pnpipehdr:
net/phonet/pep.c:295:8: warning: array index 4 is past the end of the array (which contains 1 element) [-Warray-bounds]
if (hdr->data[4] == PEP_IND_READY)
^ ~
include/net/phonet/pep.h:66:3: note: array 'data' declared here
u8 data[1];
Using a flexible array member at the end of the struct avoids the
warning, but since we cannot have a flexible array member inside
of the union, each index now has to be moved back by one, which
makes it a little uglier.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/net/phonet/pep.h | 5 +++--
net/phonet/pep.c | 32 ++++++++++++++++----------------
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/include/net/phonet/pep.h b/include/net/phonet/pep.h
index b669fe6dbc3b..98f31c7ea23d 100644
--- a/include/net/phonet/pep.h
+++ b/include/net/phonet/pep.h
@@ -63,10 +63,11 @@ struct pnpipehdr {
u8 state_after_reset; /* reset request */
u8 error_code; /* any response */
u8 pep_type; /* status indication */
- u8 data[1];
+ u8 data0; /* anything else */
};
+ u8 data[];
};
-#define other_pep_type data[1]
+#define other_pep_type data[0]
static inline struct pnpipehdr *pnp_hdr(struct sk_buff *skb)
{
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index 9fc76b19cd3c..db3473540303 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -132,7 +132,7 @@ static int pep_indicate(struct sock *sk, u8 id, u8 code,
ph->utid = 0;
ph->message_id = id;
ph->pipe_handle = pn->pipe_handle;
- ph->data[0] = code;
+ ph->error_code = code;
return pn_skb_send(sk, skb, NULL);
}
@@ -153,7 +153,7 @@ static int pipe_handler_request(struct sock *sk, u8 id, u8 code,
ph->utid = id; /* whatever */
ph->message_id = id;
ph->pipe_handle = pn->pipe_handle;
- ph->data[0] = code;
+ ph->error_code = code;
return pn_skb_send(sk, skb, NULL);
}
@@ -208,7 +208,7 @@ static int pep_ctrlreq_error(struct sock *sk, struct sk_buff *oskb, u8 code,
struct pnpipehdr *ph;
struct sockaddr_pn dst;
u8 data[4] = {
- oph->data[0], /* PEP type */
+ oph->pep_type, /* PEP type */
code, /* error code, at an unusual offset */
PAD, PAD,
};
@@ -221,7 +221,7 @@ static int pep_ctrlreq_error(struct sock *sk, struct sk_buff *oskb, u8 code,
ph->utid = oph->utid;
ph->message_id = PNS_PEP_CTRL_RESP;
ph->pipe_handle = oph->pipe_handle;
- ph->data[0] = oph->data[1]; /* CTRL id */
+ ph->data0 = oph->data[0]; /* CTRL id */
pn_skb_get_src_sockaddr(oskb, &dst);
return pn_skb_send(sk, skb, &dst);
@@ -272,17 +272,17 @@ static int pipe_rcv_status(struct sock *sk, struct sk_buff *skb)
return -EINVAL;
hdr = pnp_hdr(skb);
- if (hdr->data[0] != PN_PEP_TYPE_COMMON) {
+ if (hdr->pep_type != PN_PEP_TYPE_COMMON) {
net_dbg_ratelimited("Phonet unknown PEP type: %u\n",
- (unsigned int)hdr->data[0]);
+ (unsigned int)hdr->pep_type);
return -EOPNOTSUPP;
}
- switch (hdr->data[1]) {
+ switch (hdr->data[0]) {
case PN_PEP_IND_FLOW_CONTROL:
switch (pn->tx_fc) {
case PN_LEGACY_FLOW_CONTROL:
- switch (hdr->data[4]) {
+ switch (hdr->data[3]) {
case PEP_IND_BUSY:
atomic_set(&pn->tx_credits, 0);
break;
@@ -292,7 +292,7 @@ static int pipe_rcv_status(struct sock *sk, struct sk_buff *skb)
}
break;
case PN_ONE_CREDIT_FLOW_CONTROL:
- if (hdr->data[4] == PEP_IND_READY)
+ if (hdr->data[3] == PEP_IND_READY)
atomic_set(&pn->tx_credits, wake = 1);
break;
}
@@ -301,12 +301,12 @@ static int pipe_rcv_status(struct sock *sk, struct sk_buff *skb)
case PN_PEP_IND_ID_MCFC_GRANT_CREDITS:
if (pn->tx_fc != PN_MULTI_CREDIT_FLOW_CONTROL)
break;
- atomic_add(wake = hdr->data[4], &pn->tx_credits);
+ atomic_add(wake = hdr->data[3], &pn->tx_credits);
break;
default:
net_dbg_ratelimited("Phonet unknown PEP indication: %u\n",
- (unsigned int)hdr->data[1]);
+ (unsigned int)hdr->data[0]);
return -EOPNOTSUPP;
}
if (wake)
@@ -318,7 +318,7 @@ static int pipe_rcv_created(struct sock *sk, struct sk_buff *skb)
{
struct pep_sock *pn = pep_sk(sk);
struct pnpipehdr *hdr = pnp_hdr(skb);
- u8 n_sb = hdr->data[0];
+ u8 n_sb = hdr->data0;
pn->rx_fc = pn->tx_fc = PN_LEGACY_FLOW_CONTROL;
__skb_pull(skb, sizeof(*hdr));
@@ -506,7 +506,7 @@ static int pep_connresp_rcv(struct sock *sk, struct sk_buff *skb)
return -ECONNREFUSED;
/* Parse sub-blocks */
- n_sb = hdr->data[4];
+ n_sb = hdr->data[3];
while (n_sb > 0) {
u8 type, buf[6], len = sizeof(buf);
const u8 *data = pep_get_sb(skb, &type, &len, buf);
@@ -739,7 +739,7 @@ static int pipe_do_remove(struct sock *sk)
ph->utid = 0;
ph->message_id = PNS_PIPE_REMOVE_REQ;
ph->pipe_handle = pn->pipe_handle;
- ph->data[0] = PAD;
+ ph->data0 = PAD;
return pn_skb_send(sk, skb, NULL);
}
@@ -817,7 +817,7 @@ static struct sock *pep_sock_accept(struct sock *sk, int flags, int *errp,
peer_type = hdr->other_pep_type << 8;
/* Parse sub-blocks (options) */
- n_sb = hdr->data[4];
+ n_sb = hdr->data[3];
while (n_sb > 0) {
u8 type, buf[1], len = sizeof(buf);
const u8 *data = pep_get_sb(skb, &type, &len, buf);
@@ -1109,7 +1109,7 @@ static int pipe_skb_send(struct sock *sk, struct sk_buff *skb)
ph->utid = 0;
if (pn->aligned) {
ph->message_id = PNS_PIPE_ALIGNED_DATA;
- ph->data[0] = 0; /* padding */
+ ph->data0 = 0; /* padding */
} else
ph->message_id = PNS_PIPE_DATA;
ph->pipe_handle = pn->pipe_handle;
--
2.20.0
^ permalink raw reply related
* WARNING: locking bug in icmp_send
From: syzbot @ 2019-02-19 21:56 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: b5372fe5dc84 exec: load_script: Do not exec truncated inte..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=122bf7b0c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=7132344728e7ec3f
dashboard link: https://syzkaller.appspot.com/bug?extid=ba21d65f55b562432c58
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14c90fa7400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ba21d65f55b562432c58@syzkaller.appspotmail.com
yz1> rejected, already enabled
Enabling of bearer <udp:
yz1> rejected, already enabled
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(class_idx > MAX_LOCKDEP_KEYS)
WARNING: CPU: 0 PID: 9 at kernel/locking/lockdep.c:3315
__lock_acquire+0x13bf/0x4700 kernel/locking/lockdep.c:3315
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.0.0-rc7+ #78
Enabling of bearer <udp:
yz1> rejected, already enabled
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
Enabling of bearer <udp:
yz1> rejected, already enabled
panic+0x2cb/0x65c kernel/panic.c:214
Enabling of bearer <udp:
yz1> rejected, already enabled
__warn.cold+0x20/0x45 kernel/panic.c:571
Enabling of bearer <udp:
yz1> rejected, already enabled
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
fixup_bug arch/x86/kernel/traps.c:173 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
Enabling of bearer <udp:
yz1> rejected, already enabled
RIP: 0010:__lock_acquire+0x13bf/0x4700 kernel/locking/lockdep.c:3315
Code: 8b 1d c9 a6 05 08 45 85 db 0f 85 d6 f4 ff ff 48 c7 c6 e0 a3 6b 87 48
c7 c7 40 78 6b 87 44 89 9c 24 98 00 00 00 e8 ef 29 ec ff <0f> 0b 44 8b 9c
24 98 00 00 00 e9 af f4 ff ff 8b 3d 7c 67 fe 08 85
RSP: 0018:ffff8880a985f320 EFLAGS: 00010086
Enabling of bearer <udp:
yz1> rejected, already enabled
RAX: 0000000000000000 RBX: 000000001ac4c57a RCX: 0000000000000000
RDX: 0000000000000100 RSI: ffffffff815a92c6 RDI: ffffed101530be56
RBP: ffff8880a985f4f0 R08: ffff8880a9846240 R09: fffffbfff1133361
R10: fffffbfff1133360 R11: ffffffff88999b03 R12: ffff8880a9846b28
R13: ffff8880a9846b32 R14: 000000001ac4c57a R15: ffff8880a9846240
Enabling of bearer <udp:
yz1> rejected, already enabled
Enabling of bearer <udp:
yz1> rejected, already enabled
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
__raw_spin_trylock include/linux/spinlock_api_smp.h:90 [inline]
_raw_spin_trylock+0x62/0x80 kernel/locking/spinlock.c:128
Enabling of bearer <udp:
yz1> rejected, already enabled
spin_trylock include/linux/spinlock.h:339 [inline]
icmp_xmit_lock net/ipv4/icmp.c:219 [inline]
icmp_send+0x54c/0x1400 net/ipv4/icmp.c:665
Enabling of bearer <udp:
yz1> rejected, already enabled
Enabling of bearer <udp:
yz1> rejected, already enabled
Enabling of bearer <udp:
yz1> rejected, already enabled
__udp4_lib_rcv+0x1fb2/0x2c50 net/ipv4/udp.c:2321
udp_rcv+0x22/0x30 net/ipv4/udp.c:2480
Enabling of bearer <udp:
yz1> rejected, already enabled
ip_protocol_deliver_rcu+0x60/0x8e0 net/ipv4/ip_input.c:208
Enabling of bearer <udp:
yz1> rejected, already enabled
ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:255
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1db/0x2f0 net/ipv4/ip_input.c:414
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:524
__netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
process_backlog+0x206/0x750 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x4fa/0x1070 net/core/dev.c:6412
__do_softirq+0x266/0x95a kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:654 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* general protection fault in ip6erspan_set_version
From: syzbot @ 2019-02-19 21:56 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: cb916fc5eabf Add linux-next specific files for 20190218
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15111104c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=6ef0fb4978ed6ac0
dashboard link: https://syzkaller.appspot.com/bug?extid=30191cf1057abd3064af
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1198a582c00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=142f37bcc00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+30191cf1057abd3064af@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 7549 Comm: syz-executor432 Not tainted 5.0.0-rc6-next-20190218
#37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
RSP: 0018:ffff888089ed7168 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8880869d6e58 RCX: 0000000000000000
RDX: 0000000000000016 RSI: ffffffff862736b4 RDI: 00000000000000b0
RBP: ffff888089ed7180 R08: 1ffff11010d3adcb R09: ffff8880869d6e58
R10: ffffed1010d3add5 R11: ffff8880869d6eaf R12: 0000000000000000
R13: ffffffff8931f8c0 R14: ffffffff862825d0 R15: ffff8880869d6e58
FS: 0000000000b3d880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000184 CR3: 0000000092cc5000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ip6erspan_newlink+0x66/0x7b0 net/ipv6/ip6_gre.c:2210
__rtnl_newlink+0x107b/0x16c0 net/core/rtnetlink.c:3176
rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3234
rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440159
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fffa69156e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440159
RDX: 0000000000000000 RSI: 0000000020001340 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000000000001 R09: 00000000004002c8
R10: 0000000000000011 R11: 0000000000000246 R12: 00000000004019e0
R13: 0000000000401a70 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 09f8a7d13b4faaa1 ]---
RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
RSP: 0018:ffff888089ed7168 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8880869d6e58 RCX: 0000000000000000
RDX: 0000000000000016 RSI: ffffffff862736b4 RDI: 00000000000000b0
RBP: ffff888089ed7180 R08: 1ffff11010d3adcb R09: ffff8880869d6e58
R10: ffffed1010d3add5 R11: ffff8880869d6eaf R12: 0000000000000000
R13: ffffffff8931f8c0 R14: ffffffff862825d0 R15: ffff8880869d6e58
FS: 0000000000b3d880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000184 CR3: 0000000092cc5000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH v4] net: ns83820: code cleanup for ns83820_probe_phy()
From: David Miller @ 2019-02-19 22:11 UTC (permalink / raw)
To: maowenan
Cc: kernel-janitors, netdev, john.fastabend, hawk, jakub.kicinski,
daniel, ast, julia.lawall, wharms
In-Reply-To: <20190219134510.51835-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Tue, 19 Feb 2019 21:45:10 +0800
> This patch is to do code cleanup for ns83820_probe_phy().
> It deletes unused variable 'first', commented out code,
> and the pointless 'for' loop.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> Acked-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
> v3->v4: delete pointless 'for' loop, variable 'i', and so on.
Before pushing out I realized I applied v3 instead of this v4, but
that's now fixed up.
^ permalink raw reply
* Re: [PATCH][next] ptp_qoriq: don't pass a large struct by value but instead pass it by reference
From: David Miller @ 2019-02-19 22:15 UTC (permalink / raw)
To: colin.king
Cc: yangbo.lu, claudiu.manoil, richardcochran, leoyang.li, netdev,
linuxppc-dev, linux-arm-kernel, kernel-janitors, linux-kernel
In-Reply-To: <20190219142120.11347-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 19 Feb 2019 14:21:20 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Passing the struct ptp_clock_info caps by parameter is passing over 130 bytes
> of data by value on the stack. Optimize this by passing it by reference instead.
> Also shinks the object code size:
>
> Before:
> text data bss dec hex filename
> 12596 2160 64 14820 39e4 drivers/ptp/ptp_qoriq.o
>
> After:
> text data bss dec hex filename
> 12567 2160 64 14791 39c7 drivers/ptp/ptp_qoriq.o
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH] sky2: Increase D3 delay again
From: David Miller @ 2019-02-19 22:17 UTC (permalink / raw)
To: kai.heng.feng; +Cc: mlindner, stephen, netdev, linux-kernel, stable
In-Reply-To: <20190219154529.8285-1-kai.heng.feng@canonical.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Tue, 19 Feb 2019 23:45:29 +0800
> Another platform requires even longer delay to make the device work
> correctly after S3.
>
> So increase the delay to 300ms.
>
> BugLink: https://bugs.launchpad.net/bugs/1798921
>
> Cc: stable@vger.kernel.org
Please do not CC: stable for networking changes.
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] team: use operstate consistently for linkup
From: David Miller @ 2019-02-19 22:18 UTC (permalink / raw)
To: gwilkie; +Cc: jiri, netdev
In-Reply-To: <20190219155715.769-1-gwilkie@vyatta.att-mail.com>
From: George Wilkie <gwilkie@vyatta.att-mail.com>
Date: Tue, 19 Feb 2019 15:57:15 +0000
> Fixes: f1d22a1e0595 ("team: account for oper state")
>
> Signed-off-by: George Wilkie <gwilkie@vyatta.att-mail.com>
Please do not put an empty line between Fixes: and other tags, all tags
are equal and should be grouped together.
^ permalink raw reply
* [pull request][net-next 00/11] Mellanox, mlx5 updates 2019-02-19
From: Saeed Mahameed @ 2019-02-19 22:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Ariel Almog, Saeed Mahameed
Hi Dave,
This series provides some updates to mlx5 driver.
In addition, there is one patch that defines new 50Gbps per lane link
modes in include/uapi/linux/ethtool.h:
("ethtool: Added support for 50Gbps per lane link modes")
For more information please see tag log below.
Please pull and let me know if there is any problem.
Thanks,
Saeed.
---
The following changes since commit 5770117186f018479b44e7d17fb2501c865c0c84:
Merge branch 'bnxt_en-Update-for-net-next' (2019-02-19 10:45:14 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2019-02-19
for you to fetch changes up to 1c50d369f560809d45e75fa9d7d6b3901192c18b:
net/mlx5: E-Switch, Disable esw manager vport correctly (2019-02-19 14:15:04 -0800)
----------------------------------------------------------------
mlx5-updates-2019-02-19
This series includes misc updates to mlx5 drivers and one ethtool update.
1) From Aya Levin:
- ethtool: Define 50Gbps per lane link modes
- add support for 50Gbps per lane link modes in mlx5 driver
2) From Tariq Toukan,
- Add a helper function to unify mlx5 resource reloading
3) From Vlad Buslov,
- Remove wrong and superfluous tc pedit header type check
4) From Tonghao Zhang,
- Some refactoring in en_tc.c to simplify the mlx5e_tc_add_fdb_flow
5) From Leon Romanovsky & Saeed,
- Compilation warning fixes
6) From Bodong wang,
- E-Switch fixes that are related to the SmarNIC series
----------------------------------------------------------------
Aya Levin (2):
ethtool: Added support for 50Gbps per lane link modes
net/mlx5: ethtool, Add ethtool support for 50Gbps per lane link modes
Bodong Wang (2):
net/mlx5: E-Switch, Fix the warning on vport index out of range
net/mlx5: E-Switch, Disable esw manager vport correctly
Leon Romanovsky (2):
net/mlx5e: Add missing static function annotation
net/mlx5: Delete unused FPGA QPN variable
Saeed Mahameed (1):
net/mlx5e: Remove unused variable ‘esw’
Tariq Toukan (1):
net/mlx5e: Wrap the open and apply of channels in one fail-safe function
Tonghao Zhang (2):
net/mlx5e: Introduce mlx5e_flow_esw_attr_init() helper
net/mlx5e: Remove 'parse_attr' argument in mlx5e_tc_add_fdb_flow()
Vlad Buslov (1):
net/mlx5e: Remove wrong and superfluous tc pedit header type check
drivers/net/ethernet/mellanox/mlx5/core/en.h | 6 +-
.../ethernet/mellanox/mlx5/core/en/monitor_stats.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 4 +-
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 297 +++++++++++++--------
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 33 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 51 ++--
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 5 +-
.../net/ethernet/mellanox/mlx5/core/fpga/core.c | 2 -
.../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 4 +-
include/uapi/linux/ethtool.h | 18 +-
10 files changed, 273 insertions(+), 149 deletions(-)
^ permalink raw reply
* [net-next 01/11] ethtool: Added support for 50Gbps per lane link modes
From: Saeed Mahameed @ 2019-02-19 22:19 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Ariel Almog, Aya Levin, Eran Ben Elisha, Saeed Mahameed
In-Reply-To: <20190219221957.2899-1-saeedm@mellanox.com>
From: Aya Levin <ayal@mellanox.com>
Added support for 50Gbps per lane link modes. Define various 50G, 100G
and 200G link modes using it.
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
include/uapi/linux/ethtool.h | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 17be76aeb468..378c52308d89 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1453,6 +1453,21 @@ enum ethtool_link_mode_bit_indices {
ETHTOOL_LINK_MODE_FEC_NONE_BIT = 49,
ETHTOOL_LINK_MODE_FEC_RS_BIT = 50,
ETHTOOL_LINK_MODE_FEC_BASER_BIT = 51,
+ ETHTOOL_LINK_MODE_50000baseKR_Full_BIT = 52,
+ ETHTOOL_LINK_MODE_50000baseSR_Full_BIT = 53,
+ ETHTOOL_LINK_MODE_50000baseCR_Full_BIT = 54,
+ ETHTOOL_LINK_MODE_50000baseLR_ER_FR_Full_BIT = 55,
+ ETHTOOL_LINK_MODE_50000baseDR_Full_BIT = 56,
+ ETHTOOL_LINK_MODE_100000baseKR2_Full_BIT = 57,
+ ETHTOOL_LINK_MODE_100000baseSR2_Full_BIT = 58,
+ ETHTOOL_LINK_MODE_100000baseCR2_Full_BIT = 59,
+ ETHTOOL_LINK_MODE_100000baseLR2_ER2_FR2_Full_BIT = 60,
+ ETHTOOL_LINK_MODE_100000baseDR2_Full_BIT = 61,
+ ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT = 62,
+ ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT = 63,
+ ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT = 64,
+ ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT = 65,
+ ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT = 66,
/* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
* 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
@@ -1461,7 +1476,7 @@ enum ethtool_link_mode_bit_indices {
*/
__ETHTOOL_LINK_MODE_LAST
- = ETHTOOL_LINK_MODE_FEC_BASER_BIT,
+ = ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT,
};
#define __ETHTOOL_LINK_MODE_LEGACY_MASK(base_name) \
@@ -1569,6 +1584,7 @@ enum ethtool_link_mode_bit_indices {
#define SPEED_50000 50000
#define SPEED_56000 56000
#define SPEED_100000 100000
+#define SPEED_200000 200000
#define SPEED_UNKNOWN -1
--
2.20.1
^ 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