* [PATCH net-next] tg3: Add Macronix NVRAM support
From: Satish Baddipadige @ 2018-01-03 5:15 UTC (permalink / raw)
To: davem
Cc: netdev, michael.chan, prashant, siva.kallam, Prashant Sreedharan,
Satish Baddipadige
From: Prashant Sreedharan <prashant.sreedharan@broadcom.com>
This patch adds the support for Macronix NVRAM
Signed-off-by: Prashant Sreedharan <prashant.sreedharan@broadcom.com>
Signed-off-by: Satish Baddipadige <satish.baddipadige@broadcom.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 21 +++++++++++++++++++--
drivers/net/ethernet/broadcom/tg3.h | 14 ++++++++++++--
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index d09c5a9..93b23f7 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3225,7 +3225,7 @@ static int tg3_nvram_read_using_eeprom(struct tg3 *tp,
return 0;
}
-#define NVRAM_CMD_TIMEOUT 5000
+#define NVRAM_CMD_TIMEOUT 10000
static int tg3_nvram_exec_cmd(struct tg3 *tp, u32 nvram_cmd)
{
@@ -14776,7 +14776,7 @@ static void tg3_get_5717_nvram_info(struct tg3 *tp)
static void tg3_get_5720_nvram_info(struct tg3 *tp)
{
- u32 nvcfg1, nvmpinstrp;
+ u32 nvcfg1, nvmpinstrp, nv_status;
nvcfg1 = tr32(NVRAM_CFG1);
nvmpinstrp = nvcfg1 & NVRAM_CFG1_5752VENDOR_MASK;
@@ -14788,6 +14788,23 @@ static void tg3_get_5720_nvram_info(struct tg3 *tp)
}
switch (nvmpinstrp) {
+ case FLASH_5762_MX25L_100:
+ case FLASH_5762_MX25L_200:
+ case FLASH_5762_MX25L_400:
+ case FLASH_5762_MX25L_800:
+ case FLASH_5762_MX25L_160_320:
+ tp->nvram_pagesize = 4096;
+ tp->nvram_jedecnum = JEDEC_MACRONIX;
+ tg3_flag_set(tp, NVRAM_BUFFERED);
+ tg3_flag_set(tp, NO_NVRAM_ADDR_TRANS);
+ tg3_flag_set(tp, FLASH);
+ nv_status = tr32(NVRAM_AUTOSENSE_STATUS);
+ tp->nvram_size =
+ (1 << (nv_status >> AUTOSENSE_DEVID &
+ AUTOSENSE_DEVID_MASK)
+ << AUTOSENSE_SIZE_IN_MB);
+ return;
+
case FLASH_5762_EEPROM_HD:
nvmpinstrp = FLASH_5720_EEPROM_HD;
break;
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index c2d02d0..9f80f5d 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -1858,7 +1858,7 @@
#define NVRAM_STAT 0x00007004
#define NVRAM_WRDATA 0x00007008
#define NVRAM_ADDR 0x0000700c
-#define NVRAM_ADDR_MSK 0x00ffffff
+#define NVRAM_ADDR_MSK 0x07ffffff
#define NVRAM_RDDATA 0x00007010
#define NVRAM_CFG1 0x00007014
#define NVRAM_CFG1_FLASHIF_ENAB 0x00000001
@@ -1940,6 +1940,11 @@
#define FLASH_5720_EEPROM_LD 0x00000003
#define FLASH_5762_EEPROM_HD 0x02000001
#define FLASH_5762_EEPROM_LD 0x02000003
+#define FLASH_5762_MX25L_100 0x00800000
+#define FLASH_5762_MX25L_200 0x00800002
+#define FLASH_5762_MX25L_400 0x00800001
+#define FLASH_5762_MX25L_800 0x00800003
+#define FLASH_5762_MX25L_160_320 0x03800002
#define FLASH_5720VENDOR_M_ATMEL_DB011D 0x01000000
#define FLASH_5720VENDOR_M_ATMEL_DB021D 0x01000002
#define FLASH_5720VENDOR_M_ATMEL_DB041D 0x01000001
@@ -2004,7 +2009,11 @@
/* 0x702c unused */
#define NVRAM_ADDR_LOCKOUT 0x00007030
-/* 0x7034 --> 0x7500 unused */
+#define NVRAM_AUTOSENSE_STATUS 0x00007038
+#define AUTOSENSE_DEVID 0x00000010
+#define AUTOSENSE_DEVID_MASK 0x00000007
+#define AUTOSENSE_SIZE_IN_MB 17
+/* 0x703c --> 0x7500 unused */
#define OTP_MODE 0x00007500
#define OTP_MODE_OTP_THRU_GRC 0x00000001
@@ -3373,6 +3382,7 @@ struct tg3 {
#define JEDEC_ST 0x20
#define JEDEC_SAIFUN 0x4f
#define JEDEC_SST 0xbf
+#define JEDEC_MACRONIX 0xc2
#define ATMEL_AT24C02_CHIP_SIZE TG3_NVRAM_SIZE_2KB
#define ATMEL_AT24C02_PAGE_SIZE (8)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH iproute2-next 6/9] rdma: Update kernel header file
From: Leon Romanovsky @ 2018-01-03 5:28 UTC (permalink / raw)
To: David Ahern
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, netdev,
Stephen Hemminger
In-Reply-To: <8dc793ba-abf7-900b-02b9-0f9f468fd49f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On Tue, Jan 02, 2018 at 07:50:43PM -0700, David Ahern wrote:
> On 1/2/18 2:37 AM, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> >
> > Synchronize iporute2 package with latest kernel
> > RDMA netlink header file.
> >
> > Signed-off-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > ---
> > include/uapi/rdma/rdma_netlink.h | 58 ++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 56 insertions(+), 2 deletions(-)
>
> FYI: uapi headers are updated separately. Once the patches hit net-next,
> I will update the headers and drop this patch.
No problem, just wanted to raise your attention that this header will be
updated in rdma-next and it will appear in net-next in delay of one cycle,
after merge cycle will complete.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2-next 0/9] RDMA resource tracking
From: Leon Romanovsky @ 2018-01-03 5:40 UTC (permalink / raw)
To: David Ahern
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, netdev,
Stephen Hemminger
In-Reply-To: <20180102093725.6172-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
On Tue, Jan 02, 2018 at 11:37:16AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
....
David,
Thanks for the review, I'll fix everything you mentioned and will send
new version a little bit later this week to give time to other reviewers
to finish their reviews.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net v2] cxgb4: Fix FW flash errors
From: Ganesh Goudar @ 2018-01-03 6:14 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
From: Arjun Vynipadath <arjun@chelsio.com>
commit 96ac18f14a5a ("cxgb4: Add support for new flash parts")
removed initialization of adapter->params.sf_fw_start causing issues
while flashing firmware to card. We no longer need sf_fw_start
in adapter->params as we already have macros defined for FW flash
addresses.
Fixes: 96ac18f14a5a ("cxgb4: Add support for new flash parts")
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
V2: Corrected the commit log
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 -
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 17 ++++++++---------
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 69d0b64..1ff7182 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -345,7 +345,6 @@ struct adapter_params {
unsigned int sf_size; /* serial flash size in bytes */
unsigned int sf_nsec; /* # of flash sectors */
- unsigned int sf_fw_start; /* start of FW image in flash */
unsigned int fw_vers; /* firmware version */
unsigned int bs_vers; /* bootstrap version */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index f2a60e0..0e9f64a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -2847,8 +2847,6 @@ enum {
SF_RD_DATA_FAST = 0xb, /* read flash */
SF_RD_ID = 0x9f, /* read ID */
SF_ERASE_SECTOR = 0xd8, /* erase sector */
-
- FW_MAX_SIZE = 16 * SF_SEC_SIZE,
};
/**
@@ -3561,8 +3559,9 @@ int t4_load_fw(struct adapter *adap, const u8 *fw_data, unsigned int size)
const __be32 *p = (const __be32 *)fw_data;
const struct fw_hdr *hdr = (const struct fw_hdr *)fw_data;
unsigned int sf_sec_size = adap->params.sf_size / adap->params.sf_nsec;
- unsigned int fw_img_start = adap->params.sf_fw_start;
- unsigned int fw_start_sec = fw_img_start / sf_sec_size;
+ unsigned int fw_start_sec = FLASH_FW_START_SEC;
+ unsigned int fw_size = FLASH_FW_MAX_SIZE;
+ unsigned int fw_start = FLASH_FW_START;
if (!size) {
dev_err(adap->pdev_dev, "FW image has no data\n");
@@ -3578,9 +3577,9 @@ int t4_load_fw(struct adapter *adap, const u8 *fw_data, unsigned int size)
"FW image size differs from size in FW header\n");
return -EINVAL;
}
- if (size > FW_MAX_SIZE) {
+ if (size > fw_size) {
dev_err(adap->pdev_dev, "FW image too large, max is %u bytes\n",
- FW_MAX_SIZE);
+ fw_size);
return -EFBIG;
}
if (!t4_fw_matches_chip(adap, hdr))
@@ -3607,11 +3606,11 @@ int t4_load_fw(struct adapter *adap, const u8 *fw_data, unsigned int size)
*/
memcpy(first_page, fw_data, SF_PAGE_SIZE);
((struct fw_hdr *)first_page)->fw_ver = cpu_to_be32(0xffffffff);
- ret = t4_write_flash(adap, fw_img_start, SF_PAGE_SIZE, first_page);
+ ret = t4_write_flash(adap, fw_start, SF_PAGE_SIZE, first_page);
if (ret)
goto out;
- addr = fw_img_start;
+ addr = fw_start;
for (size -= SF_PAGE_SIZE; size; size -= SF_PAGE_SIZE) {
addr += SF_PAGE_SIZE;
fw_data += SF_PAGE_SIZE;
@@ -3621,7 +3620,7 @@ int t4_load_fw(struct adapter *adap, const u8 *fw_data, unsigned int size)
}
ret = t4_write_flash(adap,
- fw_img_start + offsetof(struct fw_hdr, fw_ver),
+ fw_start + offsetof(struct fw_hdr, fw_ver),
sizeof(hdr->fw_ver), (const u8 *)&hdr->fw_ver);
out:
if (ret)
--
2.1.0
^ permalink raw reply related
* [PATCH net V2 0/2] bug fixes for ENA Ethernet driver
From: netanel @ 2018-01-03 6:17 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys, gtzalik
From: Netanel Belgazal <netanel@amazon.com>
Changes from V1:
Revome incorrect "ena: invoke netif_carrier_off() only after netdev
registered" patch
This patchset contains 2 bug fixes:
* handle rare race condition during MSI-X initialization
* fix error processing in ena_down()
Netanel Belgazal (2):
net: ena: unmask MSI-X only after device initialization is completed
net: ena: fix error handling in ena_down() sequence
drivers/net/ethernet/amazon/ena/ena_netdev.c | 45 ++++++++++++++++++----------
1 file changed, 30 insertions(+), 15 deletions(-)
--
2.7.3.AMZN
^ permalink raw reply
* [PATCH net V2 1/2] net: ena: unmask MSI-X only after device initialization is completed
From: netanel @ 2018-01-03 6:17 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys, gtzalik
In-Reply-To: <1514960250-107256-1-git-send-email-netanel@amazon.com>
From: Netanel Belgazal <netanel@amazon.com>
Under certain conditions MSI-X interrupt might arrive right after it
was unmasked in ena_up(). There is a chance it would be processed by
the driver before device ENA_FLAG_DEV_UP flag is set. In such a case
the interrupt is ignored.
ENA device operates in auto-masked mode, therefore ignoring
interrupt leaves it masked for good.
Moving unmask of interrupt to be the last step in ena_up().
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 97c5a89a9cf7..6fb28fd43eb3 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -1565,7 +1565,7 @@ static int ena_rss_configure(struct ena_adapter *adapter)
static int ena_up_complete(struct ena_adapter *adapter)
{
- int rc, i;
+ int rc;
rc = ena_rss_configure(adapter);
if (rc)
@@ -1584,17 +1584,6 @@ static int ena_up_complete(struct ena_adapter *adapter)
ena_napi_enable_all(adapter);
- /* Enable completion queues interrupt */
- for (i = 0; i < adapter->num_queues; i++)
- ena_unmask_interrupt(&adapter->tx_ring[i],
- &adapter->rx_ring[i]);
-
- /* schedule napi in case we had pending packets
- * from the last time we disable napi
- */
- for (i = 0; i < adapter->num_queues; i++)
- napi_schedule(&adapter->ena_napi[i].napi);
-
return 0;
}
@@ -1731,7 +1720,7 @@ static int ena_create_all_io_rx_queues(struct ena_adapter *adapter)
static int ena_up(struct ena_adapter *adapter)
{
- int rc;
+ int rc, i;
netdev_dbg(adapter->netdev, "%s\n", __func__);
@@ -1774,6 +1763,17 @@ static int ena_up(struct ena_adapter *adapter)
set_bit(ENA_FLAG_DEV_UP, &adapter->flags);
+ /* Enable completion queues interrupt */
+ for (i = 0; i < adapter->num_queues; i++)
+ ena_unmask_interrupt(&adapter->tx_ring[i],
+ &adapter->rx_ring[i]);
+
+ /* schedule napi in case we had pending packets
+ * from the last time we disable napi
+ */
+ for (i = 0; i < adapter->num_queues; i++)
+ napi_schedule(&adapter->ena_napi[i].napi);
+
return rc;
err_up:
--
2.7.3.AMZN
^ permalink raw reply related
* [PATCH net V2 2/2] net: ena: fix error handling in ena_down() sequence
From: netanel @ 2018-01-03 6:17 UTC (permalink / raw)
To: davem, netdev
Cc: Netanel Belgazal, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, evgenys, gtzalik
In-Reply-To: <1514960250-107256-1-git-send-email-netanel@amazon.com>
From: Netanel Belgazal <netanel@amazon.com>
ENA admin command queue errors are not handled as part of ena_down().
As a result, in case of error admin queue transitions to non-running
state and aborts all subsequent commands including those coming from
ena_up(). Reset scheduled by the driver from the timer service
context would not proceed due to sharing rtnl with ena_up()/ena_down()
Signed-off-by: Netanel Belgazal <netanel@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 6fb28fd43eb3..fbe21a817bd8 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -75,6 +75,9 @@ static struct workqueue_struct *ena_wq;
MODULE_DEVICE_TABLE(pci, ena_pci_tbl);
static int ena_rss_init_default(struct ena_adapter *adapter);
+static void check_for_admin_com_state(struct ena_adapter *adapter);
+static void ena_destroy_device(struct ena_adapter *adapter);
+static int ena_restore_device(struct ena_adapter *adapter);
static void ena_tx_timeout(struct net_device *dev)
{
@@ -1884,6 +1887,17 @@ static int ena_close(struct net_device *netdev)
if (test_bit(ENA_FLAG_DEV_UP, &adapter->flags))
ena_down(adapter);
+ /* Check for device status and issue reset if needed*/
+ check_for_admin_com_state(adapter);
+ if (unlikely(test_bit(ENA_FLAG_TRIGGER_RESET, &adapter->flags))) {
+ netif_err(adapter, ifdown, adapter->netdev,
+ "Destroy failure, restarting device\n");
+ ena_dump_stats_to_dmesg(adapter);
+ /* rtnl lock already obtained in dev_ioctl() layer */
+ ena_destroy_device(adapter);
+ ena_restore_device(adapter);
+ }
+
return 0;
}
@@ -2544,11 +2558,12 @@ static void ena_destroy_device(struct ena_adapter *adapter)
ena_com_set_admin_running_state(ena_dev, false);
- ena_close(netdev);
+ if (test_bit(ENA_FLAG_DEV_UP, &adapter->flags))
+ ena_down(adapter);
/* Before releasing the ENA resources, a device reset is required.
* (to prevent the device from accessing them).
- * In case the reset flag is set and the device is up, ena_close
+ * In case the reset flag is set and the device is up, ena_down()
* already perform the reset, so it can be skipped.
*/
if (!(test_bit(ENA_FLAG_TRIGGER_RESET, &adapter->flags) && dev_up))
--
2.7.3.AMZN
^ permalink raw reply related
* [PATCH] MAINTAINERS: Update my email address.
From: Pravin B Shelar @ 2018-01-03 4:14 UTC (permalink / raw)
To: davem; +Cc: netdev, Pravin B Shelar
Signed-off-by: Pravin Shelar <pshelar@ovn.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 753799d..1704ed4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10152,7 +10152,7 @@ F: drivers/irqchip/irq-ompic.c
F: drivers/irqchip/irq-or1k-*
OPENVSWITCH
-M: Pravin Shelar <pshelar@nicira.com>
+M: Pravin B Shelar <pshelar@ovn.org>
L: netdev@vger.kernel.org
L: dev@openvswitch.org
W: http://openvswitch.org
--
2.7.4
^ permalink raw reply related
* Re: [ovs-dev] Pravin Shelar
From: Pravin Shelar @ 2018-01-03 6:20 UTC (permalink / raw)
To: David Miller
Cc: Joe Perches, Ben Pfaff, Julia Lawall,
Linux Kernel Network Developers, ovs dev
In-Reply-To: <20180102.143607.379618958903573659.davem@davemloft.net>
On Tue, Jan 2, 2018 at 11:36 AM, David Miller <davem@davemloft.net> wrote:
> From: Pravin Shelar <pshelar@ovn.org>
> Date: Thu, 28 Dec 2017 15:47:39 -0800
>
>> Thanks Joe for the patch. But it is corrupted. I will send updated patch soon.
>
> I'm still waiting for this, just FYI :)
I sent the patch.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing
From: Pravin Shelar @ 2018-01-03 6:21 UTC (permalink / raw)
To: Ed Swierk
Cc: ovs-dev, Linux Kernel Network Developers, Benjamin Warren,
Keith Holleman
In-Reply-To: <CAO_EM_=Uzwx8UYe6=cae5WmKqLJFnG1-3BKM7Y3fezMOZXv9Sw@mail.gmail.com>
On Fri, Dec 22, 2017 at 4:39 PM, Ed Swierk <eswierk@skyportsystems.com> wrote:
> On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar <pshelar@ovn.org> wrote:
>> On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk <eswierk@skyportsystems.com> wrote:
>>> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
>>> included in the L3 length. For example, a short IPv4 packet may have
>>> up to 6 bytes of padding following the IP payload when received on an
>>> Ethernet device. In the normal IPv4 receive path, ip_rcv() trims the
>>> packet to ip_hdr->tot_len before invoking netfilter hooks (including
>>> conntrack and nat).
>>>
>>> In the IPv6 receive path, ip6_rcv() does the same using
>>> ipv6_hdr->payload_len. Similarly in the br_netfilter receive path,
>>> br_validate_ipv4() and br_validate_ipv6() trim the packet to the L3
>>> length before invoking NF_INET_PRE_ROUTING hooks.
>>>
>>> In the OVS conntrack receive path, ovs_ct_execute() pulls the skb to
>>> the L3 header but does not trim it to the L3 length before calling
>>> nf_conntrack_in(NF_INET_PRE_ROUTING). When nf_conntrack_proto_tcp
>>> encounters a packet with lower-layer padding, nf_checksum() fails and
>>> logs "nf_ct_tcp: bad TCP checksum". While extra zero bytes don't
>>> affect the checksum, the length in the IP pseudoheader does. That
>>> length is based on skb->len, and without trimming, it doesn't match
>>> the length the sender used when computing the checksum.
>>>
>>> The assumption throughout nf_conntrack and nf_nat is that skb->len
>>> reflects the length of the L3 header and payload, so there is no need
>>> to refer back to ip_hdr->tot_len or ipv6_hdr->payload_len.
>>>
>>> This change brings OVS into line with other netfilter users, trimming
>>> IPv4 and IPv6 packets prior to L3+ netfilter processing.
>>>
>>> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
>>> ---
>>> v2:
>>> - Trim packet in nat receive path as well as conntrack
>>> - Free skb on error
>>> ---
>>> net/openvswitch/conntrack.c | 34 ++++++++++++++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>>> index b27c5c6..1bdc78f 100644
>>> --- a/net/openvswitch/conntrack.c
>>> +++ b/net/openvswitch/conntrack.c
>>> @@ -703,6 +703,33 @@ static bool skb_nfct_cached(struct net *net,
>>> return ct_executed;
>>> }
>>>
>>> +/* Trim the skb to the L3 length. Assumes the skb is already pulled to
>>> + * the L3 header. The skb is freed on error.
>>> + */
>>> +static int skb_trim_l3(struct sk_buff *skb)
>>> +{
>>> + unsigned int nh_len;
>>> + int err;
>>> +
>>> + switch (skb->protocol) {
>>> + case htons(ETH_P_IP):
>>> + nh_len = ntohs(ip_hdr(skb)->tot_len);
>>> + break;
>>> + case htons(ETH_P_IPV6):
>>> + nh_len = ntohs(ipv6_hdr(skb)->payload_len)
>>> + + sizeof(struct ipv6hdr);
>>> + break;
>>> + default:
>>> + nh_len = skb->len;
>>> + }
>>> +
>>> + err = pskb_trim_rcsum(skb, nh_len);
>>> + if (err)
>> This should is unlikely.
>
> I'll add unlikely().
>
>>> + kfree_skb(skb);
>>> +
>>> + return err;
>>> +}
>>> +
>> This looks like a generic function, it probably does not belong to OVS
>> code base.
>
> Indeed. I'll move it to skbuff.c, unless you have a better idea.
>
>>> #ifdef CONFIG_NF_NAT_NEEDED
>>> /* Modelled after nf_nat_ipv[46]_fn().
>>> * range is only used for new, uninitialized NAT state.
>>> @@ -715,8 +742,12 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct nf_conn *ct,
>>> {
>>> int hooknum, nh_off, err = NF_ACCEPT;
>>>
>>> + /* The nat module expects to be working at L3. */
>>> nh_off = skb_network_offset(skb);
>>> skb_pull_rcsum(skb, nh_off);
>>> + err = skb_trim_l3(skb);
>>> + if (err)
>>> + return err;
>>>
>> ct-nat is executed within ct action, so I do not see why you you call
>> skb-trim again from ovs_ct_nat_execute().
>> ovs_ct_execute() trim should take care of the skb.
>
> I see. Doesn't that mean that skb_pull_rcsum() is also unnecessary in
> ovs_ct_nat_execute(), as ovs_ct_execute() has already pulled the skb
> to the L3 header?
>
Yes, It looks redundant. but lets address it in separate patch.
^ permalink raw reply
* Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing
From: Pravin Shelar @ 2018-01-03 6:21 UTC (permalink / raw)
To: Ed Swierk
Cc: ovs-dev, Linux Kernel Network Developers, Benjamin Warren,
Keith Holleman
In-Reply-To: <CAO_EM_=Uzwx8UYe6=cae5WmKqLJFnG1-3BKM7Y3fezMOZXv9Sw@mail.gmail.com>
On Fri, Dec 22, 2017 at 4:39 PM, Ed Swierk <eswierk@skyportsystems.com> wrote:
> On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar <pshelar@ovn.org> wrote:
>> On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk <eswierk@skyportsystems.com> wrote:
>>> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
>>> included in the L3 length. For example, a short IPv4 packet may have
>>> up to 6 bytes of padding following the IP payload when received on an
>>> Ethernet device. In the normal IPv4 receive path, ip_rcv() trims the
>>> packet to ip_hdr->tot_len before invoking netfilter hooks (including
>>> conntrack and nat).
>>>
>>> In the IPv6 receive path, ip6_rcv() does the same using
>>> ipv6_hdr->payload_len. Similarly in the br_netfilter receive path,
>>> br_validate_ipv4() and br_validate_ipv6() trim the packet to the L3
>>> length before invoking NF_INET_PRE_ROUTING hooks.
>>>
>>> In the OVS conntrack receive path, ovs_ct_execute() pulls the skb to
>>> the L3 header but does not trim it to the L3 length before calling
>>> nf_conntrack_in(NF_INET_PRE_ROUTING). When nf_conntrack_proto_tcp
>>> encounters a packet with lower-layer padding, nf_checksum() fails and
>>> logs "nf_ct_tcp: bad TCP checksum". While extra zero bytes don't
>>> affect the checksum, the length in the IP pseudoheader does. That
>>> length is based on skb->len, and without trimming, it doesn't match
>>> the length the sender used when computing the checksum.
>>>
>>> The assumption throughout nf_conntrack and nf_nat is that skb->len
>>> reflects the length of the L3 header and payload, so there is no need
>>> to refer back to ip_hdr->tot_len or ipv6_hdr->payload_len.
>>>
>>> This change brings OVS into line with other netfilter users, trimming
>>> IPv4 and IPv6 packets prior to L3+ netfilter processing.
>>>
>>> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
>>> ---
>>> v2:
>>> - Trim packet in nat receive path as well as conntrack
>>> - Free skb on error
>>> ---
>>> net/openvswitch/conntrack.c | 34 ++++++++++++++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>>> index b27c5c6..1bdc78f 100644
>>> --- a/net/openvswitch/conntrack.c
>>> +++ b/net/openvswitch/conntrack.c
>>> @@ -703,6 +703,33 @@ static bool skb_nfct_cached(struct net *net,
>>> return ct_executed;
>>> }
>>>
>>> +/* Trim the skb to the L3 length. Assumes the skb is already pulled to
>>> + * the L3 header. The skb is freed on error.
>>> + */
>>> +static int skb_trim_l3(struct sk_buff *skb)
>>> +{
>>> + unsigned int nh_len;
>>> + int err;
>>> +
>>> + switch (skb->protocol) {
>>> + case htons(ETH_P_IP):
>>> + nh_len = ntohs(ip_hdr(skb)->tot_len);
>>> + break;
>>> + case htons(ETH_P_IPV6):
>>> + nh_len = ntohs(ipv6_hdr(skb)->payload_len)
>>> + + sizeof(struct ipv6hdr);
>>> + break;
>>> + default:
>>> + nh_len = skb->len;
>>> + }
>>> +
>>> + err = pskb_trim_rcsum(skb, nh_len);
>>> + if (err)
>> This should is unlikely.
>
> I'll add unlikely().
>
>>> + kfree_skb(skb);
>>> +
>>> + return err;
>>> +}
>>> +
>> This looks like a generic function, it probably does not belong to OVS
>> code base.
>
> Indeed. I'll move it to skbuff.c, unless you have a better idea.
>
>>> #ifdef CONFIG_NF_NAT_NEEDED
>>> /* Modelled after nf_nat_ipv[46]_fn().
>>> * range is only used for new, uninitialized NAT state.
>>> @@ -715,8 +742,12 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct nf_conn *ct,
>>> {
>>> int hooknum, nh_off, err = NF_ACCEPT;
>>>
>>> + /* The nat module expects to be working at L3. */
>>> nh_off = skb_network_offset(skb);
>>> skb_pull_rcsum(skb, nh_off);
>>> + err = skb_trim_l3(skb);
>>> + if (err)
>>> + return err;
>>>
>> ct-nat is executed within ct action, so I do not see why you you call
>> skb-trim again from ovs_ct_nat_execute().
>> ovs_ct_execute() trim should take care of the skb.
>
> I see. Doesn't that mean that skb_pull_rcsum() is also unnecessary in
> ovs_ct_nat_execute(), as ovs_ct_execute() has already pulled the skb
> to the L3 header?
>
Yes, It looks redundant. but lets address it in separate patch.
^ permalink raw reply
* Re: general protection fault in copy_verifier_state
From: Alexei Starovoitov @ 2018-01-03 6:22 UTC (permalink / raw)
To: syzbot; +Cc: ast, daniel, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <089e08231920e153a70561d30737@google.com>
On Tue, Jan 02, 2018 at 02:58:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6bb8824732f69de0f233ae6b1a8158e149627b38
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+32ac5a3e473f2e01cfc7@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
> R13: 656c6c616b7a7973 R14: 000000000000000e R15: 0000000000000000
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3197 Comm: syzkaller425062 Not tainted 4.15.0-rc5+ #170
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:copy_func_state kernel/bpf/verifier.c:403 [inline]
> RIP: 0010:copy_verifier_state+0x364/0x590 kernel/bpf/verifier.c:431
> RSP: 0018:ffff8801c7fff130 EFLAGS: 00010203
> RAX: 0000000000000070 RBX: dffffc0000000000 RCX: 0000000000000384
> RDX: 0000000000000000 RSI: ffff8801c938d800 RDI: ffff8801c938d800
> RBP: ffff8801c7fff188 R08: ffff8801c938d700 R09: ffff8801c938d700
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801c8066940
> R13: ffff8801c938d700 R14: 0000000000000000 R15: ffff8801c938d800
> FS: 0000000001581880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020a97000 CR3: 00000001c839a001 CR4: 00000000001606e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> pop_stack+0x8c/0x270 kernel/bpf/verifier.c:449
> push_stack kernel/bpf/verifier.c:491 [inline]
> check_cond_jmp_op kernel/bpf/verifier.c:3598 [inline]
> do_check+0x4b60/0xa050 kernel/bpf/verifier.c:4731
> bpf_check+0x3296/0x58c0 kernel/bpf/verifier.c:5489
> bpf_prog_load+0xa2a/0x1b00 kernel/bpf/syscall.c:1198
> SYSC_bpf kernel/bpf/syscall.c:1807 [inline]
> SyS_bpf+0x1044/0x4420 kernel/bpf/syscall.c:1769
> entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x4404f9
> RSP: 002b:00007fff03dc4a48 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00000000004404f9
> RDX: 0000000000000048 RSI: 0000000020903000 RDI: 0000000000000005
> RBP: 000000000000000f R08: 0000000000000002 R09: 0000000000003332
> R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
> R13: 656c6c616b7a7973 R14: 000000000000000e R15: 0000000000000000
> Code: 4b 8d 3c f7 48 89 f8 48 c1 e8 03 80 3c 18 00 0f 85 05 02 00 00 4f 8b
> 34 f7 49 8d 8e 84 03 00 00 48 89 c8 48 89 4d c8 48 c1 e8 03 <0f> b6 14 18 48
> 89 c8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
> RIP: copy_func_state kernel/bpf/verifier.c:403 [inline] RSP:
> ffff8801c7fff130
> RIP: copy_verifier_state+0x364/0x590 kernel/bpf/verifier.c:431 RSP:
> ffff8801c7fff130
> ---[ end trace 18f3ab976ca58c6c ]---
thanks for the report.
Looks like it needs this fix:
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 98d8637cf70d..0876d4402dc3 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -375,6 +375,8 @@ static int realloc_func_state(struct bpf_func_state *state, int size,
static void free_func_state(struct bpf_func_state *state)
{
+ if (!state)
+ return;
kfree(state->stack);
kfree(state);
}
@@ -487,6 +489,8 @@ static struct bpf_verifier_state *push_stack(struct bpf_verifier_env *env,
}
return &elem->st;
err:
+ free_verifier_state(env->cur_state, true);
+ env->cur_state = NULL;
/* pop all elements and return */
while (!pop_stack(env, NULL, NULL));
return NULL;
will submit it properly after few more tests.
^ permalink raw reply related
* Re: WARNING in adjust_ptr_min_max_vals
From: Alexei Starovoitov @ 2018-01-03 6:40 UTC (permalink / raw)
To: syzbot; +Cc: ast, daniel, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <94eb2c05a53056c2100561d80f92@google.com>
On Tue, Jan 02, 2018 at 08:58:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> 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.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6d362cadd45dc0a12ba4@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1514685224.971:7): avc: denied { map } for
> pid=3144 comm="syzkaller663366" path="/root/syzkaller663366580" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> WARNING: CPU: 1 PID: 3144 at kernel/bpf/verifier.c:2359
> adjust_ptr_min_max_vals+0x977/0x20a0 kernel/bpf/verifier.c:2359
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 3144 Comm: syzkaller663366 Not tainted 4.15.0-rc4-next-20171221+
> #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
> fixup_bug arch/x86/kernel/traps.c:246 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
> invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:adjust_ptr_min_max_vals+0x977/0x20a0 kernel/bpf/verifier.c:2359
> RSP: 0018:ffff8801c97ef198 EFLAGS: 00010293
> RAX: ffff8801c94e8240 RBX: ffff8801c8ee4b00 RCX: ffffffff817eebb7
> RDX: 0000000000000000 RSI: ffffc90000002048 RDI: ffffc90000002049
> RBP: ffff8801c97ef228 R08: 0000000000000000 R09: ffffffff858fa920
> R10: 0000000000000071 R11: ffffffff858f9d00 R12: 0000000000000000
> R13: 0000000000000001 R14: ffffc90000002048 R15: ffff8801c8e02040
> adjust_reg_min_max_vals kernel/bpf/verifier.c:2799 [inline]
> check_alu_op kernel/bpf/verifier.c:2997 [inline]
> do_check+0x67e0/0xae20 kernel/bpf/verifier.c:4448
> bpf_check+0x2b1b/0x49f0 kernel/bpf/verifier.c:5374
> bpf_prog_load+0xa2a/0x1b00 kernel/bpf/syscall.c:1192
> SYSC_bpf kernel/bpf/syscall.c:1724 [inline]
> SyS_bpf+0x1044/0x4420 kernel/bpf/syscall.c:1686
> entry_SYSCALL_64_fastpath+0x1f/0x96
that's an interesting bug.
If I decipher fuzzed bpf insns correctly the sequence:
r0 = 0x0
if r0 s<= 0x0 goto pc+0
r0 -= r1
causes:
if (WARN_ON_ONCE(known && (smin_val != smax_val))) {
and smin_val=1 smax_val=0
since the verifier did:
case BPF_JSLE:
false_reg->smin_value = max_t(s64, false_reg->smin_value, val + 1);
Not sure what the best fix yet.
^ permalink raw reply
* Re: [PATCH v3 00/27] kill devm_ioremap_nocache
From: Yisheng Xie @ 2018-01-03 6:42 UTC (permalink / raw)
To: christophe leroy, Guenter Roeck, Greg KH, starvik-VrBV9hrLPhE,
jesper.nilsson-VrBV9hrLPhE, tony.luck-ral2JQCrhuEAvxtiuMwx3w,
fenghua.yu-ral2JQCrhuEAvxtiuMwx3w, jonas-A9uVI2HLR7kOP4wsBPIw7w,
shorne-Re5JQEeQqe8AvxtiuMwx3w, dhowells-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, ysxie-H32Fclmsjq1BDgjK7y7TUQ,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
richard-/L3Ra7n9ekc, marek.vasut-Re5JQEeQqe8AvxtiuMwx3w,
cyrille.pitchen-yU5RGvR974pGWvitb5QawA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, wim-IQzOog9fTRqzQB+pC5nmwQ,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, ralf-6z/3iImG2C8G8FEW9MqTrA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
marc.zyngier-5wv7dgnIgG8, arnd-r2nGTMty4D4,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
industrypack-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <6c0ade63-f4d3-d44d-c622-b091eb2ba902-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
+ cris/ia64/mn10300/openrisc maintainers
On 2017/12/25 9:09, Yisheng Xie wrote:
> hi Christophe and Greg,
>
> On 2017/12/24 16:55, christophe leroy wrote:
>>
>>
>> Le 23/12/2017 à 16:57, Guenter Roeck a écrit :
>>> On 12/23/2017 05:48 AM, Greg KH wrote:
>>>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
>>>>> Hi all,
>>>>>
>>>>> When I tried to use devm_ioremap function and review related code, I found
>>>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other,
>>>>> except one use ioremap while the other use ioremap_nocache.
>>>>
>>>> For all arches? Really? Look at MIPS, and x86, they have different
>>>> functions.
>>>>
>>>
>>> Both mips and x86 end up mapping the same function, but other arches don't.
>>> mn10300 is one where ioremap and ioremap_nocache are definitely different.
>>
>> alpha: identical
>> arc: identical
>> arm: identical
>> arm64: identical
>> cris: different <==
>> frv: identical
>> hexagone: identical
>> ia64: different <==
>> m32r: identical
>> m68k: identical
>> metag: identical
>> microblaze: identical
>> mips: identical
>> mn10300: different <==
>> nios: identical
>> openrisc: different <==
>> parisc: identical
>> riscv: identical
>> s390: identical
>> sh: identical
>> sparc: identical
>> tile: identical
>> um: rely on asm/generic
>> unicore32: identical
>> x86: identical
>> asm/generic (no mmu): identical
>
> Wow, that's correct, sorry for I have just checked the main archs, I means
> x86,arm, arm64, mips.
>
> However, I stall have no idea about why these 4 archs want different ioremap
> function with others. Drivers seems cannot aware this? If driver call ioremap
> want he really want for there 4 archs, cache or nocache?
Could you please help about this? it is out of my knowledge.
Thanks
Yisheng
>
>>
>> So 4 among all arches seems to have ioremap() and ioremap_nocache() being different.
>>
>> Could we have a define set by the 4 arches on which ioremap() and ioremap_nocache() are different, something like HAVE_DIFFERENT_IOREMAP_NOCACHE ?
>
> Then, what the HAVE_DIFFERENT_IOREMAP_NOCACHE is uesed for ?
>
> Thanks
> Yisheng
>>
>> Christophe
>>
>>>
>>> Guenter
>>>
>>>>> While ioremap's
>>>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the
>>>>> same function with devm_ioremap, which can just be killed to reduce the size
>>>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
>>>>>
>>>>> I have posted two versions, which use macro instead of function for
>>>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
>>>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate
>>>>> thing. So here comes v3 and please help to review.
>>>>
>>>> I don't think this can be done, what am I missing? These functions are
>>>> not identical, sorry for missing that before.
>
> Never mind, I should checked all the arches, sorry about that.
>
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>>
>>
>> .
>>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH net] sctp: fix error path in sctp_stream_init
From: Xin Long @ 2018-01-03 6:45 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, Vlad Yasevich, Neil Horman
In-Reply-To: <74b65f56d6912704f3ef79a46242cc2ca567e4e3.1514928664.git.marcelo.leitner@gmail.com>
On Wed, Jan 3, 2018 at 5:44 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> syzbot noticed a NULL pointer dereference panic in sctp_stream_free()
> which was caused by an incomplete error handling in sctp_stream_init().
> By not clearing stream->outcnt, it made a for() in sctp_stream_free()
> think that it had elements to free, but not, leading to the panic.
>
> As suggested by Xin Long, this patch also simplifies the error path by
> moving it to the only if() that uses it.
>
> See-also: https://www.spinics.net/lists/netdev/msg473756.html
> See-also: https://www.spinics.net/lists/netdev/msg465024.html
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Fixes: f952be79cebd ("sctp: introduce struct sctp_stream_out_ext")
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/stream.c | 22 ++++++++++------------
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> index 76ea66be0bbee7d3f018676d52c8b95ba06dbcb1..524dfeb94c41ab1ac735746a8acf93af1c96ae48 100644
> --- a/net/sctp/stream.c
> +++ b/net/sctp/stream.c
> @@ -156,9 +156,9 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
> sctp_stream_outq_migrate(stream, NULL, outcnt);
> sched->sched_all(stream);
>
> - i = sctp_stream_alloc_out(stream, outcnt, gfp);
> - if (i)
> - return i;
> + ret = sctp_stream_alloc_out(stream, outcnt, gfp);
> + if (ret)
> + goto out;
>
> stream->outcnt = outcnt;
> for (i = 0; i < stream->outcnt; i++)
> @@ -170,19 +170,17 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
> if (!incnt)
> goto out;
>
> - i = sctp_stream_alloc_in(stream, incnt, gfp);
> - if (i) {
> - ret = -ENOMEM;
> - goto free;
> + ret = sctp_stream_alloc_in(stream, incnt, gfp);
> + if (ret) {
> + sched->free(stream);
> + kfree(stream->out);
> + stream->out = NULL;
> + stream->outcnt = 0;
> + goto out;
> }
>
> stream->incnt = incnt;
> - goto out;
>
> -free:
> - sched->free(stream);
> - kfree(stream->out);
> - stream->out = NULL;
> out:
> return ret;
> }
> --
> 2.14.3
>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
^ permalink raw reply
* Re: [PATCH] bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-01-03 7:00 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-netdev, Andy Gospodarek, Jay Vosburgh, Veaceslav Falico,
LKML, kernel-janitors
In-Reply-To: <6cdc726b-82bc-85b6-393b-0e2002c19341@users.sourceforge.net>
On Mon, Jan 1, 2018 at 8:07 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 1 Jan 2018 17:00:04 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
What is the issue with this message?
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/net/bonding/bond_main.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index c669554d70bb..a96e0c9cc4bf 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3910,7 +3910,6 @@ int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave)
> GFP_KERNEL);
> if (!new_arr) {
> ret = -ENOMEM;
> - pr_err("Failed to build slave-array.\n");
> goto out;
> }
> if (BOND_MODE(bond) == BOND_MODE_8023AD) {
> --
> 2.15.1
>
^ permalink raw reply
* Re: [RFC crypto v3 0/9] Chelsio Inline TLS
From: Atul Gupta @ 2018-01-03 7:06 UTC (permalink / raw)
To: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Ganesh GR
Cc: netdev@vger.kernel.org, davem@davemloft.net, davejwatson@fb.com,
smueller, Stefano Brivio, hannes
In-Reply-To: <1513769582-25786-1-git-send-email-atul.gupta@chelsio.com>
Addressed the review comments in v2 and v3, please suggest if there is
any other comment and step to proceed?
Thanks
Atul Gupta
On Wednesday 20 December 2017 05:03 PM, Atul Gupta wrote:
> RFC series for Chelsio Inline TLS driver (chtls.ko)
>
> Driver use the ULP infrastructure to register chtls as Inline TLS ULP.
> Chtls use TCP Sockets to transmit and receive TLS record. TCP proto_ops
> is extended to offload TLS record.
>
> T6 adapter provides the following features:
> -TLS record offload, TLS header, encrypt, digest and transmit
> -TLS record receive and decrypt
> -TLS keys store
> -TCP/IP engine
> -TLS engine
> -GCM crypto engine [support CBC also]
>
> TLS provides security at the transport layer. It uses TCP to provide
> reliable end-to-end transport of application data. It relies on TCP
> for any retransmission. TLS session comprises of three parts:
> a. TCP/IP connection
> b. TLS handshake
> c. Record layer processing
>
> TLS handshake state machine is executed in host (refer standard
> implementation eg. OpenSSL). Setsockopt [SOL_TCP, TCP_ULP] initialize
> TCP proto-ops for Chelsio inline tls support. setsockopt(sock, SOL_TCP,
> TCP_ULP, "chtls", sizeof("chtls"));
>
> Tx and Rx Keys are decided during handshake and programmed onto the chip
> after CCS is exchanged.
> struct tls12_crypto_info_aes_gcm_128 crypto_info
> setsockopt(sock, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info))
> Finish is the first encrypted/decrypted message tx/rx inline.
>
> On the Tx path TLS engine receive plain text from openssl, insert IV,
> fetches the tx key, create cipher text records and generate MAC. TLS
> header is added to cipher text and forward to TCP/IP engine for transport
> layer processing and transmission on wire.
> TX:
> Application--openssl--chtls---TLS engine---encrypt/auth---TCP/IP
> engine---wire.
>
> On the Rx side, data received is PDU aligned at record
> boundaries. TLS processes only the complete record. If rx key is programmed
> on CCS receive, data is decrypted and plain text is posted to host.
> RX:
> Wire--cipher-text--TCP/IP engine [PDU align]---TLS engine---
> decrypt/auth---plain-text--chtls--openssl--application
>
> v3: fixed the kbuild test issues
> -made few funtions static
> -initialized few variables
>
> v2: fixed the following based on the review comments of Stephan Mueller,
> Stefano Brivio and Hannes Frederic
> -Added more details in cover letter
> -Fixed indentation and formating issues
> -Using aes instead of aes-generic
> -memset key info after programing the key on chip
> -reordered the patch sequence
>
> Atul Gupta (9):
> chtls: structure and macro definiton
> cxgb4: Inline TLS FW Interface
> cxgb4: LLD driver changes to enable TLS
> chcr: Key Macro
> chtls: Key program
> chtls: CPL handler definition
> chtls: Inline crypto request Tx/Rx
> chtls: Register the ULP
> Makefile Kconfig
>
> drivers/crypto/chelsio/Kconfig | 10 +
> drivers/crypto/chelsio/Makefile | 1 +
> drivers/crypto/chelsio/chcr_algo.h | 42 +
> drivers/crypto/chelsio/chcr_core.h | 55 +-
> drivers/crypto/chelsio/chtls/Makefile | 4 +
> drivers/crypto/chelsio/chtls/chtls.h | 480 +++++
> drivers/crypto/chelsio/chtls/chtls_cm.c | 2045 ++++++++++++++++++++
> drivers/crypto/chelsio/chtls/chtls_cm.h | 203 ++
> drivers/crypto/chelsio/chtls/chtls_hw.c | 394 ++++
> drivers/crypto/chelsio/chtls/chtls_io.c | 1867 ++++++++++++++++++
> drivers/crypto/chelsio/chtls/chtls_main.c | 584 ++++++
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 18 +-
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 32 +-
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 7 +
> drivers/net/ethernet/chelsio/cxgb4/sge.c | 98 +-
> drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 121 +-
> drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 2 +
> drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 165 +-
> include/uapi/linux/tls.h | 1 +
> net/ipv4/tcp_minisocks.c | 1 +
> 20 files changed, 6111 insertions(+), 19 deletions(-)
> create mode 100644 drivers/crypto/chelsio/chtls/Makefile
> create mode 100644 drivers/crypto/chelsio/chtls/chtls.h
> create mode 100644 drivers/crypto/chelsio/chtls/chtls_cm.c
> create mode 100644 drivers/crypto/chelsio/chtls/chtls_cm.h
> create mode 100644 drivers/crypto/chelsio/chtls/chtls_hw.c
> create mode 100644 drivers/crypto/chelsio/chtls/chtls_io.c
> create mode 100644 drivers/crypto/chelsio/chtls/chtls_main.c
>
^ permalink raw reply
* [PATCHv4 0/2] capability controlled user-namespaces
From: Mahesh Bandewar @ 2018-01-03 7:26 UTC (permalink / raw)
To: LKML, James Morris
Cc: Netdev, Kernel-hardening, Linux API, Linux Security, Serge Hallyn,
Michael Kerrisk, Kees Cook, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
TL;DR version
-------------
Creating a sandbox environment with namespaces is challenging
considering what these sandboxed processes can engage into. e.g.
CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few.
Current form of user-namespaces, however, if changed a bit can allow
us to create a sandbox environment without locking down user-
namespaces.
Detailed version
----------------
Problem
-------
User-namespaces in the current form have increased the attack surface as
any process can acquire capabilities which are not available to them (by
default) by performing combination of clone()/unshare()/setns() syscalls.
#define _GNU_SOURCE
#include <stdio.h>
#include <sched.h>
#include <netinet/in.h>
int main(int ac, char **av)
{
int sock = -1;
printf("Attempting to open RAW socket before unshare()...\n");
sock = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW);
if (sock < 0) {
perror("socket() SOCK_RAW failed: ");
} else {
printf("Successfully opened RAW-Sock before unshare().\n");
close(sock);
sock = -1;
}
if (unshare(CLONE_NEWUSER | CLONE_NEWNET) < 0) {
perror("unshare() failed: ");
return 1;
}
printf("Attempting to open RAW socket after unshare()...\n");
sock = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW);
if (sock < 0) {
perror("socket() SOCK_RAW failed: ");
} else {
printf("Successfully opened RAW-Sock after unshare().\n");
close(sock);
sock = -1;
}
return 0;
}
The above example shows how easy it is to acquire NET_RAW capabilities
and once acquired, these processes could take benefit of above mentioned
or similar issues discovered/undiscovered with malicious intent. Note
that this is just an example and the problem/solution is not limited
to NET_RAW capability *only*.
The easiest fix one can apply here is to lock-down user-namespaces which
many of the distros do (i.e. don't allow users to create user namespaces),
but unfortunately that prevents everyone from using them.
Approach
--------
Introduce a notion of 'controlled' user-namespaces. Every process on
the host is allowed to create user-namespaces (governed by the limit
imposed by per-ns sysctl) however, mark user-namespaces created by
sandboxed processes as 'controlled'. Use this 'mark' at the time of
capability check in conjunction with a global capability whitelist.
If the capability is not whitelisted, processes that belong to
controlled user-namespaces will not be allowed.
Processes that do not have CAP_SYS_ADMIN in init-ns can *only* create
controlled user-namespaces. In other words, user-namespaces created by
privileged processes (those which have CAP_SYS_ADMIN in init-ns) are
not controlled. A hierarchy underneath any controlled user-ns is always
controlled.
A global whitelist is list of capabilities governed by a sysctl
(kernel.controlled_userns_caps_whitelist) which is available to
(privileged) user in init-ns to modify while it's applicable to all
controlled user-namespaces on the host irrespective of when that user-ns
was created.
Marking user-namespaces controlled without modifying the whitelist is
equivalent of the current behavior. The default value of whitelist includes
all capabilities so that the compatibility is maintained. However it gives
admins fine-grained ability to control various capabilities system wide
without locking down user-namespaces.
Example
-------
Here is the example that demonstrates the behavior of a kernel that has
this patch-set applied. It uses the same c-code from this commit-log and
is called acquire_raw.c -
(a) The 'root' user has all the capabilities all the time (before and
after taking capability).
root@vm0:~# id
uid=0(root) gid=0(root) groups=0(root)
root@vm0:~# sysctl -q kernel.controlled_userns_caps_whitelist
kernel.controlled_userns_caps_whitelist = 1f,ffffffff
root@vm0:~# ./acquire_raw
Attempting to open RAW socket before unshare()...
Successfully opened RAW-Sock before unshare().
Attempting to open RAW socket after unshare()...
Successfully opened RAW-Sock after unshare().
root@vm0:~# sysctl -w kernel.controlled_userns_caps_whitelist=1f,ffffdfff
kernel.controlled_userns_caps_whitelist = 1f,ffffdfff
root@vm0:~# ./acquire_raw
Attempting to open RAW socket before unshare()...
Successfully opened RAW-Sock before unshare().
Attempting to open RAW socket after unshare()...
Successfully opened RAW-Sock after unshare().
(b) Unprivileged user cannot change the mask.
mahesh@vm0:~$ id
uid=1000(mahesh) gid=1000(mahesh)
groups=1000(mahesh),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),118(lpadmin),128(sambashare)
mahesh@vm0:~$ sysctl -q kernel.controlled_userns_caps_whitelist
kernel.controlled_userns_caps_whitelist = 1f,ffffffff
mahesh@vm0:~$ sysctl -w kernel.controlled_userns_caps_whitelist=1f,ffffdfff
sysctl: permission denied on key 'kernel.controlled_userns_caps_whitelist'
(c) Unprivileged user does not have CAP_NET_RAW in init-ns but can get
that capability inside child-user-ns when the controlled_userns_caps
mask is unchanged (current behavior).
mahesh@vm0:~$ sysctl -q kernel.controlled_userns_caps_whitelist
kernel.controlled_userns_caps_whitelist = 1f,ffffffff
mahesh@vm0:~$ ./acquire_raw
Attempting to open RAW socket before unshare()...
socket() SOCK_RAW failed: : Operation not permitted
Attempting to open RAW socket after unshare()...
Successfully opened RAW-Sock after unshare().
(d) Changing the controlled_userns_caps_whitelist mask will prevent user
for acquiring 'controlled capability' inside user-namespace.
mahesh@vm0:~$ sysctl -q kernel.controlled_userns_caps_whitelist
kernel.controlled_userns_caps_whitelist = 1f,ffffdfff
mahesh@vm0:~$ ./acquire_raw
Attempting to open RAW socket before unshare()...
socket() SOCK_RAW failed: : Operation not permitted
Attempting to open RAW socket after unshare()...
socket() SOCK_RAW failed: : Operation not permitted
Please see individual patches in this series.
Mahesh Bandewar (2):
capability: introduce sysctl for controlled user-ns capability whitelist
userns: control capabilities of some user namespaces
Documentation/sysctl/kernel.txt | 21 +++++++++++++++++
include/linux/capability.h | 7 ++++++
include/linux/user_namespace.h | 25 ++++++++++++++++++++
kernel/capability.c | 52 +++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 5 ++++
kernel/user_namespace.c | 4 ++++
security/commoncap.c | 8 +++++++
7 files changed, 122 insertions(+)
--
2.15.1.620.gb9897f4670-goog
^ permalink raw reply
* [PATCHv4 1/2] capability: introduce sysctl for controlled user-ns capability whitelist
From: Mahesh Bandewar @ 2018-01-03 7:26 UTC (permalink / raw)
To: LKML, James Morris
Cc: Netdev, Kernel-hardening, Linux API, Linux Security, Serge Hallyn,
Michael Kerrisk, Kees Cook, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
Add a sysctl variable kernel.controlled_userns_caps_whitelist. Capability
mask is stored in kernel as kernel_cap_t type (array of u32). This sysctl
takes input as comma separated hex u32 words. For simplicity one could
see this sysctl to operate on string inputs. However the value is not
expected to change that often during the life of a kernel-boot. It makes
more sense to use the widely available API instead of bringing another
string manipulation for the purpose of making this simpler.
The default value set (for kernel.controlled_userns_caps_whitelist) is
CAP_FULL_SET indicating that no capability is controlled by default to
maintain compatibility with the existing behavior of user-ns. Administrator
will have to modify this sysctl to control any capability as such. e.g. to
control CAP_NET_RAW the mask need to be changed like -
# sysctl -q kernel.controlled_userns_caps_whitelist
kernel.controlled_userns_caps_whitelist = 1f,ffffffff
# sysctl -w kernel.controlled_userns_caps_whitelist=1f,ffffdfff
kernel.controlled_userns_caps_whitelist = 1f,ffffdfff
For bit-to-mask conversion please check include/uapi/linux/capability.h
file.
Any capabilities that are not part of this mask will be controlled and
will not be allowed to processes in controlled user-ns. In above example
CAP_NET_RAW will not be available to controlled-user-namespaces.
Acked-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
v4:
commit message changes.
v3:
Added couple of comments as requested by Serge Hallyn
v2:
Rebase
v1:
Initial submission
Documentation/sysctl/kernel.txt | 21 ++++++++++++++++++
include/linux/capability.h | 3 +++
kernel/capability.c | 47 +++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 5 +++++
4 files changed, 76 insertions(+)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 694968c7523c..6aa1e087afee 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -25,6 +25,7 @@ show up in /proc/sys/kernel:
- bootloader_version [ X86 only ]
- callhome [ S390 only ]
- cap_last_cap
+- controlled_userns_caps_whitelist
- core_pattern
- core_pipe_limit
- core_uses_pid
@@ -187,6 +188,26 @@ CAP_LAST_CAP from the kernel.
==============================================================
+controlled_userns_caps_whitelist
+
+Capability mask that is whitelisted for "controlled" user namespaces.
+Any capability that is missing from this mask will not be allowed to
+any process that is attached to a controlled-userns. e.g. if CAP_NET_RAW
+is not part of this mask, then processes running inside any controlled
+userns's will not be allowed to perform action that needs CAP_NET_RAW
+capability. However, processes that are attached to a parent user-ns
+hierarchy that is *not* controlled and has CAP_NET_RAW can continue
+performing those actions. User-namespaces are marked "controlled" at
+the time of their creation based on the capabilities of the creator.
+A process that does not have CAP_SYS_ADMIN will create user-namespaces
+that are controlled.
+
+The value is expressed as two comma separated hex words (u32). This
+sysctl is available in init-ns and users with CAP_SYS_ADMIN in init-ns
+are allowed to make changes.
+
+==============================================================
+
core_pattern:
core_pattern is used to specify a core dumpfile pattern name.
diff --git a/include/linux/capability.h b/include/linux/capability.h
index f640dcbc880c..7d79a4689625 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -14,6 +14,7 @@
#define _LINUX_CAPABILITY_H
#include <uapi/linux/capability.h>
+#include <linux/sysctl.h>
#define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3
@@ -248,6 +249,8 @@ extern bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns);
/* audit system wants to get cap info from files as well */
extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
+int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
+ void __user *buff, size_t *lenp, loff_t *ppos);
extern int cap_convert_nscap(struct dentry *dentry, void **ivalue, size_t size);
diff --git a/kernel/capability.c b/kernel/capability.c
index 1e1c0236f55b..4a859b7d4902 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -29,6 +29,8 @@ EXPORT_SYMBOL(__cap_empty_set);
int file_caps_enabled = 1;
+kernel_cap_t controlled_userns_caps_whitelist = CAP_FULL_SET;
+
static int __init file_caps_disable(char *str)
{
file_caps_enabled = 0;
@@ -507,3 +509,48 @@ bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns)
rcu_read_unlock();
return (ret == 0);
}
+
+/* Controlled-userns capabilities routines */
+#ifdef CONFIG_SYSCTL
+int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
+ void __user *buff, size_t *lenp, loff_t *ppos)
+{
+ DECLARE_BITMAP(caps_bitmap, CAP_LAST_CAP);
+ struct ctl_table caps_table;
+ char tbuf[NAME_MAX];
+ int ret;
+
+ ret = bitmap_from_u32array(caps_bitmap, CAP_LAST_CAP,
+ controlled_userns_caps_whitelist.cap,
+ _KERNEL_CAPABILITY_U32S);
+ if (ret != CAP_LAST_CAP)
+ return -1;
+
+ scnprintf(tbuf, NAME_MAX, "%*pb", CAP_LAST_CAP, caps_bitmap);
+
+ caps_table.data = tbuf;
+ caps_table.maxlen = NAME_MAX;
+ caps_table.mode = table->mode;
+ ret = proc_dostring(&caps_table, write, buff, lenp, ppos);
+ if (ret)
+ return ret;
+ if (write) {
+ kernel_cap_t tmp;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ ret = bitmap_parse_user(buff, *lenp, caps_bitmap, CAP_LAST_CAP);
+ if (ret)
+ return ret;
+
+ ret = bitmap_to_u32array(tmp.cap, _KERNEL_CAPABILITY_U32S,
+ caps_bitmap, CAP_LAST_CAP);
+ if (ret != CAP_LAST_CAP)
+ return -1;
+
+ controlled_userns_caps_whitelist = tmp;
+ }
+ return 0;
+}
+#endif /* CONFIG_SYSCTL */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 557d46728577..759b6c286806 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1217,6 +1217,11 @@ static struct ctl_table kern_table[] = {
.extra2 = &one,
},
#endif
+ {
+ .procname = "controlled_userns_caps_whitelist",
+ .mode = 0644,
+ .proc_handler = proc_douserns_caps_whitelist,
+ },
{ }
};
--
2.15.1.620.gb9897f4670-goog
^ permalink raw reply related
* [PATCHv4 2/2] userns: control capabilities of some user namespaces
From: Mahesh Bandewar @ 2018-01-03 7:26 UTC (permalink / raw)
To: LKML, James Morris
Cc: Netdev, Kernel-hardening, Linux API, Linux Security, Serge Hallyn,
Michael Kerrisk, Kees Cook, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
With this new notion of "controlled" user-namespaces, the controlled
user-namespaces are marked at the time of their creation while the
capabilities of processes that belong to them are controlled using the
global mask.
Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
that belongs to uncontrolled user-ns can create another (child) user-
namespace that is uncontrolled. Any other process (that either does
not have SYS_ADMIN or belongs to a controlled user-ns) can only
create a user-ns that is controlled.
global-capability-whitelist (controlled_userns_caps_whitelist) is used
at the capability check-time and keeps the semantics for the processes
that belong to uncontrolled user-ns as it is. Processes that belong to
controlled user-ns however are subjected to different checks-
(a) if the capability in question is controlled and process belongs
to controlled user-ns, then it's always denied.
(b) if the capability in question is NOT controlled then fall back
to the traditional check.
Acked-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
v4:
Rebase
v3:
Rebase
v2:
Don't recalculate user-ns flags for every setns() call.
v1:
Initial submission.
include/linux/capability.h | 4 ++++
include/linux/user_namespace.h | 25 +++++++++++++++++++++++++
kernel/capability.c | 5 +++++
kernel/user_namespace.c | 4 ++++
security/commoncap.c | 8 ++++++++
5 files changed, 46 insertions(+)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 7d79a4689625..383f31f066f0 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -251,6 +251,10 @@ extern bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns);
extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
void __user *buff, size_t *lenp, loff_t *ppos);
+/* Controlled capability is capability that is missing from the capability-mask
+ * controlled_userns_caps_whitelist controlled via sysctl.
+ */
+bool is_capability_controlled(int cap);
extern int cap_convert_nscap(struct dentry *dentry, void **ivalue, size_t size);
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index d6b74b91096b..a5c48684b317 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -32,6 +32,7 @@ struct uid_gid_map { /* 64 bytes -- 1 cache line */
};
#define USERNS_SETGROUPS_ALLOWED 1UL
+#define USERNS_CONTROLLED 2UL
#define USERNS_INIT_FLAGS USERNS_SETGROUPS_ALLOWED
@@ -112,6 +113,21 @@ static inline void put_user_ns(struct user_namespace *ns)
__put_user_ns(ns);
}
+/* Controlled user-ns is the one that is created by a process that does not
+ * have CAP_SYS_ADMIN (or descended from such an user-ns).
+ * For more details please see the sysctl description of
+ * controlled_userns_caps_whitelist.
+ */
+static inline bool is_user_ns_controlled(const struct user_namespace *ns)
+{
+ return ns->flags & USERNS_CONTROLLED;
+}
+
+static inline void mark_user_ns_controlled(struct user_namespace *ns)
+{
+ ns->flags |= USERNS_CONTROLLED;
+}
+
struct seq_operations;
extern const struct seq_operations proc_uid_seq_operations;
extern const struct seq_operations proc_gid_seq_operations;
@@ -170,6 +186,15 @@ static inline struct ns_common *ns_get_owner(struct ns_common *ns)
{
return ERR_PTR(-EPERM);
}
+
+static inline bool is_user_ns_controlled(const struct user_namespace *ns)
+{
+ return false;
+}
+
+static inline void mark_user_ns_controlled(struct user_namespace *ns)
+{
+}
#endif
#endif /* _LINUX_USER_H */
diff --git a/kernel/capability.c b/kernel/capability.c
index 4a859b7d4902..bffe249922de 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -511,6 +511,11 @@ bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns)
}
/* Controlled-userns capabilities routines */
+bool is_capability_controlled(int cap)
+{
+ return !cap_raised(controlled_userns_caps_whitelist, cap);
+}
+
#ifdef CONFIG_SYSCTL
int proc_douserns_caps_whitelist(struct ctl_table *table, int write,
void __user *buff, size_t *lenp, loff_t *ppos)
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 246d4d4ce5c7..ca0556d466b6 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -141,6 +141,10 @@ int create_user_ns(struct cred *new)
goto fail_keyring;
set_cred_user_ns(new, ns);
+ if (!ns_capable(parent_ns, CAP_SYS_ADMIN) ||
+ is_user_ns_controlled(parent_ns))
+ mark_user_ns_controlled(ns);
+
return 0;
fail_keyring:
#ifdef CONFIG_PERSISTENT_KEYRINGS
diff --git a/security/commoncap.c b/security/commoncap.c
index 4f8e09340956..5454e9c03ee8 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -73,6 +73,14 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
{
struct user_namespace *ns = targ_ns;
+ /* If the capability is controlled and user-ns that process
+ * belongs-to is 'controlled' then return EPERM and no need
+ * to check the user-ns hierarchy.
+ */
+ if (is_user_ns_controlled(cred->user_ns) &&
+ is_capability_controlled(cap))
+ return -EPERM;
+
/* See if cred has the capability in the target user namespace
* by examining the target user namespace and all of the target
* user namespace's parents.
--
2.15.1.620.gb9897f4670-goog
^ permalink raw reply related
* [PATCH] rtnetlink: give a user socket to get_target_net()
From: Andrei Vagin @ 2018-01-03 7:27 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: David Ahern, Florian Westphal, Andrei Vagin, Jiri Benc
This function is used from two places: rtnl_dump_ifinfo and
rtnl_getlink. In rtnl_getlink(), we give a request skb into
get_target_net(), but in rtnl_dump_ifinfo, we give a response skb
into get_target_net().
The problem here is that NETLINK_CB() isn't initialized for the response
skb. In both cases we can get a user socket and give it instead of skb
into get_target_net().
This bug was found by syzkaller with this call-trace:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 1 PID: 3149 Comm: syzkaller140561 Not tainted 4.15.0-rc4-mm1+ #47
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868
RSP: 0018:ffff8801c880f348 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8443f900
RDX: 000000000000007b RSI: ffffffff86510f40 RDI: 00000000000003d8
RBP: ffff8801c880f360 R08: 0000000000000000 R09: 1ffff10039101e4f
R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff86510f40
R13: 000000000000000c R14: 0000000000000004 R15: 0000000000000011
FS: 0000000001a1a880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020151000 CR3: 00000001c9511005 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
netlink_ns_capable+0x26/0x30 net/netlink/af_netlink.c:886
get_target_net+0x9d/0x120 net/core/rtnetlink.c:1765
rtnl_dump_ifinfo+0x2e5/0xee0 net/core/rtnetlink.c:1806
netlink_dump+0x48c/0xce0 net/netlink/af_netlink.c:2222
__netlink_dump_start+0x4f0/0x6d0 net/netlink/af_netlink.c:2319
netlink_dump_start include/linux/netlink.h:214 [inline]
rtnetlink_rcv_msg+0x7f0/0xb10 net/core/rtnetlink.c:4485
netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2441
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
netlink_unicast+0x4be/0x6a0 net/netlink/af_netlink.c:1334
netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
Cc: Jiri Benc <jbenc@redhat.com>
Fixes: 79e1ad148c84 ("rtnetlink: use netnsid to query interface")
Signed-off-by: Andrei Vagin <avagin@openvz.org>
---
net/core/rtnetlink.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index dabba2a91fc8..778d7f03404a 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1681,18 +1681,18 @@ static bool link_dump_filtered(struct net_device *dev,
return false;
}
-static struct net *get_target_net(struct sk_buff *skb, int netnsid)
+static struct net *get_target_net(struct sock *sk, int netnsid)
{
struct net *net;
- net = get_net_ns_by_id(sock_net(skb->sk), netnsid);
+ net = get_net_ns_by_id(sock_net(sk), netnsid);
if (!net)
return ERR_PTR(-EINVAL);
/* For now, the caller is required to have CAP_NET_ADMIN in
* the user namespace owning the target net ns.
*/
- if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
+ if (!sk_ns_capable(sk, net->user_ns, CAP_NET_ADMIN)) {
put_net(net);
return ERR_PTR(-EACCES);
}
@@ -1733,7 +1733,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
ifla_policy, NULL) >= 0) {
if (tb[IFLA_IF_NETNSID]) {
netnsid = nla_get_s32(tb[IFLA_IF_NETNSID]);
- tgt_net = get_target_net(skb, netnsid);
+ tgt_net = get_target_net(skb->sk, netnsid);
if (IS_ERR(tgt_net)) {
tgt_net = net;
netnsid = -1;
@@ -2883,7 +2883,7 @@ static int rtnl_getlink(struct sk_buff *skb, struct nlmsghdr *nlh,
if (tb[IFLA_IF_NETNSID]) {
netnsid = nla_get_s32(tb[IFLA_IF_NETNSID]);
- tgt_net = get_target_net(skb, netnsid);
+ tgt_net = get_target_net(NETLINK_CB(skb).sk, netnsid);
if (IS_ERR(tgt_net))
return PTR_ERR(tgt_net);
}
--
2.13.6
^ permalink raw reply related
* Re: [PATCH net] sctp: fix handling of ICMP Frag Needed for too small MTUs
From: Xin Long @ 2018-01-03 7:31 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, Vlad Yasevich, Neil Horman
In-Reply-To: <bc48ba9bc70796eb309a28b83f7fcf986ad13211.1514928667.git.marcelo.leitner@gmail.com>
On Wed, Jan 3, 2018 at 5:44 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> syzbot reported a hang involving SCTP, on which it kept flooding dmesg
> with the message:
> [ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> low, using default minimum of 512
>
> That happened because whenever SCTP hits an ICMP Frag Needed, it tries
> to adjust to the new MTU and triggers an immediate retransmission. But
> it didn't consider the fact that MTUs smaller than the SCTP minimum MTU
> allowed (512) would not cause the PMTU to change, and issued the
> retransmission anyway (thus leading to another ICMP Frag Needed, and so
> on).
>
> The fix is to disable Path MTU discovery for such transport and to skip
> the retransmission in such cases. By doing this, SCTP will do the
> backoff retransmissions as needed and will likely switch to another
> transport if available.
>
> See-also: https://lkml.org/lkml/2017/12/22/811
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/input.c | 5 ++++-
> net/sctp/transport.c | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index 621b5ca3fd1c17c3d7ef7bb1c7677ab98cebbe77..a24658c6f181e03d85f12dbe929c8bb4abaefcbd 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -412,8 +412,11 @@ void sctp_icmp_frag_needed(struct sock *sk, struct sctp_association *asoc,
> * Needed will never be sent, but if a message was sent before
> * PMTU discovery was disabled that was larger than the PMTU, it
> * would not be fragmented, so it must be re-transmitted fragmented.
> + * If the new PMTU is invalid, we will keep getting ICMP Frag
> + * Needed. In this case, simply avoid the retransmit.
> */
> - sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
> + if (pmtu >= SCTP_DEFAULT_MINSEGMENT)
> + sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
> }
>
> void sctp_icmp_redirect(struct sock *sk, struct sctp_transport *t,
> diff --git a/net/sctp/transport.c b/net/sctp/transport.c
> index 1e5a22430cf56e40a6f323081beb97836b506384..fbd9fe25764d4d98f93c60a48eccefd9cc6b4165 100644
> --- a/net/sctp/transport.c
> +++ b/net/sctp/transport.c
> @@ -259,6 +259,8 @@ void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
> * pmtu discovery on this transport.
> */
> t->pathmtu = SCTP_DEFAULT_MINSEGMENT;
> + t->param_flags = (t->param_flags & ~SPP_PMTUD) |
> + SPP_PMTUD_DISABLE;
It seems that once it hits here, this transport will have the minimum pmtu
forever, even after t->dst has expired. It means this tx path will not come
back to normal any more even when it gets a needfrag with reasonable
pmtu. is it too harsh to this transport ?
Another thing is on sctp_sendmsg, it also checks pmtu_pending that may
be set by needfrag, and goes to sctp_assoc_sync_pmtu to trigger this
warning again.
> } else {
> t->pathmtu = pmtu;
> }
> --
> 2.14.3
>
^ permalink raw reply
* RE: [PATCH v4 net-next 0/4] qed*: Advance to FW 8.33.1.0
From: Elior, Ariel @ 2018-01-03 7:32 UTC (permalink / raw)
To: David Miller, Tayar, Tomer
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20180102.135836.317444223426222615.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> From: Tomer Tayar <Tomer.Tayar-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> Date: Wed, 27 Dec 2017 19:30:04 +0200
>
> > This series advances all qed* drivers to use firmware 8.33.1.0 which brings
> > new capabilities and initial support of new HW. The changes are mostly in
> > qed, and include changes in the FW interface files, as well as updating the
> > FW initialization and debug collection code. The protocol drivers have
> > minor functional changes for this firmware.
> >
> > Patch 1 Rearranges and refactors the FW interface files in preparation of
> > the new FW (no functional change).
> > Patch 2 Prepares the code for support of new HW (no functional change).
> > Patch 3 Actual utilization of the new FW.
> > Patch 4 Advances drivers' version.
> >
> > v3->v4:
> > Fix a compilation issue which was reported by krobot (dependency on CRC8).
> >
> > v2->v3:
> > Resend the series with a fixed title in the cover letter.
> >
> > v1->v2:
> > - Break the previous single patch into several patches.
> > - Fix compilation issues which were reported by krobot.
>
> I'm going to apply this, however....
>
> These firmware update changes are rediculously invasive.
>
> Backporting patches through these updates will be a giant task if not
> impossible for anyone who tries to do something like this.
>
> Who reviewed these changes outside of Cavium to look for clerical
> and typographical errors? I be nobody did. I personally scanned
> them for about 20 minutes.
>
> Therefore, it is my judgment that the way firmware support updates are
> done in the QED driver is detrimental to it's long term
> maintainability.
>
> Thank you.
Hi Dave,
We fully understand the concern regarding the size/depth of these changes,
and the difficulty of getting them reviewed, etc. Hopefully, this is the last time
you will see such massive changes. Future FW upgrades are expected to be far
lighter in their impact on the code. We also plan to make them more
frequent, which will further reduce the size/invasiveness of each change.
Thanks, and appreciate your time spent on reviewing this.
Ariel
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: general protection fault in __netlink_ns_capable
From: Andrei Vagin @ 2018-01-03 7:37 UTC (permalink / raw)
To: syzbot
Cc: Jason, akpm, alexander.deucher, avagin, chris, davem, dsahern,
edumazet, elena.reshetova, gregkh, herbert, johannes.berg,
linux-kernel, lucien.xin, mchehab, netdev, syzkaller-bugs
In-Reply-To: <20180103003508.GA16712@outlook.office365.com>
On Tue, Jan 02, 2018 at 04:35:11PM -0800, Andrei Vagin wrote:
> On Tue, Jan 02, 2018 at 10:58:01AM -0800, syzbot wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 75aa5540627fdb3d8f86229776ea87f995275351
> > git://git.cmpxchg.org/linux-mmots.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> >
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+e432865c29eb4c48c142@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> >
> > netlink: 3 bytes leftover after parsing attributes in process
> > `syzkaller140561'.
> > netlink: 3 bytes leftover after parsing attributes in process
> > `syzkaller140561'.
> > netlink: 3 bytes leftover after parsing attributes in process
> > `syzkaller140561'.
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault: 0000 [#1] SMP KASAN
> > Dumping ftrace buffer:
> > (ftrace buffer empty)
> > Modules linked in:
> > CPU: 1 PID: 3149 Comm: syzkaller140561 Not tainted 4.15.0-rc4-mm1+ #47
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:__netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868
>
> NETLINK_CB(skb).sk is NULL here. It looks like we have to use
> sk_ns_capable instead of netlink_ns_capable:
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index c688dc564b11..408c75de52ea 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1762,7 +1762,7 @@ static struct net *get_target_net(struct sk_buff
> *skb, int netnsid)
> /* For now, the caller is required to have CAP_NET_ADMIN in
> * the user namespace owning the target net ns.
> */
> - if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
> + if (!sk_ns_capable(skb->sk, net->user_ns, CAP_NET_ADMIN)) {
> put_net(net);
> return ERR_PTR(-EACCES);
> }
>
get_target_net() is used twice in the code. In rtnl_getlink(), we need
to use netlink_ns_capable(skb, ...), but in rtnl_dump_ifinfo, we need to
use sk_ns_capable(skb->sk, ...).
Pls, take a look at this patch:
https://patchwork.ozlabs.org/patch/854896/
Subject: rtnetlink: give a user socket to get_target_net()
^ permalink raw reply
* Re: [RFC PATCH net-next 03/19] ipv6: Clear nexthop flags upon netdev up
From: Ido Schimmel @ 2018-01-03 7:44 UTC (permalink / raw)
To: David Ahern; +Cc: Ido Schimmel, netdev, davem, roopa, nicolas.dichtel, mlxsw
In-Reply-To: <de00438c-c5b6-bb5e-0f00-ee92ceea93b7@gmail.com>
Hi David,
On Tue, Jan 02, 2018 at 09:20:47AM -0700, David Ahern wrote:
> On 12/31/17 9:14 AM, Ido Schimmel wrote:
> > Previous patch marked nexthops with the 'dead' and 'linkdown' flags.
> > Clear these flags when the netdev comes back up.
> >
> > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > ---
> > include/net/ip6_route.h | 1 +
> > net/ipv6/addrconf.c | 3 +++
> > net/ipv6/route.c | 29 +++++++++++++++++++++++++++++
> > 3 files changed, 33 insertions(+)
> >
> > diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> > index 18e442ea93d8..caad39198c2a 100644
> > --- a/include/net/ip6_route.h
> > +++ b/include/net/ip6_route.h
> > @@ -169,6 +169,7 @@ void rt6_ifdown(struct net *net, struct net_device *dev);
> > void rt6_mtu_change(struct net_device *dev, unsigned int mtu);
> > void rt6_remove_prefsrc(struct inet6_ifaddr *ifp);
> > void rt6_clean_tohost(struct net *net, struct in6_addr *gateway);
> > +void rt6_sync_up(struct net_device *dev, unsigned int nh_flags);
> >
> > static inline const struct rt6_info *skb_rt6_info(const struct sk_buff *skb)
> > {
> > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> > index ed06b1190f05..b6405568ed7b 100644
> > --- a/net/ipv6/addrconf.c
> > +++ b/net/ipv6/addrconf.c
> > @@ -3484,6 +3484,9 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
> > if (run_pending)
> > addrconf_dad_run(idev);
> >
> > + /* Device has an address by now */
> > + rt6_sync_up(dev, RTNH_F_DEAD);
> > +
>
> Seems like this should be in the NETDEV_UP section, say after
> addrconf_permanent_addr.
Unless the `keep_addr_on_down` sysctl is set, then at this stage the
netdev doesn't have an IP address and we shouldn't clear the dead flag
just yet.
This is consistent with IPv4 that clears the dead flag from nexthops in
a multipath route only if the nexthop device has an IP address. When the
last IPv4 address is removed from a netdev all the routes using it are
flushed and there's nothing to clear upon NETDEV_UP.
Assuming you're OK with that, I can reword the commit message to make it
clearer.
^ 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