* Re: IGMP joins come from the wrong SA/interface
From: Hannes Frederic Sowa @ 2014-01-19 18:18 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: netdev
In-Reply-To: <20140118191107.GA21979@sesse.net>
On Sat, Jan 18, 2014 at 08:11:07PM +0100, Steinar H. Gunderson wrote:
> It doesn't matter if I drop the “multicast” token from the ip route line.
> Behavior is still exactly the same; it comes out of eth0 instead of eth0.2,
> with the wrong source address.
>
> This used to work, once upon a time, but I fear it broke during a
> kernel upgrade. It's hard for me to say exactly when; probably
> a few months ago. Any ideas?
I currently only remember one commit 0a7e22609067ff ("ipv4: fix
ineffective source address selection") which did affect multicast source
address selection in recent times.
Maybe try a revert?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 3/4] ethtool: Support for configurable RSS hash key.
From: Ben Hutchings @ 2014-01-19 18:27 UTC (permalink / raw)
To: Venkata Duvvuru; +Cc: netdev@vger.kernel.org
In-Reply-To: <BF3270C86E8B1349A26C34E4EC1C44CB2C83D8E5@CMEXMB1.ad.emulex.com>
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
On Fri, 2014-01-17 at 13:02 +0000, Venkata Duvvuru wrote:
> This ethtool patch primarily copies the ioctl command data structures from/to the User space and invokes the driver hook.
[...]
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
> @@ -678,6 +678,22 @@ struct ethtool_rx_ntuple {
> struct ethtool_rx_ntuple_flow_spec fs;
> };
>
> +
> +/**
> + * struct ethtool_rss_hkey - command to set/get RSS hash key of the device.
> + * @cmd: Command number - %ETHTOOL_SET_RSS_HKEY/ETHTOOL_GET_RSS_HKEY
> + * @data: 40 or 16 byte rss hash key
> + * @data_len: rss hash key length
> + */
> +
> +#define RSS_HASH_KEY_LEN 40
This should have an 'ETHTOOL_' or 'ETH_' prefix. But I wonder whether
there should actually be a static maximum length.
> +/* RSS Hash key */
> +struct ethtool_rss_hkey {
> + __u32 cmd; /* ETHTOOL_SET/GET_RSS_HKEY */
> + __u8 data[RSS_HASH_KEY_LEN];
> + __u32 data_len;
> +};
[...]
How about putting data after the data_len and giving it a length of 0,
so this is extensible to an arbitrary length key?
If we're extending the RSS configuration interface, there are a few
other things that might be worth doing at the same time:
- Single commands to get/set both the key and the indirection table at
the same time
- Add a field to distinguish multiple RSS contexts (some hardware can
use RSS contexts together with filters, though RX NFC does not support
that yet)
Ben.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4 ethtool] ethtool: Support for configurable RSS hash key.
From: Ben Hutchings @ 2014-01-19 18:35 UTC (permalink / raw)
To: Venkata Duvvuru; +Cc: netdev@vger.kernel.org
In-Reply-To: <BF3270C86E8B1349A26C34E4EC1C44CB2C83D8D4@CMEXMB1.ad.emulex.com>
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
On Fri, 2014-01-17 at 13:02 +0000, Venkata Duvvuru wrote:
> This ethtool patch will primarily implement the parser for the options provided by the user for set and get hashkey before invoking the ioctl.
> This patch also has Ethtool man page changes which describes the Usage of set and get hashkey options.
I'd prefer to have this combined with the -x/-X options (and add new
long options to reflect that they cover the key as well).
[...]
> diff --git a/ethtool.c b/ethtool.c
> index b06dfa3..4b05b0c 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -471,6 +471,59 @@ static int rxflow_str_to_type(const char *str)
> return flow_type;
> }
>
> +static inline int is_hkey_char_valid(const char rss_hkey_string) {
A char is not a string.
> + /* Are there any invalid characters in the string */
> + return ((rss_hkey_string >= '0' && rss_hkey_string <= '9') ||
> + (rss_hkey_string >= 'a' && rss_hkey_string <= 'f') ||
> + (rss_hkey_string >= 'A' && rss_hkey_string <= 'F')); }
Braces are in the wrong places. And the whole function is redundant
with isxdigit() anyway.
> +static int convert_string_to_hashkey(struct ethtool_rss_hkey *rss_hkey,
> + const char *rss_hkey_string)
> +{
> + int i = 0;
> + int hex_byte;
> +
> + do {
> + if (i > (RSS_HASH_KEY_LEN - 1)) {
Comparing with the wrong limit.
[...]
> +static int get_hashkey(struct cmd_context *ctx) {
Brace in the wrong place.
[...]
> + for (i = 0; i < RSS_HASH_KEY_LEN; i++) {
> + if (i == (RSS_HASH_KEY_LEN - 1))
Wrong length.
> + printf("%02x\n", rss_hkey->data[i]);
> + else
> + printf("%02x:", rss_hkey->data[i]);
> + }
> +
> +done:
> + free(rss_hkey);
> + return rc;
> +}
[...]
--
Ben Hutchings
friends: People who know you well, but like you anyway.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: ping [PATCH v3] WAN: Adding support for Lantiq PEF2256 E1 chipset (FALC56)
From: Joe Perches @ 2014-01-19 19:34 UTC (permalink / raw)
To: Christophe Leroy
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Grant Likely, Krzysztof Halasa,
devicetree, linux-doc, linux-kernel, netdev, marc.balemboy
In-Reply-To: <20140119180732.A1D99432AF@localhost.localdomain>
On Sun, 2014-01-19 at 19:07 +0100, Christophe Leroy wrote:
> Pinging this watch as we got no feedback since 22 Nov, although we have taken
> into account reviews from v1 and v2.
>
> The patch adds WAN support for Lantiq FALC56 - PEF2256 E1 Chipset.
trivia:
> diff -urN a/drivers/net/wan/pef2256.c b/drivers/net/wan/pef2256.c
[]
> +static void config_hdlc_timeslot(struct pef2256_dev_priv *priv, int ts)
> +{
> + static struct {
> + u32 ttr;
> + u32 rtr;
> + } regs[] = {
> + { TTR1, RTR1 },
> + { TTR2, RTR2 },
> + { TTR3, RTR3 },
> + { TTR4, RTR4 },
> + };
const
> + int cfg_bit = 1 << (31 - ts);
> + int reg_bit = 1 << (7 - (ts % 8));
> + int j = ts / 8;
looks endian specific
> +
> + if (j >= 4)
> + return;
> +
> + if (priv->Tx_TS & cfg_bit)
> + pef2256_s8(priv, regs[j].ttr, 1 << reg_bit);
> +
> + if (priv->Rx_TS & cfg_bit)
> + pef2256_s8(priv, regs[j].rtr, 1 << reg_bit);
> +}
> +static void init_falc(struct pef2256_dev_priv *priv)
> +{
a lot of the below looks like it should use
switch/case blocks.
> + /* Clocking rate for FALC56 */
> +
> + /* Nothing to do for clocking rate 2M */
> +
> + /* clocking rate 4M */
> + if (priv->clock_rate == CLOCK_RATE_4M)
> + pef2256_s8(priv, SIC1, SIC1_SSC0);
> +
> + /* clocking rate 8M */
> + if (priv->clock_rate == CLOCK_RATE_8M)
> + pef2256_s8(priv, SIC1, SIC1_SSC1);
> +
> + /* clocking rate 16M */
> + if (priv->clock_rate == CLOCK_RATE_16M) {
> + pef2256_s8(priv, SIC1, SIC1_SSC0);
> + pef2256_s8(priv, SIC1, SIC1_SSC1);
> + }
> +
> + /* data rate for FALC56 */
> +
> + /* Nothing to do for data rate 2M on the system data bus */
> +
> + /* data rate 4M on the system data bus */
> + if (priv->data_rate == DATA_RATE_4M)
> + pef2256_s8(priv, FMR1, FMR1_SSD0);
> +
> + /* data rate 8M on the system data bus */
> + if (priv->data_rate == DATA_RATE_8M)
> + pef2256_s8(priv, SIC1, SIC1_SSD1);
> +
> + /* data rate 16M on the system data bus */
> + if (priv->data_rate == DATA_RATE_16M) {
> + pef2256_s8(priv, FMR1, FMR1_SSD0);
> + pef2256_s8(priv, SIC1, SIC1_SSD1);
> + }
> +
> + /* channel phase for FALC56 */
> +
> + /* Nothing to do for channel phase 1 */
> +
> + if (priv->channel_phase == CHANNEL_PHASE_2)
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> +
> + if (priv->channel_phase == CHANNEL_PHASE_3)
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> +
> + if (priv->channel_phase == CHANNEL_PHASE_4) {
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> + }
> +
> + if (priv->channel_phase == CHANNEL_PHASE_5)
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> +
> + if (priv->channel_phase == CHANNEL_PHASE_6) {
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> + }
> +
> + if (priv->channel_phase == CHANNEL_PHASE_7) {
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> + }
> +
> + if (priv->channel_phase == CHANNEL_PHASE_8) {
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> + }
> +static ssize_t fs_attr_mode_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
> + long int value;
> + int ret = kstrtol(buf, 10, &value);
> + int reconfigure = (value != priv->mode);
Ugly test and set before determining if the previous
function was successful.
> + if (value != MASTER_MODE && value != SLAVE_MODE)
> + ret = -EINVAL;
> +
> + if (ret < 0)
> + netdev_info(ndev, "Invalid mode (0 or 1 expected\n");
> + else {
> + priv->mode = value;
> + if (reconfigure && netif_carrier_ok(ndev))
> + init_falc(priv);
> + }
> +
> + return strnlen(buf, count);
odd that you set ret and then don't use it.
> +static ssize_t fs_attr_Tx_TS_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
> + unsigned long value;
> + int ret = kstrtoul(buf, 16, (long int *)&value);
unportable cast
> + int reconfigure = (value != priv->mode);
again with the test/set before determining function success.
^ permalink raw reply
* [ PATCH net-next vw] qlcnic: fix sparse warnings
From: Stephen Hemminger @ 2014-01-19 19:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140118.230924.161581406065831782.davem@davemloft.net>
From: Fengguang Wu <fengguang.wu@intel.com>
Subject: [PATCH net-next] qlcnic: fix sparse warnings
Previous patch changed prototypes, but forgot functions.
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
v2 - fix indentation
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c 2014-01-18 13:41:07.000000000 -0800
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c 2014-01-19 10:55:19.207423506 -0800
@@ -2066,8 +2066,8 @@ void qlcnic_83xx_change_l2_filter(struct
qlcnic_83xx_sre_macaddr_change(adapter, mac, vlan_id, QLCNIC_MAC_ADD);
}
-void qlcnic_83xx_configure_mac(struct qlcnic_adapter *adapter, u8 *mac,
- u8 type, struct qlcnic_cmd_args *cmd)
+static void qlcnic_83xx_configure_mac(struct qlcnic_adapter *adapter, u8 *mac,
+ u8 type, struct qlcnic_cmd_args *cmd)
{
switch (type) {
case QLCNIC_SET_STATION_MAC:
@@ -2170,7 +2170,7 @@ static void qlcnic_83xx_handle_link_aen(
qlcnic_advert_link_change(adapter, link_status);
}
-irqreturn_t qlcnic_83xx_handle_aen(int irq, void *data)
+static irqreturn_t qlcnic_83xx_handle_aen(int irq, void *data)
{
struct qlcnic_adapter *adapter = data;
struct qlcnic_mailbox *mbx;
@@ -3517,7 +3517,7 @@ int qlcnic_83xx_flash_test(struct qlcnic
return 0;
}
-int qlcnic_83xx_shutdown(struct pci_dev *pdev)
+static int qlcnic_83xx_shutdown(struct pci_dev *pdev)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
struct net_device *netdev = adapter->netdev;
@@ -3892,8 +3892,8 @@ int qlcnic_83xx_init_mailbox_work(struct
return 0;
}
-pci_ers_result_t qlcnic_83xx_io_error_detected(struct pci_dev *pdev,
- pci_channel_state_t state)
+static pci_ers_result_t qlcnic_83xx_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
@@ -3914,7 +3914,7 @@ pci_ers_result_t qlcnic_83xx_io_error_de
return PCI_ERS_RESULT_NEED_RESET;
}
-pci_ers_result_t qlcnic_83xx_io_slot_reset(struct pci_dev *pdev)
+static pci_ers_result_t qlcnic_83xx_io_slot_reset(struct pci_dev *pdev)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
int err = 0;
@@ -3937,7 +3937,7 @@ disconnect:
return PCI_ERS_RESULT_DISCONNECT;
}
-void qlcnic_83xx_io_resume(struct pci_dev *pdev)
+static void qlcnic_83xx_io_resume(struct pci_dev *pdev)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
^ permalink raw reply
* [PATCH net-next] phy: cleanup 10g code
From: Stephen Hemminger @ 2014-01-19 19:48 UTC (permalink / raw)
To: Andy Fleming, David Miller; +Cc: netdev
Code should avoid needless exports, don't export something unless it used.
Make local functions static and remove unused stubs.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/phy/phy_device.c 2014-01-14 09:46:20.709651675 -0800
+++ b/drivers/net/phy/phy_device.c 2014-01-18 14:29:37.163405318 -0800
@@ -767,12 +767,6 @@ static int genphy_config_advert(struct p
return changed;
}
-int gen10g_config_advert(struct phy_device *dev)
-{
- return 0;
-}
-EXPORT_SYMBOL(gen10g_config_advert);
-
/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
* @phydev: target phy_device struct
@@ -820,12 +814,6 @@ int genphy_restart_aneg(struct phy_devic
}
EXPORT_SYMBOL(genphy_restart_aneg);
-int gen10g_restart_aneg(struct phy_device *phydev)
-{
- return 0;
-}
-EXPORT_SYMBOL(gen10g_restart_aneg);
-
/**
* genphy_config_aneg - restart auto-negotiation or write BMCR
* @phydev: target phy_device struct
@@ -867,11 +855,10 @@ int genphy_config_aneg(struct phy_device
}
EXPORT_SYMBOL(genphy_config_aneg);
-int gen10g_config_aneg(struct phy_device *phydev)
+static int gen10g_config_aneg(struct phy_device *phydev)
{
return 0;
}
-EXPORT_SYMBOL(gen10g_config_aneg);
/**
* genphy_update_link - update link status in @phydev
@@ -1004,7 +991,7 @@ int genphy_read_status(struct phy_device
}
EXPORT_SYMBOL(genphy_read_status);
-int gen10g_read_status(struct phy_device *phydev)
+static int gen10g_read_status(struct phy_device *phydev)
{
int devad, reg;
u32 mmd_mask = phydev->c45_ids.devices_in_package;
@@ -1030,7 +1017,6 @@ int gen10g_read_status(struct phy_device
return 0;
}
-EXPORT_SYMBOL(gen10g_read_status);
static int genphy_config_init(struct phy_device *phydev)
{
@@ -1102,11 +1088,10 @@ int genphy_suspend(struct phy_device *ph
}
EXPORT_SYMBOL(genphy_suspend);
-int gen10g_suspend(struct phy_device *phydev)
+static int gen10g_suspend(struct phy_device *phydev)
{
return 0;
}
-EXPORT_SYMBOL(gen10g_suspend);
int genphy_resume(struct phy_device *phydev)
{
@@ -1123,11 +1108,10 @@ int genphy_resume(struct phy_device *phy
}
EXPORT_SYMBOL(genphy_resume);
-int gen10g_resume(struct phy_device *phydev)
+static int gen10g_resume(struct phy_device *phydev)
{
return 0;
}
-EXPORT_SYMBOL(gen10g_resume);
/**
* phy_probe - probe and init a PHY device
^ permalink raw reply
* Re: US$200 Million Humanitarian Projects
From: Mr. Wllliam Billington @ 2014-01-19 17:19 UTC (permalink / raw)
To: Recipients
Good day,
This is based on blind trust hoping you can be trusted. The above sum is avaliable for worldwide Humanitarian projects and you will get 20% of the total sum for your involvement if interested.
Regards,
Mr. William Billington
^ permalink raw reply
* Re: Linux kernel patch: elide fib_validate_source() completely when possible - bad side effect?
From: gregory hoggarth @ 2014-01-19 20:49 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
In-Reply-To: <alpine.LFD.2.11.1401170953370.1827@ja.home.ssi.bg>
Hi Julian,
>>> Julian Anastasov <ja@ssi.bg> 17/1/14 09:24 PM >>>
>
> Hello,
>
> On Fri, 17 Jan 2014, gregory hoggarth wrote:
>
>> Hi,
>>
>> I work for Allied Telesis, a company that manufactures and sells routers and
>> switches.
>>
>> Earlier in the year we upgraded the linux kernel on our L3 switch firmware to
>> v3.6.2 which includes this patch. Our testers have picked up a change in
>> behaviour which I have traced back to this patch and I'd like to get comments
>> on whether this is a bug or not.
>>
>> We found that in a configuration with a device under test (DUT) that has an
>> IP address 192.168.0.1 / 24, sending an ICMP echo request with a source IP
>> address of 192.168.0.255 will now be accepted by the DUT, which will send an
>> ICMP echo reply back to the 192.168.0.255 address with a broadcast MAC
>> address of FFFF.FFFF.FFFF, meaning any other devices in the L2 domain will
>> pick up and process the ICMP reply.
>
> ...
>
>> Initially we were thinking that a device configured with 192.168.0.255 / 23
>> sending a ping to 192.168.0.1 / 24 should expect to get a reply, even
>> though this is somewhat of a misconfiguration in that the subnets aren't
>> matching and that some things may not work properly. For example ping from
>> a device with IP address 192.168.0.254 would behave correctly, so it seemed
>> correct that a ping from 192.168.0.255 should also work properly. However
>> it appears that some other part of the kernel is detecting that the echo
>> reply packet sent by the DUT has a destination IP address of the subnet
>> broadcast, so instead of sending it with a unicast MAC address it sends it
>> with the broadcast MAC address, which means all other devices on the subnet
>> would process the ICMP echo reply. This therefore makes it seem like the
>> ICMP echo request should have been dropped in the first place.
>>
>> The patch added the "if (!r && !fib_num_tclassid_users)" check to
>> fib_validate_source, which for our devices evaluates to true, hence
>> returning early and the source address check inside __fib_validate_source
>> is not carried out.
>>
>>
>> Does anyone have comments as to what the correct behaviour should be in
>> this case, and whether this is an unexpected side-effect from the patch or
>> not?
>
> It seems only __fib_validate_source can reject all kind
> of broadcast addresses in saddr. ip_route_input_slow() rejects
> only the well known broadcasts. Without rp_filter may be we
> can at least drop attempts to send replies back to broadcast
> addresses? For example, checking result of ip_route_output_key() in
> icmp_reply():
>
> if (rt->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
> => ip_rt_put()
>
> For icmp_send() in icmp_route_lookup() ?
>
> For TCP in inet_csk_route_req() ?
>
> I did not checked all places...
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
Thank you for your reply.
While I think your solution may work, isn't the proper approach to drop these
rogue packets, rather than wasting CPU and other resources processing them,
and then beginning to craft responses which are in turn dropped?
Also seems better to drop the initial rogue packet, as that should cover all
(?) different types of packets, rather than having to add small patches into
ICMP, TCP and any other places that may need it.
So my question really is was the original patch correct and there's something
wrong with our device configuration, or is this an overlooked / untested side-
effect from that patch that as a result means the patch should be re-worked?
Thanks,
Greg
^ permalink raw reply
* [PATCH net-next] ipv6: optimize link local address search
From: Hannes Frederic Sowa @ 2014-01-19 20:58 UTC (permalink / raw)
To: netdev; +Cc: brian.haley
ipv6_link_dev_addr sorts newly added addresses by scope in
ifp->addr_list. Smaller scope addresses are added to the tail of the
list. Use this fact to iterate in reverse over addr_list and break out
as soon as a higher scoped one showes up, so we can spare some cycles
on machines with lot's of addresses.
The ordering of the addresses is not relevant and we are more likely to
get the eui64 generated address with this change anyway.
Suggested-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/addrconf.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f91e107..31bdedc 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1437,7 +1437,9 @@ int __ipv6_get_lladdr(struct inet6_dev *idev, struct in6_addr *addr,
struct inet6_ifaddr *ifp;
int err = -EADDRNOTAVAIL;
- list_for_each_entry(ifp, &idev->addr_list, if_list) {
+ list_for_each_entry_reverse(ifp, &idev->addr_list, if_list) {
+ if (ifp->scope > IFA_LINK)
+ break;
if (ifp->scope == IFA_LINK &&
!(ifp->flags & banned_flags)) {
*addr = ifp->addr;
@@ -1858,7 +1860,9 @@ static int ipv6_inherit_eui64(u8 *eui, struct inet6_dev *idev)
struct inet6_ifaddr *ifp;
read_lock_bh(&idev->lock);
- list_for_each_entry(ifp, &idev->addr_list, if_list) {
+ list_for_each_entry_reverse(ifp, &idev->addr_list, if_list) {
+ if (ifp->scope > IFA_LINK)
+ break;
if (ifp->scope == IFA_LINK && !(ifp->flags&IFA_F_TENTATIVE)) {
memcpy(eui, ifp->addr.s6_addr+8, 8);
err = 0;
@@ -3239,7 +3243,9 @@ static bool ipv6_lonely_lladdr(struct inet6_ifaddr *ifp)
struct inet6_ifaddr *ifpiter;
struct inet6_dev *idev = ifp->idev;
- list_for_each_entry(ifpiter, &idev->addr_list, if_list) {
+ list_for_each_entry_reverse(ifpiter, &idev->addr_list, if_list) {
+ if (ifpiter->scope > IFA_LINK)
+ break;
if (ifp != ifpiter && ifpiter->scope == IFA_LINK &&
(ifpiter->flags & (IFA_F_PERMANENT|IFA_F_TENTATIVE|
IFA_F_OPTIMISTIC|IFA_F_DADFAILED)) ==
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH] net: gre: don't pull skb if dealing with icmp message
From: Pravin Shelar @ 2014-01-19 21:08 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, Daniel Borkmann, netdev
In-Reply-To: <52DB8E4A.7050809@cn.fujitsu.com>
On Sun, Jan 19, 2014 at 12:35 AM, Duan Jiong <duanj.fnst@cn.fujitsu.com> wrote:
>
> When dealing with icmp messages, the skb->data points the
> ip header that triggered the sending of the icmp message.
>
> In gre_cisco_err(), the parse_gre_header() is called, and the
> iptunnel_pull_header() is called to pull the skb at the end of
> the parse_gre_header(). Unfortunately, the ipgre_err still needs
> the skb->data points the ip header following the icmp layer,
> and those ip addresses in ip header will be used to look up
> tunnel by ip_tunnel_lookup().
>
This looks like bug.
Can you use ip_hdr() rather than skb->data in ipgre_err().
Same is done in ipgre_rcv().
^ permalink raw reply
* [PATCH] gss_krb5: use lcm from kernel lib
From: Luis Henriques @ 2014-01-19 21:50 UTC (permalink / raw)
To: Trond Myklebust, J. Bruce Fields, David S. Miller
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Replace hardcoded lowest common multiple algorithm by the lcm()
function in kernel lib.
Signed-off-by: Luis Henriques <luis.henriques-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
---
net/sunrpc/auth_gss/gss_krb5_keys.c | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 76e42e6..a16c5b6 100644
--- a/net/sunrpc/auth_gss/gss_krb5_keys.c
+++ b/net/sunrpc/auth_gss/gss_krb5_keys.c
@@ -59,6 +59,7 @@
#include <linux/crypto.h>
#include <linux/sunrpc/gss_krb5.h>
#include <linux/sunrpc/xdr.h>
+#include <linux/lcm.h>
#ifdef RPC_DEBUG
# define RPCDBG_FACILITY RPCDBG_AUTH
@@ -72,7 +73,7 @@
static void krb5_nfold(u32 inbits, const u8 *in,
u32 outbits, u8 *out)
{
- int a, b, c, lcm;
+ unsigned long ulcm;
int byte, i, msbit;
/* the code below is more readable if I make these bytes
@@ -82,17 +83,7 @@ static void krb5_nfold(u32 inbits, const u8 *in,
outbits >>= 3;
/* first compute lcm(n,k) */
-
- a = outbits;
- b = inbits;
-
- while (b != 0) {
- c = b;
- b = a%b;
- a = c;
- }
-
- lcm = outbits*inbits/a;
+ ulcm = lcm(inbits, outbits);
/* now do the real work */
@@ -101,7 +92,7 @@ static void krb5_nfold(u32 inbits, const u8 *in,
/* this will end up cycling through k lcm(k,n)/k times, which
is correct */
- for (i = lcm-1; i >= 0; i--) {
+ for (i = ulcm-1; i >= 0; i--) {
/* compute the msbit in k which gets added into this byte */
msbit = (
/* first, start with the msbit in the first,
--
1.8.3.2
Cheers,
--
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 related
* issues with vxlan RX checksum offload under OVS datapath
From: Or Gerlitz @ 2014-01-19 22:05 UTC (permalink / raw)
To: Pravin B Shelar, Joseph Gasparakis; +Cc: netdev
Hi Pravin,
While testing the gro udp patches over a setup with openvswitch I noted
that the RX checksum offload support introduced by Joseph's commit
0afb166 "vxlan: Add capability of Rx checksum offload for inner packet"
works fine when you use a setup made of
NIC --> IP stack --> vxlan device --> bridge --> tap
but not when its
NIC --> IP stack --> ovs vxlan port --> OVS DP --> tap
I narrowed it down to the fact the when going the OVS
pathskb->encapsulation remains true also after the decap is done.
Basically, this is the original hunk
> @@ -607,7 +607,17 @@ static int vxlan_udp_encap_recv(struct sock *sk,
> struct sk_buff *skb)
>
> __skb_tunnel_rx(skb, vxlan->dev);
> skb_reset_network_header(skb);
> - skb->ip_summed = CHECKSUM_NONE;
> +
> + /* If the NIC driver gave us an encapsulated packet with
> + * CHECKSUM_UNNECESSARY and Rx checksum feature is enabled,
> + * leave the CHECKSUM_UNNECESSARY, the device checksummed it
> + * for us. Otherwise force the upper layers to verify it.
> + */
> + if (skb->ip_summed != CHECKSUM_UNNECESSARY ||
> !skb->encapsulation ||
> + !(vxlan->dev->features & NETIF_F_RXCSUM))
> + skb->ip_summed = CHECKSUM_NONE;
> +
> + skb->encapsulation = 0;
which was moved by your commits
5cfccc5 vxlan: Add vxlan recv demux.
7ce0475 vxlan: Restructure vxlan receive.
to a code which isn't shared by the vxlan driver and ovs vxlan datapath
code, and I was thinking lets just move it back to vxlan_udp_encap_recv.
However, we can't really make the "vxlan->dev->features &
NETIF_F_RXCSUM" check - since there's no vxlan device for ovs datapath,
any idea how to overcome this.
Moving this to shared code (while removing the check for
vxlan->dev->features) made things to work on my setup, but this misses
one of the original conditions, ideas?
I believe its too late for 3.13 unless there is going to be -rc9, but
lets first see what's the right fix.
Or.
^ permalink raw reply
* [PATCH net-next] sctp: fix missing SCTP mailing list address update
From: Jean Sacren @ 2014-01-19 22:24 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman; +Cc: linux-sctp, netdev, Daniel Borkmann
The commit 91705c61b5202 ("net: sctp: trivial: update mailing list
address") updated almost all the SCTP mailing list address from
"lksctp-developers@lists.sourceforge.net"
to
"linux-sctp@vger.kernel.org"
except for the one in include/linux/sctp.h file. Fix this way trivial
one so that all is updated.
Signed-off-by: Jean Sacren <sakiwit@gmail.com>
Cc: Daniel Borkmann <dborkman@redhat.com>
---
include/linux/sctp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index c4c5eba26d9f..a9414fd49dc6 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -28,7 +28,7 @@
*
* Please send any bug reports or fixes you make to the
* email address(es):
- * lksctp developers <lksctp-developerst@lists.sourceforge.net>
+ * lksctp developers <linux-sctp@vger.kernel.org>
*
* Or submit a bug report through the following website:
* http://www.sf.net/projects/lksctp
^ permalink raw reply related
* Re: [PATCH net-next] sctp: fix missing SCTP mailing list address update
From: Daniel Borkmann @ 2014-01-19 22:44 UTC (permalink / raw)
To: Jean Sacren; +Cc: Vlad Yasevich, Neil Horman, linux-sctp, netdev
In-Reply-To: <1390170293-15851-1-git-send-email-sakiwit@gmail.com>
On 01/19/2014 11:24 PM, Jean Sacren wrote:
> The commit 91705c61b5202 ("net: sctp: trivial: update mailing list
> address") updated almost all the SCTP mailing list address from
>
> "lksctp-developers@lists.sourceforge.net"
> to
> "linux-sctp@vger.kernel.org"
>
> except for the one in include/linux/sctp.h file. Fix this way trivial
> one so that all is updated.
>
> Signed-off-by: Jean Sacren <sakiwit@gmail.com>
> Cc: Daniel Borkmann <dborkman@redhat.com>
Absolutely, thanks!
Acked-by: Daniel Borkmann <dborkman@redhat.com>
^ permalink raw reply
* Re: [PATCH] rtlwifi: Add firmware for r8723au
From: Ben Hutchings @ 2014-01-19 23:35 UTC (permalink / raw)
To: Larry Finger; +Cc: dwmw2, linux-wireless, netdev
In-Reply-To: <1388709729-28496-1-git-send-email-Larry.Finger@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
On Thu, 2014-01-02 at 18:42 -0600, Larry Finger wrote:
> This firmware is for a driver that will soon be submitted to the kernel.
> It occurs as data statements in Realtek driver rtl8723A_WiFi_linux_v4.1.3_6044.20121224.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> WHENCE | 13 +++++++++++++
> rtlwifi/rtl8723aufw_A.bin | Bin 0 -> 22172 bytes
> rtlwifi/rtl8723aufw_B.bin | Bin 0 -> 24118 bytes
> rtlwifi/rtl8723aufw_B_NoBT.bin | Bin 0 -> 19200 bytes
> 4 files changed, 13 insertions(+)
> create mode 100644 rtlwifi/rtl8723aufw_A.bin
> create mode 100644 rtlwifi/rtl8723aufw_B.bin
> create mode 100644 rtlwifi/rtl8723aufw_B_NoBT.bin
[...]
Applied, thanks.
Ben.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: ping [PATCH v3] WAN: Adding support for Lantiq PEF2256 E1 chipset (FALC56)
From: Rob Landley @ 2014-01-20 0:50 UTC (permalink / raw)
To: Joe Perches, Christophe Leroy
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Grant Likely, Krzysztof Halasa,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, marc.balemboy-GgN8y9CXRhA
In-Reply-To: <1390160095.2290.9.camel@joe-AO722>
On 01/19/14 13:34, Joe Perches wrote:
> On Sun, 2014-01-19 at 19:07 +0100, Christophe Leroy wrote:
>> Pinging this watch as we got no feedback since 22 Nov, although we have taken
>> into account reviews from v1 and v2.
>>
>> The patch adds WAN support for Lantiq FALC56 - PEF2256 E1 Chipset.
...
>> +static ssize_t fs_attr_Tx_TS_store(struct device *dev,
>> + struct device_attribute *attr, const char *buf,
>> + size_t count)
>> +{
>> + struct net_device *ndev = dev_get_drvdata(dev);
>> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
>> + unsigned long value;
>> + int ret = kstrtoul(buf, 16, (long int *)&value);
>
> unportable cast
How is that not portable? It's long == pointer on Linux, which supports
LP64 on all targets. (As do BSD, MacOSX, android, and iOS.)
http://www.unix.org/whitepapers/64bit.html
http://www.unix.org/version2/whatsnew/lp64_wp.html
Do you mean it's not portable to Windows?
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
Rob
--
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: [PATCH V4 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: David Miller @ 2014-01-20 1:12 UTC (permalink / raw)
To: florent.fourcot; +Cc: netdev
In-Reply-To: <1389975305-12477-1-git-send-email-florent.fourcot@enst-bretagne.fr>
From: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Date: Fri, 17 Jan 2014 17:15:03 +0100
> With this option, the socket will reply with the flow label value read
> on received packets.
>
> The goal is to have a connection with the same flow label in both
> direction of the communication.
>
> Changelog of V4:
> * Do not erase the flow label on the listening socket. Use pktopts to
> store the received value
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Applied.
^ permalink raw reply
* Re: [PATCH V4 net-next 2/3] ipv6: add a flag to get the flow label used remotly
From: David Miller @ 2014-01-20 1:12 UTC (permalink / raw)
To: florent.fourcot; +Cc: netdev
In-Reply-To: <1389975305-12477-2-git-send-email-florent.fourcot@enst-bretagne.fr>
From: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Date: Fri, 17 Jan 2014 17:15:04 +0100
> This information is already available via IPV6_FLOWINFO
> of IPV6_2292PKTOPTIONS, and them a filtering to get the flow label
> information. But it is probably logical and easier for users to add this
> here, and to control both sent/received flow label values with the
> IPV6_FLOWLABEL_MGR option.
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Applied.
^ permalink raw reply
* Re: [PATCH v4 net-next 3/3] ipv6: add flowlabel_consistency sysctl
From: David Miller @ 2014-01-20 1:13 UTC (permalink / raw)
To: florent.fourcot; +Cc: netdev
In-Reply-To: <1389975305-12477-3-git-send-email-florent.fourcot@enst-bretagne.fr>
From: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Date: Fri, 17 Jan 2014 17:15:05 +0100
> With the introduction of IPV6_FL_F_REFLECT, there is no guarantee of
> flow label unicity. This patch introduces a new sysctl to protect the old
> behaviour, enable by default.
>
> Changelog of V3:
> * rename ip6_flowlabel_consistency to flowlabel_consistency
> * use net_info_ratelimited()
> * checkpatch cleanups
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sch_netem: replace magic numbers with enumerate
From: David Miller @ 2014-01-20 1:17 UTC (permalink / raw)
To: yangyingliang; +Cc: netdev, stephen
In-Reply-To: <1390040011-13296-1-git-send-email-yangyingliang@huawei.com>
From: Yang Yingliang <yangyingliang@huawei.com>
Date: Sat, 18 Jan 2014 18:13:31 +0800
> Replace some magic numbers which describe states of 4-state model
> loss generator with enumerate.
>
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: gre: don't pull skb if dealing with icmp message
From: Duan Jiong @ 2014-01-20 1:37 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David Miller, Daniel Borkmann, netdev
In-Reply-To: <CALnjE+qtB4fEw4HdUZy6nXU6gSAjeSCiBn0EaQR9o_d2SY3yNQ@mail.gmail.com>
于 2014年01月20日 05:08, Pravin Shelar 写道:
> On Sun, Jan 19, 2014 at 12:35 AM, Duan Jiong <duanj.fnst@cn.fujitsu.com> wrote:
>>
>> When dealing with icmp messages, the skb->data points the
>> ip header that triggered the sending of the icmp message.
>>
>> In gre_cisco_err(), the parse_gre_header() is called, and the
>> iptunnel_pull_header() is called to pull the skb at the end of
>> the parse_gre_header(). Unfortunately, the ipgre_err still needs
>> the skb->data points the ip header following the icmp layer,
>> and those ip addresses in ip header will be used to look up
>> tunnel by ip_tunnel_lookup().
>>
> This looks like bug.
> Can you use ip_hdr() rather than skb->data in ipgre_err().
> Same is done in ipgre_rcv().
That's maybe not a good idea. The ip_hdr() will the return the outmost
ip header, but we need inner ip header following the icmp layer.
Thanks,
Duan
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] ipcomp: Convert struct xt_ipcomp spis into 16bits
From: Fan Du @ 2014-01-20 1:55 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: steffen.klassert, davem, netdev, netfilter-devel
In-Reply-To: <20140118122437.GA4309@localhost>
On 2014年01月18日 20:24, Pablo Neira Ayuso wrote:
> On Sat, Jan 18, 2014 at 10:16:14AM +0800, Fan Du wrote:
>> > sparse warnings: (new ones prefixed by>>)
>> >
>>>>>> > >> >> net/netfilter/xt_ipcomp.c:63:26: sparse: restricted __be16 degrades to integer
>>>>>> > >> >> net/netfilter/xt_ipcomp.c:63:26: sparse: cast to restricted __be32
>> >
>> > Fix this by using 16bits long spi, as IPcomp CPI is only valid for 16bits.
>> >
>> > Signed-off-by: Fan Du<fan.du@windriver.com>
>> > ---
>> > include/uapi/linux/netfilter/xt_ipcomp.h | 2 +-
>> > net/netfilter/xt_ipcomp.c | 4 ++--
>> > 2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/include/uapi/linux/netfilter/xt_ipcomp.h b/include/uapi/linux/netfilter/xt_ipcomp.h
>> > index 45c7e40..ca82ebb 100644
>> > --- a/include/uapi/linux/netfilter/xt_ipcomp.h
>> > +++ b/include/uapi/linux/netfilter/xt_ipcomp.h
>> > @@ -4,7 +4,7 @@
>> > #include<linux/types.h>
>> >
>> > struct xt_ipcomp {
>> > - __u32 spis[2]; /* Security Parameter Index */
>> > + __u16 spis[2]; /* Security Parameter Index */
> This changes the binary interface so it break userspace (iptables
> needs to be recompiled), we're still in time to make such change as
> this is net-next stuff, but what I understand from the patch
> description is that this aims to fix a sparse warning, which is a bit
> of intrusive change.
>
> Didn't you find any way to fix this without change the layout of
> xt_ipcomp?
>
My bad for not catching this in the initial ipcomp version.
It would be easier to just use ntohs here to ease sparse checking.
From dbf796e63d600256fd40000669b83227ddccebc4 Mon Sep 17 00:00:00 2001
From: Fan Du <fan.du@windriver.com>
Date: Mon, 20 Jan 2014 09:42:12 +0800
Subject: [PATCHv2 net-next] ipcomp: Use ntohs to ease sparse warning
0-DAY kernel build testing backend reported:
sparse warnings: (new ones prefixed by >>)
>> >> net/netfilter/xt_ipcomp.c:63:26: sparse: restricted __be16 degrades to integer
>> >> net/netfilter/xt_ipcomp.c:63:26: sparse: cast to restricted __be32
Fix this by using ntohs without shifting.
Tested with: make C=1 CF=-D__CHECK_ENDIAN__
Signed-off-by: Fan Du <fan.du@windriver.com>
---
net/netfilter/xt_ipcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/xt_ipcomp.c b/net/netfilter/xt_ipcomp.c
index a4c7561..89d5310 100644
--- a/net/netfilter/xt_ipcomp.c
+++ b/net/netfilter/xt_ipcomp.c
@@ -60,7 +60,7 @@ static bool comp_mt(const struct sk_buff *skb, struct xt_action_param *par)
}
return spi_match(compinfo->spis[0], compinfo->spis[1],
- ntohl(chdr->cpi << 16),
+ ntohs(chdr->cpi),
!!(compinfo->invflags & XT_IPCOMP_INV_SPI));
}
--
1.7.9.5
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply related
* Re: [Xen-devel] [PATCH net-next v2] xen-netfront: clean up code in xennet_release_rx_bufs
From: annie li @ 2014-01-20 2:33 UTC (permalink / raw)
To: David Vrabel
Cc: Wei Liu, ian.campbell, netdev, xen-devel, andrew.bennieston,
davem
In-Reply-To: <52D96D73.1030803@citrix.com>
On 2014/1/18 1:50, David Vrabel wrote:
> On 17/01/14 15:43, annie li wrote:
>> No, I am trying to implement 2 patches.
> I don't understand the need for two patches here, particularly when
> the first patch introduces a security issue.
This is basically connected with personal taste. I am thinking that my
original patch is removing unnecessary code for grant transfer and then
keep rx release consistent with tx path, the security issue you
mentioned exist in current tx too. The second one is to change
gnttab_end_foreign_access and netfront tx/rx, blkfront, etc. But if you
like to merge them together, I can do that.
Thanks
Annie
> You can fold the following
> (untested) patch into your v2 patch and give it a try?
>
> Thanks.
>
> David
>
> 8<----------------------
> xen-netfront: prevent unsafe reuse of rx buf pages after uninit
>
> ---
> drivers/net/xen-netfront.c | 21 +++++++++++++++++----
> 1 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 692589e..47aa599 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1134,19 +1134,32 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
>
> static void xennet_release_rx_bufs(struct netfront_info *np)
> {
> - struct sk_buff *skb;
> int id, ref;
>
> spin_lock_bh(&np->rx_lock);
>
> for (id = 0; id < NET_RX_RING_SIZE; id++) {
> + struct sk_buff *skb;
> + skb_frag_t *frag;
> + const struct page *page;
> +
> + skb = np->rx_skbs[id];
> + if (!skb)
> + continue;
> +
> ref = np->grant_rx_ref[id];
> if (ref == GRANT_INVALID_REF)
> continue;
>
> - skb = np->rx_skbs[id];
> - gnttab_end_foreign_access_ref(ref, 0);
> - gnttab_release_grant_reference(&np->gref_rx_head, ref);
> + frag = &skb_shinfo(skb)->frags[0];
> + page = skb_frag_page(frag);
> +
> + /* gnttab_end_foreign_access() needs a page ref until
> + * foreign access is ended (which may be deferred).
> + */
> + get_page(page);
> +
> + gnttab_end_foreign_access(ref, 0, page);
> np->grant_rx_ref[id] = GRANT_INVALID_REF;
>
> kfree_skb(skb);
^ permalink raw reply
* [PATCH net-next] ipv6: make IPV6_RECVPKTINFO work for ipv4 datagrams
From: Hannes Frederic Sowa @ 2014-01-20 2:43 UTC (permalink / raw)
To: netdev; +Cc: gert
We currently don't report IPV6_RECVPKTINFO in cmsg access ancillary data
for IPv4 datagrams on IPv6 sockets.
This patch splits the ip6_datagram_recv_ctl into two functions, one
which handles both protocol families, AF_INET and AF_INET6, while the
ip6_datagram_recv_specific_ctl only handles IPv6 cmsg data.
ip6_datagram_recv_*_ctl never reported back any errors, so we can make
them return void. Also provide a helper for protocols which don't offer dual
personality to further use ip6_datagram_recv_ctl, which is exported to
modules.
I needed to shuffle the code for ping around a bit to make it easier to
implement dual personality for ping ipv6 sockets in future.
Reported-by: Gert Doering <gert@space.net>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/ipv6.h | 3 +++
include/net/ip.h | 1 +
include/net/ping.h | 8 ++++++--
include/net/transp_v6.h | 9 +++++++--
net/ipv4/ip_sockglue.c | 6 +++---
net/ipv4/ping.c | 7 ++++++-
net/ipv6/datagram.c | 38 ++++++++++++++++++++++++++++++--------
net/ipv6/ipv6_sockglue.c | 4 +---
net/ipv6/ping.c | 10 ++++++----
net/ipv6/udp.c | 6 +++++-
10 files changed, 68 insertions(+), 24 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 7e1ded0..ea81e7a 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -283,6 +283,8 @@ static inline void inet_sk_copy_descendant(struct sock *sk_to,
#define __ipv6_only_sock(sk) (inet6_sk(sk)->ipv6only)
#define ipv6_only_sock(sk) ((sk)->sk_family == PF_INET6 && __ipv6_only_sock(sk))
+#define ipv6_sk_rxinfo(sk) ((sk)->sk_family == PF_INET6 && \
+ inet6_sk(sk)->rxopt.bits.rxinfo)
static inline const struct in6_addr *inet6_rcv_saddr(const struct sock *sk)
{
@@ -299,6 +301,7 @@ static inline int inet_v6_ipv6only(const struct sock *sk)
#else
#define __ipv6_only_sock(sk) 0
#define ipv6_only_sock(sk) 0
+#define ipv6_sk_rxinfo(sk) 0
static inline struct ipv6_pinfo * inet6_sk(const struct sock *__sk)
{
diff --git a/include/net/ip.h b/include/net/ip.h
index 7876e3b..23be0fd 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -63,6 +63,7 @@ struct ipcm_cookie {
};
#define IPCB(skb) ((struct inet_skb_parm*)((skb)->cb))
+#define PKTINFO_SKB_CB(skb) ((struct in_pktinfo *)((skb)->cb))
struct ip_ra_chain {
struct ip_ra_chain __rcu *next;
diff --git a/include/net/ping.h b/include/net/ping.h
index 7601365..026479b 100644
--- a/include/net/ping.h
+++ b/include/net/ping.h
@@ -33,8 +33,12 @@
struct pingv6_ops {
int (*ipv6_recv_error)(struct sock *sk, struct msghdr *msg, int len,
int *addr_len);
- int (*ip6_datagram_recv_ctl)(struct sock *sk, struct msghdr *msg,
- struct sk_buff *skb);
+ void (*ip6_datagram_recv_common_ctl)(struct sock *sk,
+ struct msghdr *msg,
+ struct sk_buff *skb);
+ void (*ip6_datagram_recv_specific_ctl)(struct sock *sk,
+ struct msghdr *msg,
+ struct sk_buff *skb);
int (*icmpv6_err_convert)(u8 type, u8 code, int *err);
void (*ipv6_icmp_error)(struct sock *sk, struct sk_buff *skb, int err,
__be16 port, u32 info, u8 *payload);
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index 48660e5..b927413 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -32,8 +32,13 @@ void tcpv6_exit(void);
int udpv6_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len);
-int ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
- struct sk_buff *skb);
+/* this does all the common and the specific ctl work */
+void ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
+ struct sk_buff *skb);
+void ip6_datagram_recv_common_ctl(struct sock *sk, struct msghdr *msg,
+ struct sk_buff *skb);
+void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
+ struct sk_buff *skb);
int ip6_datagram_send_ctl(struct net *net, struct sock *sk, struct msghdr *msg,
struct flowi6 *fl6, struct ipv6_txoptions *opt,
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 22f15eb..580dd96 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -56,7 +56,6 @@
/*
* SOL_IP control messages.
*/
-#define PKTINFO_SKB_CB(__skb) ((struct in_pktinfo *)((__skb)->cb))
static void ip_cmsg_recv_pktinfo(struct msghdr *msg, struct sk_buff *skb)
{
@@ -1055,9 +1054,10 @@ e_inval:
void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
{
struct in_pktinfo *pktinfo = PKTINFO_SKB_CB(skb);
+ bool prepare = (inet_sk(sk)->cmsg_flags & IP_CMSG_PKTINFO) ||
+ ipv6_sk_rxinfo(sk);
- if ((inet_sk(sk)->cmsg_flags & IP_CMSG_PKTINFO) &&
- skb_rtable(skb)) {
+ if (prepare && skb_rtable(skb)) {
pktinfo->ipi_ifindex = inet_iif(skb);
pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb);
} else {
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index e09e883..4a9e426 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -906,7 +906,12 @@ int ping_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
}
if (inet6_sk(sk)->rxopt.all)
- pingv6_ops.ip6_datagram_recv_ctl(sk, msg, skb);
+ pingv6_ops.ip6_datagram_recv_common_ctl(sk, msg, skb);
+ if (skb->protocol == htons(ETH_P_IPV6) &&
+ inet6_sk(sk)->rxopt.all)
+ pingv6_ops.ip6_datagram_recv_specific_ctl(sk, msg, skb);
+ else if (skb->protocol == htons(ETH_P_IP) && isk->cmsg_flags)
+ ip_cmsg_recv(msg, skb);
#endif
} else {
BUG();
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index bce73cb..cd8699b 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -377,10 +377,12 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
sin->sin6_family = AF_INET6;
sin->sin6_flowinfo = 0;
sin->sin6_port = 0;
+ if (np->rxopt.all)
+ ip6_datagram_recv_common_ctl(sk, msg, skb);
if (skb->protocol == htons(ETH_P_IPV6)) {
sin->sin6_addr = ipv6_hdr(skb)->saddr;
if (np->rxopt.all)
- ip6_datagram_recv_ctl(sk, msg, skb);
+ ip6_datagram_recv_specific_ctl(sk, msg, skb);
sin->sin6_scope_id =
ipv6_iface_scope_id(&sin->sin6_addr,
IP6CB(skb)->iif);
@@ -471,20 +473,34 @@ out:
}
-int ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
- struct sk_buff *skb)
+void ip6_datagram_recv_common_ctl(struct sock *sk, struct msghdr *msg,
+ struct sk_buff *skb)
{
struct ipv6_pinfo *np = inet6_sk(sk);
- struct inet6_skb_parm *opt = IP6CB(skb);
- unsigned char *nh = skb_network_header(skb);
+ bool is_ipv6 = skb->protocol == htons(ETH_P_IPV6);
if (np->rxopt.bits.rxinfo) {
struct in6_pktinfo src_info;
- src_info.ipi6_ifindex = opt->iif;
- src_info.ipi6_addr = ipv6_hdr(skb)->daddr;
+ if (is_ipv6) {
+ src_info.ipi6_ifindex = IP6CB(skb)->iif;
+ src_info.ipi6_addr = ipv6_hdr(skb)->daddr;
+ } else {
+ src_info.ipi6_ifindex =
+ PKTINFO_SKB_CB(skb)->ipi_ifindex;
+ ipv6_addr_set_v4mapped(ip_hdr(skb)->daddr,
+ &src_info.ipi6_addr);
+ }
put_cmsg(msg, SOL_IPV6, IPV6_PKTINFO, sizeof(src_info), &src_info);
}
+}
+
+void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
+ struct sk_buff *skb)
+{
+ struct ipv6_pinfo *np = inet6_sk(sk);
+ struct inet6_skb_parm *opt = IP6CB(skb);
+ unsigned char *nh = skb_network_header(skb);
if (np->rxopt.bits.rxhlim) {
int hlim = ipv6_hdr(skb)->hop_limit;
@@ -602,7 +618,13 @@ int ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
put_cmsg(msg, SOL_IPV6, IPV6_ORIGDSTADDR, sizeof(sin6), &sin6);
}
}
- return 0;
+}
+
+void ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
+ struct sk_buff *skb)
+{
+ ip6_datagram_recv_common_ctl(sk, msg, skb);
+ ip6_datagram_recv_specific_ctl(sk, msg, skb);
}
EXPORT_SYMBOL_GPL(ip6_datagram_recv_ctl);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 2855b00..663b731 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1002,10 +1002,8 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
release_sock(sk);
if (skb) {
- int err = ip6_datagram_recv_ctl(sk, &msg, skb);
+ ip6_datagram_recv_ctl(sk, &msg, skb);
kfree_skb(skb);
- if (err)
- return err;
} else {
if (np->rxopt.bits.rxinfo) {
struct in6_pktinfo src_info;
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index cd71f3a..94a3d04 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -62,10 +62,9 @@ static int dummy_ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len,
{
return -EAFNOSUPPORT;
}
-static int dummy_ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
+static void dummy_ip6_datagram_recv_ctl(struct sock *sk, struct msghdr *msg,
struct sk_buff *skb)
{
- return -EAFNOSUPPORT;
}
static int dummy_icmpv6_err_convert(u8 type, u8 code, int *err)
{
@@ -254,7 +253,9 @@ int __init pingv6_init(void)
return ret;
#endif
pingv6_ops.ipv6_recv_error = ipv6_recv_error;
- pingv6_ops.ip6_datagram_recv_ctl = ip6_datagram_recv_ctl;
+ pingv6_ops.ip6_datagram_recv_common_ctl = ip6_datagram_recv_common_ctl;
+ pingv6_ops.ip6_datagram_recv_specific_ctl =
+ ip6_datagram_recv_specific_ctl;
pingv6_ops.icmpv6_err_convert = icmpv6_err_convert;
pingv6_ops.ipv6_icmp_error = ipv6_icmp_error;
pingv6_ops.ipv6_chk_addr = ipv6_chk_addr;
@@ -267,7 +268,8 @@ int __init pingv6_init(void)
void pingv6_exit(void)
{
pingv6_ops.ipv6_recv_error = dummy_ipv6_recv_error;
- pingv6_ops.ip6_datagram_recv_ctl = dummy_ip6_datagram_recv_ctl;
+ pingv6_ops.ip6_datagram_recv_common_ctl = dummy_ip6_datagram_recv_ctl;
+ pingv6_ops.ip6_datagram_recv_specific_ctl = dummy_ip6_datagram_recv_ctl;
pingv6_ops.icmpv6_err_convert = dummy_icmpv6_err_convert;
pingv6_ops.ipv6_icmp_error = dummy_ipv6_icmp_error;
pingv6_ops.ipv6_chk_addr = dummy_ipv6_chk_addr;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 233c3ab..1e586d9 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -477,12 +477,16 @@ try_again:
}
*addr_len = sizeof(*sin6);
}
+
+ if (np->rxopt.all)
+ ip6_datagram_recv_common_ctl(sk, msg, skb);
+
if (is_udp4) {
if (inet->cmsg_flags)
ip_cmsg_recv(msg, skb);
} else {
if (np->rxopt.all)
- ip6_datagram_recv_ctl(sk, msg, skb);
+ ip6_datagram_recv_specific_ctl(sk, msg, skb);
}
err = copied;
--
1.8.4.2
^ permalink raw reply related
* Re: ipv4_dst_destroy panic regression after 3.10.15
From: dormando @ 2014-01-20 2:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel
In-Reply-To: <1390027758.31367.505.camel@edumazet-glaptop2.roam.corp.google.com>
> On Fri, 2014-01-17 at 17:25 -0800, dormando wrote:
> > Hi,
> >
> > Upgraded a few kernels to the latest 3.10 stable tree while tracking down
> > a rare kernel panic, seems to have introduced a much more frequent kernel
> > panic. Takes anywhere from 4 hours to 2 days to trigger:
> >
> > <4>[196727.311203] general protection fault: 0000 [#1] SMP
> > <4>[196727.311224] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode ipmi_watchdog ipmi_devintf sb_edac edac_core lpc_ich mfd_core tpm_tis tpm tpm_bios ipmi_si ipmi_msghandler isci igb libsas i2c_algo_bit ixgbe ptp pps_core mdio
> > <4>[196727.311333] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 3.10.26 #1
> > <4>[196727.311344] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
> > <4>[196727.311364] task: ffff885e6f069700 ti: ffff885e6f072000 task.ti: ffff885e6f072000
> > <4>[196727.311377] RIP: 0010:[<ffffffff815f8c7f>] [<ffffffff815f8c7f>] ipv4_dst_destroy+0x4f/0x80
> > <4>[196727.311399] RSP: 0018:ffff885effd23a70 EFLAGS: 00010282
> > <4>[196727.311409] RAX: dead000000200200 RBX: ffff8854c398ecc0 RCX: 0000000000000040
> > <4>[196727.311423] RDX: dead000000100100 RSI: dead000000100100 RDI: dead000000200200
> > <4>[196727.311437] RBP: ffff885effd23a80 R08: ffffffff815fd9e0 R09: ffff885d5a590800
> > <4>[196727.311451] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > <4>[196727.311464] R13: ffffffff81c8c280 R14: 0000000000000000 R15: ffff880e85ee16ce
> > <4>[196727.311510] FS: 0000000000000000(0000) GS:ffff885effd20000(0000) knlGS:0000000000000000
> > <4>[196727.311554] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > <4>[196727.311581] CR2: 00007a46751eb000 CR3: 0000005e65688000 CR4: 00000000000407e0
> > <4>[196727.311625] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > <4>[196727.311669] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > <4>[196727.311713] Stack:
> > <4>[196727.311733] ffff8854c398ecc0 ffff8854c398ecc0 ffff885effd23ab0 ffffffff815b7f42
> > <4>[196727.311784] ffff88be6595bc00 ffff8854c398ecc0 0000000000000000 ffff8854c398ecc0
> > <4>[196727.311834] ffff885effd23ad0 ffffffff815b86c6 ffff885d5a590800 ffff8816827821c0
> > <4>[196727.311885] Call Trace:
> > <4>[196727.311907] <IRQ>
> > <4>[196727.311912] [<ffffffff815b7f42>] dst_destroy+0x32/0xe0
> > <4>[196727.311959] [<ffffffff815b86c6>] dst_release+0x56/0x80
> > <4>[196727.311986] [<ffffffff81620bd5>] tcp_v4_do_rcv+0x2a5/0x4a0
> > <4>[196727.312013] [<ffffffff81622b5a>] tcp_v4_rcv+0x7da/0x820
> > <4>[196727.312041] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
> > <4>[196727.312070] [<ffffffff815de02d>] ? nf_hook_slow+0x7d/0x150
> > <4>[196727.312097] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
> > <4>[196727.312125] [<ffffffff815fda92>] ip_local_deliver_finish+0xb2/0x230
> > <4>[196727.312154] [<ffffffff815fdd9a>] ip_local_deliver+0x4a/0x90
> > <4>[196727.312183] [<ffffffff815fd799>] ip_rcv_finish+0x119/0x360
> > <4>[196727.312212] [<ffffffff815fe00b>] ip_rcv+0x22b/0x340
> > <4>[196727.312242] [<ffffffffa0339680>] ? macvlan_broadcast+0x160/0x160 [macvlan]
> > <4>[196727.312275] [<ffffffff815b0c62>] __netif_receive_skb_core+0x512/0x640
> > <4>[196727.312308] [<ffffffff811427fb>] ? kmem_cache_alloc+0x13b/0x150
> > <4>[196727.312338] [<ffffffff815b0db1>] __netif_receive_skb+0x21/0x70
> > <4>[196727.312368] [<ffffffff815b0fa1>] netif_receive_skb+0x31/0xa0
> > <4>[196727.312397] [<ffffffff815b1ae8>] napi_gro_receive+0xe8/0x140
> > <4>[196727.312433] [<ffffffffa00274f1>] ixgbe_poll+0x551/0x11f0 [ixgbe]
> > <4>[196727.312463] [<ffffffff815fe00b>] ? ip_rcv+0x22b/0x340
> > <4>[196727.312491] [<ffffffff815b1691>] net_rx_action+0x111/0x210
> > <4>[196727.312521] [<ffffffff815b0db1>] ? __netif_receive_skb+0x21/0x70
> > <4>[196727.312552] [<ffffffff810519d0>] __do_softirq+0xd0/0x270
> > <4>[196727.312583] [<ffffffff816cef3c>] call_softirq+0x1c/0x30
> > <4>[196727.312613] [<ffffffff81004205>] do_softirq+0x55/0x90
> > <4>[196727.312640] [<ffffffff81051c85>] irq_exit+0x55/0x60
> > <4>[196727.312668] [<ffffffff816cf5c3>] do_IRQ+0x63/0xe0
> > <4>[196727.312696] [<ffffffff816c5aaa>] common_interrupt+0x6a/0x6a
> > <4>[196727.312722] <EOI>
> > <4>[196727.312727] [<ffffffff8100a150>] ? default_idle+0x20/0xe0
> > <4>[196727.312775] [<ffffffff8100a8ff>] arch_cpu_idle+0xf/0x20
> > <4>[196727.312803] [<ffffffff8108d330>] cpu_startup_entry+0xc0/0x270
> > <4>[196727.312833] [<ffffffff816b276e>] start_secondary+0x1f9/0x200
> > <4>[196727.312860] Code: 4a 9f e9 81 e8 13 cb 0c 00 48 8b 93 b0 00 00 00 48 bf 00 02 20 00 00 00 ad de 48 8b 83 b8 00 00 00 48 be 00 01 10 00 00 00 ad de <48> 89 42 08 48 89 10 48 89 bb b8 00 00 00 48 c7 c7 4a 9f e9 81
> > <1>[196727.313071] RIP [<ffffffff815f8c7f>] ipv4_dst_destroy+0x4f/0x80
> > <4>[196727.313100] RSP <ffff885effd23a70>
> > <4>[196727.313377] ---[ end trace 64b3f14fae0f2e29 ]---
> > <0>[196727.380908] Kernel panic - not syncing: Fatal exception in interrupt
> >
> >
> > ... bisecting it's going to be a pain... I tried eyeballing the diffs and
> > am trying a revert or two.
> >
> > We've hit it in .25, .26 so far. I have .27 running but not sure if it
> > crashed, so the change exists between .15 and .25.
>
> Please try following fix, thanks for the report !
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 25071b48921c..78a50a22298a 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1333,7 +1333,7 @@ static void ipv4_dst_destroy(struct dst_entry
> *dst)
>
> if (!list_empty(&rt->rt_uncached)) {
> spin_lock_bh(&rt_uncached_lock);
> - list_del(&rt->rt_uncached);
> + list_del_init(&rt->rt_uncached);
> spin_unlock_bh(&rt_uncached_lock);
> }
> }
This one crashed after a day and a half with a new-to-me trace. The other
machine running 3.10.27 + the reversion of the other patch is still going.
I now have two machines on that kernel to see if they're stable for more
than two days.
Panic#2 Part1
<4>[116124.368440] ------------[ cut here ]------------
<4>[116124.368450] WARNING: at net/core/dst.c:276 dst_release+0x7e/0x80()
<4>[116124.368451] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich isci ipmi_watchdog ipmi_devintf ixgbe microcode igb sb_edac edac_core libsas lpc_ich i2c_algo_bit mfd_core ptp pps_core tpm_tis mdio tpm tpm_bios ipmi_si ipmi_msghandler
<4>[116124.368470] CPU: 1 PID: 166084 Comm: cache-worker Tainted: G W 3.10.27 #1
<4>[116124.368471] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[116124.368473] ffffffff81a86f96 ffff885effc23b30 ffffffff816c045e ffff885effc23b70
<4>[116124.368475] ffffffff81049930 ffff88be64ed4000 ffff88531e227980 00000000fffffff9
<4>[116124.368477] ffffffff81c876c0 ffff8852ef21ec00 ffff882dffaaa5e2 ffff885effc23b80
<4>[116124.368479] Call Trace:
<4>[116124.368480] <IRQ> [<ffffffff816c045e>] dump_stack+0x19/0x1b
<4>[116124.368490] [<ffffffff81049930>] warn_slowpath_common+0x70/0xa0
<4>[116124.368492] [<ffffffff8104997a>] warn_slowpath_null+0x1a/0x20
<4>[116124.368494] [<ffffffff815b870e>] dst_release+0x7e/0x80
<4>[116124.368497] [<ffffffff816351f9>] inet_sock_destruct+0x129/0x1d0
<4>[116124.368500] [<ffffffff8159d4bd>] __sk_free+0x1d/0x140
<4>[116124.368502] [<ffffffff8159d675>] sk_free+0x25/0x30
<4>[116124.368506] [<ffffffff8161e3fd>] sock_put+0x1d/0x30
<4>[116124.368508] [<ffffffff81622afb>] tcp_v4_rcv+0x77b/0x820
<4>[116124.368511] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[116124.368515] [<ffffffff815de03d>] ? nf_hook_slow+0x7d/0x150
<4>[116124.368517] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[116124.368519] [<ffffffff815fda92>] ip_local_deliver_finish+0xb2/0x230
<4>[116124.368521] [<ffffffff815fdd9a>] ip_local_deliver+0x4a/0x90
<4>[116124.368523] [<ffffffff815fd799>] ip_rcv_finish+0x119/0x360
<4>[116124.368526] [<ffffffff815fe00b>] ip_rcv+0x22b/0x340
<4>[116124.368529] [<ffffffff815b0c82>] __netif_receive_skb_core+0x512/0x640
<4>[116124.368531] [<ffffffff815b0dd1>] __netif_receive_skb+0x21/0x70
<4>[116124.368533] [<ffffffff815b0ebb>] process_backlog+0x9b/0x170
<4>[116124.368535] [<ffffffff815b16b1>] net_rx_action+0x111/0x210
<4>[116124.368538] [<ffffffff810519d0>] __do_softirq+0xd0/0x270
<4>[116124.368542] [<ffffffff816cf03c>] call_softirq+0x1c/0x30
<4>[116124.368546] [<ffffffff81004215>] do_softirq+0x55/0x90
<4>[116124.368548] [<ffffffff81051c85>] irq_exit+0x55/0x60
<4>[116124.368550] [<ffffffff816cf6c3>] do_IRQ+0x63/0xe0
<4>[116124.368553] [<ffffffff816c5baa>] common_interrupt+0x6a/0x6a
<4>[116124.368554] <EOI> [<ffffffff816cde02>] ? system_call_fastpath+0x16/0x1b
<4>[116124.368558] ---[ end trace 3ed2370f32f77a53 ]---
<7>[116125.177470] Peer 88.153.144.82:50962/80 unexpectedly shrunk window 2770172661:2770430920 (repaired)
<7>[116127.452869] Peer 88.153.144.82:50962/80 unexpectedly shrunk window 2770172661:2770430920 (repaired)
<7>[116132.003660] Peer 88.153.144.82:50962/80 unexpectedly shrunk window 2770172661:2770430920 (repaired)
<4>[116133.987013] general protection fault: 0000 [#1] SMP
<4>[116133.987033] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich isci ipmi_watchdog ipmi_devintf ixgbe microcode igb sb_edac edac_core libsas lpc_ich i2c_algo_bit mfd_core ptp pps_core tpm_tis mdio tpm tpm_bios ipmi_si ipmi_msghandler
<4>[116133.987137] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G W 3.10.27 #1
<4>[116133.987150] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[116133.987168] task: ffff885e6f7edc00 ti: ffff885e6f7f4000 task.ti: ffff885e6f7f4000
<4>[116133.987182] RIP: 0010:[<ffffffff8164f120>] [<ffffffff8164f120>] iptable_raw_hook+0x20/0x70
<4>[116133.987202] RSP: 0018:ffff885effca38f0 EFLAGS: 00010246
<4>[116133.987212] RAX: ffca3aa0ffff885e RBX: ffca3aa0ffff885e RCX: ffca3aa0ffff885e
<4>[116133.987226] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff885e3b447100
<4>[116133.987240] RBP: ffff885effca38f0 R08: ffff884b3183fc00 R09: ffff885e3b447100
<4>[116133.987254] R10: ffff88be6df7be80 R11: 0000000000000013 R12: ffff885effca3990
<4>[116133.987285] R13: 0000000000000000 R14: 0000000000000003 R15: ffff885e3b447100
<4>[116133.987328] FS: 0000000000000000(0000) GS:ffff885effca0000(0000) knlGS:0000000000000000
<4>[116133.987372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[116133.987399] CR2: 00007a306991d000 CR3: 0000005e0e44f000 CR4: 00000000000407e0
<4>[116133.987441] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[116133.987484] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[116133.987526] Stack:
<4>[116133.987546] ffff885effca3950 ffffffff815ddf7f ffff885effca3910 ffffffff81cb4c90
<4>[116133.987596] ffff885effca3930 ffff885e66024f30 0000000000000020 ffff885e3b447100
<4>[116133.987645] ffffffff81600e90 0000000000000003 ffff885e3b447100 0000000000000000
<4>[116133.987695] Call Trace:
<4>[116133.987716] <IRQ>
<4>[116133.987721] [<ffffffff815ddf7f>] nf_iterate+0x8f/0xd0
<4>[116133.987770] [<ffffffff81600e90>] ? ip_forward_options+0x200/0x200
<4>[116133.987798] [<ffffffff815de03d>] nf_hook_slow+0x7d/0x150
<4>[116133.987825] [<ffffffff81600e90>] ? ip_forward_options+0x200/0x200
<4>[116133.987853] [<ffffffff81602c22>] __ip_local_out+0x72/0x80
<4>[116133.987880] [<ffffffff81602c46>] ip_local_out+0x16/0x30
<4>[116133.987906] [<ffffffff81603f39>] ip_send_skb+0x19/0x50
<4>[116133.987932] [<ffffffff81603fa7>] ip_push_pending_frames+0x37/0x40
<4>[116133.987960] [<ffffffff8160438f>] ip_send_unicast_reply+0x29f/0x2f0
<4>[116133.987989] [<ffffffff8161a5b6>] ? tcp_write_xmit+0x2b6/0xa90
<4>[116133.988019] [<ffffffff8161e2ba>] tcp_v4_send_ack+0x1ba/0x210
<4>[116133.988048] [<ffffffff816226f5>] tcp_v4_rcv+0x375/0x820
<4>[116133.988075] [<ffffffff815de03d>] ? nf_hook_slow+0x7d/0x150
<4>[116133.988103] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[116133.988131] [<ffffffff815fda92>] ip_local_deliver_finish+0xb2/0x230
<4>[116133.988159] [<ffffffff815fdd9a>] ip_local_deliver+0x4a/0x90
<4>[116133.988187] [<ffffffff815fd799>] ip_rcv_finish+0x119/0x360
<4>[116133.988214] [<ffffffff815fe00b>] ip_rcv+0x22b/0x340
<4>[116133.988242] [<ffffffff815b0c82>] __netif_receive_skb_core+0x512/0x640
<4>[116133.988272] [<ffffffff81079b00>] ? resched_task+0x60/0x70
<4>[116133.988299] [<ffffffff815b0dd1>] __netif_receive_skb+0x21/0x70
<4>[116133.988326] [<ffffffff815b0ebb>] process_backlog+0x9b/0x170
<4>[116133.988354] [<ffffffff8107a1a6>] ? ttwu_do_activate.constprop.91+0x66/0x70
<4>[116133.988384] [<ffffffff815b16b1>] net_rx_action+0x111/0x210
<4>[116133.988412] [<ffffffff810519d0>] __do_softirq+0xd0/0x270
<4>[116133.988441] [<ffffffff816cf03c>] call_softirq+0x1c/0x30
<4>[116133.988470] [<ffffffff81004215>] do_softirq+0x55/0x90
<4>[116133.988495] [<ffffffff81051c85>] irq_exit+0x55/0x60
<4>[116133.988521] [<ffffffff816cf6c3>] do_IRQ+0x63/0xe0
<4>[116133.988548] [<ffffffff816c5baa>] common_interrupt+0x6a/0x6a
<4>[116133.988574] <EOI>
<4>[116133.988578] [<ffffffff8100a160>] ? default_idle+0x20/0xe0
<4>[116133.988624] [<ffffffff8100a90f>] arch_cpu_idle+0xf/0x20
<4>[116133.988652] [<ffffffff8108d330>] cpu_startup_entry+0xc0/0x270
<4>[116133.988681] [<ffffffff816b288e>] start_secondary+0x1f9/0x200
<4>[116133.988708] Code: eb f2 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 83 ff 03 49 89 f1 48 89 e5 74 27 48 85 d2 48 89 d0 89 fe 48 0f 44 c1 4c 89 cf <48> 8b 80 e8 03 00 00 4c 8b 80 50 03 00 00 e8 6d d8 ff ff 5d c3
<1>[116133.988905] RIP [<ffffffff8164f120>] iptable_raw_hook+0x20/0x70
<4>[116133.988934] RSP <ffff885effca38f0>
<4>[116133.989217] ---[ end trace 3ed2370f32f77a54 ]---
<0>[116134.851050] Kernel panic - not syncing: Fatal exception in interrupt
^ 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