* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"
From: Michael Ellerman @ 2017-12-19 12:28 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev@vger.kernel.org, Jouni Malinen, Rasmus Villemoes,
Johannes Berg, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20171202074155.29146-1-johannes@sipsolutions.net>
Hi Johannes,
> From: Johannes Berg <johannes.berg@intel.com>
>
> This reverts commit d6f295e9def0; some userspace (in the case
> we noticed it's wpa_supplicant), is relying on the current
> error code to determine that a fixed name interface already
> exists.
>
> Reported-by: Jouni Malinen <j@w1.fi>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> net/core/dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This revert seems to have broken networking on one of my powerpc
machines, according to git bisect.
The symptom is DHCP fails and I don't get a link, I didn't dig any
further than that. I can if it's helpful.
I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name
is now the same as dev_alloc_name_ns") only makes sense while
d6f295e9def0 remains in the tree.
ie. before the entire series, dev_get_valid_name() would return EEXIST,
and that was retained when 87c320e51519 was merged, but now that
d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE.
I can get the network up again if I also revert 87c320e51519 ("net:
core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with
the gross patch below.
cheers
diff --git a/net/core/dev.c b/net/core/dev.c
index f47e96b62308..d0304461ad32 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1146,7 +1146,11 @@ EXPORT_SYMBOL(dev_alloc_name);
int dev_get_valid_name(struct net *net, struct net_device *dev,
const char *name)
{
- return dev_alloc_name_ns(net, dev, name);
+ int rc = dev_alloc_name_ns(net, dev, name);
+ if (rc == -ENFILE)
+ rc = -EEXIST;
+
+ return rc;
}
EXPORT_SYMBOL(dev_get_valid_name);
^ permalink raw reply related
* Re: r8169 regression: UDP packets dropped intermittantly
From: Michal Kubecek @ 2017-12-19 12:25 UTC (permalink / raw)
To: Jonathan Woithe; +Cc: Holger Hoffstätte, netdev, linux-kernel
In-Reply-To: <20171219054532.GA13685@marvin.atrad.com.au>
On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote:
> This clearly indicates that not every card using the r8169 driver is
> vulnerable to the problem. It also explains why Holger was unable to
> reproduce the result on his system: the PCIe cards do not appear to suffer
> from the problem. Most likely the PCI RTL-8169 chip is affected, but newer
> PCIe variations do not. However, obviously more testing will be required
> with a wider variety of cards if this inference is to hold up.
The r8169 driver supports many slightly different variants of the chip.
To identify your variant more precisely, look for a line like
r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0xffffc90003135000, d4:3d:7e:2a:30:08, XID 0c900800 IRQ 38
in kernel log.
Michal Kubecek
^ permalink raw reply
* Re: xfrm: Reinject transport-mode packets through tasklet
From: Steffen Klassert @ 2017-12-19 12:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20171215054044.GA24688@gondor.apana.org.au>
On Fri, Dec 15, 2017 at 04:40:44PM +1100, Herbert Xu wrote:
> This is an old bugbear of mine:
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg03894.html
>
> By crafting special packets, it is possible to cause recursion
> in our kernel when processing transport-mode packets at levels
> that are only limited by packet size.
>
> The easiest one is with DNAT, but an even worse one is where
> UDP encapsulation is used in which case you just have to insert
> an UDP encapsulation header in between each level of recursion.
>
> This patch avoids this problem by reinjecting tranport-mode packets
> through a tasklet.
>
> Fixes: b05e106698d9 ("[IPV4/6]: Netfilter IPsec input hooks")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to the ipsec tree, thanks Herbert!
^ permalink raw reply
* Re: [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 12:17 UTC (permalink / raw)
To: Andy Shevchenko, linux-pci, timur
Cc: linux-arm-msm, linux-arm-kernel, David S. Miller, Kees Cook,
Eric Dumazet, Tobias Klauser, open list:NETWORKING DRIVERS,
open list
In-Reply-To: <1513680330.7000.167.camel@linux.intel.com>
On 12/19/2017 5:45 AM, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 00:37 -0500, Sinan Kaya wrote:
>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>> where a PCI device is present. This restricts the device drivers to be
>> reused for other domain numbers.
>>
>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>> pci_get_domain_bus_and_slot().
>>
>
> Where this idea come from?
There are systems out (mostly ARM) there with non-zero segment numbers. The
pci_get_bus_and_slot() API is restrictive and unnecessarily forces 0 segment
numbers for some generic device drivers. Obtaining the segment number is as
easy as calling pci_domain_nr().
The problems with pci_get_bus_and_slot() are:
1. we don't know if the device driver intentionally called pci_get_bus_and_slot()
to limit 0 segment number.
2. we don't know if the driver developer just copied an example from another
system and it just happened to work on x86 architecture while broken on other
architectures.
Some device drivers may want to limit the segment number. Than specifying 0
while calling pci_get_domain_bus_and_slot() is a better way to express this.
pci_get_bus_and_slot() is unnecessarily restricting some device drivers. Nvidia
as an example. I remember that somebody came up with a very ugly patch to force
segment 0 into Microsoft hypervisor layer.
This was rejected out right and told to fix the Nvidia driver instead. This patch
essentially fixes some of these flaws while removing the limiting API from the
kernel altogether so that same mistakes are not made.
>
> pci_get_bus_and_slot() still might be useful for the wired devices in
> SoC where we know for sure that domain == 0.
>
Then hard code the domain number as 0 while calling pci_get_domain_bus_and_slot()
if you know for sure that this device will never work on a non-zero domain.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH 1/1] net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support
From: Daniele Palmas @ 2017-12-19 12:01 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev
In-Reply-To: <CAGRyCJGywkma7dcS0CCmcyU+Q-MJ1DTUJVoRzr9TCKZXDp6B6w@mail.gmail.com>
2017-12-14 22:28 GMT+01:00 Daniele Palmas <dnlplm@gmail.com>:
> 2017-12-14 18:55 GMT+01:00 Bjørn Mork <bjorn@mork.no>:
>> Daniele Palmas <dnlplm@gmail.com> writes:
>>
>>> This patch adds support for Telit ME910 PID 0x1101.
>>>
>>> Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
>>
>> Acked-by: Bjørn Mork <bjorn@mork.no>
>>
>>> bInterfaceSubClass 254
>>
>> Just curious: Is there some meaning hidden here?
>>
>
> That was puzzling also for me, so I checked the original QC
> composition and had the same value. None of the documents I have has a
> reference to this.
>
> As far as I know, from the functional point of view, it is a normal AT
> command port like the other one. But I'll try to investigate a bit
> more..
>
Confirmed, there is no difference between those two interfaces other
than the bInterfaceSubClass code.
Regards,
Daniele
> Thanks,
> Daniele
>
>>
>> Bjørn
^ permalink raw reply
* Re: [PATCH net-next] udp: handle gro_receive only when necessary
From: Paolo Abeni @ 2017-12-19 11:47 UTC (permalink / raw)
To: zhangliping; +Cc: davem, netdev, zhangliping
In-Reply-To: <581a1e57.7029.1606e6f4d4f.Coremail.zhanglkk1990@163.com>
On Tue, 2017-12-19 at 19:01 +0800, zhangliping wrote:
> At 2017-12-18 22:45:30, "Paolo Abeni" <pabeni@redhat.com> wrote:
> > Understood, thanks. Still the time spent in 'udp4_lib_lookup2' looks
> > quite different/higher than what I observe in my tests. Are you using
> > x86_64? if not, do you see many cache misses in udp4_lib_lookup2?
>
> Yes, x86_64. Here is the host's lscpu output info:
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Byte Order: Little Endian
> CPU(s): 12
> On-line CPU(s) list: 0-11
> Thread(s) per core: 1
> Core(s) per socket: 6
> CPU socket(s): 2
> NUMA node(s): 2
> Vendor ID: GenuineIntel
> CPU family: 6
> Model: 62
> Stepping: 4
> CPU MHz: 2095.074
> BogoMIPS: 4196.28
> Virtualization: VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache: 256K
> L3 cache: 15360K
> NUMA node0 CPU(s): 0-5
> NUMA node1 CPU(s): 6-11
>
> Btw, my guest OS is Centos 3.10.0-514.26.2.el7.x86_64, is this kernel
> too old to be tested?
Understood. Yes, such kernel is a bit too old. So the perf trace you
reported refer to the CentOS kernel?
If you try a current vanilla kernel (or an upcoming rhel 7.5, for
shameless self promotion) you should see much better figures (and a
smaller differenct with your patch in)
Cheers,
Paolo
^ permalink raw reply
* Re: [PATCH net-next] udp: handle gro_receive only when necessary
From: zhangliping @ 2017-12-19 11:01 UTC (permalink / raw)
To: Paolo Abeni; +Cc: davem, netdev, zhangliping
In-Reply-To: <1513608330.8795.7.camel@redhat.com>
Hi,
At 2017-12-18 22:45:30, "Paolo Abeni" <pabeni@redhat.com> wrote:
>Understood, thanks. Still the time spent in 'udp4_lib_lookup2' looks
>quite different/higher than what I observe in my tests. Are you using
>x86_64? if not, do you see many cache misses in udp4_lib_lookup2?
Yes, x86_64. Here is the host's lscpu output info:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 12
On-line CPU(s) list: 0-11
Thread(s) per core: 1
Core(s) per socket: 6
CPU socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 62
Stepping: 4
CPU MHz: 2095.074
BogoMIPS: 4196.28
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 15360K
NUMA node0 CPU(s): 0-5
NUMA node1 CPU(s): 6-11
Btw, my guest OS is Centos 3.10.0-514.26.2.el7.x86_64, is this kernel
too old to be tested?
^ permalink raw reply
* [PATCH v2] net: arc_emac: fix arc_emac_rx() error paths
From: Alexander Kochetkov @ 2017-12-19 11:07 UTC (permalink / raw)
To: netdev, linux-kernel, David S. Miller
Cc: Florian Fainelli, Eric Dumazet, Alexander Kochetkov
In-Reply-To: <1513358406-32503-1-git-send-email-al.kochet@gmail.com>
arc_emac_rx() has some issues found by code review.
In case netdev_alloc_skb_ip_align() or dma_map_single() failure
rx fifo entry will not be returned to EMAC.
In case dma_map_single() failure previously allocated skb became
lost to driver. At the same time address of newly allocated skb
will not be provided to EMAC.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
Changes in v2:
- Rebased against stable linux-4.14.y branch
drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 363d909..bd277b0 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -212,39 +212,48 @@ static int arc_emac_rx(struct net_device *ndev, int budget)
continue;
}
- pktlen = info & LEN_MASK;
- stats->rx_packets++;
- stats->rx_bytes += pktlen;
- skb = rx_buff->skb;
- skb_put(skb, pktlen);
- skb->dev = ndev;
- skb->protocol = eth_type_trans(skb, ndev);
-
- dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
- dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
-
- /* Prepare the BD for next cycle */
- rx_buff->skb = netdev_alloc_skb_ip_align(ndev,
- EMAC_BUFFER_SIZE);
- if (unlikely(!rx_buff->skb)) {
+ /* Prepare the BD for next cycle. netif_receive_skb()
+ * only if new skb was allocated and mapped to avoid holes
+ * in the RX fifo.
+ */
+ skb = netdev_alloc_skb_ip_align(ndev, EMAC_BUFFER_SIZE);
+ if (unlikely(!skb)) {
+ if (net_ratelimit())
+ netdev_err(ndev, "cannot allocate skb\n");
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
- /* Because receive_skb is below, increment rx_dropped */
stats->rx_dropped++;
continue;
}
- /* receive_skb only if new skb was allocated to avoid holes */
- netif_receive_skb(skb);
-
- addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data,
+ addr = dma_map_single(&ndev->dev, (void *)skb->data,
EMAC_BUFFER_SIZE, DMA_FROM_DEVICE);
if (dma_mapping_error(&ndev->dev, addr)) {
if (net_ratelimit())
- netdev_err(ndev, "cannot dma map\n");
- dev_kfree_skb(rx_buff->skb);
+ netdev_err(ndev, "cannot map dma buffer\n");
+ dev_kfree_skb(skb);
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
+ stats->rx_dropped++;
continue;
}
+
+ /* unmap previosly mapped skb */
+ dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
+ dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
+
+ pktlen = info & LEN_MASK;
+ stats->rx_packets++;
+ stats->rx_bytes += pktlen;
+ skb_put(rx_buff->skb, pktlen);
+ rx_buff->skb->dev = ndev;
+ rx_buff->skb->protocol = eth_type_trans(rx_buff->skb, ndev);
+
+ netif_receive_skb(rx_buff->skb);
+
+ rx_buff->skb = skb;
dma_unmap_addr_set(rx_buff, addr, addr);
dma_unmap_len_set(rx_buff, len, EMAC_BUFFER_SIZE);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] net: arc_emac: restart stalled EMAC
From: Alexander Kochetkov @ 2017-12-19 11:03 UTC (permalink / raw)
To: netdev, linux-kernel, David S. Miller
Cc: Florian Fainelli, Eric Dumazet, Alexander Kochetkov
In-Reply-To: <1513358406-32503-1-git-send-email-al.kochet@gmail.com>
Under certain conditions EMAC stop reception of incoming packets and
continuously increment R_MISS register instead of saving data into
provided buffer. The commit implement workaround for such situation.
Then the stall detected EMAC will be restarted.
On device the stall looks like the device lost it's dynamic IP address.
ifconfig shows that interface error counter rapidly increments.
At the same time on the DHCP server we can see continues DHCP-requests
from device.
In real network stalls happen really rarely. To make them frequent the
broadcast storm[1] should be simulated. For simulation it is necessary
to make following connections:
1. connect radxarock to 1st port of switch
2. connect some PC to 2nd port of switch
3. connect two other free ports together using standard ethernet cable,
in order to make a switching loop.
After that, is necessary to make a broadcast storm. For example, running on
PC 'ping' to some IP address triggers ARP-request storm. After some
time (~10sec), EMAC on rk3188 will stall.
Observed and tested on rk3188 radxarock.
[1] https://en.wikipedia.org/wiki/Broadcast_radiation
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
Changes in v2:
- Rebased against stable linux-4.14.y branch
drivers/net/ethernet/arc/emac.h | 2 +
drivers/net/ethernet/arc/emac_main.c | 111 ++++++++++++++++++++++++++++++++++
2 files changed, 113 insertions(+)
diff --git a/drivers/net/ethernet/arc/emac.h b/drivers/net/ethernet/arc/emac.h
index 3c63b16..d9efbc8 100644
--- a/drivers/net/ethernet/arc/emac.h
+++ b/drivers/net/ethernet/arc/emac.h
@@ -159,6 +159,8 @@ struct arc_emac_priv {
unsigned int link;
unsigned int duplex;
unsigned int speed;
+
+ unsigned int rx_missed_errors;
};
/**
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 3241af1..363d909 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -26,6 +26,8 @@
#include "emac.h"
+static void arc_emac_restart(struct net_device *ndev);
+
/**
* arc_emac_tx_avail - Return the number of available slots in the tx ring.
* @priv: Pointer to ARC EMAC private data structure.
@@ -259,6 +261,53 @@ static int arc_emac_rx(struct net_device *ndev, int budget)
}
/**
+ * arc_emac_rx_miss_handle - handle R_MISS register
+ * @ndev: Pointer to the net_device structure.
+ */
+static void arc_emac_rx_miss_handle(struct net_device *ndev)
+{
+ struct arc_emac_priv *priv = netdev_priv(ndev);
+ struct net_device_stats *stats = &ndev->stats;
+ unsigned int miss;
+
+ miss = arc_reg_get(priv, R_MISS);
+ if (miss) {
+ stats->rx_errors += miss;
+ stats->rx_missed_errors += miss;
+ priv->rx_missed_errors += miss;
+ }
+}
+
+/**
+ * arc_emac_rx_stall_check - check RX stall
+ * @ndev: Pointer to the net_device structure.
+ * @budget: How many BDs requested to process on 1 call.
+ * @work_done: How many BDs processed
+ *
+ * Under certain conditions EMAC stop reception of incoming packets and
+ * continuously increment R_MISS register instead of saving data into
+ * provided buffer. This function detect that condition and restart
+ * EMAC.
+ */
+static void arc_emac_rx_stall_check(struct net_device *ndev,
+ int budget, unsigned int work_done)
+{
+ struct arc_emac_priv *priv = netdev_priv(ndev);
+ struct arc_emac_bd *rxbd;
+
+ if (work_done)
+ priv->rx_missed_errors = 0;
+
+ if (priv->rx_missed_errors && budget) {
+ rxbd = &priv->rxbd[priv->last_rx_bd];
+ if (le32_to_cpu(rxbd->info) & FOR_EMAC) {
+ arc_emac_restart(ndev);
+ priv->rx_missed_errors = 0;
+ }
+ }
+}
+
+/**
* arc_emac_poll - NAPI poll handler.
* @napi: Pointer to napi_struct structure.
* @budget: How many BDs to process on 1 call.
@@ -272,6 +321,7 @@ static int arc_emac_poll(struct napi_struct *napi, int budget)
unsigned int work_done;
arc_emac_tx_clean(ndev);
+ arc_emac_rx_miss_handle(ndev);
work_done = arc_emac_rx(ndev, budget);
if (work_done < budget) {
@@ -279,6 +329,8 @@ static int arc_emac_poll(struct napi_struct *napi, int budget)
arc_reg_or(priv, R_ENABLE, RXINT_MASK | TXINT_MASK);
}
+ arc_emac_rx_stall_check(ndev, budget, work_done);
+
return work_done;
}
@@ -320,6 +372,8 @@ static irqreturn_t arc_emac_intr(int irq, void *dev_instance)
if (status & MSER_MASK) {
stats->rx_missed_errors += 0x100;
stats->rx_errors += 0x100;
+ priv->rx_missed_errors += 0x100;
+ napi_schedule(&priv->napi);
}
if (status & RXCR_MASK) {
@@ -732,6 +786,63 @@ static int arc_emac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
}
+/**
+ * arc_emac_restart - Restart EMAC
+ * @ndev: Pointer to net_device structure.
+ *
+ * This function do hardware reset of EMAC in order to restore
+ * network packets reception.
+ */
+static void arc_emac_restart(struct net_device *ndev)
+{
+ struct arc_emac_priv *priv = netdev_priv(ndev);
+ struct net_device_stats *stats = &ndev->stats;
+ int i;
+
+ if (net_ratelimit())
+ netdev_warn(ndev, "restarting stalled EMAC\n");
+
+ netif_stop_queue(ndev);
+
+ /* Disable interrupts */
+ arc_reg_clr(priv, R_ENABLE, RXINT_MASK | TXINT_MASK | ERR_MASK);
+
+ /* Disable EMAC */
+ arc_reg_clr(priv, R_CTRL, EN_MASK);
+
+ /* Return the sk_buff to system */
+ arc_free_tx_queue(ndev);
+
+ /* Clean Tx BD's */
+ priv->txbd_curr = 0;
+ priv->txbd_dirty = 0;
+ memset(priv->txbd, 0, TX_RING_SZ);
+
+ for (i = 0; i < RX_BD_NUM; i++) {
+ struct arc_emac_bd *rxbd = &priv->rxbd[i];
+ unsigned int info = le32_to_cpu(rxbd->info);
+
+ if (!(info & FOR_EMAC)) {
+ stats->rx_errors++;
+ stats->rx_dropped++;
+ }
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
+ }
+ priv->last_rx_bd = 0;
+
+ /* Make sure info is visible to EMAC before enable */
+ wmb();
+
+ /* Enable interrupts */
+ arc_reg_set(priv, R_ENABLE, RXINT_MASK | TXINT_MASK | ERR_MASK);
+
+ /* Enable EMAC */
+ arc_reg_or(priv, R_CTRL, EN_MASK);
+
+ netif_start_queue(ndev);
+}
+
static const struct net_device_ops arc_emac_netdev_ops = {
.ndo_open = arc_emac_open,
.ndo_stop = arc_emac_stop,
--
1.7.9.5
^ permalink raw reply related
* dst refcount is -1
From: Ortwin Glück @ 2017-12-19 10:56 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, netdev, Wei Wang
Hi,
On 4.14.6 I just got this (on a busy firewall):
[Tue Dec 19 11:15:59 2017] dst_release: dst:ffff9bb7aca0d6c0 refcnt:-1
Are you sure the refcounting is now correct?
Ortwin
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
From: Marc Kleine-Budde @ 2017-12-19 10:47 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Simon Horman, Geert Uytterhoeven, linux-can@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Chris Paterson, Biju Das,
Wolfgang Grandegger, Rob Herring, Mark Rutland
In-Reply-To: <TY1PR06MB08953B33F245840430CD3DABC00F0@TY1PR06MB0895.apcprd06.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 444 bytes --]
On 12/19/2017 11:17 AM, Fabrizio Castro wrote:
> Hello Marc,
>
> does this patch look ok to you?
Yes, Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: Andy Shevchenko @ 2017-12-19 10:45 UTC (permalink / raw)
To: Sinan Kaya, linux-pci, timur
Cc: linux-arm-msm, linux-arm-kernel, David S. Miller, Kees Cook,
Eric Dumazet, Tobias Klauser, open list:NETWORKING DRIVERS,
open list
In-Reply-To: <1513661883-28662-15-git-send-email-okaya@codeaurora.org>
On Tue, 2017-12-19 at 00:37 -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
Where this idea come from?
pci_get_bus_and_slot() still might be useful for the wired devices in
SoC where we know for sure that domain == 0.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v3 net-next 0/6] tls: Add generic NIC offload infrastructure
From: Jiri Pirko @ 2017-12-19 10:30 UTC (permalink / raw)
To: Ilya Lesokhin
Cc: netdev, davem, davejwatson, tom, hannes, borisp, aviadye, liranl
In-Reply-To: <20171218171010.GB6823@nanopsycho>
Mon, Dec 18, 2017 at 06:10:10PM CET, jiri@resnulli.us wrote:
>Mon, Dec 18, 2017 at 12:10:27PM CET, ilyal@mellanox.com wrote:
>>Changes from v2:
>>- Fix sk use after free and possible netdev use after free
>>- tls device now keeps a refernce on the offloading netdev
>>- tls device registers to the netdev notifer.
>> Upon a NETDEV_DOWN event, offload is stopped and
>> the reference on the netdev is dropped.
>>- SW fallback support for skb->ip_summed != CHECKSUM_PARTIAL
>>- Merged TLS patches are no longer part of this series.
>>
>>Changes from v1:
>>- Remove the binding of the socket to a specific netdev
>> through sk->sk_bound_dev_if.
>> Add a check in validate_xmit_skb to detect route changes
>> and call SW fallback code to do the crypto in software.
>>- tls_get_record now returns the tls record sequence number.
>> This is required to support connections with rcd_sn != iv.
>>- Bug fixes to the TLS code.
>>
>>This patchset adds a generic infrastructure to offload TLS crypto to a
>>network devices.
>>
>>patches 1-2 Export functions that we need
>>patch 3 adds infrastructue for offloaded socket fallback
>>patches 4-5 add new NDOs and capabilities.
>>patch 6 adds the TLS NIC offload infrastructure.
>>
>>Github with mlx5e TLS offload support:
>>https://github.com/Mellanox/tls-offload/tree/tls_device_v3
>
>I don't get it. You are pushing infra but not the actual driver part
>who is consuming the infra? Why?
Okay. Since the driver that uses the API introduced by this patchset
is missing, this patchset should be marked as RFC.
Dave, I see that you were about to apply v2. I'm sure you missed this.
Thanks.
^ permalink raw reply
* Re: [PATCH bpf 8/9] bpf: fix integer overflows
From: Edward Cree @ 2017-12-19 10:29 UTC (permalink / raw)
To: Alexei Starovoitov, David S . Miller
Cc: Daniel Borkmann, Jann Horn, netdev, kernel-team
In-Reply-To: <20171219041201.1979983-9-ast@kernel.org>
On 19/12/17 04:12, Alexei Starovoitov wrote:
> Also reduce the scope of "scalar op scalar" tracking.
<snip>
> @@ -2046,6 +2088,12 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
> src_known = tnum_is_const(src_reg.var_off);
> dst_known = tnum_is_const(dst_reg->var_off);
>
> + if (!src_known &&
> + opcode != BPF_ADD && opcode != BPF_SUB && opcode != BPF_AND) {
> + __mark_reg_unknown(dst_reg);
> + return 0;
> + }
> +
> switch (opcode) {
> case BPF_ADD:
> if (signed_add_overflows(dst_reg->smin_value, smin_val) ||
Still not seeing any explanation for why this change is necessary.
It also seems arbitrary, e.g. why is AND allowed but not OR?
Hypothetical use case: combining a series of flags based on data read from
packet into an array index used for storing into a map value. That sounds
to me like something someone may be legitimately doing.
-Ed
^ permalink raw reply
* RE: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
From: Fabrizio Castro @ 2017-12-19 10:17 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Simon Horman, Geert Uytterhoeven, linux-can@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Chris Paterson, Biju Das,
Fabrizio Castro, Wolfgang Grandegger, Rob Herring, Mark Rutland
In-Reply-To: <1510067449-17017-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hello Marc,
does this patch look ok to you?
Thanks,
Fab
> Subject: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
>
> Document "renesas,can-r8a7743" and "renesas,can-r8a7745" compatible
> strings. Since the fallback compatible string ("renesas,rcar-gen2-can")
> activates the right code in the driver, no driver change is needed.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/can/rcar_can.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 06bb7cc..94a7f33 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -2,7 +2,9 @@ Renesas R-Car CAN controller Device Tree Bindings
> -------------------------------------------------
>
> Required properties:
> -- compatible: "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> +- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
> + "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
> + "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
> "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
> "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC.
> @@ -12,7 +14,8 @@ Required properties:
> "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
> "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
> "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
> - "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
> + "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
> + compatible device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
> When compatible with the generic version, nodes must list the
> SoC-specific version corresponding to the platform first
> --
> 2.7.4
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* pull-request: mac80211 2017-12-19
From: Johannes Berg @ 2017-12-19 9:57 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
Other work has been hectic, and I got caught by rc4. We still
have a few more fixes though - and more build issues were
reported.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 0afe9d4ab9d40c281bdcdd118661fe8e4bdcef18:
mac80211: fix locking in ieee80211_sta_tear_down_BA_sessions (2017-12-11 10:50:00 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-12-19
for you to fetch changes up to 04a7279ff12fc47b657f70731d401c0064f5838a:
cfg80211: ship certificates as hex files (2017-12-19 09:28:01 +0100)
----------------------------------------------------------------
A few more fixes:
* hwsim:
- set To-DS bit in some frames missing it
- fix sleeping in atomic
* nl80211:
- doc cleanup
- fix locking in an error path
* build:
- don't append to created certs C files
- ship certificate pre-hexdumped
----------------------------------------------------------------
Adiel Aloni (1):
mac80211_hwsim: enable TODS BIT in null data frame
Jia-Ju Bai (1):
mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl
Johannes Berg (2):
nl80211: fix nl80211_send_iface() error paths
cfg80211: ship certificates as hex files
Jonathan Corbet (1):
nl80211: Remove obsolete kerneldoc line
Thierry Reding (1):
cfg80211: always rewrite generated files from scratch
drivers/net/wireless/mac80211_hwsim.c | 3 +-
include/net/cfg80211.h | 1 -
net/wireless/Makefile | 31 ++++--------
net/wireless/certs/sforshee.hex | 86 ++++++++++++++++++++++++++++++++++
net/wireless/certs/sforshee.x509 | Bin 680 -> 0 bytes
net/wireless/nl80211.c | 6 ++-
6 files changed, 102 insertions(+), 25 deletions(-)
create mode 100644 net/wireless/certs/sforshee.hex
delete mode 100644 net/wireless/certs/sforshee.x509
^ permalink raw reply
* Re: [PATCH v4 25/36] nds32: Miscellaneous header files
From: Arnd Bergmann @ 2017-12-19 9:54 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAEbi=3fWvrvdqUYOWdmbAHDmMpLiUaTaL_-jUjqg=p4aZiMLrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 19, 2017 at 6:34 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi, Arnd:
>
> 2017-12-18 19:13 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>> On Mon, Dec 18, 2017 at 7:46 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>
>>> This patch introduces some miscellaneous header files.
>>
>>> +static inline void __delay(unsigned long loops)
>>> +{
>>> + __asm__ __volatile__(".align 2\n"
>>> + "1:\n"
>>> + "\taddi\t%0, %0, -1\n"
>>> + "\tbgtz\t%0, 1b\n"
>>> + :"=r"(loops)
>>> + :"0"(loops));
>>> +}
>>> +
>>> +static inline void __udelay(unsigned long usecs, unsigned long lpj)
>>> +{
>>> + usecs *= (unsigned long)(((0x8000000000000000ULL / (500000 / HZ)) +
>>> + 0x80000000ULL) >> 32);
>>> + usecs = (unsigned long)(((unsigned long long)usecs * lpj) >> 32);
>>> + __delay(usecs);
>>> +}
>>
>> Do you have a reliable clocksource that you can read here instead of doing the
>> loop? It's generally preferred to have an accurate delay if at all possible, the
>> delay loop calibration is only for those architectures that don't have any
>> way to observe how much time has passed accurately.
>>
>
> We currently only have atcpit100 as clocksource but it is an IP of SoC.
> These delay API will be unavailable if we changed to another SoC
> unless all these timer driver provided the same APIs.
> It may suffer our customers if they forget to port these APIs in their
> timer drivers when they try to use nds32 in the first beginning.
Ok, thanks for the clarification.
> Or maybe I can use a CONFIG_USE_ACCURATE_DELAY to keep these 2
> implementions for these purposes?
I'd just add a one-line comment in delay.h to explain that there is no
cycle counter in the CPU.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: thunderx sgmii interface hang
From: Sunil Kovvuri @ 2017-12-19 9:47 UTC (permalink / raw)
To: Tim Harvey; +Cc: Andrew Lunn, Sunil Goutham, netdev
In-Reply-To: <CAJ+vNU0yYkoAGZ6sU9VGfA6A04KU4s3rzZSb=1uxsqwKHioePQ@mail.gmail.com>
On Tue, Dec 19, 2017 at 3:23 AM, Tim Harvey <tharvey@gateworks.com> wrote:
> On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> The nic appears to work fine (pings, TCP etc) up until a performance
>>> test is attempted.
>>> When an iperf bandwidth test is attempted the nic ends up in a state
>>> where truncated-ip packets are being sent out (per a tcpdump from
>>> another board):
>>
>> Hi Tim
>>
>> Are pause frames supported? Have you tried turning them off?
>>
>> Can you reproduce the issue with UDP? Or is it TCP only?
>>
>
> Andrew,
>
> Pause frames don't appear to be supported yet and the issue occurs
> when using UDP as well as TCP. I'm not clear what the best way to
> troubleshoot this is.
>
> Sunil, have any others reported this issue? I do not have a Cavium
> CN80xx/CN81xx reference board that has SGMII.
Cavium's CN80xx/CN81xx reference board has marvell,88e1240 phy
and i have never faced personally nor i heard from anyone having
such issues.
Thanks,
Sunil.
>
> Regards,
>
> Tim
^ permalink raw reply
* Re: [PATCH] wireless: Always rewrite generated files from scratch
From: Johannes Berg @ 2017-12-19 9:42 UTC (permalink / raw)
To: Thierry Reding; +Cc: David S . Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171214133338.10551-1-thierry.reding@gmail.com>
On Thu, 2017-12-14 at 14:33 +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Currently the certs C code generation appends to the generated files,
> which is most likely a leftover from commit 715a12334764 ("wireless:
> don't write C files on failures"). This causes duplicate code in the
> generated files if the certificates have their timestamps modified
> between builds and thereby trigger the generation rules.
Yes, d'oh. Applied, thanks.
johannes
^ permalink raw reply
* Re: WARNING in sysfs_warn_dup
From: Dmitry Vyukov @ 2017-12-19 9:06 UTC (permalink / raw)
To: Greg KH
Cc: syzbot, LKML, syzkaller-bugs, David Miller, Daniel Borkmann,
Eric Dumazet, jakub.kicinski, Willem de Bruijn, Rasmus Villemoes,
John Fastabend, Tobin C. Harding, netdev
In-Reply-To: <CACT4Y+ZggKsEjCRZsFPW5-7_ByBcz4G0uRdieLL==r4mLQjhFA@mail.gmail.com>
On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>> On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > 6084b576dca2e898f5c101baef151f7bfdbb606d
>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> >
>> > Unfortunately, I don't have any reproducer for this bug yet.
>> >
>> >
>> > netlink: 9 bytes leftover after parsing attributes in process
>> > `syz-executor3'.
>> > sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing
>> > data in;
>> > program syz-executor0 not setting count and/or reply_len properly
>> > sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data
>> > in;
>> > program syz-executor0 not setting count and/or reply_len properly
>> > WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
>> > fs/sysfs/dir.c:30
>> > Kernel panic - not syncing: panic_on_warn set ...
>>
>> Looks like a networking issue, it tried to create two sysfs directories
>> with the same name, which isn't a sysfs bug :)
Now as plain text:
+net/core/dev.c maintainers
Let's keep the footer as well, so that people know how to handle this report:
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
syzbot will keep track of this bug report.
Once a fix for this bug is merged into any tree, reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: Possible unsafe usage of skb->cb in virtio-net
From: Jason Wang @ 2017-12-19 9:06 UTC (permalink / raw)
To: Michael S. Tsirkin, Ilya Lesokhin
Cc: netdev, Willem de Bruijn, David Miller, virtualization
In-Reply-To: <20171102142758-mutt-send-email-mst@kernel.org>
On 2017年11月02日 21:01, Michael S. Tsirkin wrote:
> On Thu, Nov 02, 2017 at 11:40:36AM +0000, Ilya Lesokhin wrote:
>> Hi,
>> I've noticed that the virtio-net uses skb->cb.
>>
>> I don't know all the detail by my understanding is it caused problem with the mlx5 driver
>> and was fixed here:
>> https://github.com/torvalds/linux/commit/34802a42b3528b0e18ea4517c8b23e1214a09332
>>
>> Thanks,
>> Ilya
> Thanks a lot for the pointer.
>
> I think this was in response to this:
> https://patchwork.ozlabs.org/patch/558324/
>
>>> + skb_push(skb, skb->data - skb_data_orig);
>>> sq->skb[pi] = skb;
>>>
>>> MLX5E_TX_SKB_CB(skb)->num_wqebbs = DIV_ROUND_UP(ds_cnt,
>> And in the middle of this we have:
>>
>> skb_pull_inline(skb, ihs);
>>
>> This is looks illegal.
>>
>> You must not modify the data pointers of any SKB that you receive for
>> sending via ->ndo_start_xmit() unless you know that absolutely you are
>> the one and only reference that exists to that SKB.
>>
>> And exactly for the case you are trying to "fix" here, you do not. If
>> the SKB is cloned, or has an elevated users count, someone else can be
>> looking at it exactly at the same time you are messing with the data
>> pointers.
>>
>> I bet mlx4 has this bug too.
>>
>> You must fix this properly, by keeping track of an offset or similar
>> internally to your driver, rather than changing the SKB data pointers.
> What virtio does is this:
>
> can_push = vi->any_header_sg &&
> !((unsigned long)skb->data & (__alignof__(*hdr) - 1)) &&
> !skb_header_cloned(skb) && skb_headroom(skb) >= hdr_len;
> /* Even if we can, don't push here yet as this would skew
> * csum_start offset below. */
> if (can_push)
> hdr = (struct virtio_net_hdr_mrg_rxbuf *)(skb->data - hdr_len);
> else
> hdr = skb_vnet_hdr(skb);
>
>
> This doesn't change the data pointers in a cloned skb but it does change the cb.
> Is it true that it's illegal to touch the cb in a cloned skb then?
>
I think not.
skb_clone() call __skb_copy_header() which did:
memcpy(new->cb, old->cb, sizeof(old->cb));
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [net-next] phylib: Add device reset GPIO support causes DSA MT7530 acquires reset-gpios fails
From: Sergei Shtylyov @ 2017-12-19 9:06 UTC (permalink / raw)
To: Sean Wang, andrew, f.fainelli, vivien.didelot
Cc: davem, netdev, linux-kernel, linux-mediatek, richard.leitner,
geert+renesas
In-Reply-To: <1513320903.28444.65.camel@mtkswgap22>
On 12/15/2017 9:55 AM, Sean Wang wrote:
> Hi Sergei,
Note that I'm no longer responsible for the patch in question -- it was
abandoned by me back in 2016. Geert has somewhat reworked it and pushed into
net-next.
MBR, Sergei
^ permalink raw reply
* [PATCH -tip v3 6/6] net: dccp: Remove dccpprobe module
From: Masami Hiramatsu @ 2017-12-19 8:59 UTC (permalink / raw)
To: Ingo Molnar, Ian McDonald, Vlad Yasevich, Stephen Hemminger,
Steven Rostedt
Cc: Peter Zijlstra, Thomas Gleixner, LKML, H . Peter Anvin,
Gerrit Renker, David S . Miller, Neil Horman, dccp, netdev,
linux-sctp, Stephen Rothwell, mhiramat
In-Reply-To: <151367381480.32364.2659143894655716709.stgit@devbox>
Remove DCCP probe module since jprobe has been deprecated.
That function is now replaced by dccp/dccp_probe trace-event.
You can use it via ftrace or perftools.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
net/dccp/Kconfig | 17 ----
net/dccp/Makefile | 2 -
net/dccp/probe.c | 203 -----------------------------------------------------
3 files changed, 222 deletions(-)
delete mode 100644 net/dccp/probe.c
diff --git a/net/dccp/Kconfig b/net/dccp/Kconfig
index 8c0ef71bed2f..b270e84d9c13 100644
--- a/net/dccp/Kconfig
+++ b/net/dccp/Kconfig
@@ -39,23 +39,6 @@ config IP_DCCP_DEBUG
Just say N.
-config NET_DCCPPROBE
- tristate "DCCP connection probing"
- depends on PROC_FS && KPROBES
- ---help---
- This module allows for capturing the changes to DCCP connection
- state in response to incoming packets. It is used for debugging
- DCCP congestion avoidance modules. If you don't understand
- what was just said, you don't need it: say N.
-
- Documentation on how to use DCCP connection probing can be found
- at:
-
- http://www.linuxfoundation.org/collaborate/workgroups/networking/dccpprobe
-
- To compile this code as a module, choose M here: the
- module will be called dccp_probe.
-
endmenu
diff --git a/net/dccp/Makefile b/net/dccp/Makefile
index 2e7b56097bc4..9d0383d2f277 100644
--- a/net/dccp/Makefile
+++ b/net/dccp/Makefile
@@ -21,9 +21,7 @@ obj-$(subst y,$(CONFIG_IP_DCCP),$(CONFIG_IPV6)) += dccp_ipv6.o
dccp_ipv6-y := ipv6.o
obj-$(CONFIG_INET_DCCP_DIAG) += dccp_diag.o
-obj-$(CONFIG_NET_DCCPPROBE) += dccp_probe.o
dccp-$(CONFIG_SYSCTL) += sysctl.o
dccp_diag-y := diag.o
-dccp_probe-y := probe.o
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
deleted file mode 100644
index 3d3fda05b32d..000000000000
--- a/net/dccp/probe.c
+++ /dev/null
@@ -1,203 +0,0 @@
-/*
- * dccp_probe - Observe the DCCP flow with kprobes.
- *
- * The idea for this came from Werner Almesberger's umlsim
- * Copyright (C) 2004, Stephen Hemminger <shemminger@osdl.org>
- *
- * Modified for DCCP from Stephen Hemminger's code
- * Copyright (C) 2006, Ian McDonald <ian.mcdonald@jandi.co.nz>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include <linux/kernel.h>
-#include <linux/kprobes.h>
-#include <linux/socket.h>
-#include <linux/dccp.h>
-#include <linux/proc_fs.h>
-#include <linux/module.h>
-#include <linux/kfifo.h>
-#include <linux/vmalloc.h>
-#include <linux/time64.h>
-#include <linux/gfp.h>
-#include <net/net_namespace.h>
-
-#include "dccp.h"
-#include "ccid.h"
-#include "ccids/ccid3.h"
-
-static int port;
-
-static int bufsize = 64 * 1024;
-
-static const char procname[] = "dccpprobe";
-
-static struct {
- struct kfifo fifo;
- spinlock_t lock;
- wait_queue_head_t wait;
- struct timespec64 tstart;
-} dccpw;
-
-static void printl(const char *fmt, ...)
-{
- va_list args;
- int len;
- struct timespec64 now;
- char tbuf[256];
-
- va_start(args, fmt);
- getnstimeofday64(&now);
-
- now = timespec64_sub(now, dccpw.tstart);
-
- len = sprintf(tbuf, "%lu.%06lu ",
- (unsigned long) now.tv_sec,
- (unsigned long) now.tv_nsec / NSEC_PER_USEC);
- len += vscnprintf(tbuf+len, sizeof(tbuf)-len, fmt, args);
- va_end(args);
-
- kfifo_in_locked(&dccpw.fifo, tbuf, len, &dccpw.lock);
- wake_up(&dccpw.wait);
-}
-
-static int jdccp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
-{
- const struct inet_sock *inet = inet_sk(sk);
- struct ccid3_hc_tx_sock *hc = NULL;
-
- if (ccid_get_current_tx_ccid(dccp_sk(sk)) == DCCPC_CCID3)
- hc = ccid3_hc_tx_sk(sk);
-
- if (port == 0 || ntohs(inet->inet_dport) == port ||
- ntohs(inet->inet_sport) == port) {
- if (hc)
- printl("%pI4:%u %pI4:%u %d %d %d %d %u %llu %llu %d\n",
- &inet->inet_saddr, ntohs(inet->inet_sport),
- &inet->inet_daddr, ntohs(inet->inet_dport), size,
- hc->tx_s, hc->tx_rtt, hc->tx_p,
- hc->tx_x_calc, hc->tx_x_recv >> 6,
- hc->tx_x >> 6, hc->tx_t_ipi);
- else
- printl("%pI4:%u %pI4:%u %d\n",
- &inet->inet_saddr, ntohs(inet->inet_sport),
- &inet->inet_daddr, ntohs(inet->inet_dport),
- size);
- }
-
- jprobe_return();
- return 0;
-}
-
-static struct jprobe dccp_send_probe = {
- .kp = {
- .symbol_name = "dccp_sendmsg",
- },
- .entry = jdccp_sendmsg,
-};
-
-static int dccpprobe_open(struct inode *inode, struct file *file)
-{
- kfifo_reset(&dccpw.fifo);
- getnstimeofday64(&dccpw.tstart);
- return 0;
-}
-
-static ssize_t dccpprobe_read(struct file *file, char __user *buf,
- size_t len, loff_t *ppos)
-{
- int error = 0, cnt = 0;
- unsigned char *tbuf;
-
- if (!buf)
- return -EINVAL;
-
- if (len == 0)
- return 0;
-
- tbuf = vmalloc(len);
- if (!tbuf)
- return -ENOMEM;
-
- error = wait_event_interruptible(dccpw.wait,
- kfifo_len(&dccpw.fifo) != 0);
- if (error)
- goto out_free;
-
- cnt = kfifo_out_locked(&dccpw.fifo, tbuf, len, &dccpw.lock);
- error = copy_to_user(buf, tbuf, cnt) ? -EFAULT : 0;
-
-out_free:
- vfree(tbuf);
-
- return error ? error : cnt;
-}
-
-static const struct file_operations dccpprobe_fops = {
- .owner = THIS_MODULE,
- .open = dccpprobe_open,
- .read = dccpprobe_read,
- .llseek = noop_llseek,
-};
-
-static __init int dccpprobe_init(void)
-{
- int ret = -ENOMEM;
-
- init_waitqueue_head(&dccpw.wait);
- spin_lock_init(&dccpw.lock);
- if (kfifo_alloc(&dccpw.fifo, bufsize, GFP_KERNEL))
- return ret;
- if (!proc_create(procname, S_IRUSR, init_net.proc_net, &dccpprobe_fops))
- goto err0;
-
- ret = register_jprobe(&dccp_send_probe);
- if (ret) {
- ret = request_module("dccp");
- if (!ret)
- ret = register_jprobe(&dccp_send_probe);
- }
-
- if (ret)
- goto err1;
-
- pr_info("DCCP watch registered (port=%d)\n", port);
- return 0;
-err1:
- remove_proc_entry(procname, init_net.proc_net);
-err0:
- kfifo_free(&dccpw.fifo);
- return ret;
-}
-module_init(dccpprobe_init);
-
-static __exit void dccpprobe_exit(void)
-{
- kfifo_free(&dccpw.fifo);
- remove_proc_entry(procname, init_net.proc_net);
- unregister_jprobe(&dccp_send_probe);
-
-}
-module_exit(dccpprobe_exit);
-
-MODULE_PARM_DESC(port, "Port to match (0=all)");
-module_param(port, int, 0);
-
-MODULE_PARM_DESC(bufsize, "Log buffer size (default 64k)");
-module_param(bufsize, int, 0);
-
-MODULE_AUTHOR("Ian McDonald <ian.mcdonald@jandi.co.nz>");
-MODULE_DESCRIPTION("DCCP snooper");
-MODULE_LICENSE("GPL");
^ permalink raw reply related
* [PATCH -tip v3 5/6] net: dccp: Add DCCP sendmsg trace event
From: Masami Hiramatsu @ 2017-12-19 8:59 UTC (permalink / raw)
To: Ingo Molnar, Ian McDonald, Vlad Yasevich, Stephen Hemminger,
Steven Rostedt
Cc: Peter Zijlstra, Thomas Gleixner, LKML, H . Peter Anvin,
Gerrit Renker, David S . Miller, Neil Horman, dccp, netdev,
linux-sctp, Stephen Rothwell, mhiramat
In-Reply-To: <151367381480.32364.2659143894655716709.stgit@devbox>
Add DCCP sendmsg trace event (dccp/dccp_probe) for
replacing dccpprobe. User can trace this event via
ftrace or perftools.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
net/dccp/proto.c | 5 +++
net/dccp/trace.h | 105 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 110 insertions(+)
create mode 100644 net/dccp/trace.h
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index 9d43c1f40274..e57b5db495cd 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -38,6 +38,9 @@
#include "dccp.h"
#include "feat.h"
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
DEFINE_SNMP_STAT(struct dccp_mib, dccp_statistics) __read_mostly;
EXPORT_SYMBOL_GPL(dccp_statistics);
@@ -761,6 +764,8 @@ int dccp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
int rc, size;
long timeo;
+ trace_dccp_probe(sk, len);
+
if (len > dp->dccps_mss_cache)
return -EMSGSIZE;
diff --git a/net/dccp/trace.h b/net/dccp/trace.h
new file mode 100644
index 000000000000..aa01321a6c37
--- /dev/null
+++ b/net/dccp/trace.h
@@ -0,0 +1,105 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM dccp
+
+#if !defined(_TRACE_DCCP_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_DCCP_H
+
+#include <net/sock.h>
+#include "dccp.h"
+#include "ccids/ccid3.h"
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(dccp_probe,
+
+ TP_PROTO(struct sock *sk, size_t size),
+
+ TP_ARGS(sk, size),
+
+ TP_STRUCT__entry(
+ /* sockaddr_in6 is always bigger than sockaddr_in */
+ __array(__u8, saddr, sizeof(struct sockaddr_in6))
+ __array(__u8, daddr, sizeof(struct sockaddr_in6))
+ __field(__u16, sport)
+ __field(__u16, dport)
+ __field(__u16, size)
+ __field(__u16, tx_s)
+ __field(__u32, tx_rtt)
+ __field(__u32, tx_p)
+ __field(__u32, tx_x_calc)
+ __field(__u64, tx_x_recv)
+ __field(__u64, tx_x)
+ __field(__u32, tx_t_ipi)
+ ),
+
+ TP_fast_assign(
+ const struct inet_sock *inet = inet_sk(sk);
+ struct ccid3_hc_tx_sock *hc = NULL;
+
+ if (ccid_get_current_tx_ccid(dccp_sk(sk)) == DCCPC_CCID3)
+ hc = ccid3_hc_tx_sk(sk);
+
+ memset(__entry->saddr, 0, sizeof(struct sockaddr_in6));
+ memset(__entry->daddr, 0, sizeof(struct sockaddr_in6));
+
+ if (sk->sk_family == AF_INET) {
+ struct sockaddr_in *v4 = (void *)__entry->saddr;
+
+ v4->sin_family = AF_INET;
+ v4->sin_port = inet->inet_sport;
+ v4->sin_addr.s_addr = inet->inet_saddr;
+ v4 = (void *)__entry->daddr;
+ v4->sin_family = AF_INET;
+ v4->sin_port = inet->inet_dport;
+ v4->sin_addr.s_addr = inet->inet_daddr;
+#if IS_ENABLED(CONFIG_IPV6)
+ } else if (sk->sk_family == AF_INET6) {
+ struct sockaddr_in6 *v6 = (void *)__entry->saddr;
+
+ v6->sin6_family = AF_INET6;
+ v6->sin6_port = inet->inet_sport;
+ v6->sin6_addr = inet6_sk(sk)->saddr;
+ v6 = (void *)__entry->daddr;
+ v6->sin6_family = AF_INET6;
+ v6->sin6_port = inet->inet_dport;
+ v6->sin6_addr = sk->sk_v6_daddr;
+#endif
+ }
+
+ /* For filtering use */
+ __entry->sport = ntohs(inet->inet_sport);
+ __entry->dport = ntohs(inet->inet_dport);
+
+ __entry->size = size;
+ if (hc) {
+ __entry->tx_s = hc->tx_s;
+ __entry->tx_rtt = hc->tx_rtt;
+ __entry->tx_p = hc->tx_p;
+ __entry->tx_x_calc = hc->tx_x_calc;
+ __entry->tx_x_recv = hc->tx_x_recv >> 6;
+ __entry->tx_x = hc->tx_x >> 6;
+ __entry->tx_t_ipi = hc->tx_t_ipi;
+ } else {
+ __entry->tx_s = 0;
+ memset(&__entry->tx_rtt, 0, (void *)&__entry->tx_t_ipi -
+ (void *)&__entry->tx_rtt +
+ sizeof(__entry->tx_t_ipi));
+ }
+ ),
+
+ TP_printk("src=%pISpc dest=%pISpc size=%d tx_s=%d tx_rtt=%d "
+ "tx_p=%d tx_x_calc=%u tx_x_recv=%llu tx_x=%llu tx_t_ipi=%d",
+ __entry->saddr, __entry->daddr, __entry->size,
+ __entry->tx_s, __entry->tx_rtt, __entry->tx_p,
+ __entry->tx_x_calc, __entry->tx_x_recv, __entry->tx_x,
+ __entry->tx_t_ipi)
+);
+
+#endif /* _TRACE_TCP_H */
+
+/* This part must be outside protection */
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE trace
+#include <trace/define_trace.h>
^ permalink raw reply related
* [PATCH -tip v3 4/6] net: sctp: Remove debug SCTP probe module
From: Masami Hiramatsu @ 2017-12-19 8:58 UTC (permalink / raw)
To: Ingo Molnar, Ian McDonald, Vlad Yasevich, Stephen Hemminger,
Steven Rostedt
Cc: Peter Zijlstra, Thomas Gleixner, LKML, H . Peter Anvin,
Gerrit Renker, David S . Miller, Neil Horman, dccp, netdev,
linux-sctp, Stephen Rothwell, mhiramat
In-Reply-To: <151367381480.32364.2659143894655716709.stgit@devbox>
Remove SCTP probe module since jprobe has been deprecated.
That function is now replaced by sctp/sctp_probe and
sctp/sctp_probe_path trace-events.
You can use it via ftrace or perftools.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
net/sctp/Kconfig | 12 ---
net/sctp/Makefile | 3 -
net/sctp/probe.c | 244 -----------------------------------------------------
3 files changed, 259 deletions(-)
delete mode 100644 net/sctp/probe.c
diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index d9c04dc1b3f3..c740b189d4ba 100644
--- a/net/sctp/Kconfig
+++ b/net/sctp/Kconfig
@@ -37,18 +37,6 @@ menuconfig IP_SCTP
if IP_SCTP
-config NET_SCTPPROBE
- tristate "SCTP: Association probing"
- depends on PROC_FS && KPROBES
- ---help---
- This module allows for capturing the changes to SCTP association
- state in response to incoming packets. It is used for debugging
- SCTP congestion control algorithms. If you don't understand
- what was just said, you don't need it: say N.
-
- To compile this code as a module, choose M here: the
- module will be called sctp_probe.
-
config SCTP_DBG_OBJCNT
bool "SCTP: Debug object counts"
depends on PROC_FS
diff --git a/net/sctp/Makefile b/net/sctp/Makefile
index 1ca84a288443..b52dfc6f8b4c 100644
--- a/net/sctp/Makefile
+++ b/net/sctp/Makefile
@@ -4,7 +4,6 @@
#
obj-$(CONFIG_IP_SCTP) += sctp.o
-obj-$(CONFIG_NET_SCTPPROBE) += sctp_probe.o
obj-$(CONFIG_INET_SCTP_DIAG) += sctp_diag.o
sctp-y := sm_statetable.o sm_statefuns.o sm_sideeffect.o \
@@ -16,8 +15,6 @@ sctp-y := sm_statetable.o sm_statefuns.o sm_sideeffect.o \
offload.o stream_sched.o stream_sched_prio.o \
stream_sched_rr.o
-sctp_probe-y := probe.o
-
sctp-$(CONFIG_SCTP_DBG_OBJCNT) += objcnt.o
sctp-$(CONFIG_PROC_FS) += proc.o
sctp-$(CONFIG_SYSCTL) += sysctl.o
diff --git a/net/sctp/probe.c b/net/sctp/probe.c
deleted file mode 100644
index 1280f85a598d..000000000000
--- a/net/sctp/probe.c
+++ /dev/null
@@ -1,244 +0,0 @@
-/*
- * sctp_probe - Observe the SCTP flow with kprobes.
- *
- * The idea for this came from Werner Almesberger's umlsim
- * Copyright (C) 2004, Stephen Hemminger <shemminger@osdl.org>
- *
- * Modified for SCTP from Stephen Hemminger's code
- * Copyright (C) 2010, Wei Yongjun <yjwei@cn.fujitsu.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include <linux/kernel.h>
-#include <linux/kprobes.h>
-#include <linux/socket.h>
-#include <linux/sctp.h>
-#include <linux/proc_fs.h>
-#include <linux/vmalloc.h>
-#include <linux/module.h>
-#include <linux/kfifo.h>
-#include <linux/time.h>
-#include <net/net_namespace.h>
-
-#include <net/sctp/sctp.h>
-#include <net/sctp/sm.h>
-
-MODULE_SOFTDEP("pre: sctp");
-MODULE_AUTHOR("Wei Yongjun <yjwei@cn.fujitsu.com>");
-MODULE_DESCRIPTION("SCTP snooper");
-MODULE_LICENSE("GPL");
-
-static int port __read_mostly = 0;
-MODULE_PARM_DESC(port, "Port to match (0=all)");
-module_param(port, int, 0);
-
-static unsigned int fwmark __read_mostly = 0;
-MODULE_PARM_DESC(fwmark, "skb mark to match (0=no mark)");
-module_param(fwmark, uint, 0);
-
-static int bufsize __read_mostly = 64 * 1024;
-MODULE_PARM_DESC(bufsize, "Log buffer size (default 64k)");
-module_param(bufsize, int, 0);
-
-static int full __read_mostly = 1;
-MODULE_PARM_DESC(full, "Full log (1=every ack packet received, 0=only cwnd changes)");
-module_param(full, int, 0);
-
-static const char procname[] = "sctpprobe";
-
-static struct {
- struct kfifo fifo;
- spinlock_t lock;
- wait_queue_head_t wait;
- struct timespec64 tstart;
-} sctpw;
-
-static __printf(1, 2) void printl(const char *fmt, ...)
-{
- va_list args;
- int len;
- char tbuf[256];
-
- va_start(args, fmt);
- len = vscnprintf(tbuf, sizeof(tbuf), fmt, args);
- va_end(args);
-
- kfifo_in_locked(&sctpw.fifo, tbuf, len, &sctpw.lock);
- wake_up(&sctpw.wait);
-}
-
-static int sctpprobe_open(struct inode *inode, struct file *file)
-{
- kfifo_reset(&sctpw.fifo);
- ktime_get_ts64(&sctpw.tstart);
-
- return 0;
-}
-
-static ssize_t sctpprobe_read(struct file *file, char __user *buf,
- size_t len, loff_t *ppos)
-{
- int error = 0, cnt = 0;
- unsigned char *tbuf;
-
- if (!buf)
- return -EINVAL;
-
- if (len == 0)
- return 0;
-
- tbuf = vmalloc(len);
- if (!tbuf)
- return -ENOMEM;
-
- error = wait_event_interruptible(sctpw.wait,
- kfifo_len(&sctpw.fifo) != 0);
- if (error)
- goto out_free;
-
- cnt = kfifo_out_locked(&sctpw.fifo, tbuf, len, &sctpw.lock);
- error = copy_to_user(buf, tbuf, cnt) ? -EFAULT : 0;
-
-out_free:
- vfree(tbuf);
-
- return error ? error : cnt;
-}
-
-static const struct file_operations sctpprobe_fops = {
- .owner = THIS_MODULE,
- .open = sctpprobe_open,
- .read = sctpprobe_read,
- .llseek = noop_llseek,
-};
-
-static enum sctp_disposition jsctp_sf_eat_sack(
- struct net *net,
- const struct sctp_endpoint *ep,
- const struct sctp_association *asoc,
- const union sctp_subtype type,
- void *arg,
- struct sctp_cmd_seq *commands)
-{
- struct sctp_chunk *chunk = arg;
- struct sk_buff *skb = chunk->skb;
- struct sctp_transport *sp;
- static __u32 lcwnd = 0;
- struct timespec64 now;
-
- sp = asoc->peer.primary_path;
-
- if (((port == 0 && fwmark == 0) ||
- asoc->peer.port == port ||
- ep->base.bind_addr.port == port ||
- (fwmark > 0 && skb->mark == fwmark)) &&
- (full || sp->cwnd != lcwnd)) {
- lcwnd = sp->cwnd;
-
- ktime_get_ts64(&now);
- now = timespec64_sub(now, sctpw.tstart);
-
- printl("%lu.%06lu ", (unsigned long) now.tv_sec,
- (unsigned long) now.tv_nsec / NSEC_PER_USEC);
-
- printl("%p %5d %5d %5d %8d %5d ", asoc,
- ep->base.bind_addr.port, asoc->peer.port,
- asoc->pathmtu, asoc->peer.rwnd, asoc->unack_data);
-
- list_for_each_entry(sp, &asoc->peer.transport_addr_list,
- transports) {
- if (sp == asoc->peer.primary_path)
- printl("*");
-
- printl("%pISc %2u %8u %8u %8u %8u %8u ",
- &sp->ipaddr, sp->state, sp->cwnd, sp->ssthresh,
- sp->flight_size, sp->partial_bytes_acked,
- sp->pathmtu);
- }
- printl("\n");
- }
-
- jprobe_return();
- return 0;
-}
-
-static struct jprobe sctp_recv_probe = {
- .kp = {
- .symbol_name = "sctp_sf_eat_sack_6_2",
- },
- .entry = jsctp_sf_eat_sack,
-};
-
-static __init int sctp_setup_jprobe(void)
-{
- int ret = register_jprobe(&sctp_recv_probe);
-
- if (ret) {
- if (request_module("sctp"))
- goto out;
- ret = register_jprobe(&sctp_recv_probe);
- }
-
-out:
- return ret;
-}
-
-static __init int sctpprobe_init(void)
-{
- int ret = -ENOMEM;
-
- /* Warning: if the function signature of sctp_sf_eat_sack_6_2,
- * has been changed, you also have to change the signature of
- * jsctp_sf_eat_sack, otherwise you end up right here!
- */
- BUILD_BUG_ON(__same_type(sctp_sf_eat_sack_6_2,
- jsctp_sf_eat_sack) == 0);
-
- init_waitqueue_head(&sctpw.wait);
- spin_lock_init(&sctpw.lock);
- if (kfifo_alloc(&sctpw.fifo, bufsize, GFP_KERNEL))
- return ret;
-
- if (!proc_create(procname, S_IRUSR, init_net.proc_net,
- &sctpprobe_fops))
- goto free_kfifo;
-
- ret = sctp_setup_jprobe();
- if (ret)
- goto remove_proc;
-
- pr_info("probe registered (port=%d/fwmark=%u) bufsize=%u\n",
- port, fwmark, bufsize);
- return 0;
-
-remove_proc:
- remove_proc_entry(procname, init_net.proc_net);
-free_kfifo:
- kfifo_free(&sctpw.fifo);
- return ret;
-}
-
-static __exit void sctpprobe_exit(void)
-{
- kfifo_free(&sctpw.fifo);
- remove_proc_entry(procname, init_net.proc_net);
- unregister_jprobe(&sctp_recv_probe);
-}
-
-module_init(sctpprobe_init);
-module_exit(sctpprobe_exit);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox