* [PATCH v4 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Ding Tianhong @ 2017-06-12 11:05 UTC (permalink / raw)
To: leedom, ashok.raj, helgaas, werner, ganeshgr, asit.k.mallick,
patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira,
gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem,
alexander.duyck, linux-arm-kernel, netdev, linux-pci,
linux-kernel
Cc: Ding Tianhong
Some devices have problems with Transaction Layer Packets with the Relaxed
Ordering Attribute set. This patch set adds a new PCIe Device Flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
devices with Relaxed Ordering issues, and a use of this new flag by the
cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
Ports.
It's been years since I've submitted kernel.org patches, I appolgise for the
almost certain submission errors.
v2: Alexander point out that the v1 was only a part of the whole solution,
some platform which has some issues could use the new flag to indicate
that it is not safe to enable relaxed ordering attribute, then we need
to clear the relaxed ordering enable bits in the PCI configuration when
initializing the device. So add a new second patch to modify the PCI
initialization code to clear the relaxed ordering enable bit in the
event that the root complex doesn't want relaxed ordering enabled.
The third patch was base on the v1's second patch and only be changed
to query the relaxed ordering enable bit in the PCI configuration space
to allow the Chelsio NIC to send TLPs with the relaxed ordering attributes
set.
This version didn't plan to drop the defines for Intel Drivers to use the
new checking way to enable relaxed ordering because it is not the hardest
part of the moment, we could fix it in next patchset when this patches
reach the goal.
v3: Redesigned the logic for pci_configure_relaxed_ordering when configuration,
If a PCIe device didn't enable the relaxed ordering attribute default,
we should not do anything in the PCIe configuration, otherwise we
should check if any of the devices above us do not support relaxed
ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on
the result if we get a return that indicate that the relaxed ordering
is not supported we should update our device to disable relaxed ordering
in configuration space. If the device above us doesn't exist or isn't
the PCIe device, we shouldn't do anything and skip updating relaxed ordering
because we are probably running in a guest.
v4: Rename the functions pcie_get_relaxed_ordering and pcie_disable_relaxed_ordering
according John's suggestion, and modify the description, use the true/false
as the return value.
We shouldn't enable relaxed ordering attribute by the setting in the root
complex configuration space for PCIe device, so fix it for cxgb4.
Fix some format issues.
Casey Leedom (2):
PCI: Add new PCIe Fabric End Node flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING
net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
Ding Tianhong (1):
PCI: Enable PCIe Relaxed Ordering if supported
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 ++++++++++
drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +--
drivers/pci/pci.c | 32 +++++++++++++++++++
drivers/pci/probe.c | 41 +++++++++++++++++++++++++
drivers/pci/quirks.c | 38 +++++++++++++++++++++++
include/linux/pci.h | 4 +++
7 files changed, 136 insertions(+), 2 deletions(-)
--
1.9.0
^ permalink raw reply
* [PATCH v4 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING
From: Ding Tianhong @ 2017-06-12 11:05 UTC (permalink / raw)
To: leedom, ashok.raj, helgaas, werner, ganeshgr, asit.k.mallick,
patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira,
gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem,
alexander.duyck, linux-arm-kernel, netdev, linux-pci,
linux-kernel
Cc: Ding Tianhong
In-Reply-To: <1497265525-4752-1-git-send-email-dingtianhong@huawei.com>
From: Casey Leedom <leedom@chelsio.com>
The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
Ordering Attribute should not be used on Transaction Layer Packets destined
for the PCIe End Node so flagged. Initially flagged this way are Intel
E5-26xx Root Complex Ports which suffer from a Flow Control Credit
Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which
don't obey PCIe 3.0 ordering rules which can lead to Data Corruption.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..58bdd23 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3999,6 +3999,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
quirk_tw686x_class);
/*
+ * Some devices have problems with Transaction Layer Packets with the Relaxed
+ * Ordering Attribute set. Such devices should mark themselves and other
+ * Device Drivers should check before sending TLPs with RO set.
+ */
+static void quirk_relaxedordering_disable(struct pci_dev *dev)
+{
+ dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
+}
+
+/*
+ * Intel E5-26xx Root Complex has a Flow Control Credit issue which can
+ * cause performance problems with Upstream Transaction Layer Packets with
+ * Relaxed Ordering set.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+
+/*
+ * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex
+ * where Upstream Transaction Layer Packets with the Relaxed Ordering
+ * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering
+ * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules
+ * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0
+ * November 10, 2010). As a result, on this platform we can't use Relaxed
+ * Ordering for Upstream TLPs.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+
+/*
* Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
* values for the Attribute as were supplied in the header of the
* corresponding Request, except as explicitly allowed when IDO is used."
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 33c2b0b..e1e8428 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -183,6 +183,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT = (__force pci_dev_flags_t) (1 << 9),
/* Do not use FLR even if device advertises PCI_AF_CAP */
PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
+ /* Don't use Relaxed Ordering for TLPs directed at this device */
+ PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
};
enum pci_irq_reroute_variant {
--
1.9.0
^ permalink raw reply related
* [PATCH v4 2/3] PCI: Enable PCIe Relaxed Ordering if supported
From: Ding Tianhong @ 2017-06-12 11:05 UTC (permalink / raw)
To: leedom, ashok.raj, helgaas, werner, ganeshgr, asit.k.mallick,
patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira,
gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem,
alexander.duyck, linux-arm-kernel, netdev, linux-pci,
linux-kernel
Cc: Ding Tianhong
In-Reply-To: <1497265525-4752-1-git-send-email-dingtianhong@huawei.com>
The PCIe Device Control Register use the bit 4 to indicate that
whether the device is permitted to enable relaxed ordering or not.
But relaxed ordering is not safe for some platform which could only
use strong write ordering, so devices are allowed (but not required)
to enable relaxed ordering bit by default.
If a PCIe device didn't enable the relaxed ordering attribute default,
we should not do anything in the PCIe configuration, otherwise we
should check if any of the devices above us do not support relaxed
ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on
the result if we get a return that indicate that the relaxed ordering
is not supported we should update our device to disable relaxed ordering
in configuration space. If the device above us doesn't exist or isn't
the PCIe device, we shouldn't do anything and skip updating relaxed ordering
because we are probably running in a guest machine.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/pci/pci.c | 32 ++++++++++++++++++++++++++++++++
drivers/pci/probe.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 2 ++
3 files changed, 75 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b01bd5b..b44f34c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4878,6 +4878,38 @@ int pcie_set_mps(struct pci_dev *dev, int mps)
EXPORT_SYMBOL(pcie_set_mps);
/**
+ * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit
+ * @dev: PCI device to query
+ *
+ * If possible clear relaxed ordering
+ */
+int pcie_clear_relaxed_ordering(struct pci_dev *dev)
+{
+ return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
+ PCI_EXP_DEVCTL_RELAX_EN);
+}
+EXPORT_SYMBOL(pcie_clear_relaxed_ordering);
+
+/**
+ * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support
+ * @dev: PCI device to query
+ *
+ * Returns true if the device support relaxed ordering attribute.
+ */
+bool pcie_relaxed_ordering_supported(struct pci_dev *dev)
+{
+ bool ro_supported = false;
+ u16 v;
+
+ pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v);
+ if ((v & PCI_EXP_DEVCTL_RELAX_EN) >> 4)
+ ro_supported = true;
+
+ return ro_supported;
+}
+EXPORT_SYMBOL(pcie_relaxed_ordering_supported);
+
+/**
* pcie_get_minimum_link - determine minimum link settings of a PCI device
* @dev: PCI device to query
* @speed: storage for minimum speed
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 19c8950..ed1f717 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1701,6 +1701,46 @@ static void pci_configure_extended_tags(struct pci_dev *dev)
PCI_EXP_DEVCTL_EXT_TAG);
}
+/**
+ * pci_dev_should_disable_relaxed_ordering - check if the PCI device
+ * should disable the relaxed ordering attribute.
+ * @dev: PCI device
+ *
+ * Return true if any of the PCI devices above us do not support
+ * relaxed ordering.
+ */
+static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev)
+{
+ bool ro_disabled = false;
+
+ while (dev) {
+ if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
+ ro_disabled = true;
+ break;
+ }
+ dev = dev->bus->self;
+ }
+
+ return ro_disabled;
+}
+
+static void pci_configure_relaxed_ordering(struct pci_dev *dev)
+{
+ struct pci_dev *bridge = pci_upstream_bridge(dev);
+
+ if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
+ return;
+
+ /* If the releaxed ordering enable bit is not set, do nothing. */
+ if (!pcie_relaxed_ordering_supported(dev))
+ return;
+
+ if (pci_dev_should_disable_relaxed_ordering(dev)) {
+ pcie_clear_relaxed_ordering(dev);
+ dev_info(&dev->dev, "Disable Relaxed Ordering\n");
+ }
+}
+
static void pci_configure_device(struct pci_dev *dev)
{
struct hotplug_params hpp;
@@ -1708,6 +1748,7 @@ static void pci_configure_device(struct pci_dev *dev)
pci_configure_mps(dev);
pci_configure_extended_tags(dev);
+ pci_configure_relaxed_ordering(dev);
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e1e8428..9870781 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1105,6 +1105,8 @@ int __pci_enable_wake(struct pci_dev *dev, pci_power_t state,
void pci_pme_wakeup_bus(struct pci_bus *bus);
void pci_d3cold_enable(struct pci_dev *dev);
void pci_d3cold_disable(struct pci_dev *dev);
+int pcie_clear_relaxed_ordering(struct pci_dev *dev);
+bool pcie_relaxed_ordering_supported(struct pci_dev *dev);
static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state,
bool enable)
--
1.9.0
^ permalink raw reply related
* [PATCH v4 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Ding Tianhong @ 2017-06-12 11:05 UTC (permalink / raw)
To: leedom, ashok.raj, helgaas, werner, ganeshgr, asit.k.mallick,
patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira,
gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem,
alexander.duyck, linux-arm-kernel, netdev, linux-pci,
linux-kernel
Cc: Ding Tianhong
In-Reply-To: <1497265525-4752-1-git-send-email-dingtianhong@huawei.com>
From: Casey Leedom <leedom@chelsio.com>
cxgb4 Ethernet driver now queries PCIe configuration space to determine
if it can send TLPs to it with the Relaxed Ordering Attribute set.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index e88c180..478f25a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -521,6 +521,7 @@ enum { /* adapter flags */
USING_SOFT_PARAMS = (1 << 6),
MASTER_PF = (1 << 7),
FW_OFLD_CONN = (1 << 9),
+ ROOT_NO_RELAXED_ORDERING = (1 << 10),
};
enum {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 38a5c67..1dd093d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4726,6 +4726,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
adapter->msg_enable = DFLT_MSG_ENABLE;
memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map));
+ /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+ * Ingress Packet Data to Free List Buffers in order to allow for
+ * chipset performance optimizations between the Root Complex and
+ * Memory Controllers. (Messages to the associated Ingress Queue
+ * notifying new Packet Placement in the Free Lists Buffers will be
+ * send without the Relaxed Ordering Attribute thus guaranteeing that
+ * all preceding PCIe Transaction Layer Packets will be processed
+ * first.) But some Root Complexes have various issues with Upstream
+ * Transaction Layer Packets with the Relaxed Ordering Attribute set.
+ * The PCIe devices which under the Root Complexes will be cleared the
+ * Relaxed Ordering bit in the configuration space, So we check our
+ * PCIe configuration space to see if it's flagged with advice against
+ * using Relaxed Ordering.
+ */
+ if (pcie_relaxed_ordering_supported(pdev))
+ adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
spin_lock_init(&adapter->stats_lock);
spin_lock_init(&adapter->tid_release_lock);
spin_lock_init(&adapter->win0_lock);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index f05f0d4..ac229a3 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2571,6 +2571,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
struct fw_iq_cmd c;
struct sge *s = &adap->sge;
struct port_info *pi = netdev_priv(dev);
+ int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING);
/* Size needs to be multiple of 16, including status entry. */
iq->size = roundup(iq->size, 16);
@@ -2624,8 +2625,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc);
c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F |
- FW_IQ_CMD_FL0FETCHRO_F |
- FW_IQ_CMD_FL0DATARO_F |
+ FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+ FW_IQ_CMD_FL0DATARO_V(relaxed) |
FW_IQ_CMD_FL0PADEN_F);
if (cong >= 0)
c.iqns_to_fl0congen |=
--
1.9.0
^ permalink raw reply related
* Re: [PATCH v2] arm: eBPF JIT compiler
From: Russell King - ARM Linux @ 2017-06-12 11:06 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Kees Cook, Shubham Bansal, Network Development, David S. Miller,
Alexei Starovoitov, linux-arm-kernel@lists.infradead.org, LKML,
Andrew Lunn
In-Reply-To: <593E6B0F.8070901@iogearbox.net>
On Mon, Jun 12, 2017 at 12:21:03PM +0200, Daniel Borkmann wrote:
> On 05/30/2017 09:19 PM, Kees Cook wrote:
> >On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal
> ><illusionist.neo@gmail.com> wrote:
> >>+static int validate_code(struct jit_ctx *ctx)
> >>+{
> >>+ int i;
> >>+
> >>+ for (i = 0; i < ctx->idx; i++) {
> >>+ u32 a32_insn = le32_to_cpu(ctx->target[i]);
>
> Given __opcode_to_mem_arm(ARM_INST_UDF) is used to fill the image,
> perhaps use the __mem_to_opcode_arm() helper for the check?
>
> >>+ if (a32_insn == ARM_INST_UDF)
The following is probably better:
if (ctx->target[i] == __opcode_to_mem_arm(ARM_INST_UDF))
since then you can take advantage of the compiler optimising the
constant rather than having to do a byte swap on an unknown 32-bit
value.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS
From: Jamal Hadi Salim @ 2017-06-12 11:10 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <20170612103432.GA1993@nanopsycho>
On 17-06-12 06:34 AM, Jiri Pirko wrote:
> Sun, Jun 11, 2017 at 08:37:25PM CEST, jhs@mojatatu.com wrote:
>> On 17-06-11 01:38 PM, Jamal Hadi Salim wrote:
>>> On 17-06-11 09:49 AM, Jiri Pirko wrote:
>>>> Sun, Jun 11, 2017 at 01:53:43PM CEST, jhs@mojatatu.com wrote:
>>>>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>>
>>>
>>>>> This patch also provides an extra feature: a validation callback
>>>>> that could be speaciliazed for other types.
>>>>
>>>> s/speaciliazed/speciliazed/
>>>>
>>>
>>> Will fix.
>>>
>>>
>>>>>
>>>>> [ATTR_GOO] = { .type = MYTYPE,
>>>>> .validation_data = &myvalidation_data,
>>>>> .validate_content = mycontent_validator },
>>>>
>>>> Indent is wrong. (Does not matter really in desc, but anyway)
>>>>
>>>
>>> I cant find out how it got indented that way; my source
>>> or email dont show it as such (but really doesnt matter).
>>>
>>>
>>>> Suggested-by: Jiri Pirko <jiri@mellanox.com>
>>>>
>>>
>>> Will add.
>>>
>>>>
>>>>> ---
>>>>> include/net/netlink.h | 11 +++++++++++
>>>>> include/uapi/linux/rtnetlink.h | 17 +++++++++++++++++
>>>>> lib/nlattr.c | 25 +++++++++++++++++++++++++
>>>>> 3 files changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/include/net/netlink.h b/include/net/netlink.h
>>>>> index 0170917..8ab9784 100644
>>>>> --- a/include/net/netlink.h
>>>>> +++ b/include/net/netlink.h
>>>>> @@ -6,6 +6,11 @@
>>>>> #include <linux/jiffies.h>
>>>>> #include <linux/in6.h>
>>>>>
>>>>> +struct nla_bit_flags {
>>>>> + u32 nla_flag_values;
>>>>> + u32 nla_flag_selector;
>>>>> +};
>>>>
>>>> I don't understand why you redefine the struct here. You already have it
>>>> defined in the uapi: struct __nla_bit_flags
>>>>
>>>> Just move this (struct nla_bit_flags) to the uapi and remove
>>>> __nla_bit_flags ?
>>>>
>>>
>>> I am not sure that will compile since the type is defined in netlink.h
>>> Also, note: uapi uses _u32 and kernel uses u32 as types i.e it is pretty
>>> common approach; i will try to move it to uapi and keep that uapi
>>> format. If it doesnt compile without acrobatics I will keep it as is.
>>>
>>
>> It doesnt compile - I could move it to linux/netlink.h but it seems
>> so out of place.
>> so i will keep things as is for now unless you can think of something
>> else.
>
> First of all, makes no sense to put this struct "struct __nla_bit_flags"
> into rtnetlink.h uapi file. This is generic netlink stuff, not specifict
> to rtnetlink.
>
> I believe that this struct should go into:
> include/uapi/linux/netlink.h
>
> struct nla_flag_bits {
> __u32 nla_flag_bits_values;
> __u32 nla_flag_bits_selector;
> };
>
> Then you can use it from userspace and everywhere in kernel.
>
That file seems to be very out of place for this stuff.
> Btw, I find it very odd that enum containling NLA_* like NLA_U32 and
> others is not part of uapi file and is rather defined in
> include/net/netlink.h. Any idea why?
>
NLA_XXX are kernel side types. They are part of net/netlink.h which is
not uapi accessible.
David Ahern has submitted a patch to move all those defines to iproute2.
Will make sense to move these to a uapi/linux/netlink-types.h but that
is waay beyond the scope of this patch set.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v10 3/4] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jamal Hadi Salim @ 2017-06-12 11:16 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <20170611141303.GC1896@nanopsycho.orion>
On 17-06-11 10:13 AM, Jiri Pirko wrote:
> Sun, Jun 11, 2017 at 01:53:45PM CEST, jhs@mojatatu.com wrote:
[..]
>> @@ -1168,14 +1185,24 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
>> if (a_o == NULL)
>> return 0;
>>
>> + if (tb[TCA_ROOT_FLAGS])
>> + nla_memcpy(&select_flags, tb[TCA_ROOT_FLAGS],
>> + sizeof(select_flags));
>
> Please introduce a helper for this attr type in patch 1:
>
> u32 select_flags;
>
> select_flags = nla_get_flag_bits_values(tb[TCA_ROOT_FLAGS])
>
This also is not useful.
It happens to be ok for this use case but not for the
general case. i.e.
We need to get the whole struct not just the values
and use the selector to pick what bits are affected.
Example if bit X is set to 1 in selector and bit X in value
is 0, then we set the kernel's bit X to 0.
cheers,
jamal
^ permalink raw reply
* Re: ravb WoL interrupt flood
From: Niklas Söderlund @ 2017-06-12 11:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Sergei Shtylyov, Linux-Renesas, netdev@vger.kernel.org
In-Reply-To: <20170530102924.GB7484@bigcity.dyn.berto.se>
Hi Geert,
On 2017-05-30 12:29:24 +0200, Niklas Söderlund wrote:
> Hi Geert,
>
> Thanks for the report. I did run a 200+ loop suspend/resume without
> issues so this error is probably hard to reproduce or something changed
> since v4.11-rc1 which if IIRC was the base I used to do the tests.
>
> All I can think of is that if the interface was down at the time the
> system was suspend. There is a bug in the driver which is in
> renesas-drivers related to that. But given that you woken up by WoL that
> is probably not the case :-)
>
> I will do more tests and see if I can reproduce this once I'm back in
> Stockholm.
I have now done over a 500 suspend/resume loops and not been able to see
this :-(
I have run it with and without your '[PATCH/RFC] clk: renesas: cpg-mssr:
Restore module clock registers during resume' patch but no noticeable
difference.
I had a small cleanup in my patch which would differ from the one you
use. The diff is only in effect when resuming from s2ram so it should
have no effect here but still it is a change. My plan is to submit the
version with this fix for tomorrows renesas-drivers and then rerun my
tests using that. If I still can't reproduce it then I think I will
submit a v2 of my WoL patch to the ML, do this sounds like an OK plan to
you?
>
>
> On 2017-05-30 11:23:23 +0200, Geert Uytterhoeven wrote:
> > Hi Niklas,
> >
> > I just got a flood of messages after WoL from s2idle on r8a7795/salvator-x:
> >
> > [ 802.341060] ravb e6800000.ethernet eth0: ignoring interrupt, rx
> > status 0x00000001, rx mask 0x00000001,
> > [ 802.350369] ravb e6800000.ethernet eth0: tx
> > status 0x00000000, tx mask 0x00000001.
> > [ 802.359684] ravb e6800000.ethernet eth0: ignoring interrupt, rx
> > status 0x00000001, rx mask 0x00000001,
> > [ 802.368993] ravb e6800000.ethernet eth0: tx
> > status 0x00000000, tx mask 0x00000001.
> > [ 802.378308] ravb e6800000.ethernet eth0: ignoring interrupt, rx
> > status 0x00000001, rx mask 0x00000001,
> > [ 802.387616] ravb e6800000.ethernet eth0: tx
> > status 0x00000000, tx mask 0x00000001.
> > [ 802.396931] ravb e6800000.ethernet eth0: ignoring interrupt, rx
> > status 0x00000001, rx mask 0x00000001,
> > [ 802.406240] ravb e6800000.ethernet eth0: tx
> > status 0x00000000, tx mask 0x00000001.
> > ...
> >
> > Unfortunately I cannot reproduce it.
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds
>
> --
> Regards,
> Niklas Söderlund
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH] ravb: add wake-on-lan support via magic packet
From: Niklas Söderlund @ 2017-06-12 11:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Sergei Shtylyov, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <CAMuHMdVzRKTtDE=+hBkde+zFyYOb54iKesSGbJVJ2j_-HPZ+wQ@mail.gmail.com>
Hi Geert,
On 2017-05-18 10:52:25 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
> <niklas.soderlund@ragnatech.se> wrote:
> > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 16, 2017 at 1:01 PM, Simon Horman <horms@verge.net.au> wrote:
> >> > Is there some way for - e.g. the driver - to not enable WoL on Gen3 SoCs
> >> > until the clock issues is sorted out? I'm quite happy to enable features
> >> > where they work; not so much where they don't.
> >>
> >> Agreed.
> >>
> >> One workaround could be to disable/enable the module clock in the WoL
> >> resume path, to make sure it is enabled. Once the enable count reaches
> >> 0, CCF will know it's disabled, and will really enable next time.
> >> You may need a double disable/double enable though, without testing I
> >> don't know remember the enable count is 1 or 2 at that point (due to PM
> >> runtime).
> >
> > I thought about this but it feels like such a hack I did not dare
> > suggest it :-) But at the same time it would be nice to enable WoL for
> > the s2idle use-case where it works. Only resume from PSCI with WoL
> > enabled that is broken, and WoL in PSCI suspend will never work :-)
>
> Indeed.
>
> > How about I add another patch in v2 on-top of this that adds the clock
> > disable/enable hack? That way it's clear that this is a workaround and
> > once we have support for suspend/resume in CPG/MSSR just that patch can
> > be reverted? Or is it cleaner to fold it in to this patch with a big
> > comment that this is a workaround? Or is it maybe better to hold of on
> > this until CPG/MSSR supports suspend/resume?
>
> Personally, I would have no problems of having the workaround integrated (and
> documented, of course) in the WoL patch, as it avoids having broken PSCI
> suspend in between WoL-without-workaround and a separate workaround.
You have now posted '[PATCH/RFC] clk: renesas: cpg-mssr: Restore module
clock registers during resume' which solves this issue. Do you think it
would be OK for me to resubmit this patch due to an unrelated fix and
state that it depends on your patch or do you feel it still would be
valuable to include a workaround in the RAVB driver as to not make it
dependent on your patch?
>
> It's not that dissimilar from the initial R-Car Gen3 support patch limiting
> ravb to 100 Mbps.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH] ravb: add wake-on-lan support via magic packet
From: Geert Uytterhoeven @ 2017-06-12 11:43 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Simon Horman, Sergei Shtylyov, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20170612113210.GH17461@bigcity.dyn.berto.se>
Hi Niklas,
On Mon, Jun 12, 2017 at 1:32 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> On 2017-05-18 10:52:25 +0200, Geert Uytterhoeven wrote:
>> On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
>> <niklas.soderlund@ragnatech.se> wrote:
>> > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
>> >> On Tue, May 16, 2017 at 1:01 PM, Simon Horman <horms@verge.net.au> wrote:
>> >> > Is there some way for - e.g. the driver - to not enable WoL on Gen3 SoCs
>> >> > until the clock issues is sorted out? I'm quite happy to enable features
>> >> > where they work; not so much where they don't.
>> >>
>> >> Agreed.
>> >>
>> >> One workaround could be to disable/enable the module clock in the WoL
>> >> resume path, to make sure it is enabled. Once the enable count reaches
>> >> 0, CCF will know it's disabled, and will really enable next time.
>> >> You may need a double disable/double enable though, without testing I
>> >> don't know remember the enable count is 1 or 2 at that point (due to PM
>> >> runtime).
>> >
>> > I thought about this but it feels like such a hack I did not dare
>> > suggest it :-) But at the same time it would be nice to enable WoL for
>> > the s2idle use-case where it works. Only resume from PSCI with WoL
>> > enabled that is broken, and WoL in PSCI suspend will never work :-)
>>
>> Indeed.
>>
>> > How about I add another patch in v2 on-top of this that adds the clock
>> > disable/enable hack? That way it's clear that this is a workaround and
>> > once we have support for suspend/resume in CPG/MSSR just that patch can
>> > be reverted? Or is it cleaner to fold it in to this patch with a big
>> > comment that this is a workaround? Or is it maybe better to hold of on
>> > this until CPG/MSSR supports suspend/resume?
>>
>> Personally, I would have no problems of having the workaround integrated (and
>> documented, of course) in the WoL patch, as it avoids having broken PSCI
>> suspend in between WoL-without-workaround and a separate workaround.
>
> You have now posted '[PATCH/RFC] clk: renesas: cpg-mssr: Restore module
> clock registers during resume' which solves this issue. Do you think it
> would be OK for me to resubmit this patch due to an unrelated fix and
> state that it depends on your patch or do you feel it still would be
> valuable to include a workaround in the RAVB driver as to not make it
> dependent on your patch?
The the module clock restore patch fixes the issue, I think it's too immature
to upstream. Applying your WoL patch as-is does introduce a regression if
WoL is enabled (although you could debate that it's not a regression, as WoL
couldn't be enabled before, but a generic userspace may try to do that anyway).
If the workaround isn't too ugly, I would include it.
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS
From: Jiri Pirko @ 2017-06-12 11:43 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <8e2f151d-3a02-4b1b-755b-23a0a85556b4@mojatatu.com>
Mon, Jun 12, 2017 at 01:10:56PM CEST, jhs@mojatatu.com wrote:
>On 17-06-12 06:34 AM, Jiri Pirko wrote:
>> Sun, Jun 11, 2017 at 08:37:25PM CEST, jhs@mojatatu.com wrote:
>> > On 17-06-11 01:38 PM, Jamal Hadi Salim wrote:
>> > > On 17-06-11 09:49 AM, Jiri Pirko wrote:
>> > > > Sun, Jun 11, 2017 at 01:53:43PM CEST, jhs@mojatatu.com wrote:
>> > > > > From: Jamal Hadi Salim <jhs@mojatatu.com>
>> > >
>> > >
>> > > > > This patch also provides an extra feature: a validation callback
>> > > > > that could be speaciliazed for other types.
>> > > >
>> > > > s/speaciliazed/speciliazed/
>> > > >
>> > >
>> > > Will fix.
>> > >
>> > >
>> > > > >
>> > > > > [ATTR_GOO] = { .type = MYTYPE,
>> > > > > .validation_data = &myvalidation_data,
>> > > > > .validate_content = mycontent_validator },
>> > > >
>> > > > Indent is wrong. (Does not matter really in desc, but anyway)
>> > > >
>> > >
>> > > I cant find out how it got indented that way; my source
>> > > or email dont show it as such (but really doesnt matter).
>> > >
>> > >
>> > > > Suggested-by: Jiri Pirko <jiri@mellanox.com>
>> > > >
>> > >
>> > > Will add.
>> > >
>> > > >
>> > > > > ---
>> > > > > include/net/netlink.h | 11 +++++++++++
>> > > > > include/uapi/linux/rtnetlink.h | 17 +++++++++++++++++
>> > > > > lib/nlattr.c | 25 +++++++++++++++++++++++++
>> > > > > 3 files changed, 53 insertions(+)
>> > > > >
>> > > > > diff --git a/include/net/netlink.h b/include/net/netlink.h
>> > > > > index 0170917..8ab9784 100644
>> > > > > --- a/include/net/netlink.h
>> > > > > +++ b/include/net/netlink.h
>> > > > > @@ -6,6 +6,11 @@
>> > > > > #include <linux/jiffies.h>
>> > > > > #include <linux/in6.h>
>> > > > >
>> > > > > +struct nla_bit_flags {
>> > > > > + u32 nla_flag_values;
>> > > > > + u32 nla_flag_selector;
>> > > > > +};
>> > > >
>> > > > I don't understand why you redefine the struct here. You already have it
>> > > > defined in the uapi: struct __nla_bit_flags
>> > > >
>> > > > Just move this (struct nla_bit_flags) to the uapi and remove
>> > > > __nla_bit_flags ?
>> > > >
>> > >
>> > > I am not sure that will compile since the type is defined in netlink.h
>> > > Also, note: uapi uses _u32 and kernel uses u32 as types i.e it is pretty
>> > > common approach; i will try to move it to uapi and keep that uapi
>> > > format. If it doesnt compile without acrobatics I will keep it as is.
>> > >
>> >
>> > It doesnt compile - I could move it to linux/netlink.h but it seems
>> > so out of place.
>> > so i will keep things as is for now unless you can think of something
>> > else.
>>
>> First of all, makes no sense to put this struct "struct __nla_bit_flags"
>> into rtnetlink.h uapi file. This is generic netlink stuff, not specifict
>> to rtnetlink.
>>
>> I believe that this struct should go into:
>> include/uapi/linux/netlink.h
>>
>> struct nla_flag_bits {
>> __u32 nla_flag_bits_values;
>> __u32 nla_flag_bits_selector;
>> };
>>
>> Then you can use it from userspace and everywhere in kernel.
>>
>That file seems to be very out of place for this stuff.
Howcome? It is a common netlink api.
>
>> Btw, I find it very odd that enum containling NLA_* like NLA_U32 and
>> others is not part of uapi file and is rather defined in
>> include/net/netlink.h. Any idea why?
>>
>
>NLA_XXX are kernel side types. They are part of net/netlink.h which is
>not uapi accessible.
>David Ahern has submitted a patch to move all those defines to iproute2.
>Will make sense to move these to a uapi/linux/netlink-types.h but that
>is waay beyond the scope of this patch set.
Well, I don't think so :)
The thing is, struct nla_flag_bits is tightly coupled with NLA_FLAG_BITS
enum value. They should be in the same uapi file. That makes sense to me.
^ permalink raw reply
* Re: [PATCH net-next v10 3/4] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jiri Pirko @ 2017-06-12 11:47 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <fbf09ea1-36ee-69b1-74b0-ac436fff86ad@mojatatu.com>
Mon, Jun 12, 2017 at 01:16:05PM CEST, jhs@mojatatu.com wrote:
>On 17-06-11 10:13 AM, Jiri Pirko wrote:
>> Sun, Jun 11, 2017 at 01:53:45PM CEST, jhs@mojatatu.com wrote:
>[..]
>> > @@ -1168,14 +1185,24 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
>> > if (a_o == NULL)
>> > return 0;
>> >
>> > + if (tb[TCA_ROOT_FLAGS])
>> > + nla_memcpy(&select_flags, tb[TCA_ROOT_FLAGS],
>> > + sizeof(select_flags));
>>
>> Please introduce a helper for this attr type in patch 1:
>>
>> u32 select_flags;
>>
>> select_flags = nla_get_flag_bits_values(tb[TCA_ROOT_FLAGS])
>>
>
>This also is not useful.
>It happens to be ok for this use case but not for the
>general case. i.e.
>We need to get the whole struct not just the values
>and use the selector to pick what bits are affected.
>Example if bit X is set to 1 in selector and bit X in value
>is 0, then we set the kernel's bit X to 0.
Sure, have another helper for selector then.
Or, you can have:
struct nla_flag_bits *fb;
fb = nla_get_flag_bits(tb[TCA_ROOT_FLAGS]);
Or all 3 helpers. My point is, it is a specific netlink attribute with
specific format, it should have get/put helpers.
^ permalink raw reply
* Re: [PATCH v3 7/9] net: mvmdio: add xmdio xsmi support
From: Antoine Tenart @ 2017-06-12 11:54 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, jason, andrew, gregory.clement,
sebastian.hesselbarth, f.fainelli, thomas.petazzoni, nadavh, mw,
netdev, linux-arm-kernel
In-Reply-To: <20170612101739.GA4902@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]
Hi Russell,
On Mon, Jun 12, 2017 at 11:17:39AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 12, 2017 at 11:57:43AM +0200, Antoine Tenart wrote:
> > +static const struct orion_mdio_ops *orion_mdio_get_ops(struct orion_mdio_dev *dev,
> > + int regnum)
> > +{
> > + if (dev->bus_type == BUS_TYPE_XSMI && (regnum & MII_ADDR_C45))
> > + return &orion_mdio_xsmi_ops;
> > + else if (dev->bus_type == BUS_TYPE_SMI)
> > + return &orion_mdio_smi_ops;
> > +
> > + return ERR_PTR(-EOPNOTSUPP);
> > +}
>
> Oh, this is where you're doing it - I'm not sure having this complexity
> is really necessary - there is no dynamic choice between the two. This
> seems to be way over-engineered.
You're right, there is no dynamic choice between the two. The advantage
is the logic of the read/write operations are not duplicated.
> You might as well make the SMI operations fail if MII_ADDR_C45 is set,
> and the XSMI operations fail if MII_ADDR_C45 is not set.
This check is already done for xSMI operations. But this should also be
the case for SMI ones, you're right.
> 1. the mdio read/write functions implement their own locking.
>
> At the MDIO level, there is already locking in the form of a per-bus
> lock "bus->mdio_lock" which will be taken whenever either of these
> functions is called. So the driver's "dev->lock" is redundant.
OK, that's a good rework to add in the series.
> 2. with the redundant locking removed, orion_mdio_write() becomes a
> call to orion_mdio_wait_ready() followed by a call to dev->ops->write.
> It seems that orion_mdio_wait_ready() could be a library function
> shared between a SMI version of orion_mdio_write() and a XSMI version.
>
> 3. the same is really true of orion_mdio_read(), although that function
> is a little more complex in itself, the result would actually end up
> being simpler.
I'm not completely convinced as the read and write functions end up
being duplicated. One for SMI operations and one for xSMI. But I don't
really care, if you think this is better let's go for it.
Should I add your first patch in my series and squash the second one in
patch 7/9? (I'll also remove the bus_type member from the private
struct, as well as the one line it's used in the probe).
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] r8152: give the device version
From: Oliver Neukum @ 2017-06-12 11:56 UTC (permalink / raw)
To: davem, netdev, hayeswang; +Cc: Oliver Neukum
Getting the device version out of the driver really aids debugging.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/net/usb/r8152.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ddc62cb69be8..1a419a45e2a2 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4368,6 +4368,8 @@ static u8 rtl_get_version(struct usb_interface *intf)
break;
}
+ dev_dbg(&intf->dev, "Detected version 0x%04x\n", version);
+
return version;
}
--
2.12.3
^ permalink raw reply related
* Re: [PATCHv3 net] xfrm: move xfrm_garbage_collect out of xfrm_policy_flush
From: Steffen Klassert @ 2017-06-12 12:13 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, David Miller, Xin Long
In-Reply-To: <1497145460-24614-1-git-send-email-liuhangbin@gmail.com>
On Sun, Jun 11, 2017 at 09:44:20AM +0800, Hangbin Liu wrote:
> Now we will force to do garbage collection if any policy removed in
> xfrm_policy_flush(). But during xfrm_net_exit(). We call flow_cache_fini()
> first and set set fc->percpu to NULL. Then after we call xfrm_policy_fini()
> -> frxm_policy_flush() -> flow_cache_flush(), we will get NULL pointer
> dereference when check percpu_empty. The code path looks like:
>
> flow_cache_fini()
> - fc->percpu = NULL
> xfrm_policy_fini()
> - xfrm_policy_flush()
> - xfrm_garbage_collect()
> - flow_cache_flush()
> - flow_cache_percpu_empty()
> - fcp = per_cpu_ptr(fc->percpu, cpu)
>
> To reproduce, just add ipsec in netns and then remove the netns.
>
> v2:
> As Xin Long suggested, since only two other places need to call it. move
> xfrm_garbage_collect() outside xfrm_policy_flush().
>
> v3:
> Fix subject mismatch after v2 fix.
>
> Fixes: 35db06912189 ("xfrm: do the garbage collection after flushing policy")
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Patch applied, thanks eveyone!
^ permalink raw reply
* Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low
From: Baxter, Jim @ 2017-06-12 12:32 UTC (permalink / raw)
To: Oliver Neukum
Cc: David S. Miller, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <1497263047.15677.13.camel@suse.com>
From: Oliver Neukum (oneukum@suse.com) Sent: Mon, 12 Jun 2017 12:24:07 +0200
> Am Dienstag, den 23.05.2017, 20:06 +0100 schrieb Jim Baxter:
>> From: David S. Miller (davem@davemloft.net)
>> Sent: Tue, 23 May 2017 11:26:25 -0400
>>>
>>> From: Oliver Neukum <oneukum@suse.com>
>>> Date: Tue, 23 May 2017 10:42:48 +0200
>>>
>>>>
>>>>
>>>> We could use a counter. After the first failure, do it once, after the
>>>> second twice and so on. And reset the counter as a higher order
>>>> allocation works. (just bound it somewhere)
>>>
>>> So an exponential backoff, that might work.
>>>
>>
>> As an idea I have created this patch as an addition to the original patch
>> in this series.
>>
>> Would this be acceptable?
>>
>> At the moment I have capped the value at 10, does anyone think it needs to
>> be much higher then that?
>
> Hi,
>
> I am working through mail backlog. If I may ask, has this patch proposal
> had a result or does something need to be done still?
>
> Regards
> Oliver
>
Hi,
I have not received any response to my additional patch yet.
Do you think I should submit it as a second RFC patchset?
Regards,
Jim
^ permalink raw reply
* Re: [PATCH net-next 1/2] r8152: split rtl8152_resume function
From: Oliver Neukum @ 2017-06-12 12:33 UTC (permalink / raw)
To: Hayes Wang, netdev; +Cc: nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-273-Taiwan-albertk@realtek.com>
Am Montag, den 12.06.2017, 16:21 +0800 schrieb Hayes Wang:
> Split rtl8152_resume() into rtl8152_runtime_resume() and
> rtl8152_system_resume().
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/usb/r8152.c | 99 ++++++++++++++++++++++++++++++-------------------
> 1 file changed, 61 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 5a02053..3257955 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -3686,6 +3686,61 @@ static bool delay_autosuspend(struct r8152 *tp)
> return false;
> }
>
> +static int rtl8152_runtime_resume(struct r8152 *tp)
> +{
> + struct net_device *netdev = tp->netdev;
> +
> + if (netif_running(netdev) && netdev->flags & IFF_UP) {
> + struct napi_struct *napi = &tp->napi;
> +
> + tp->rtl_ops.autosuspend_en(tp, false);
> + napi_disable(napi);
> + set_bit(WORK_ENABLE, &tp->flags);
> +
> + if (netif_carrier_ok(netdev)) {
> + if (rtl8152_get_speed(tp) & LINK_STATUS) {
> + rtl_start_rx(tp);
> + } else {
> + netif_carrier_off(netdev);
> + tp->rtl_ops.disable(tp);
> + netif_info(tp, link, netdev, "linking down\n");
> + }
> + }
> +
> + napi_enable(napi);
> + clear_bit(SELECTIVE_SUSPEND, &tp->flags);
> + smp_mb__after_atomic();
> +
> + if (!list_empty(&tp->rx_done))
> + napi_schedule(&tp->napi);
> +
> + usb_submit_urb(tp->intr_urb, GFP_KERNEL);
If you ever built a device with included storage, this can deadlock,
as you may want to wake up a device for memory that is needed to wake
up a device. Use GFP_NOIO in resume() and reset_resume(), always.
Regards
Oliver
^ permalink raw reply
* [net-next] net: phy: marvell: Show complete link partner advertising
From: Thomas Bogendoerfer @ 2017-06-12 12:54 UTC (permalink / raw)
To: andrew, f.fainelli, netdev, linux-kernel
From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Give back all modes advertised by the link partner. This change brings
the marvell phy driver in line with all other phy drivers.
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
---
drivers/net/phy/marvell.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4c5246fed69b..8400403b3f62 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1139,7 +1139,6 @@ static int marvell_read_status_page_an(struct phy_device *phydev,
int status;
int lpa;
int lpagb;
- int adv;
status = phy_read(phydev, MII_M1011_PHY_STATUS);
if (status < 0)
@@ -1153,12 +1152,6 @@ static int marvell_read_status_page_an(struct phy_device *phydev,
if (lpagb < 0)
return lpagb;
- adv = phy_read(phydev, MII_ADVERTISE);
- if (adv < 0)
- return adv;
-
- lpa &= adv;
-
if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
phydev->duplex = DUPLEX_FULL;
else
--
1.8.5.6
^ permalink raw reply related
* Re: WARNING in dev_watchdog
From: Ben Hutchings @ 2017-06-12 13:17 UTC (permalink / raw)
To: Dison River, Greg KH; +Cc: netdev, linux-kernel, security
In-Reply-To: <CAJsXRPHmYk5FQBhwfP7d_Ah7cNHk=P_7-RLHzBTuLwrukqpBWQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
On Mon, 2017-06-12 at 16:13 +0800, Dison River wrote:
> Sorry,this WARNING is not reproducible.And I don't have PoC for this
> bug.
I found and reported a similar bug in e1000 and e1000e some years ago,
which was fixed in the latter here:
https://git.kernel.org/linus/d821a4c4d11ad160925dab2bb009b8444beff484
I think e1000 may still be unfixed, so this might be the same bug.
Ben.
--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Build issues for samples/bpf/ after rebase or git pull (solved)
From: Jesper Dangaard Brouer @ 2017-06-12 13:17 UTC (permalink / raw)
To: xdp-newbies@vger.kernel.org; +Cc: brouer, netdev@vger.kernel.org
Hi XDP newbies (and Google-search),
Just gotten bitten by this common build error issue. I git rebased my work
on a newer kernel, and is now getting build errors for make samples/bpf/.
Which fails with compile errors (see below), for tools/lib/bpf/bpf.c.
The solution is to (re)run: make headers_install
As described in[1]: samples/bpf/README.rst, we need to run make headers_install.
This will creates a local "usr/include" directory in the git/build top
level directory, that the make system automatically pickup first. And
when rebasing or pulling latest git changes, we have to remember to
rerun this, if bpf header files changed.
[1] https://github.com/torvalds/linux/blob/master/samples/bpf/README.rst
p.s. Hope this will help other hitting this issue, seeding the bpf / XDP info pool ;-)
- -
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
$ make
make -C ../../ /home/jbrouer/git/kernel/net-next/samples/bpf/
make[1]: Entering directory '/home/jbrouer/git/kernel/net-next'
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK scripts/mod/devicetable-offsets.h
LD /home/jbrouer/git/kernel/net-next/samples/bpf/built-in.o
HOSTCC /home/jbrouer/git/kernel/net-next/samples/bpf/test_lru_dist.o
HOSTCC /home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.o
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_verify_program’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:137:6: error: ‘union bpf_attr’ has no member named ‘prog_flags’; did you mean ‘map_flags’?
attr.prog_flags = strict_alignment ? BPF_F_STRICT_ALIGNMENT : 0;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:137:39: error: ‘BPF_F_STRICT_ALIGNMENT’ undeclared (first use in this function)
attr.prog_flags = strict_alignment ? BPF_F_STRICT_ALIGNMENT : 0;
^~~~~~~~~~~~~~~~~~~~~~
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:137:39: note: each undeclared identifier is reported only once for each function it appears in
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_prog_get_next_id’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:267:6: error: ‘union bpf_attr’ has no member named ‘start_id’; did you mean ‘target_fd’?
attr.start_id = start_id;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:269:16: error: ‘BPF_PROG_GET_NEXT_ID’ undeclared (first use in this function)
err = sys_bpf(BPF_PROG_GET_NEXT_ID, &attr, sizeof(attr));
^~~~~~~~~~~~~~~~~~~~
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:271:18: error: ‘union bpf_attr’ has no member named ‘next_id’; did you mean ‘next_key’?
*next_id = attr.next_id;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_map_get_next_id’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:282:6: error: ‘union bpf_attr’ has no member named ‘start_id’; did you mean ‘target_fd’?
attr.start_id = start_id;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:284:16: error: ‘BPF_MAP_GET_NEXT_ID’ undeclared (first use in this function)
err = sys_bpf(BPF_MAP_GET_NEXT_ID, &attr, sizeof(attr));
^~~~~~~~~~~~~~~~~~~
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:286:18: error: ‘union bpf_attr’ has no member named ‘next_id’; did you mean ‘next_key’?
*next_id = attr.next_id;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_prog_get_fd_by_id’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:296:6: error: ‘union bpf_attr’ has no member named ‘prog_id’; did you mean ‘prog_type’?
attr.prog_id = id;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:298:17: error: ‘BPF_PROG_GET_FD_BY_ID’ undeclared (first use in this function)
return sys_bpf(BPF_PROG_GET_FD_BY_ID, &attr, sizeof(attr));
^~~~~~~~~~~~~~~~~~~~~
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_map_get_fd_by_id’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:306:6: error: ‘union bpf_attr’ has no member named ‘map_i ’; did you mean ‘map_fd’?
attr.map_id = id;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:308:17: error: ‘BPF_MAP_GET_FD_BY_ID’ undeclared (first use in this function)
return sys_bpf(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr));
^~~~~~~~~~~~~~~~~~~~
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_obj_get_info_by_fd’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:318:6: error: ‘union bpf_attr’ has no member named ‘info’
attr.info.bpf_fd = prog_fd;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:319:6: error: ‘union bpf_attr’ has no member named ‘info’
attr.info.info_len = *info_len;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:320:6: error: ‘union bpf_attr’ has no member named ‘info’
attr.info.info = ptr_to_u64(info);
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:322:16: error: ‘BPF_OBJ_GET_INFO_BY_FD’ undeclared (first use in this function)
err = sys_bpf(BPF_OBJ_GET_INFO_BY_FD, &attr, sizeof(attr));
^~~~~~~~~~~~~~~~~~~~~~
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:324:19: error: ‘union bpf_attr’ has no member named ‘info’
*info_len = attr.info.info_len;
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_prog_get_fd_by_id’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:299:1: warning: control reaches end of non-void function -Wreturn-type]
}
^
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c: In function ‘bpf_map_get_fd_by_id’:
/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.c:309:1: warning: control reaches end of non-void function -Wreturn-type]
}
^
scripts/Makefile.host:124: recipe for target '/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.o' failed
make[2]: *** [/home/jbrouer/git/kernel/net-next/samples/bpf/../../tools/lib/bpf/bpf.o] Error 1
Makefile:1683: recipe for target '/home/jbrouer/git/kernel/net-next/samples/bpf/' failed
make[1]: *** [/home/jbrouer/git/kernel/net-next/samples/bpf/] Error 2
make[1]: Leaving directory '/home/jbrouer/git/kernel/net-next'
Makefile:157: recipe for target 'all' failed
make: *** [all] Error 2
^ permalink raw reply
* Toggling link state breaks network connectivity
From: Mason @ 2017-06-12 13:22 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, Mans Rullgard, Thibaud Cornic
Hello,
I am using the following drivers for Ethernet connectivity.
drivers/net/ethernet/aurora/nb8800.c
drivers/net/phy/at803x.c
Pulling the cable and plugging it back works as expected.
(I can ping both before and after.)
However, if I toggle the link state in software (using ip link set),
the board loses network connectivity.
# Statically assign IP address
ip addr add 172.27.64.77/18 brd 172.27.127.255 dev eth0
# Set link state to "up"
ip link set eth0 up
# ping -c 3 172.27.64.1 > /tmp/v1
PING 172.27.64.1 (172.27.64.1): 56 data bytes
64 bytes from 172.27.64.1: seq=0 ttl=64 time=18.321 ms
--- 172.27.64.1 ping statistics ---
3 packets transmitted, 1 packets received, 66% packet loss
round-trip min/avg/max = 18.321/18.321/18.321 ms
172.27.64.1 is a desktop system.
Running
% tcpdump -n -i eth1-boards ether host 00:16:e8:4d:7f:c4
on the desktop, I get:
15:01:45.187346 ARP, Request who-has 172.27.64.1 tell 172.27.64.77, length 46
15:01:45.187359 ARP, Reply 172.27.64.1 is-at 00:15:17:24:e0:81, length 28
15:01:45.194633 IP 172.27.64.77 > 172.27.64.1: ICMP echo request, id 41219, seq 0, length 64
15:01:45.194662 IP 172.27.64.1 > 172.27.64.77: ICMP echo reply, id 41219, seq 0, length 64
15:01:50.198564 ARP, Request who-has 172.27.64.77 tell 172.27.64.1, length 28
15:01:50.205929 IP 172.27.64.77 > 172.27.64.1: ICMP echo request, id 41219, seq 1, length 64
15:01:50.205951 IP 172.27.64.1 > 172.27.64.77: ICMP echo reply, id 41219, seq 1, length 64
15:01:50.213217 IP 172.27.64.77 > 172.27.64.1: ICMP echo request, id 41219, seq 2, length 64
15:01:50.213232 IP 172.27.64.1 > 172.27.64.77: ICMP echo reply, id 41219, seq 2, length 64
15:01:51.198563 ARP, Request who-has 172.27.64.77 tell 172.27.64.1, length 28
15:01:51.209586 ARP, Reply 172.27.64.77 is-at 00:16:e8:4d:7f:c4, length 46
15:01:51.209598 ARP, Reply 172.27.64.77 is-at 00:16:e8:4d:7f:c4, length 46
Packet #1: the board asks for the desktop's MAC address
Packet #2: the desktop replies instantly
Packet #3: the board sends the first ping
Packet #4: the desktop replies instantly
Then the board goes quiet for a long time (why???)
Packet #5: the desktop asks for the board's MAC address (doesn't it have it already?)
Packet #6: this seems to unwedge the board, which sends the second ping
Packet #7: the desktop replies instantly
Packet #8: the board sends the third ping
Packet #9: the desktop replies instantly
Packet #10: the desktop asks again for the board's MAC address
Packet #11 and #12: the board answers twice (for the old and new requests?)
Some oddities, but it seems to work.
Now toggle the link state:
% ip link set eth0 down
% ip link set eth0 up
% ping -c 3 172.27.64.1 > /tmp/v2
PING 172.27.64.1 (172.27.64.1): 56 data bytes
--- 172.27.64.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
On the desktop, I see
15:14:03.900162 ARP, Request who-has 172.27.64.1 tell 172.27.64.77, length 46
15:14:03.900175 ARP, Reply 172.27.64.1 is-at 00:15:17:24:e0:81, length 28
15:14:05.017189 ARP, Request who-has 172.27.64.1 tell 172.27.64.77, length 46
15:14:05.017200 ARP, Reply 172.27.64.1 is-at 00:15:17:24:e0:81, length 28
15:14:06.030531 ARP, Request who-has 172.27.64.1 tell 172.27.64.77, length 46
15:14:06.030541 ARP, Reply 172.27.64.1 is-at 00:15:17:24:e0:81, length 28
So basically, the board is asking the desktop for its MAC address,
and the desktop is answering immediately. But the board doesn't seem
to be getting the replies... Any ideas, or words of wisdom, as they say?
Regards.
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-06-12
From: Kalle Valo @ 2017-06-12 13:31 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next, more info in the tag below. But do
note that Stephen reported qtnfmac will fail to build with the net tree
due to the changes in netdev destructor:
https://lkml.kernel.org/r/20170608122759.7ffda0c3@canb.auug.org.au
So once you pull these changes AND your net tree to net-next you need to
apply Stephen's patch above. As of this writing there is no build
breakage (yet).
Please let me know if there are any problems.
Kalle
The following changes since commit a95cfad947d5f40cfbf9ad3019575aac1d8ac7a6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-05-15 15:50:49 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-06-12
for you to fetch changes up to 219569ad0c41df7a7f999a2cad688c6b6ce173e2:
rsi: use subdirectory for firmware file (2017-06-01 12:51:19 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.13
The first pull request for 4.13. We have a new driver qtnfmac, but
also rsi driver got a support for new firmware and supporting ath10k
SDIO devices was started.
Major changes:
ath10k
* add initial SDIO support (still work in progress)
rsi
* new loading for the new firmware version
rtlwifi
* final patches for the new btcoex support
rt2x00
* add device ID for Epson WN7512BEP
qtnfmac
* new driver for Quantenna QSR10G chipsets
----------------------------------------------------------------
Ammly Fredrick (1):
ath9k: fix spelling in ath9k_tx99_init()
Arend Van Spriel (2):
brcmfmac: move scheduled scan wiphy param setting to pno module
ath6kl: assure headroom of skbuff is writable in .start_xmit()
Arend van Spriel (1):
brcmfmac: add firmware feature detection for gscan feature
Arnd Bergmann (11):
wlcore: fix 64K page support
rt2x00: change function pointers for register accessors
rt2x00: convert rt2800_rfcsr_read return type
rt2x00: convert rt2x00_rf_read return type
rt2x00: convert rt2x00mmio_register_read return type
rt2x00: convert rt2x00usb_register_read return type
rt2x00: convert rt2800_register_read return type
rt2x00: convert rt2*_bbp_read return type
rt2x00: convert rt2x00_eeprom_read return type
rt2x00: convert rt2800_eeprom_read return type
rt2x00: convert rt2x00_desc_read return type
Brian Norris (11):
mwifiex: initiate card-specific work atomically
mwifiex: pcie: add card_reset() support
mwifiex: pcie: de-duplicate buffer allocation code
mwifiex: fixup error cases in mwifiex_add_virtual_intf()
mwifiex: don't drop lock between list-retrieval / list-deletion
mwifiex: don't leak stashed beacon buffer on reset
mwifiex: remove useless 'mwifiex_lock'
mwifiex: remove redundant 'adapter' check in mwifiex_adapter_cleanup
mwifiex: 11h: drop unnecessary check for '!priv'
mwifiex: pcie: remove useless pdev check
mwifiex: pcie: stop setting/clearing 'surprise_removed'
Chi-hsien Lin (1):
brcmfmac: remove setting IBSS mode when stopping AP
Colin Ian King (4):
rtlwifi: fix spelling mistake: "Pairwiase" -> "Pairwise"
rtlwifi: rtl8723ae: fix spelling mistake: "Coexistance" -> "Coexistence"
ath5k: fix memory leak on buf on failed eeprom read
qtnfmac: remove duplicated assignment to mac
Dan Carpenter (2):
p54: allocate enough space for ->used_rxkeys
rtlwifi: btcoex: 23b 1ant: initialize bt_disabled to false
Douglas Anderson (3):
mwifiex: Don't release tx_ba_stream_tbl_lock while iterating
mwifiex: Don't release cmd_pending_q_lock while iterating
mwifiex: Add locking to mwifiex_11n_delba
Elena Reshetova (2):
hostap: convert hostap_cmd_queue.usecnt from atomic_t to refcount_t
orinoco_usb: convert request_context.refcount from atomic_t to refcount_t
Erik Stromdahl (10):
ath10k: htc: made static function public
ath10k: htc: rx trailer lookahead support
ath10k: htc: move htc ctrl ep connect to htc_init
ath10k: htc: refactorization
ath10k: various sdio related definitions
ath10k: add sdio extra initializations
ath10k: sdio get target info
ath10k: htc: ready_ext msg support
ath10k: different fw file name for sdio
ath10k: add initial SDIO support
Geliang Tang (2):
wlcore: use memdup_user
wil6210: use memdup_user
Gustavo A. R. Silva (1):
ath9k: remove unnecessary code
Igor Mitsyanko (1):
qtnfmac: introduce new FullMAC driver for Quantenna chipsets
Johan Hovold (1):
mwifiex: add missing USB-descriptor endianness conversion
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karim Eshapa (1):
rsi: rsi_91x_core: Use time_after time comparison
Kees Cook (3):
ray_cs: Avoid reading past end of buffer
libertas: Avoid reading past end of buffer
libertas: Remove function entry/exit debugging
Larry Finger (5):
rtlwifi: btcoex: Remove 21a 1ant configuration parameter
rtlwifi: btcoex: Remove 23b 1ant configuration parameter
rtlwifi: btcoex: Remove 23b 2ant configuration parameter
rtlwifi: btcoex: Remove 92e 2ant configuration parameter
rtlwifi: btcoex: Restore 23b 1ant routine for tdma adjustment
Markus Elfring (1):
ssb: Delete an error message for a failed memory allocation in ssb_devices_register()
Michael Mera (1):
ath10k: fix out of bounds access to local buffer
Ping-Ke Shih (25):
rtlwifi: btcoex: 23b 1ant: rename and coding style modification.
rtlwifi: btcoex: 23b 1ant: TDMA duration for ACL busy
rtlwifi: btcoex: 23b 1ant: monitor wifi and BT counter
rtlwifi: btcoex: 23b 1ant: check if BT high priority packet exist
rtlwifi: btcoex: 23b 1ant: monitor bt is enabled or disabled
rtlwifi: btcoex: 23b 1ant: check PS state before setting tdma duration
rtlwifi: btcoex: 23b 1ant: Switch antenna to wifi or BT.
rtlwifi: btcoex: 23b 1ant: need these information when scan
rtlwifi: btcoex: 23b 1ant: adjust wifi duration for bt a2dp
rtlwifi: btcoex: 23b 1ant: add wifi_only argument to init_hwconfig
rtlwifi: btcoex: 23b 1ant: Add power_on_setting
rtlwifi: btcoex: 23b 1ant: parse more BT information from C2H
rtlwifi: btcoex: 23b 1ant: Setup register for BT WHCK test
rtlwifi: btcoex: 23b 1ant: Add rf status notification
rtlwifi: btcoex: 23b 1ant: fine tune connect notify
rtlwifi: btcoex: 23b 1ant: Revise media status notify to fix no scan result issue
rtlwifi: btcoex: 23b 1ant: Special packets statistic in notification
rtlwifi: btcoex: 23b 1ant: define wifi in high priority task.
rtlwifi: btcoex: 23b 1ant: check more cases when bt is queing
rtlwifi: btcoex: 23b 1ant: remove verbose log from periodic function
rtlwifi: btcoex: 23b 1ant: Add coex_table_type to log
rtlwifi: btcoex: 23b 1ant: coex table fine tune
rtlwifi: btcoex: 23b 1ant: fine tune for wifi connected
rtlwifi: btcoex: 23b 1ant: fine tune for wifi not connected
rtlwifi: btcoex: 23b 1ant: fine tune for bt_sco_hid busy
Prameela Rani Garnepudi (10):
rsi: Rename file rsi_91x_pkt.c to rsi_91x_hal.c
rsi: Changes to sdio reads and writes
rsi: Changes in USB read and write operations
rsi: use macros in USB specific code
rsi: Handle usb multi-byte write failure case properly
rsi: Add usb multi-byte read operation
rsi: Add host interface operations as separate structure.
rsi: Add new host interface operations
rsi: Add new firmware loading method
rsi: Remove old firmware loading method
Ryan Hsu (1):
ath10k: append the wmi_op_version to testmode get_version cmd
Shawn Lin (1):
mwifiex: simplify the code around ra_list
Stanislaw Gruszka (2):
ath9k: check ah->curchan when updating tx power
iwlegacy: warn when enabling power save
Takashi Iwai (1):
b43: Add missing MODULE_FIRMWARE()
Tom Gaudasinski (1):
rt2x00: Add device ID for Epson WN7512BEP
Xie Qirong (1):
brcmfmac: btcoex: replace init_timer with setup_timer
Xinming Hu (7):
mwifiex: p2p client using same data path as station
mwifiex: use variable interface header length
mwifiex: usb: kill urb before free its memory
mwifiex: usb: transmit aggregation packets
mwifiex: usb: add timer to flush aggregation packets
mwifiex: check next packet length for usb tx aggregation
mwifiex: uap: process remain on channel expired event
Yan-Hsuan Chuang (24):
rtlwifi: btcoex: 21a 2ant: set tdma with rssi states
rtlwifi: btcoex: 21a 2ant: refine btc8821a2ant_action_hid_a2dp
rtlwifi: btcoex: 21a 2ant: set wifi standby when halting of entering ips
rtlwifi: btcoex: 21a 2ant: settings before wifi firmware is ready
rtlwifi: btcoex: 21a 2ant: add pnp notidy to avoid LPS/IPS mismatch
rtlwifi: btcoex: 21a 2ant: run mechanism if status changes or auto adjust is set
rtlwifi: btcoex: 21a 2ant: init wlan when leave ips
rtlwifi: btcoex: 21a 2ant: refine bt info notify to have more profilings
rtlwifi: btcoex: 21a 2ant: fix PTA unstable problem when hw init
rtlwifi: btcoex: 21a 2ant: remove unused antenna detection variables
rtlwifi: btcoex: 21a 1ant: set tdma and coex table when wifi is idle
rtlwifi: btcoex: 21a 1ant: more bt profiling when wifi receives special packet
rtlwifi: btcoex: 21a 1ant: shorten wifi slot when connected scan
rtlwifi: btcoex: 21a 1ant: react to special packet when wifi is not scanning
rtlwifi: btcoex: 21a 1ant: coex table and tdma settings for softap mode
rtlwifi: btcoex: 21a 1ant: wifi slot time adjustment
rtlwifi: btcoex: 21a 1ant: normal mode for retry limit when connected
rtlwifi: btcoex: 21a 1ant: mark packet high priority when scanning
rtlwifi: btcoex: 21a 1ant: use default value when initiating coex
rtlwifi: btcoex: 21a 1ant: re-init coex after wifi leaves IPS
rtlwifi: btcoex: 21a 1ant: treat ARP as special packet
rtlwifi: btcoex: 21a 1ant: fix some coding style issues
rtlwifi: btcoex: 21a 1ant: add bt_tx_rx_mask into bt info
rtlwifi: btcoex: 23b 1ant: turn off ps and tdma mechanism when concurrent mode
amit karwar (2):
rsi: define RSI_USB_BUF_SIZE macro
rsi: use subdirectory for firmware file
MAINTAINERS | 8 +
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/Makefile | 1 +
drivers/net/wireless/ath/ath10k/Kconfig | 7 +
drivers/net/wireless/ath/ath10k/Makefile | 3 +
drivers/net/wireless/ath/ath10k/bmi.c | 71 +
drivers/net/wireless/ath/ath10k/bmi.h | 2 +
drivers/net/wireless/ath/ath10k/core.c | 36 +-
drivers/net/wireless/ath/ath10k/core.h | 3 +
drivers/net/wireless/ath/ath10k/debug.c | 16 +-
drivers/net/wireless/ath/ath10k/debug.h | 2 +
drivers/net/wireless/ath/ath10k/htc.c | 244 ++-
drivers/net/wireless/ath/ath10k/htc.h | 39 +-
drivers/net/wireless/ath/ath10k/hw.h | 53 +
drivers/net/wireless/ath/ath10k/sdio.c | 2113 ++++++++++++++++++++
drivers/net/wireless/ath/ath10k/sdio.h | 229 +++
drivers/net/wireless/ath/ath10k/targaddrs.h | 24 +
drivers/net/wireless/ath/ath10k/testmode.c | 7 +
drivers/net/wireless/ath/ath10k/testmode_i.h | 1 +
drivers/net/wireless/ath/ath5k/debug.c | 5 +-
drivers/net/wireless/ath/ath6kl/txrx.c | 13 +-
drivers/net/wireless/ath/ath9k/common.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/tx99.c | 2 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 12 +-
drivers/net/wireless/broadcom/b43/main.c | 10 +
.../wireless/broadcom/brcm80211/brcmfmac/btcoex.c | 4 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 21 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 22 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 4 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 59 +
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 10 +
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 8 +
drivers/net/wireless/intel/iwlegacy/common.c | 2 +
drivers/net/wireless/intel/iwlegacy/common.h | 1 +
drivers/net/wireless/intersil/hostap/hostap_hw.c | 12 +-
drivers/net/wireless/intersil/hostap/hostap_wlan.h | 3 +-
.../net/wireless/intersil/orinoco/orinoco_usb.c | 15 +-
drivers/net/wireless/intersil/p54/fwio.c | 5 +-
drivers/net/wireless/marvell/libertas/cfg.c | 104 +-
drivers/net/wireless/marvell/libertas/cmd.c | 116 +-
drivers/net/wireless/marvell/libertas/cmdresp.c | 9 -
drivers/net/wireless/marvell/libertas/defs.h | 9 -
drivers/net/wireless/marvell/libertas/ethtool.c | 3 -
drivers/net/wireless/marvell/libertas/if_cs.c | 36 -
drivers/net/wireless/marvell/libertas/if_sdio.c | 66 +-
drivers/net/wireless/marvell/libertas/if_spi.c | 38 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 27 +-
drivers/net/wireless/marvell/libertas/main.c | 81 +-
drivers/net/wireless/marvell/libertas/mesh.c | 54 +-
drivers/net/wireless/marvell/libertas/rx.c | 6 -
drivers/net/wireless/marvell/libertas/tx.c | 3 -
drivers/net/wireless/marvell/mwifiex/11h.c | 6 -
drivers/net/wireless/marvell/mwifiex/11n.c | 17 +-
drivers/net/wireless/marvell/mwifiex/11n_aggr.c | 14 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 71 +-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 15 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 10 +
drivers/net/wireless/marvell/mwifiex/init.c | 17 +-
drivers/net/wireless/marvell/mwifiex/main.c | 4 +
drivers/net/wireless/marvell/mwifiex/main.h | 21 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 207 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 28 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 18 +
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 24 +
drivers/net/wireless/marvell/mwifiex/sta_tx.c | 12 +-
drivers/net/wireless/marvell/mwifiex/tdls.c | 7 +-
drivers/net/wireless/marvell/mwifiex/txrx.c | 15 +-
drivers/net/wireless/marvell/mwifiex/uap_event.c | 11 +
drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 5 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 585 ++++--
drivers/net/wireless/marvell/mwifiex/usb.h | 23 +
drivers/net/wireless/marvell/mwifiex/wmm.c | 16 +-
drivers/net/wireless/quantenna/Kconfig | 16 +
drivers/net/wireless/quantenna/Makefile | 6 +
drivers/net/wireless/quantenna/qtnfmac/Kconfig | 19 +
drivers/net/wireless/quantenna/qtnfmac/Makefile | 31 +
drivers/net/wireless/quantenna/qtnfmac/bus.h | 139 ++
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 995 +++++++++
drivers/net/wireless/quantenna/qtnfmac/cfg80211.h | 43 +
drivers/net/wireless/quantenna/qtnfmac/commands.c | 1982 ++++++++++++++++++
drivers/net/wireless/quantenna/qtnfmac/commands.h | 74 +
drivers/net/wireless/quantenna/qtnfmac/core.c | 618 ++++++
drivers/net/wireless/quantenna/qtnfmac/core.h | 173 ++
drivers/net/wireless/quantenna/qtnfmac/debug.c | 46 +
drivers/net/wireless/quantenna/qtnfmac/debug.h | 50 +
drivers/net/wireless/quantenna/qtnfmac/event.c | 452 +++++
drivers/net/wireless/quantenna/qtnfmac/event.h | 27 +
.../net/wireless/quantenna/qtnfmac/pearl/pcie.c | 1378 +++++++++++++
.../quantenna/qtnfmac/pearl/pcie_bus_priv.h | 89 +
.../wireless/quantenna/qtnfmac/pearl/pcie_ipc.h | 158 ++
.../quantenna/qtnfmac/pearl/pcie_regs_pearl.h | 353 ++++
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 901 +++++++++
.../net/wireless/quantenna/qtnfmac/qlink_util.c | 71 +
.../net/wireless/quantenna/qtnfmac/qlink_util.h | 80 +
.../net/wireless/quantenna/qtnfmac/qtn_hw_ids.h | 32 +
drivers/net/wireless/quantenna/qtnfmac/shm_ipc.c | 176 ++
drivers/net/wireless/quantenna/qtnfmac/shm_ipc.h | 80 +
.../net/wireless/quantenna/qtnfmac/shm_ipc_defs.h | 46 +
drivers/net/wireless/quantenna/qtnfmac/trans.c | 224 +++
drivers/net/wireless/quantenna/qtnfmac/trans.h | 57 +
drivers/net/wireless/quantenna/qtnfmac/util.c | 114 ++
drivers/net/wireless/quantenna/qtnfmac/util.h | 45 +
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 181 +-
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 195 +-
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 173 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 911 ++++-----
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 22 +-
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 44 +-
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 6 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 20 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 12 +-
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00debug.h | 4 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h | 7 +-
drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 12 +-
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00usb.h | 16 +-
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 285 +--
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 189 +-
drivers/net/wireless/ray_cs.c | 7 +-
.../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c | 68 +-
.../realtek/rtlwifi/btcoexist/halbtc8192e2ant.h | 2 -
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 2043 ++++++++++++++-----
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.h | 47 +-
.../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 80 +-
.../realtek/rtlwifi/btcoexist/halbtc8723b2ant.h | 2 -
.../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c | 275 ++-
.../realtek/rtlwifi/btcoexist/halbtc8821a1ant.h | 4 +-
.../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 515 +++--
.../realtek/rtlwifi/btcoexist/halbtc8821a2ant.h | 10 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 28 +
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 2 +-
drivers/net/wireless/rsi/Makefile | 2 +-
drivers/net/wireless/rsi/rsi_91x_core.c | 2 +-
drivers/net/wireless/rsi/rsi_91x_hal.c | 740 +++++++
drivers/net/wireless/rsi/rsi_91x_pkt.c | 215 --
drivers/net/wireless/rsi/rsi_91x_sdio.c | 211 +-
drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 190 +-
drivers/net/wireless/rsi/rsi_91x_usb.c | 166 +-
drivers/net/wireless/rsi/rsi_91x_usb_ops.c | 125 --
drivers/net/wireless/rsi/rsi_common.h | 3 +-
drivers/net/wireless/rsi/rsi_hal.h | 81 +
drivers/net/wireless/rsi/rsi_main.h | 36 +-
drivers/net/wireless/rsi/rsi_sdio.h | 6 +-
drivers/net/wireless/rsi/rsi_usb.h | 5 +-
drivers/net/wireless/ti/wlcore/debugfs.c | 13 +-
drivers/net/wireless/ti/wlcore/spi.c | 6 +-
drivers/ssb/main.c | 1 -
153 files changed, 16692 insertions(+), 3509 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath10k/sdio.c
create mode 100644 drivers/net/wireless/ath/ath10k/sdio.h
create mode 100644 drivers/net/wireless/quantenna/Kconfig
create mode 100644 drivers/net/wireless/quantenna/Makefile
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/Kconfig
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/Makefile
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/bus.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/cfg80211.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/commands.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/commands.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/core.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/core.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/debug.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/debug.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/event.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/event.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_ipc.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_regs_pearl.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/qlink.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/qlink_util.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/qlink_util.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/qtn_hw_ids.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/shm_ipc.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/shm_ipc.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/shm_ipc_defs.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/trans.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/trans.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/util.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/util.h
create mode 100644 drivers/net/wireless/rsi/rsi_91x_hal.c
delete mode 100644 drivers/net/wireless/rsi/rsi_91x_pkt.c
create mode 100644 drivers/net/wireless/rsi/rsi_hal.h
^ permalink raw reply
* Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
From: Kalle Valo @ 2017-06-12 13:46 UTC (permalink / raw)
To: Arend van Spriel
Cc: Emil Lenngren, Emmanuel Grumbach, Kees Cook, Jason A. Donenfeld,
LKML, kernel-hardening@lists.openwall.com, Anna Schumaker,
David Howells, David Safford, David S. Miller, Gilad Ben-Yossef,
Greg Kroah-Hartman, Gustavo Padovan, J. Bruce Fields, Jeff Layton,
Johan Hedberg, Johannes Berg, Marcel Holtmann,
Mimi Zohar <zoha
In-Reply-To: <5595d4bc-a43e-7a89-eb86-fa77556cd7af@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> On 6/11/2017 11:30 PM, Emil Lenngren wrote:
>> 2017-06-11 22:48 GMT+02:00 Emmanuel Grumbach <egrumbach@gmail.com>:
>>> On Sun, Jun 11, 2017 at 4:36 PM, Kees Cook <keescook@chromium.org> wrote:
>>>>
>>>> On Sun, Jun 11, 2017 at 1:13 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>>> "Jason A. Donenfeld" <Jason@zx2c4.com> writes:
>>>>>
>>>>>> Whenever you're comparing two MACs, it's important to do this using
>>>>>> crypto_memneq instead of memcmp. With memcmp, you leak timing information,
>>>>>> which could then be used to iteratively forge a MAC.
>>>>>
>>>>> Do you have any pointers where I could learn more about this?
>>>>
>>>> While not using C specifically, this talks about the problem generally:
>>>> https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html
>>>>
>>>
>>> Sorry for the stupid question, but the MAC address is in plaintext in
>>> the air anyway or easily accessible via user space tools. I fail to
>>> see what it is so secret about a MAC address in that code where that
>>> same MAC address is accessible via myriads of ways.
>>
>> I think you're mixing up Media Access Control (MAC) addresses with
>> Message Authentication Code (MAC). The second one is a cryptographic
>> signature of a message.
>
> While this may be obvious to those who are in the know this mixup is
> easily made outside the crypto domain and especially in the (wireless)
> networking domain (my mind wandered towards the same error path).
I did realise that this was about Message Authentication Code (yay!) but
I got lost because I thought this is somehow related to timestamps :)
Thanks to Kees I now understand this is about revealing execution time
to the attacker, not timestamps or anything like that.
> As this series is touching stuff outside crypto it is good to be
> explicit and not use such abbreviations that can be misinterpreted.
> The article Kees referred to is also useful to get into the proper
> context here and at least worth mentioning this or other useful
> references in the cover letter.
And the kernel documentation we have is not really helping much:
/**
* crypto_memneq - Compare two areas of memory without leaking
* timing information.
*
* @a: One area of memory
* @b: Another area of memory
* @size: The size of the area.
*
* Returns 0 when data is equal, 1 otherwise.
*/
For most people "leaking timing information" does not tell much. Adding
a sentence or two _why_ this function should be used would be very
helpful.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v1] net/phy: Make phy_ethtool_ksettings_get return void
From: David Miller @ 2017-06-12 13:51 UTC (permalink / raw)
To: yuval.shaia
Cc: michael.chan, f.fainelli, siva.kallam, prashant, madalin.bucur,
leoli, sebastian.hesselbarth, sergei.shtylyov, grygorii.strashko,
w-kwok2, m-karicheri2, andrew, woojung.huh, UNGLinuxDriver,
vivien.didelot, arnd, tremyfr, jarod, horms+renesas,
kazuya.mizuguchi.ks, dan.carpenter, niklas.soderlund+renesas,
johan, masaru.nagai.vx, geert+renesas, laurent.pinchart,
chris.brandt, ivan.khoronzhuk, mugunthanvnm, netdev,
linux-arm-kernel
In-Reply-To: <20170612074233.8688-1-yuval.shaia@oracle.com>
From: Yuval Shaia <yuval.shaia@oracle.com>
Date: Mon, 12 Jun 2017 10:42:33 +0300
> Make return value void since function never return meaningfull value
>
> Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> Re-sending since last time forgot to add netdev-list
> v0 ->v1:
> * These files were missing in v0
> * drivers/net/ethernet/renesas/ravb_main.c
> * drivers/net/ethernet/renesas/sh_eth.c
> * drivers/net/ethernet/ti/netcp_ethss.c
> * Add Acked-by: Sergei Shtylyov
This doesn't apply cleanly to net-next at all.
Please respin against an uptodate net-next tree, thank you.
^ permalink raw reply
* Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS
From: Jamal Hadi Salim @ 2017-06-12 13:51 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <20170612114345.GB1993@nanopsycho>
On 17-06-12 07:43 AM, Jiri Pirko wrote:
> Mon, Jun 12, 2017 at 01:10:56PM CEST, jhs@mojatatu.com wrote:
>> On 17-06-12 06:34 AM, Jiri Pirko wrote:
>>> Sun, Jun 11, 2017 at 08:37:25PM CEST, jhs@mojatatu.com wrote:
>>>> On 17-06-11 01:38 PM, Jamal Hadi Salim wrote:
>>>>> On 17-06-11 09:49 AM, Jiri Pirko wrote:
>>>>>> Sun, Jun 11, 2017 at 01:53:43PM CEST, jhs@mojatatu.com wrote:
>>>>>>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>>>>
>>>>>
>>>>>>> This patch also provides an extra feature: a validation callback
>>>>>>> that could be speaciliazed for other types.
>>>>>>
>>>>>> s/speaciliazed/speciliazed/
>>>>>>
>>>>>
>>>>> Will fix.
>>>>>
>>>>>
>>>>>>>
>>>>>>> [ATTR_GOO] = { .type = MYTYPE,
>>>>>>> .validation_data = &myvalidation_data,
>>>>>>> .validate_content = mycontent_validator },
>>>>>>
>>>>>> Indent is wrong. (Does not matter really in desc, but anyway)
>>>>>>
>>>>>
>>>>> I cant find out how it got indented that way; my source
>>>>> or email dont show it as such (but really doesnt matter).
>>>>>
>>>>>
>>>>>> Suggested-by: Jiri Pirko <jiri@mellanox.com>
>>>>>>
>>>>>
>>>>> Will add.
>>>>>
>>>>>>
>>> I believe that this struct should go into:
>>> include/uapi/linux/netlink.h
>>>
>>> struct nla_flag_bits {
>>> __u32 nla_flag_bits_values;
>>> __u32 nla_flag_bits_selector;
>>> };
>>>
>>> Then you can use it from userspace and everywhere in kernel.
>>>
>> That file seems to be very out of place for this stuff.
>
> Howcome? It is a common netlink api.
>
Take a look at that file's content. It talks about what goes in
the netlink header. Adding types in it seems out of place.
>> NLA_XXX are kernel side types. They are part of net/netlink.h which is
>> not uapi accessible.
>> David Ahern has submitted a patch to move all those defines to iproute2.
>> Will make sense to move these to a uapi/linux/netlink-types.h but that
>> is waay beyond the scope of this patch set.
>
> Well, I don't think so :)
>
> The thing is, struct nla_flag_bits is tightly coupled with NLA_FLAG_BITS
> enum value. They should be in the same uapi file. That makes sense to me.
>
Sure - they should be in the same file. But is it uapi/linux/netlink.h?
cheers,
jamal
^ 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