* Re: [PATCH net] sfc: ARFS filter IDs
From: kbuild test robot @ 2018-04-24 5:29 UTC (permalink / raw)
To: Edward Cree; +Cc: kbuild-all, linux-net-drivers, David Miller, netdev
In-Reply-To: <2ee1ef47-886d-278d-4a8d-234d74e26ad7@solarflare.com>
[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]
Hi Edward,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url: https://github.com/0day-ci/linux/commits/Edward-Cree/sfc-ARFS-filter-IDs/20180424-080737
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/net/ethernet/sfc/farch.c: In function 'efx_farch_filter_rfs_expire_one':
>> drivers/net/ethernet/sfc/farch.c:2938:7: warning: 'rule' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (rule)
^
coccinelle warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/sfc/efx.c:3032:1-20: alloc with no test, possible model on line 3041
drivers/net/ethernet/sfc/efx.c:3032:1-20: alloc with no test, possible model on line 3062
vim +/rule +2938 drivers/net/ethernet/sfc/farch.c
2902
2903 bool efx_farch_filter_rfs_expire_one(struct efx_nic *efx, u32 flow_id,
2904 unsigned int index)
2905 {
2906 struct efx_farch_filter_state *state = efx->filter_state;
2907 struct efx_farch_filter_table *table;
2908 bool ret = false, force = false;
2909 u16 arfs_id;
2910
2911 down_write(&state->lock);
2912 spin_lock_bh(&efx->rps_hash_lock);
2913 table = &state->table[EFX_FARCH_FILTER_TABLE_RX_IP];
2914 if (test_bit(index, table->used_bitmap) &&
2915 table->spec[index].priority == EFX_FILTER_PRI_HINT) {
2916 struct efx_filter_spec spec;
2917 struct efx_arfs_rule *rule;
2918
2919 efx_farch_filter_to_gen_spec(&spec, &table->spec[index]);
2920 if (!efx->rps_hash_table) {
2921 /* In the absence of the table, we always returned 0 to
2922 * ARFS, so use the same to query it.
2923 */
2924 arfs_id = 0;
2925 } else {
2926 rule = efx_rps_hash_find(efx, &spec);
2927 if (!rule) {
2928 /* ARFS table doesn't know of this filter, remove it */
2929 force = true;
2930 } else {
2931 arfs_id = rule->arfs_id;
2932 if (!efx_rps_check_rule(rule, index, &force))
2933 goto out_unlock;
2934 }
2935 }
2936 if (force || rps_may_expire_flow(efx->net_dev, spec.dmaq_id,
2937 flow_id, arfs_id)) {
> 2938 if (rule)
2939 rule->filter_id = EFX_ARFS_FILTER_ID_REMOVING;
2940 efx_rps_hash_del(efx, &spec);
2941 efx_farch_filter_table_clear_entry(efx, table, index);
2942 ret = true;
2943 }
2944 }
2945 out_unlock:
2946 spin_unlock_bh(&efx->rps_hash_lock);
2947 up_write(&state->lock);
2948 return ret;
2949 }
2950
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 62891 bytes --]
^ permalink raw reply
* Re: [Patch nf] ipvs: initialize tbl->entries in ip_vs_lblc_init_svc()
From: Julian Anastasov @ 2018-04-24 5:17 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, lvs-devel, netfilter-devel, Simon Horman,
Pablo Neira Ayuso
In-Reply-To: <20180423210445.18336-1-xiyou.wangcong@gmail.com>
Hello,
On Mon, 23 Apr 2018, Cong Wang wrote:
> Similarly, tbl->entries is not initialized after kmalloc(),
> therefore causes an uninit-value warning in ip_vs_lblc_check_expire(),
> as reported by syzbot.
>
> Reported-by: <syzbot+3e9695f147fb529aa9bc@syzkaller.appspotmail.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Julian Anastasov <ja@ssi.bg>
> Cc: Pablo Neira Ayuso <pablo@netfilter.org>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Thanks!
Acked-by: Julian Anastasov <ja@ssi.bg>
> ---
> net/netfilter/ipvs/ip_vs_lblc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
> index 3057e453bf31..83918119ceb8 100644
> --- a/net/netfilter/ipvs/ip_vs_lblc.c
> +++ b/net/netfilter/ipvs/ip_vs_lblc.c
> @@ -371,6 +371,7 @@ static int ip_vs_lblc_init_svc(struct ip_vs_service *svc)
> tbl->counter = 1;
> tbl->dead = false;
> tbl->svc = svc;
> + atomic_set(&tbl->entries, 0);
>
> /*
> * Hook periodic timer for garbage collection
> --
> 2.13.0
Regards
^ permalink raw reply
* Re: [Patch nf] ipvs: initialize tbl->entries after allocation
From: Julian Anastasov @ 2018-04-24 5:16 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, lvs-devel, netfilter-devel, Simon Horman,
Pablo Neira Ayuso
In-Reply-To: <20180423205341.13142-1-xiyou.wangcong@gmail.com>
Hello,
On Mon, 23 Apr 2018, Cong Wang wrote:
> tbl->entries is not initialized after kmalloc(), therefore
> causes an uninit-value warning in ip_vs_lblc_check_expire()
> as reported by syzbot.
>
> Reported-by: <syzbot+3dfdea57819073a04f21@syzkaller.appspotmail.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Julian Anastasov <ja@ssi.bg>
> Cc: Pablo Neira Ayuso <pablo@netfilter.org>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Thanks!
Acked-by: Julian Anastasov <ja@ssi.bg>
> ---
> net/netfilter/ipvs/ip_vs_lblcr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/netfilter/ipvs/ip_vs_lblcr.c b/net/netfilter/ipvs/ip_vs_lblcr.c
> index 92adc04557ed..bc2bc5eebcb8 100644
> --- a/net/netfilter/ipvs/ip_vs_lblcr.c
> +++ b/net/netfilter/ipvs/ip_vs_lblcr.c
> @@ -534,6 +534,7 @@ static int ip_vs_lblcr_init_svc(struct ip_vs_service *svc)
> tbl->counter = 1;
> tbl->dead = false;
> tbl->svc = svc;
> + atomic_set(&tbl->entries, 0);
>
> /*
> * Hook periodic timer for garbage collection
> --
> 2.13.0
Regards
^ permalink raw reply
* Re: [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework
From: Stephen Hemminger @ 2018-04-24 5:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Siwei Liu, Jiri Pirko, Sridhar Samudrala, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang
In-Reply-To: <20180424043042-mutt-send-email-mst@kernel.org>
On Tue, 24 Apr 2018 04:42:22 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Apr 23, 2018 at 06:25:03PM -0700, Stephen Hemminger wrote:
> > On Mon, 23 Apr 2018 12:44:39 -0700
> > Siwei Liu <loseweigh@gmail.com> wrote:
> >
> > > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> > > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > >>
> > > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > >> > > > >
> > > >> > > > >I will NAK patches to change to common code for netvsc especially the
> > > >> > > > >three device model. MS worked hard with distro vendors to support transparent
> > > >> > > > >mode, ans we really can't have a new model; or do backport.
> > > >> > > > >
> > > >> > > > >Plus, DPDK is now dependent on existing model.
> > > >> > > >
> > > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities.
> > > >> > >
> > > >> > > The network device model is a userspace API, and DPDK is a userspace application.
> > > >> >
> > > >> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > > >> > AFAIK it's normally banging device registers directly.
> > > >> >
> > > >> > > You can't go breaking userspace even if you don't like the application.
> > > >> >
> > > >> > Could you please explain how is the proposed patchset breaking
> > > >> > userspace? Ignoring DPDK for now, I don't think it changes the userspace
> > > >> > API at all.
> > > >> >
> > > >>
> > > >> The DPDK has a device driver vdev_netvsc which scans the Linux network devices
> > > >> to look for Linux netvsc device and the paired VF device and setup the
> > > >> DPDK environment. This setup creates a DPDK failsafe (bondingish) instance
> > > >> and sets up TAP support over the Linux netvsc device as well as the Mellanox
> > > >> VF device.
> > > >>
> > > >> So it depends on existing 2 device model. You can't go to a 3 device model
> > > >> or start hiding devices from userspace.
> > > >
> > > > Okay so how does the existing patch break that? IIUC does not go to
> > > > a 3 device model since netvsc calls failover_register directly.
> > > >
> > > >> Also, I am working on associating netvsc and VF device based on serial number
> > > >> rather than MAC address. The serial number is how Windows works now, and it makes
> > > >> sense for Linux and Windows to use the same mechanism if possible.
> > > >
> > > > Maybe we should support same for virtio ...
> > > > Which serial do you mean? From vpd?
> > > >
> > > > I guess you will want to keep supporting MAC for old hypervisors?
> >
> > The serial number has always been in the hypervisor since original support of SR-IOV
> > in WS2008. So no backward compatibility special cases would be needed.
>
> Is that a serial from real hardware or a hypervisor thing?
>
>
It is a hypervisor thing in the PCI hyperv code and the hyperv Netvsc interface.
It might also be in the PCI spec, but the value in Hyper-V is being generated by the host.
^ permalink raw reply
* Re: [PATCH net v2] net: ethtool: Add missing kernel doc for FEC parameters
From: Roopa Prabhu @ 2018-04-24 4:41 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David Miller, Vidya Sagar Ravipati, Dustin Byford
In-Reply-To: <20180423225138.8238-1-f.fainelli@gmail.com>
On Mon, Apr 23, 2018 at 3:51 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> While adding support for ethtool::get_fecparam and set_fecparam, kernel
> doc for these functions was missed, add those.
>
> Fixes: 1a5f3da20bd9 ("net: ethtool: add support for forward error correction modes")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next] net: init sk_cookie for inet socket
From: Yafang Shao @ 2018-04-24 4:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Alexei Starovoitov, netdev, LKML
In-Reply-To: <788ce3f1-6534-5c2e-1870-5ebd8ea4ae7f@gmail.com>
On Tue, Apr 24, 2018 at 12:09 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 04/23/2018 08:58 AM, David Miller wrote:
>> From: Yafang Shao <laoar.shao@gmail.com>
>> Date: Sun, 22 Apr 2018 21:50:04 +0800
>>
>>> With sk_cookie we can identify a socket, that is very helpful for
>>> traceing and statistic, i.e. tcp tracepiont and ebpf.
>>> So we'd better init it by default for inet socket.
>>> When using it, we just need call atomic64_read(&sk->sk_cookie).
>>>
>>> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
>>
>> Applied, thank you.
>>
>
> This is adding yet another atomic_inc on a global cache line.
>
That's a trade-off.
> Most applications do not need the cookie being ever set.
>
> The existing mechanism was fine. Set it on demand.
There are some drawback in the existing mechanism.
- we have to set the net->cookie_gen and then sk->sk_cookie when we
want to get the sk_cookie, that's a little expensive as well.
After that change, sock_gen_cookie() could be replaced by
atomic64_read(&sk->sk_cookie) in most places.
- If the application want to get the sk_cookie, it must set it first.
What if the application don't have the permision to write?
Furthermore, maybe it is a security concern ?
Thanks
Yafang
^ permalink raw reply
* Re: [PATCH net-next 0/4] mm,tcp: provide mmap_hook to solve lockdep issue
From: Eric Dumazet @ 2018-04-24 4:30 UTC (permalink / raw)
To: Andy Lutomirski, Eric Dumazet
Cc: Eric Dumazet, David S . Miller, netdev, linux-kernel,
Soheil Hassas Yeganeh, linux-mm, Linux API
In-Reply-To: <CALCETrWOLU+P_jVpuOUQT2e_5ZShAP3OM0yJZMbC=pv5La9Cvg@mail.gmail.com>
On 04/23/2018 07:04 PM, Andy Lutomirski wrote:
> On Mon, Apr 23, 2018 at 2:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Hi Andy
>>
>> On 04/23/2018 02:14 PM, Andy Lutomirski wrote:
>
>>> I would suggest that you rework the interface a bit. First a user would call mmap() on a TCP socket, which would create an empty VMA. (It would set vm_ops to point to tcp_vm_ops or similar so that the TCP code could recognize it, but it would have no effect whatsoever on the TCP state machine. Reading the VMA would get SIGBUS.) Then a user would call a new ioctl() or setsockopt() function and pass something like:
>>
>>
>>>
>>> struct tcp_zerocopy_receive {
>>> void *address;
>>> size_t length;
>>> };
>>>
>>> The kernel would verify that [address, address+length) is entirely inside a single TCP VMA and then would do the vm_insert_range magic.
>>
>> I have no idea what is the proper API for that.
>> Where the TCP VMA(s) would be stored ?
>> In TCP socket, or MM layer ?
>
> MM layer. I haven't tested this at all, and the error handling is
> totally wrong, but I think you'd do something like:
>
> len = get_user(...);
>
> down_read(¤t->mm->mmap_sem);
>
> vma = find_vma(mm, start);
> if (!vma || vma->vm_start > start)
> return -EFAULT;
>
> /* This is buggy. You also need to check that the file is a socket.
> This is probably trivial. */
> if (vma->vm_file->private_data != sock)
> return -EINVAL;
>
> if (len > vma->vm_end - start)
> return -EFAULT; /* too big a request. */
>
> and now you'd do the vm_insert_page() dance, except that you don't
> have to abort the whole procedure if you discover that something isn't
> aligned right. Instead you'd just stop and tell the caller that you
> didn't map the full requested size. You might also need to add some
> code to charge the caller for the pages that get pinned, but that's an
> orthogonal issue.
>
> You also need to provide some way for user programs to signal that
> they're done with the page in question. MADV_DONTNEED might be
> sufficient.
>
> In the mmap() helper, you might want to restrict the mapped size to
> something reasonable. And it might be nice to hook mremap() to
> prevent user code from causing too much trouble.
>
> With my x86-writer-of-TLB-code hat on, I expect the major performance
> costs to be the generic costs of mmap() and munmap() (which only
> happen once per socket instead of once per read if you like my idea),
> the cost of a TLB miss when the data gets read (really not so bad on
> modern hardware), and the cost of the TLB invalidation when user code
> is done with the buffers. The latter is awful, especially in
> multithreaded programs. In fact, it's so bad that it might be worth
> mentioning in the documentation for this code that it just shouldn't
> be used in multithreaded processes. (Also, on non-PCID hardware,
> there's an annoying situation in which a recently-migrated thread that
> removes a mapping sends an IPI to the CPU that the thread used to be
> on. I thought I had a clever idea to get rid of that IPI once, but it
> turned out to be wrong.)
>
> Architectures like ARM that have superior TLB handling primitives will
> not be hurt as badly if this is used my a multithreaded program.
>
>>
>>
>> And I am not sure why the error handling would be better (point 4), unless we can return smaller @length than requested maybe ?
>
> Exactly. If I request 10MB mapped and only the first 9MB are aligned
> right, I still want the first 9 MB.
>
>>
>> Also how the VMA space would be accounted (point 3) when creating an empty VMA (no pages in there yet)
>
> There's nothing to account. It's the same as mapping /dev/null or
> similar -- the mm core should take care of it for you.
>
Thanks Andy, I am working on all this, and initial patch looks sane enough.
include/uapi/linux/tcp.h | 7 +
net/ipv4/tcp.c | 175 +++++++++++++++++++++++------------------------
2 files changed, 93 insertions(+), 89 deletions(-)
I will test all this before sending for review asap.
( I have not done the compat code yet, this can be done later I guess)
^ permalink raw reply
* Re: [PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
From: Matthew Wilcox @ 2018-04-24 3:46 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Michal Hocko, David Miller, Andrew Morton, linux-mm, eric.dumazet,
edumazet, netdev, linux-kernel, mst, jasowang, virtualization,
dm-devel, Vlastimil Babka
In-Reply-To: <alpine.LRH.2.02.1804232003100.2299@file01.intranet.prod.int.rdu2.redhat.com>
On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote:
> Some bugs (such as buffer overflows) are better detected
> with kmalloc code, so we must test the kmalloc path too.
Well now, this brings up another item for the collective TODO list --
implement redzone checks for vmalloc. Unless this is something already
taken care of by kasan or similar.
^ permalink raw reply
* Re: [PATCH 2/2] alx: add disable_wol paramenter
From: AceLan Kao @ 2018-04-24 3:45 UTC (permalink / raw)
To: David Miller
Cc: Andrew Lunn, James Cliburn, Chris Snook, rakesh, netdev,
Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CAFv23Q=QYastpgLxHiwr_PSdoeWfEjiNp6x2F9kM5EYhRee2hA@mail.gmail.com>
Hi,
May I know the final decision of this patch?
Thanks.
Best regards,
AceLan Kao.
2018-04-10 10:40 GMT+08:00 AceLan Kao <acelan.kao@canonical.com>:
> The problem is I don't have a machine with that wakeup issue, and I
> need WoL feature.
> Instead of spreading "alx with WoL" dkms package everywhere, I would
> like to see it's supported in the driver and is disabled by default.
>
> Moreover, the wakeup issue may come from old Atheros chips, or result
> from buggy BIOS.
> With the WoL has been removed from the driver, no one will report
> issue about that, and we don't have any chance to find a fix for it.
>
> Adding this feature back is not covering a paper on the issue, it
> makes people have a chance to examine this feature.
>
> 2018-04-09 22:50 GMT+08:00 David Miller <davem@davemloft.net>:
>> From: Andrew Lunn <andrew@lunn.ch>
>> Date: Mon, 9 Apr 2018 14:39:10 +0200
>>
>>> On Mon, Apr 09, 2018 at 07:35:14PM +0800, AceLan Kao wrote:
>>>> The WoL feature was reported broken and will lead to
>>>> the system resume immediately after suspending.
>>>> This symptom is not happening on every system, so adding
>>>> disable_wol option and disable WoL by default to prevent the issue from
>>>> happening again.
>>>
>>>> const char alx_drv_name[] = "alx";
>>>>
>>>> +/* disable WoL by default */
>>>> +bool disable_wol = 1;
>>>> +module_param(disable_wol, bool, 0);
>>>> +MODULE_PARM_DESC(disable_wol, "Disable Wake on Lan feature");
>>>> +
>>>
>>> Hi AceLan
>>>
>>> This seems like you are papering over the cracks. And module
>>> parameters are not liked.
>>>
>>> Please try to find the real problem.
>>
>> Agreed.
^ permalink raw reply
* Re: [PATCH net-next] net: fib_rules: fix l3mdev netlink attr processing
From: David Ahern @ 2018-04-24 3:43 UTC (permalink / raw)
To: David Miller, roopa; +Cc: netdev
In-Reply-To: <20180423.232158.1633374650832506893.davem@davemloft.net>
On 4/23/18 9:21 PM, David Miller wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
> Date: Mon, 23 Apr 2018 20:08:41 -0700
>
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> Fixes: b16fb418b1bf ("net: fib_rules: add extack support")
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Applied.
>
> It would be nice to get rid of these if() conditionals dangling
> around ifdef blocks. They are quite error prone.
>
I'll send a patch. I'd prefer a different message when NET_L3_MASTER_DEV
is not enabled.
^ permalink raw reply
* Re: [PATCH 1/1] Revert "rds: ib: add error handle"
From: santosh.shilimkar @ 2018-04-24 3:27 UTC (permalink / raw)
To: Zhu Yanjun, linux-rdma, rds-devel; +Cc: davem, netdev
In-Reply-To: <1524533941-4072-1-git-send-email-yanjun.zhu@oracle.com>
On 4/23/18 6:39 PM, Zhu Yanjun wrote:
> This reverts commit 3b12f73a5c2977153f28a224392fd4729b50d1dc.
>
> After long time discussion and investigations, it seems that there
> is no mem leak. So this patch is reverted.
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
> ---
Well your fix was not for any leaks but just proper labels for
graceful exits. I don't know which long time discussion
you are referring but there is no need to revert this change
unless you see any issue with your change.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH net-next] net: fib_rules: fix l3mdev netlink attr processing
From: David Miller @ 2018-04-24 3:21 UTC (permalink / raw)
To: roopa; +Cc: netdev, dsa
In-Reply-To: <1524539321-9103-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Mon, 23 Apr 2018 20:08:41 -0700
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Fixes: b16fb418b1bf ("net: fib_rules: add extack support")
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Applied.
It would be nice to get rid of these if() conditionals dangling
around ifdef blocks. They are quite error prone.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] fib rules extack support
From: Roopa Prabhu @ 2018-04-24 3:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Ahern, Ido Schimmel
In-Reply-To: <20180423.102154.1160969910648664493.davem@davemloft.net>
On Mon, Apr 23, 2018 at 7:21 AM, David Miller <davem@davemloft.net> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
> Date: Sat, 21 Apr 2018 09:41:29 -0700
>
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> First patch refactors code to move fib rule netlink handling
>> into a common function. This became obvious when adding
>> duplicate extack msgs in add and del paths. Second patch
>> adds extack msgs.
>>
>> v2 - Dropped the ip route get support and selftests from
>> the series to look at the input path some more (as pointed
>> out by ido). Will come back to that next week when i have
>> some time. resending just the extack part for now.
>
> Series applied, but I was really looking forward to having those
> nice test cases in the tree.
yes, am on it. (and also excited about my first selftest!)
thanks (I just sent a follow-up bug fix for vrf).
^ permalink raw reply
* [PATCH net-next] net: fib_rules: fix l3mdev netlink attr processing
From: Roopa Prabhu @ 2018-04-24 3:08 UTC (permalink / raw)
To: davem; +Cc: netdev, dsa
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Fixes: b16fb418b1bf ("net: fib_rules: add extack support")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
Looks like I broke this when i split extack changes into a separate patch :(
net/core/fib_rules.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index ebd9351..2271c80 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -541,8 +541,10 @@ static int fib_nl2rule(struct sk_buff *skb, struct nlmsghdr *nlh,
nlrule->l3mdev = nla_get_u8(tb[FRA_L3MDEV]);
if (nlrule->l3mdev != 1)
#endif
+ {
NL_SET_ERR_MSG(extack, "Invalid l3mdev");
goto errout_free;
+ }
}
nlrule->action = frh->action;
--
2.1.4
^ permalink raw reply related
* [PATCH] mac80211_hwsim: fix a possible memory leak in hwsim_new_radio_nl()
From: YueHaibing @ 2018-04-24 3:08 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, YueHaibing
'hwname' should be freed before leaving from the error handling cases,
otherwise it will cause mem leak
Fixes: cb1a5bae5684 ("mac80211_hwsim: add permanent mac address option for new radios")
Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
drivers/net/wireless/mac80211_hwsim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 96d26cf..4a017a0 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3236,6 +3236,7 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct genl_info *info)
GENL_SET_ERR_MSG(info,"MAC is no valid source addr");
NL_SET_BAD_ATTR(info->extack,
info->attrs[HWSIM_ATTR_PERM_ADDR]);
+ kfree(hwname);
return -EINVAL;
}
--
2.7.0
^ permalink raw reply related
* [PATCH v2 8/8] ipconfig: Write NTP server IPs to /proc/net/ipconfig/ntp_servers
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
Distributed filesystems are most effective when the server and client
clocks are synchronised. Embedded devices often use NFS for their
root filesystem but typically do not contain an RTC, so the clocks of
the NFS server and the embedded device will be out-of-sync when the root
filesystem is mounted (and may not be synchronised until late in the
boot process).
Extend ipconfig with the ability to export IP addresses of NTP servers
it discovers to /proc/net/ipconfig/ntp_servers. They can be supplied as
follows:
- If ipconfig is configured manually via the "ip=" or "nfsaddrs="
kernel command line parameters, one NTP server can be specified in
the new "<ntp0-ip>" parameter.
- If ipconfig is autoconfigured via DHCP, request DHCP option 42 in
the DHCPDISCOVER message, and record the IP addresses of up to three
NTP servers sent by the responding DHCP server in the subsequent
DHCPOFFER message.
ipconfig will only write the NTP server IP addresses it discovers to
/proc/net/ipconfig/ntp_servers, one per line (in the order received from
the DHCP server, if DHCP autoconfiguration is used); making use of these
NTP servers is the responsibility of a user space process (e.g. an
initrd/initram script that invokes an NTP client before mounting an NFS
root filesystem).
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
Documentation/filesystems/nfs/nfsroot.txt | 35 +++++++--
net/ipv4/ipconfig.c | 118 +++++++++++++++++++++++++++---
2 files changed, 136 insertions(+), 17 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
index a1030bea60d3..d2963123eb1c 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -5,6 +5,7 @@ Written 1996 by Gero Kuhlmann <gero@gkminix.han.de>
Updated 1997 by Martin Mares <mj@atrey.karlin.mff.cuni.cz>
Updated 2006 by Nico Schottelius <nico-kernel-nfsroot@schottelius.org>
Updated 2006 by Horms <horms@verge.net.au>
+Updated 2018 by Chris Novakovic <chris@chrisn.me.uk>
@@ -79,7 +80,7 @@ nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
- <dns0-ip>:<dns1-ip>
+ <dns0-ip>:<dns1-ip>:<ntp0-ip>
This parameter tells the kernel how to configure IP addresses of devices
and also how to set up the IP routing table. It was originally called
@@ -178,9 +179,18 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
<dns1-ip> IP address of secondary nameserver.
See <dns0-ip>.
- After configuration (whether manual or automatic) is complete, a file is
- created at /proc/net/pnp in the following format; lines are omitted if
- their respective value is empty following configuration.
+ <ntp0-ip> IP address of a Network Time Protocol (NTP) server.
+ Value is exported to /proc/net/ipconfig/ntp_servers, but is
+ otherwise unused (see below).
+
+ Default: None if not using autoconfiguration; determined
+ automatically if using autoconfiguration.
+
+ After configuration (whether manual or automatic) is complete, two files
+ are created in the following format; lines are omitted if their respective
+ value is empty following configuration:
+
+ - /proc/net/pnp:
#PROTO: <DHCP|BOOTP|RARP|MANUAL> (depending on configuration method)
domain <dns-domain> (if autoconfigured, the DNS domain)
@@ -189,13 +199,26 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
nameserver <dns2-ip> (tertiary name server IP)
bootserver <server-ip> (NFS server IP)
- <dns-domain> and <dns2-ip> are requested during autoconfiguration; they
- cannot be specified as part of the "ip=" kernel command line parameter.
+ - /proc/net/ipconfig/ntp_servers:
+
+ <ntp0-ip> (NTP server IP)
+ <ntp1-ip> (NTP server IP)
+ <ntp2-ip> (NTP server IP)
+
+ <dns-domain> and <dns2-ip> (in /proc/net/pnp) and <ntp1-ip> and <ntp2-ip>
+ (in /proc/net/ipconfig/ntp_servers) are requested during autoconfiguration;
+ they cannot be specified as part of the "ip=" kernel command line parameter.
Because the "domain" and "nameserver" options are recognised by DNS
resolvers, /etc/resolv.conf is often linked to /proc/net/pnp on systems
that use an NFS root filesystem.
+ Note that the kernel will not synchronise the system time with any NTP
+ servers it discovers; this is the responsibility of a user space process
+ (e.g. an initrd/initramfs script that passes the IP addresses listed in
+ /proc/net/ipconfig/ntp_servers to an NTP client before mounting the real
+ root filesystem if it is on NFS).
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 9abf833f3a99..d839d74853fc 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -28,6 +28,9 @@
*
* Multiple Nameservers in /proc/net/pnp
* -- Josef Siemes <jsiemes@web.de>, Aug 2002
+ *
+ * NTP servers in /proc/net/ipconfig/ntp_servers
+ * -- Chris Novakovic <chris@chrisn.me.uk>, April 2018
*/
#include <linux/types.h>
@@ -93,6 +96,7 @@
#define CONF_TIMEOUT_MAX (HZ*30) /* Maximum allowed timeout */
#define CONF_NAMESERVERS_MAX 3 /* Maximum number of nameservers
- '3' from resolv.h */
+#define CONF_NTP_SERVERS_MAX 3 /* Maximum number of NTP servers */
#define NONE cpu_to_be32(INADDR_NONE)
#define ANY cpu_to_be32(INADDR_ANY)
@@ -152,6 +156,7 @@ static int ic_proto_used; /* Protocol used, if any */
#define ic_proto_used 0
#endif
static __be32 ic_nameservers[CONF_NAMESERVERS_MAX]; /* DNS Server IP addresses */
+static __be32 ic_ntp_servers[CONF_NTP_SERVERS_MAX]; /* NTP server IP addresses */
static u8 ic_domain[64]; /* DNS (not NIS) domain name */
/*
@@ -579,6 +584,15 @@ static inline void __init ic_nameservers_predef(void)
ic_nameservers[i] = NONE;
}
+/* Predefine NTP servers */
+static inline void __init ic_ntp_servers_predef(void)
+{
+ int i;
+
+ for (i = 0; i < CONF_NTP_SERVERS_MAX; i++)
+ ic_ntp_servers[i] = NONE;
+}
+
/*
* DHCP/BOOTP support.
*/
@@ -674,6 +688,7 @@ ic_dhcp_init_options(u8 *options, struct ic_device *d)
17, /* Boot path */
26, /* MTU */
40, /* NIS domain name */
+ 42, /* NTP servers */
};
*e++ = 55; /* Parameter request list */
@@ -753,12 +768,13 @@ static void __init ic_bootp_init_ext(u8 *e)
*/
static inline void __init ic_bootp_init(void)
{
- /* Re-initialise all name servers to NONE, in case any were set via the
- * "ip=" or "nfsaddrs=" kernel command line parameters: any IP addresses
- * specified there will already have been decoded but are no longer
- * needed
+ /* Re-initialise all name servers and NTP servers to NONE, in case any
+ * were set via the "ip=" or "nfsaddrs=" kernel command line parameters:
+ * any IP addresses specified there will already have been decoded but
+ * are no longer needed
*/
ic_nameservers_predef();
+ ic_ntp_servers_predef();
dev_add_pack(&bootp_packet_type);
}
@@ -922,6 +938,15 @@ static void __init ic_do_bootp_ext(u8 *ext)
ic_bootp_string(utsname()->domainname, ext+1, *ext,
__NEW_UTS_LEN);
break;
+ case 42: /* NTP servers */
+ servers = *ext / 4;
+ if (servers > CONF_NTP_SERVERS_MAX)
+ servers = CONF_NTP_SERVERS_MAX;
+ for (i = 0; i < servers; i++) {
+ if (ic_ntp_servers[i] == NONE)
+ memcpy(&ic_ntp_servers[i], ext+1+4*i, 4);
+ }
+ break;
}
}
@@ -1268,6 +1293,7 @@ static int __init ic_dynamic(void)
#ifdef CONFIG_PROC_FS
+/* Name servers: */
static int pnp_seq_show(struct seq_file *seq, void *v)
{
int i;
@@ -1306,7 +1332,7 @@ static const struct file_operations pnp_seq_fops = {
};
/* Create the /proc/net/ipconfig directory */
-static int ipconfig_proc_net_init(void)
+static int __init ipconfig_proc_net_init(void)
{
ipconfig_dir = proc_net_mkdir(&init_net, "ipconfig", init_net.proc_net);
if (!ipconfig_dir)
@@ -1314,6 +1340,52 @@ static int ipconfig_proc_net_init(void)
return 0;
}
+
+/* Create a new file under /proc/net/ipconfig */
+static int ipconfig_proc_net_create(const char *name,
+ const struct file_operations *fops)
+{
+ char *pname;
+ struct proc_dir_entry *p;
+
+ if (!ipconfig_dir)
+ return -ENOMEM;
+
+ pname = kasprintf(GFP_KERNEL, "%s%s", "ipconfig/", name);
+ if (!pname)
+ return -ENOMEM;
+
+ p = proc_create(pname, 0444, init_net.proc_net, fops);
+ kfree(pname);
+ if (!p)
+ return -ENOMEM;
+
+ return 0;
+}
+
+/* Write NTP server IP addresses to /proc/net/ipconfig/ntp_servers */
+static int ntp_servers_seq_show(struct seq_file *seq, void *v)
+{
+ int i;
+
+ for (i = 0; i < CONF_NTP_SERVERS_MAX; i++) {
+ if (ic_ntp_servers[i] != NONE)
+ seq_printf(seq, "%pI4\n", &ic_ntp_servers[i]);
+ }
+ return 0;
+}
+
+static int ntp_servers_seq_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, ntp_servers_seq_show, NULL);
+}
+
+static const struct file_operations ntp_servers_seq_fops = {
+ .open = ntp_servers_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
#endif /* CONFIG_PROC_FS */
/*
@@ -1388,17 +1460,20 @@ static int __init ip_auto_config(void)
int err;
unsigned int i;
- /* Initialise all name servers to NONE (but only if the "ip=" or
- * "nfsaddrs=" kernel command line parameters weren't decoded, otherwise
- * we'll overwrite the IP addresses specified there)
+ /* Initialise all name servers and NTP servers to NONE (but only if the
+ * "ip=" or "nfsaddrs=" kernel command line parameters weren't decoded,
+ * otherwise we'll overwrite the IP addresses specified there)
*/
- if (ic_set_manually == 0)
+ if (ic_set_manually == 0) {
ic_nameservers_predef();
+ ic_ntp_servers_predef();
+ }
#ifdef CONFIG_PROC_FS
proc_create("pnp", 0444, init_net.proc_net, &pnp_seq_fops);
- ipconfig_proc_net_init();
+ if (ipconfig_proc_net_init() == 0)
+ ipconfig_proc_net_create("ntp_servers", &ntp_servers_seq_fops);
#endif /* CONFIG_PROC_FS */
if (!ic_enable)
@@ -1523,6 +1598,19 @@ static int __init ip_auto_config(void)
if (i + 1 == CONF_NAMESERVERS_MAX)
pr_cont("\n");
}
+ /* NTP servers (if any): */
+ for (i = 0; i < CONF_NTP_SERVERS_MAX; i++) {
+ if (ic_ntp_servers[i] != NONE) {
+ if (i == 0)
+ pr_info(" ntpserver%u=%pI4",
+ i, &ic_ntp_servers[i]);
+ else
+ pr_cont(", ntpserver%u=%pI4",
+ i, &ic_ntp_servers[i]);
+ }
+ if (i + 1 == CONF_NTP_SERVERS_MAX)
+ pr_cont("\n");
+ }
#endif /* !SILENT */
/*
@@ -1620,8 +1708,9 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
- /* Initialise all name servers to NONE */
+ /* Initialise all name servers and NTP servers to NONE */
ic_nameservers_predef();
+ ic_ntp_servers_predef();
/* Parse string for static IP assignment. */
ip = addrs;
@@ -1680,6 +1769,13 @@ static int __init ip_auto_config_setup(char *addrs)
ic_nameservers[1] = NONE;
}
break;
+ case 9:
+ if (CONF_NTP_SERVERS_MAX >= 1) {
+ ic_ntp_servers[0] = in_aton(ip);
+ if (ic_ntp_servers[0] == ANY)
+ ic_ntp_servers[0] = NONE;
+ }
+ break;
}
}
ip = cp;
--
2.14.1
^ permalink raw reply related
* [PATCH v2 7/8] ipconfig: Create /proc/net/ipconfig directory
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
To allow ipconfig to report IP configuration details to user space
processes without cluttering /proc/net, create a new subdirectory
/proc/net/ipconfig. All files containing IP configuration details should
be written to this directory.
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
net/ipv4/ipconfig.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index e11dfd29a929..9abf833f3a99 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -158,6 +158,9 @@ static u8 ic_domain[64]; /* DNS (not NIS) domain name */
* Private state.
*/
+/* proc_dir_entry for /proc/net/ipconfig */
+static struct proc_dir_entry *ipconfig_dir;
+
/* Name of user-selected boot device */
static char user_dev_name[IFNAMSIZ] __initdata = { 0, };
@@ -1301,6 +1304,16 @@ static const struct file_operations pnp_seq_fops = {
.llseek = seq_lseek,
.release = single_release,
};
+
+/* Create the /proc/net/ipconfig directory */
+static int ipconfig_proc_net_init(void)
+{
+ ipconfig_dir = proc_net_mkdir(&init_net, "ipconfig", init_net.proc_net);
+ if (!ipconfig_dir)
+ return -ENOMEM;
+
+ return 0;
+}
#endif /* CONFIG_PROC_FS */
/*
@@ -1384,6 +1397,8 @@ static int __init ip_auto_config(void)
#ifdef CONFIG_PROC_FS
proc_create("pnp", 0444, init_net.proc_net, &pnp_seq_fops);
+
+ ipconfig_proc_net_init();
#endif /* CONFIG_PROC_FS */
if (!ic_enable)
--
2.14.1
^ permalink raw reply related
* [PATCH v2 6/8] ipconfig: Correctly initialise ic_nameservers
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
ic_nameservers, which stores the list of name servers discovered by
ipconfig, is initialised (i.e. has all of its elements set to NONE, or
0xffffffff) by ic_nameservers_predef() in the following scenarios:
- before the "ip=" and "nfsaddrs=" kernel command line parameters are
parsed (in ip_auto_config_setup());
- before autoconfiguring via DHCP or BOOTP (in ic_bootp_init()), in
order to clear any values that may have been set after parsing "ip="
or "nfsaddrs=" and are no longer needed.
This means that ic_nameservers_predef() is not called when neither "ip="
nor "nfsaddrs=" is specified on the kernel command line. In this
scenario, every element in ic_nameservers remains set to 0x00000000,
which is indistinguishable from ANY and causes pnp_seq_show() to write
the following (bogus) information to /proc/net/pnp:
#MANUAL
nameserver 0.0.0.0
nameserver 0.0.0.0
nameserver 0.0.0.0
This is potentially problematic for systems that blindly link
/etc/resolv.conf to /proc/net/pnp.
Ensure that ic_nameservers is also initialised when neither "ip=" nor
"nfsaddrs=" are specified by calling ic_nameservers_predef() in
ip_auto_config(), but only when ip_auto_config_setup() was not called
earlier. This causes the following to be written to /proc/net/pnp, and
is consistent with what gets written when ipconfig is configured
manually but no name servers are specified on the kernel command line:
#MANUAL
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
net/ipv4/ipconfig.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 0f460d6d3cce..e11dfd29a929 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -750,6 +750,11 @@ static void __init ic_bootp_init_ext(u8 *e)
*/
static inline void __init ic_bootp_init(void)
{
+ /* Re-initialise all name servers to NONE, in case any were set via the
+ * "ip=" or "nfsaddrs=" kernel command line parameters: any IP addresses
+ * specified there will already have been decoded but are no longer
+ * needed
+ */
ic_nameservers_predef();
dev_add_pack(&bootp_packet_type);
@@ -1370,6 +1375,13 @@ static int __init ip_auto_config(void)
int err;
unsigned int i;
+ /* Initialise all name servers to NONE (but only if the "ip=" or
+ * "nfsaddrs=" kernel command line parameters weren't decoded, otherwise
+ * we'll overwrite the IP addresses specified there)
+ */
+ if (ic_set_manually == 0)
+ ic_nameservers_predef();
+
#ifdef CONFIG_PROC_FS
proc_create("pnp", 0444, init_net.proc_net, &pnp_seq_fops);
#endif /* CONFIG_PROC_FS */
@@ -1593,6 +1605,7 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ /* Initialise all name servers to NONE */
ic_nameservers_predef();
/* Parse string for static IP assignment. */
--
2.14.1
^ permalink raw reply related
* [PATCH v2 5/8] ipconfig: Document /proc/net/pnp
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
Fully document the format used by the /proc/net/pnp file written by
ipconfig, explain where its values originate from, and clarify that the
tertiary name server IP and DNS domain name are only written to the file
when autoconfiguration is used.
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
Documentation/filesystems/nfs/nfsroot.txt | 34 ++++++++++++++++++++++++++-----
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
index 1513e5d663fd..a1030bea60d3 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -110,6 +110,9 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
will not be triggered if it is missing and NFS root is not
in operation.
+ Value is exported to /proc/net/pnp with the prefix "bootserver "
+ (see below).
+
Default: Determined using autoconfiguration.
The address of the autoconfiguration server is used.
@@ -165,12 +168,33 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
Default: any
- <dns0-ip> IP address of first nameserver.
- Value gets exported by /proc/net/pnp which is often linked
- on embedded systems by /etc/resolv.conf.
+ <dns0-ip> IP address of primary nameserver.
+ Value is exported to /proc/net/pnp with the prefix "nameserver "
+ (see below).
+
+ Default: None if not using autoconfiguration; determined
+ automatically if using autoconfiguration.
+
+ <dns1-ip> IP address of secondary nameserver.
+ See <dns0-ip>.
+
+ After configuration (whether manual or automatic) is complete, a file is
+ created at /proc/net/pnp in the following format; lines are omitted if
+ their respective value is empty following configuration.
+
+ #PROTO: <DHCP|BOOTP|RARP|MANUAL> (depending on configuration method)
+ domain <dns-domain> (if autoconfigured, the DNS domain)
+ nameserver <dns0-ip> (primary name server IP)
+ nameserver <dns1-ip> (secondary name server IP)
+ nameserver <dns2-ip> (tertiary name server IP)
+ bootserver <server-ip> (NFS server IP)
+
+ <dns-domain> and <dns2-ip> are requested during autoconfiguration; they
+ cannot be specified as part of the "ip=" kernel command line parameter.
- <dns1-ip> IP address of second nameserver.
- Same as above.
+ Because the "domain" and "nameserver" options are recognised by DNS
+ resolvers, /etc/resolv.conf is often linked to /proc/net/pnp on systems
+ that use an NFS root filesystem.
nfsrootdebug
--
2.14.1
^ permalink raw reply related
* [PATCH v2 4/8] ipconfig: BOOTP: Request CONF_NAMESERVERS_MAX name servers
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
When ipconfig is autoconfigured via BOOTP, the request packet
initialised by ic_bootp_init_ext() always allocates 8 bytes for the name
server option, limiting the BOOTP server to responding with at most 2
name servers even though ipconfig in fact supports an arbitrary number
of name servers (as defined by CONF_NAMESERVERS_MAX, which is currently
3).
Only request name servers in the request packet if CONF_NAMESERVERS_MAX
is positive (to comply with [1, §3.8]), and allocate enough space in the
packet for CONF_NAMESERVERS_MAX name servers to indicate the maximum
number we can accept in response.
[1] RFC 2132, "DHCP Options and BOOTP Vendor Extensions":
https://tools.ietf.org/rfc/rfc2132.txt
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
net/ipv4/ipconfig.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index bcf3c4f9882d..0f460d6d3cce 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -721,9 +721,11 @@ static void __init ic_bootp_init_ext(u8 *e)
*e++ = 3; /* Default gateway request */
*e++ = 4;
e += 4;
+#if CONF_NAMESERVERS_MAX > 0
*e++ = 6; /* (DNS) name server request */
- *e++ = 8;
- e += 8;
+ *e++ = 4 * CONF_NAMESERVERS_MAX;
+ e += 4 * CONF_NAMESERVERS_MAX;
+#endif
*e++ = 12; /* Host name request */
*e++ = 32;
e += 32;
--
2.14.1
^ permalink raw reply related
* [PATCH v2 3/8] ipconfig: BOOTP: Don't request IEN-116 name servers
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
When ipconfig is autoconfigured via BOOTP, the request packet
initialised by ic_bootp_init_ext() allocates 8 bytes for tag 5 ("Name
Server" [1, §3.7]), but tag 5 in the response isn't processed by
ic_do_bootp_ext(). Instead, allocate the 8 bytes to tag 6 ("Domain Name
Server" [1, §3.8]), which is processed by ic_do_bootp_ext(), and appears
to have been the intended tag to request.
This won't cause any breakage for existing users, as tag 5 responses
provided by BOOTP servers weren't being processed anyway.
[1] RFC 2132, "DHCP Options and BOOTP Vendor Extensions":
https://tools.ietf.org/rfc/rfc2132.txt
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
net/ipv4/ipconfig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index d0ea0ecc9008..bcf3c4f9882d 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -721,7 +721,7 @@ static void __init ic_bootp_init_ext(u8 *e)
*e++ = 3; /* Default gateway request */
*e++ = 4;
e += 4;
- *e++ = 5; /* Name server request */
+ *e++ = 6; /* (DNS) name server request */
*e++ = 8;
e += 8;
*e++ = 12; /* Host name request */
--
2.14.1
^ permalink raw reply related
* [PATCH v2 2/8] ipconfig: Tidy up reporting of name servers
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
Commit 5e953778a2aab04929a5e7b69f53dc26e39b079e ("ipconfig: add
nameserver IPs to kernel-parameter ip=") adds the IP addresses of
discovered name servers to the summary printed by ipconfig when
configuration is complete. It appears the intention in ip_auto_config()
was to print the name servers on a new line (especially given the
spacing and lack of comma before "nameserver0="), but they're actually
printed on the same line as the NFS root filesystem configuration
summary:
[ 0.686186] IP-Config: Complete:
[ 0.686226] device=eth0, hwaddr=xx:xx:xx:xx:xx:xx, ipaddr=10.0.0.2, mask=255.255.255.0, gw=10.0.0.1
[ 0.686328] host=test, domain=example.com, nis-domain=(none)
[ 0.686386] bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath= nameserver0=10.0.0.1
This makes it harder to read and parse ipconfig's output. Instead, print
the name servers on a separate line:
[ 0.791250] IP-Config: Complete:
[ 0.791289] device=eth0, hwaddr=xx:xx:xx:xx:xx:xx, ipaddr=10.0.0.2, mask=255.255.255.0, gw=10.0.0.1
[ 0.791407] host=test, domain=example.com, nis-domain=(none)
[ 0.791475] bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath=
[ 0.791476] nameserver0=10.0.0.1
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
net/ipv4/ipconfig.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 43f620feb1c4..d0ea0ecc9008 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1481,16 +1481,19 @@ static int __init ip_auto_config(void)
&ic_servaddr, &root_server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(", mtu=%d", ic_dev_mtu);
- for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
+ /* Name servers (if any): */
+ for (i = 0; i < CONF_NAMESERVERS_MAX; i++) {
if (ic_nameservers[i] != NONE) {
- pr_cont(" nameserver%u=%pI4",
- i, &ic_nameservers[i]);
- break;
+ if (i == 0)
+ pr_info(" nameserver%u=%pI4",
+ i, &ic_nameservers[i]);
+ else
+ pr_cont(", nameserver%u=%pI4",
+ i, &ic_nameservers[i]);
}
- for (i++; i < CONF_NAMESERVERS_MAX; i++)
- if (ic_nameservers[i] != NONE)
- pr_cont(", nameserver%u=%pI4", i, &ic_nameservers[i]);
- pr_cont("\n");
+ if (i + 1 == CONF_NAMESERVERS_MAX)
+ pr_cont("\n");
+ }
#endif /* !SILENT */
/*
--
2.14.1
^ permalink raw reply related
* [PATCH v2 1/8] ipconfig: Document setting of NIS domain name
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>
ic_do_bootp_ext() is responsible for parsing the "ip=" and "nfsaddrs="
kernel parameters. If a "." character is found in parameter 4 (the
client's hostname), everything before the first "." is used as the
hostname, and everything after it is used as the NIS domain name (but
not necessarily the DNS domain name).
Document this behaviour in Documentation/filesystems/nfs/nfsroot.txt,
as it is not made explicit.
Signed-off-by: Chris Novakovic <chris@chrisn.me.uk>
---
Documentation/filesystems/nfs/nfsroot.txt | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
index 5efae00f6c7f..1513e5d663fd 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -123,10 +123,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
Default: Determined using autoconfiguration.
- <hostname> Name of the client. May be supplied by autoconfiguration,
- but its absence will not trigger autoconfiguration.
- If specified and DHCP is used, the user provided hostname will
- be carried in the DHCP request to hopefully update DNS record.
+ <hostname> Name of the client. If a '.' character is present, anything
+ before the first '.' is used as the client's hostname, and anything
+ after it is used as its NIS domain name. May be supplied by
+ autoconfiguration, but its absence will not trigger autoconfiguration.
+ If specified and DHCP is used, the user-provided hostname (and NIS
+ domain name, if present) will be carried in the DHCP request; this
+ may cause a DNS record to be created or updated for the client.
Default: Client IP address is used in ASCII notation.
--
2.14.1
^ permalink raw reply related
* [PATCH v2 0/8] ipconfig: NTP server support, bug fixes, documentation improvements
From: Chris Novakovic @ 2018-04-24 2:56 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Chris Novakovic
This series (against net-next) makes various improvements to ipconfig:
- Patch #1 correctly documents the behaviour of parameter 4 in the
"ip=" and "nfsaddrs=" command line parameter.
- Patch #2 tidies up the printk()s for reporting configured name
servers.
- Patch #3 fixes a bug in autoconfiguration via BOOTP whereby the IP
addresses of IEN-116 name servers are requested from the BOOTP
server, rather than those of DNS name servers.
- Patch #4 requests the number of DNS servers specified by
CONF_NAMESERVERS_MAX when autoconfiguring via BOOTP, rather than
hardcoding it to 2.
- Patch #5 fully documents the contents and format of /proc/net/pnp in
Documentation/filesystems/nfs/nfsroot.txt.
- Patch #6 fixes a bug whereby bogus information is written to
/proc/net/pnp when ipconfig is not used.
- Patch #7 creates a new procfs directory for ipconfig-related
configuration reports at /proc/net/ipconfig.
- Patch #8 allows for NTP servers to be configured (manually on the
kernel command line or automatically via DHCP), enabling systems with
an NFS root filesystem to synchronise their clock before mounting
their root filesystem. NTP server IP addresses are written to
/proc/net/ipconfig/ntp_servers.
Changes from v1:
- David requested that a new directory /proc/net/ipconfig be created to
contain ipconfig-related configuration reports, which is implemented
in the new patch #7. NTP server IPs are now written to this directory
instead of /proc/net/ntp in the new patch #8.
- Cong and David both requested that the modification to CREDITS be
dropped. This patch has been removed from the series.
Chris Novakovic (8):
ipconfig: Document setting of NIS domain name
ipconfig: Tidy up reporting of name servers
ipconfig: BOOTP: Don't request IEN-116 name servers
ipconfig: BOOTP: Request CONF_NAMESERVERS_MAX name servers
ipconfig: Document /proc/net/pnp
ipconfig: Correctly initialise ic_nameservers
ipconfig: Create /proc/net/ipconfig directory
ipconfig: Write NTP server IPs to /proc/net/ipconfig/ntp_servers
Documentation/filesystems/nfs/nfsroot.txt | 70 ++++++++++++--
net/ipv4/ipconfig.c | 151 +++++++++++++++++++++++++++---
2 files changed, 200 insertions(+), 21 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: [PATCH iproute2 net-next] vxlan: add ttl auto in help message
From: David Ahern @ 2018-04-24 2:48 UTC (permalink / raw)
To: Hangbin Liu, netdev
In-Reply-To: <1524537617-22863-1-git-send-email-liuhangbin@gmail.com>
On 4/23/18 8:40 PM, Hangbin Liu wrote:
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> ip/iplink_vxlan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
applied to iproute2-next. Thanks,
^ 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