* [PATCH v4 3/3] Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990
From: Matthias Kaehlcke @ 2019-02-19 20:05 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, linux-kernel, netdev, Balakrishna Godavarthi,
Matthias Kaehlcke
In-Reply-To: <20190219200559.13079-1-mka@chromium.org>
Set quirk for wcn3990 to read BD_ADDR from a firmware node property.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
---
Changes in v4:
-none
Changes in v3:
- none
Changes in v2:
- patch added to the series
---
drivers/bluetooth/hci_qca.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 5e03504c4e0ca..26efc2ef98d9a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1192,6 +1192,7 @@ static int qca_setup(struct hci_uart *hu)
* setup for every hci up.
*/
set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks);
+ set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
hu->hdev->shutdown = qca_power_off;
ret = qca_wcn3990_init(hu);
if (ret)
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* [PATCH v4 1/3] Bluetooth: Add quirk for reading BD_ADDR from fwnode property
From: Matthias Kaehlcke @ 2019-02-19 20:05 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, linux-kernel, netdev, Balakrishna Godavarthi,
Matthias Kaehlcke
In-Reply-To: <20190219200559.13079-1-mka@chromium.org>
Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
the public Bluetooth address from the firmware node property
'local-bd-address'. If quirk is set and the property does not exist
or is invalid the controller is marked as unconfigured.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Tested-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
---
Changes in v4:
- none
Changes in v3:
- return no value from hci_dev_get_bd_addr_from_property() since
currently nobody uses it anyway
- use bacpy() in hci_dev_get_bd_addr_from_property()
- return -EADDRNOTAVAIL if no BD_ADDR is configured or if the driver
has no ->set_bdaddr
Changes in v2:
- added check for return value of ->setup()
- only read BD_ADDR from the property if it isn't assigned yet. This
is needed to support configuration from user space
- refactored the branch of the new quirk to get rid of 'bd_addr_set'
- added 'Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>' tag
---
include/net/bluetooth/hci.h | 12 +++++++++++
net/bluetooth/hci_core.c | 43 +++++++++++++++++++++++++++++++++++++
net/bluetooth/mgmt.c | 6 ++++--
3 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index c36dc1e20556a..fbba43e9bef5b 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -158,6 +158,18 @@ enum {
*/
HCI_QUIRK_INVALID_BDADDR,
+ /* When this quirk is set, the public Bluetooth address
+ * initially reported by HCI Read BD Address command
+ * is considered invalid. The public BD Address can be
+ * specified in the fwnode property 'local-bd-address'.
+ * If this property does not exist or is invalid controller
+ * configuration is required before this device can be used.
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_USE_BDADDR_PROPERTY,
+
/* When this quirk is set, the duplicate filtering during
* scanning is based on Bluetooth devices addresses. To allow
* RSSI based updates, restart scanning if needed.
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 26e3d36aee298..d6b2540ba7f8b 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -30,6 +30,7 @@
#include <linux/rfkill.h>
#include <linux/debugfs.h>
#include <linux/crypto.h>
+#include <linux/property.h>
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -1355,6 +1356,32 @@ int hci_inquiry(void __user *arg)
return err;
}
+/**
+ * hci_dev_get_bd_addr_from_property - Get the Bluetooth Device Address
+ * (BD_ADDR) for a HCI device from
+ * a firmware node property.
+ * @hdev: The HCI device
+ *
+ * Search the firmware node for 'local-bd-address'.
+ *
+ * All-zero BD addresses are rejected, because those could be properties
+ * that exist in the firmware tables, but were not updated by the firmware. For
+ * example, the DTS could define 'local-bd-address', with zero BD addresses.
+ */
+static void hci_dev_get_bd_addr_from_property(struct hci_dev *hdev)
+{
+ struct fwnode_handle *fwnode = dev_fwnode(hdev->dev.parent);
+ bdaddr_t ba;
+ int ret;
+
+ ret = fwnode_property_read_u8_array(fwnode, "local-bd-address",
+ (u8 *)&ba, sizeof(ba));
+ if (ret < 0 || !bacmp(&ba, BDADDR_ANY))
+ return;
+
+ bacpy(&hdev->public_addr, &ba);
+}
+
static int hci_dev_do_open(struct hci_dev *hdev)
{
int ret = 0;
@@ -1422,6 +1449,22 @@ static int hci_dev_do_open(struct hci_dev *hdev)
if (hdev->setup)
ret = hdev->setup(hdev);
+ if (ret)
+ goto setup_failed;
+
+ if (test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) {
+ if (!bacmp(&hdev->public_addr, BDADDR_ANY))
+ hci_dev_get_bd_addr_from_property(hdev);
+
+ if (bacmp(&hdev->public_addr, BDADDR_ANY) &&
+ hdev->set_bdaddr)
+ ret = hdev->set_bdaddr(hdev,
+ &hdev->public_addr);
+ else
+ ret = -EADDRNOTAVAIL;
+ }
+
+setup_failed:
/* The transport driver can set these quirks before
* creating the HCI device or in its setup callback.
*
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index ccce954f81468..fae84353d030f 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -551,7 +551,8 @@ static bool is_configured(struct hci_dev *hdev)
!hci_dev_test_flag(hdev, HCI_EXT_CONFIGURED))
return false;
- if (test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) &&
+ if ((test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) ||
+ test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) &&
!bacmp(&hdev->public_addr, BDADDR_ANY))
return false;
@@ -566,7 +567,8 @@ static __le32 get_missing_options(struct hci_dev *hdev)
!hci_dev_test_flag(hdev, HCI_EXT_CONFIGURED))
options |= MGMT_OPTION_EXTERNAL_CONFIG;
- if (test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) &&
+ if ((test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) ||
+ test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) &&
!bacmp(&hdev->public_addr, BDADDR_ANY))
options |= MGMT_OPTION_PUBLIC_ADDRESS;
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* [PATCH v4 2/3] Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
From: Matthias Kaehlcke @ 2019-02-19 20:05 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, linux-kernel, netdev, Balakrishna Godavarthi,
Matthias Kaehlcke
In-Reply-To: <20190219200559.13079-1-mka@chromium.org>
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
---
Changes in v4:
- btqcomsmd_setup(): removed unused variables 'err' and 'btq'
Changes in v3:
- none
Changes in v2:
- removed now unused field 'bdaddr' from struct btqcomsmd
- added 'Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>' tag
---
drivers/bluetooth/btqcomsmd.c | 31 +++----------------------------
1 file changed, 3 insertions(+), 28 deletions(-)
diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
index 7df3eed1ef5e9..e0d4c6f1d3ab6 100644
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -28,7 +28,6 @@
struct btqcomsmd {
struct hci_dev *hdev;
- bdaddr_t bdaddr;
struct rpmsg_endpoint *acl_channel;
struct rpmsg_endpoint *cmd_channel;
};
@@ -116,32 +115,17 @@ static int btqcomsmd_close(struct hci_dev *hdev)
static int btqcomsmd_setup(struct hci_dev *hdev)
{
- struct btqcomsmd *btq = hci_get_drvdata(hdev);
struct sk_buff *skb;
- int err;
skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
if (IS_ERR(skb))
return PTR_ERR(skb);
kfree_skb(skb);
- /* Devices do not have persistent storage for BD address. If no
- * BD address has been retrieved during probe, mark the device
- * as having an invalid BD address.
- */
- if (!bacmp(&btq->bdaddr, BDADDR_ANY)) {
- set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks);
- return 0;
- }
-
- /* When setting a configured BD address fails, mark the device
- * as having an invalid BD address.
+ /* Devices do not have persistent storage for BD address. Retrieve
+ * it from the firmware node property.
*/
- err = qca_set_bdaddr_rome(hdev, &btq->bdaddr);
- if (err) {
- set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks);
- return 0;
- }
+ set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
return 0;
}
@@ -169,15 +153,6 @@ static int btqcomsmd_probe(struct platform_device *pdev)
if (IS_ERR(btq->cmd_channel))
return PTR_ERR(btq->cmd_channel);
- /* The local-bd-address property is usually injected by the
- * bootloader which has access to the allocated BD address.
- */
- if (!of_property_read_u8_array(pdev->dev.of_node, "local-bd-address",
- (u8 *)&btq->bdaddr, sizeof(bdaddr_t))) {
- dev_info(&pdev->dev, "BD address %pMR retrieved from device-tree",
- &btq->bdaddr);
- }
-
hdev = hci_alloc_dev();
if (!hdev)
return -ENOMEM;
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* [PATCH v4 0/3] Add quirk for reading BD_ADDR from fwnode property
From: Matthias Kaehlcke @ 2019-02-19 20:05 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, linux-kernel, netdev, Balakrishna Godavarthi,
Matthias Kaehlcke
On some systems the Bluetooth Device Address (BD_ADDR) isn't stored
on the Bluetooth chip itself. One way to configure the address is
through the device tree (patched in by the bootloader). The btqcomsmd
driver is an example, it can read the address from the DT property
'local-bd-address'.
To avoid redundant open-coded reading of 'local-bd-address' and error
handling this series adds the quirk HCI_QUIRK_USE_BDADDR_PROPERTY to
retrieve the BD address of a device from the DT and adapts the
btqcomsmd and hci_qca drivers to use this quirk.
Matthias Kaehlcke (3):
Bluetooth: Add quirk for reading BD_ADDR from fwnode property
Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990
drivers/bluetooth/btqcomsmd.c | 31 +++----------------------
drivers/bluetooth/hci_qca.c | 1 +
include/net/bluetooth/hci.h | 12 ++++++++++
net/bluetooth/hci_core.c | 43 +++++++++++++++++++++++++++++++++++
net/bluetooth/mgmt.c | 6 +++--
5 files changed, 63 insertions(+), 30 deletions(-)
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply
* [PATCH net-next] i40e: mark expected switch fall-through
From: Gustavo A. R. Silva @ 2019-02-19 20:18 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/i40e/i40e_xsk.c: In function ‘i40e_run_xdp_zc’:
drivers/net/ethernet/intel/i40e/i40e_xsk.c:209:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
bpf_warn_invalid_xdp_action(act);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/i40e/i40e_xsk.c:210:2: note: here
case XDP_ABORTED:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
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/i40e/i40e_xsk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index e190a2c2b9ff..a02776cf1656 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -207,6 +207,7 @@ static int i40e_run_xdp_zc(struct i40e_ring *rx_ring, struct xdp_buff *xdp)
break;
default:
bpf_warn_invalid_xdp_action(act);
+ /* fall through */
case XDP_ABORTED:
trace_xdp_exception(rx_ring->netdev, xdp_prog, act);
/* fallthrough -- handle aborts by dropping packet */
--
2.20.1
^ permalink raw reply related
* [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
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