* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Dumazet @ 2019-07-24 6:39 UTC (permalink / raw)
To: netdev, David S. Miller, Florian Westphal, Ilya Maximets,
Eric Dumazet, David Ahern, linux-kernel, syzkaller-bugs
In-Reply-To: <20190724013813.GB643@sol.localdomain>
On 7/24/19 3:38 AM, Eric Biggers wrote:
> [This email was generated by a script. Let me know if you have any suggestions
> to make it better, or if you want it re-generated with the latest status.]
>
> Of the currently open syzbot reports against the upstream kernel, I've manually
> marked 99 of them as possibly being bugs in the net subsystem. This category
> only includes the networking bugs that I couldn't assign to a more specific
> component (bpf, xfrm, bluetooth, tls, tipc, sctp, wireless, etc.). I've listed
> these reports below, sorted by an algorithm that tries to list first the reports
> most likely to be still valid, important, and actionable.
>
> Of these 99 bugs, 17 were seen in mainline in the last week.
>
> Of these 99 bugs, 4 were bisected to commits from the following people:
>
> Florian Westphal <fw@strlen.de>
> Ilya Maximets <i.maximets@samsung.com>
> Eric Dumazet <edumazet@google.com>
> David Ahern <dsahern@gmail.com>
>
> If you believe a bug is no longer valid, please close the syzbot report by
> sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
> original thread, as explained at https://goo.gl/tpsmEJ#status
>
> If you believe I misattributed a bug to the net subsystem, please let me know,
> and if possible forward the report to the correct people or mailing list.
>
Some of the bugs have been fixed already, before syzbot found them.
Why force human to be gentle to bots and actually replying to them ?
I usually simply wait that syzbot is finding the bug does not repro anymore,
but now if you send these emails, we will have even more pressure on us.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Song Liu @ 2019-07-24 6:30 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Kees Cook, linux-security@vger.kernel.org,
Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team,
Lorenz Bauer, Jann Horn, Greg KH, Linux API
In-Reply-To: <1DE886F3-3982-45DE-B545-67AD6A4871AB@amacapital.net>
> On Jul 23, 2019, at 6:40 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
>
>
>> On Jul 23, 2019, at 3:56 PM, Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jul 23, 2019, at 8:11 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>
>>> On Mon, Jul 22, 2019 at 1:54 PM Song Liu <songliubraving@fb.com> wrote:
>>>>
>>>> Hi Andy, Lorenz, and all,
>>>>
>>>>> On Jul 2, 2019, at 2:32 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>
>>>>> On Tue, Jul 2, 2019 at 2:04 PM Kees Cook <keescook@chromium.org> wrote:
>>>>>>
>>>>>>> On Mon, Jul 01, 2019 at 06:59:13PM -0700, Andy Lutomirski wrote:
>>>>>>> I think I'm understanding your motivation. You're not trying to make
>>>>>>> bpf() generically usable without privilege -- you're trying to create
>>>>>>> a way to allow certain users to access dangerous bpf functionality
>>>>>>> within some limits.
>>>>>>>
>>>>>>> That's a perfectly fine goal, but I think you're reinventing the
>>>>>>> wheel, and the wheel you're reinventing is quite complicated and
>>>>>>> already exists. I think you should teach bpftool to be secure when
>>>>>>> installed setuid root or with fscaps enabled and put your policy in
>>>>>>> bpftool. If you want to harden this a little bit, it would seem
>>>>>>> entirely reasonable to add a new CAP_BPF_ADMIN and change some, but
>>>>>>> not all, of the capable() checks to check CAP_BPF_ADMIN instead of the
>>>>>>> capabilities that they currently check.
>>>>>>
>>>>>> If finer grained controls are wanted, it does seem like the /dev/bpf
>>>>>> path makes the most sense. open, request abilities, use fd. The open can
>>>>>> be mediated by DAC and LSM. The request can be mediated by LSM. This
>>>>>> provides a way to add policy at the LSM level and at the tool level.
>>>>>> (i.e. For tool-level controls: leave LSM wide open, make /dev/bpf owned
>>>>>> by "bpfadmin" and bpftool becomes setuid "bpfadmin". For fine-grained
>>>>>> controls, leave /dev/bpf wide open and add policy to SELinux, etc.)
>>>>>>
>>>>>> With only a new CAP, you don't get the fine-grained controls. (The
>>>>>> "request abilities" part is the key there.)
>>>>>
>>>>> Sure you do: the effective set. It has somewhat bizarre defaults, but
>>>>> I don't think that's a real problem. Also, this wouldn't be like
>>>>> CAP_DAC_READ_SEARCH -- you can't accidentally use your BPF caps.
>>>>>
>>>>> I think that a /dev capability-like object isn't totally nuts, but I
>>>>> think we should do it well, and this patch doesn't really achieve
>>>>> that. But I don't think bpf wants fine-grained controls like this at
>>>>> all -- as I pointed upthread, a fine-grained solution really wants
>>>>> different treatment for the different capable() checks, and a bunch of
>>>>> them won't resemble capabilities or /dev/bpf at all.
>>>>
>>>> With 5.3-rc1 out, I am back on this. :)
>>>>
>>>> How about we modify the set as:
>>>> 1. Introduce sys_bpf_with_cap() that takes fd of /dev/bpf.
>>>
>>> I'm fine with this in principle, but:
>>>
>>>> 2. Better handling of capable() calls through bpf code. I guess the
>>>> biggest problem here is is_priv in verifier.c:bpf_check().
>>>
>>> I think it would be good to understand exactly what /dev/bpf will
>>> enable one to do. Without some care, it would just become the next
>>> CAP_SYS_ADMIN: if you can open it, sure, you're not root, but you can
>>> intercept network traffic, modify cgroup behavior, and do plenty of
>>> other things, any of which can probably be used to completely take
>>> over the system.
>>
>> Well, yes. sys_bpf() is pretty powerful.
>>
>> The goal of /dev/bpf is to enable special users to call sys_bpf(). In
>> the meanwhile, such users should not take down the whole system easily
>> by accident, e.g., with rm -rf /.
>
> That’s easy, though — bpftool could learn to read /etc/bpfusers before allowing ruid != 0.
This is a great idea! fscaps + /etc/bpfusers should do the trick.
>
>>
>> It is similar to CAP_BPF_ADMIN, without really adding the CAP_.
>>
>> I think adding new CAP_ requires much more effort.
>>
>
> A new CAP_ is straightforward — add the definition and change the max cap.
>
>>>
>>> It would also be nice to understand why you can't do what you need to
>>> do entirely in user code using setuid or fscaps.
>>
>> It is not very easy to achieve the same control: only certain users can
>> run certain tools (bpftool, etc.).
>>
>> The closest approach I can find is:
>> 1. use libcap (pam_cap) to give CAP_SETUID to certain users;
>> 2. add setuid(0) to bpftool.
>>
>> The difference between this approach and /dev/bpf is that certain users
>> would be able to run other tools that call setuid(). Though I am not
>> sure how many tools call setuid(), and how risky they are.
>
> I think you’re misunderstanding me. Install bpftool with either the setuid (S_ISUID) mode or with an appropriate fscap bit — see the setcap(8) manpage.
>
> The downside of this approach is that it won’t work well in a container, and containers are cool these days :)
>
>>
>>>
>>> Finally, at risk of rehashing some old arguments, I'll point out that
>>> the bpf() syscall is an unusual design to begin with. As an example,
>>> consider bpf_prog_attach(). Outside of bpf(), if I want to change the
>>> behavior of a cgroup, I would write to a file in
>>> /sys/kernel/cgroup/unified/whatever/, and normal DAC and MAC rules
>>> apply. With bpf(), however, I just call bpf() to attach a program to
>>> the cgroup. bpf() says "oh, you are capable(CAP_NET_ADMIN) -- go for
>>> it!". Unless I missed something major, and I just re-read the code,
>>> there is no check that the caller has write or LSM permission to
>>> anything at all in cgroupfs, and the existing API would make it very
>>> awkward to impose any kind of DAC rules here.
>>>
>>> So I think it might actually be time to repay some techincal debt and
>>> come up with a real fix. As a less intrusive approach, you could see
>>> about requiring ownership of the cgroup directory instead of
>>> CAP_NET_ADMIN. As a more intrusive but perhaps better approach, you
>>> could invert the logic to to make it work like everything outside of
>>> cgroup: add pseudo-files like bpf.inet_ingress to the cgroup
>>> directories, and require a writable fd to *that* to a new improved
>>> attach API. If a user could do:
>>>
>>> int fd = open("/sys/fs/cgroup/.../bpf.inet_attach", O_RDWR); /* usual
>>> DAC and MAC policy applies */
>>> int bpf_fd = setup the bpf stuff; /* no privilege required, unless
>>> the program is huge or needs is_priv */
>>> bpf(BPF_IMPROVED_ATTACH, target = fd, program = bpf_fd);
>>>
>>> there would be no capabilities or global privilege at all required for
>>> this. It would just work with cgroup delegation, containers, etc.
>>>
>>> I think you could even pull off this type of API change with only
>>> libbpf changes. In particular, there's this code:
>>>
>>> int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type,
>>> unsigned int flags)
>>> {
>>> union bpf_attr attr;
>>>
>>> memset(&attr, 0, sizeof(attr));
>>> attr.target_fd = target_fd;
>>> attr.attach_bpf_fd = prog_fd;
>>> attr.attach_type = type;
>>> attr.attach_flags = flags;
>>>
>>> return sys_bpf(BPF_PROG_ATTACH, &attr, sizeof(attr));
>>> }
>>>
>>> This would instead do something like:
>>>
>>> int specific_target_fd = openat(target_fd, bpf_type_to_target[type], O_RDWR);
>>> attr.target_fd = specific_target_fd;
>>> ...
>>>
>>> return sys_bpf(BPF_PROG_IMPROVED_ATTACH, &attr, sizeof(attr));
>>>
>>> Would this solve your problem without needing /dev/bpf at all?
>>
>> This gives fine grain access control. I think it solves the problem.
>> But it also requires a lot of rework to sys_bpf(). And it may also
>> break backward/forward compatibility?
>>
>
> I think the compatibility issue is manageable. The current bpf() interface would be supported for at least several years, and libbpf could detect that the new interface isn’t supported and fall back the old interface
You are right. New BPF_PROG_IMPROVED_ATTACH helps compatibility.
I missed that part.
>
>> Personally, I think it is an overkill for the original motivation:
>> call sys_bpf() with special user instead of root.
>
> It’s overkill for your specific use case, but I’m trying to encourage you to either solve your problem entirely in userspace or to solve a more general problem in the kernel :)
I do like both proposals. Thanks for these invaluable suggestions.
>
> In furtherance of bpf’s goal of world domination, I think it would be great if it Just Worked in a container. My proposal does this.
Let me think more about this and discuss with the team.
Thanks again,
Song
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in bpf_int_jit_compile
From: syzbot @ 2019-07-24 6:28 UTC (permalink / raw)
To: andriin, ast, bpf, daniel, kafai, linux-kernel, netdev,
songliubraving, syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1760ff84600000
kernel config: https://syzkaller.appspot.com/x/.config?x=7937b718ddac333b
dashboard link: https://syzkaller.appspot.com/bug?extid=35101610ff3e83119b1b
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13c017a4600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=173f8278600000
The bug was bisected to:
commit 2589726d12a1b12eaaa93c7f1ea64287e383c7a5
Author: Alexei Starovoitov <ast@kernel.org>
Date: Sat Jun 15 19:12:20 2019 +0000
bpf: introduce bounded loops
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13df66afa00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=103f66afa00000
console output: https://syzkaller.appspot.com/x/log.txt?x=17df66afa00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+35101610ff3e83119b1b@syzkaller.appspotmail.com
Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
==================================================================
BUG: KASAN: slab-out-of-bounds in do_jit /arch/x86/net/bpf_jit_comp.c:966
[inline]
BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x4d19/0x7530
/arch/x86/net/bpf_jit_comp.c:1132
Read of size 4 at addr ffff8880960cc2bc by task syz-executor607/7822
CPU: 0 PID: 7822 Comm: syz-executor607 Not tainted 5.2.0+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack /lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 /lib/dump_stack.c:113
print_address_description+0x75/0x5b0 /mm/kasan/report.c:351
__kasan_report+0x14b/0x1c0 /mm/kasan/report.c:482
kasan_report+0x26/0x50 /mm/kasan/common.c:612
__asan_report_load4_noabort+0x14/0x20 /mm/kasan/generic_report.c:131
do_jit /arch/x86/net/bpf_jit_comp.c:966 [inline]
bpf_int_jit_compile+0x4d19/0x7530 /arch/x86/net/bpf_jit_comp.c:1132
bpf_prog_select_runtime+0x756/0xa50 /kernel/bpf/core.c:1725
bpf_prog_load /kernel/bpf/syscall.c:1702 [inline]
__do_sys_bpf+0x7d4e/0xc0e0 /kernel/bpf/syscall.c:2849
__se_sys_bpf /kernel/bpf/syscall.c:2808 [inline]
__x64_sys_bpf+0x7a/0x90 /kernel/bpf/syscall.c:2808
do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4402c9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffeb7a02c18 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004402c9
RDX: 0000000000000046 RSI: 0000000020000180 RDI: 0000000000000005
RBP: 00000000006ca018 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000ffffffff R11: 0000000000000246 R12: 0000000000401b50
R13: 0000000000401be0 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 7822:
save_stack /mm/kasan/common.c:69 [inline]
set_track /mm/kasan/common.c:77 [inline]
__kasan_kmalloc+0x11c/0x1b0 /mm/kasan/common.c:487
kasan_kmalloc+0x9/0x10 /mm/kasan/common.c:501
kmem_cache_alloc_trace+0x215/0x2f0 /mm/slab.c:3550
kmalloc /./include/linux/slab.h:552 [inline]
kzalloc /./include/linux/slab.h:748 [inline]
bpf_int_jit_compile+0x1b2/0x7530 /arch/x86/net/bpf_jit_comp.c:1092
bpf_prog_select_runtime+0x756/0xa50 /kernel/bpf/core.c:1725
bpf_prog_load /kernel/bpf/syscall.c:1702 [inline]
__do_sys_bpf+0x7d4e/0xc0e0 /kernel/bpf/syscall.c:2849
__se_sys_bpf /kernel/bpf/syscall.c:2808 [inline]
__x64_sys_bpf+0x7a/0x90 /kernel/bpf/syscall.c:2808
do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 7329:
save_stack /mm/kasan/common.c:69 [inline]
set_track /mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x12a/0x1e0 /mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 /mm/kasan/common.c:457
__cache_free /mm/slab.c:3425 [inline]
kfree+0x115/0x200 /mm/slab.c:3756
tomoyo_path_perm+0x6cc/0x8b0 /security/tomoyo/file.c:842
tomoyo_inode_getattr+0x1c/0x20 /security/tomoyo/tomoyo.c:129
security_inode_getattr+0xd5/0x150 /security/security.c:1182
vfs_getattr+0x2a/0x6d0 /fs/stat.c:115
vfs_statx /fs/stat.c:191 [inline]
vfs_stat /./include/linux/fs.h:3182 [inline]
__do_sys_newstat /fs/stat.c:341 [inline]
__se_sys_newstat+0x10c/0x210 /fs/stat.c:337
__x64_sys_newstat+0x5b/0x70 /fs/stat.c:337
do_syscall_64+0xfe/0x140 /arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8880960cc280
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 28 bytes to the right of
32-byte region [ffff8880960cc280, ffff8880960cc2a0)
The buggy address belongs to the page:
page:ffffea0002583300 refcount:1 mapcount:0 mapping:ffff8880aa4001c0
index:0xffff8880960ccfc1
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea00027f47c8 ffffea0002a53a48 ffff8880aa4001c0
raw: ffff8880960ccfc1 ffff8880960cc000 000000010000003f 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880960cc180: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
ffff8880960cc200: fb fb fb fb fc fc fc fc 00 00 01 fc fc fc fc fc
> ffff8880960cc280: 00 00 00 00 fc fc fc fc 00 00 fc fc fc fc fc fc
^
ffff8880960cc300: fb fb fb fb fc fc fc fc 00 00 01 fc fc fc fc fc
ffff8880960cc380: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [bpf-next 2/6] tcp: add skb-less helpers to retrieve SYN cookie
From: kbuild test robot @ 2019-07-24 6:19 UTC (permalink / raw)
To: Petar Penkov
Cc: kbuild-all, netdev, bpf, davem, ast, daniel, edumazet, lmb, sdf,
Petar Penkov
In-Reply-To: <20190723002042.105927-3-ppenkov.kernel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]
Hi Petar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Petar-Penkov/Introduce-a-BPF-helper-to-generate-SYN-cookies/20190723-235628
base: https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: parisc-c8000_defconfig (attached as .config)
compiler: hppa64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=parisc
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
hppa64-linux-ld: arch/parisc/kernel/entry.o(.text.hot+0x22b8): cannot reach preempt_schedule_irq
arch/parisc/kernel/entry.o: In function `intr_do_preempt':
(.text.hot+0x22b8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `preempt_schedule_irq' defined in .sched.text section in kernel/sched/core.o
net/ipv4/tcp_input.o: In function `.LC240':
>> (.data.rel.ro+0x718): undefined reference to `__cookie_v6_init_sequence'
---
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: 18429 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] block/bio, fs: convert put_page() to put_user_page*()
From: Christoph Hellwig @ 2019-07-24 6:17 UTC (permalink / raw)
To: john.hubbard
Cc: Andrew Morton, Alexander Viro, Anna Schumaker, David S . Miller,
Dominique Martinet, Eric Van Hensbergen, Jason Gunthorpe,
Jason Wang, Jens Axboe, Latchesar Ionkov, Michael S . Tsirkin,
Miklos Szeredi, Trond Myklebust, Christoph Hellwig,
Matthew Wilcox, linux-mm, LKML, ceph-devel, kvm, linux-block,
linux-cifs, linux-fsdevel, linux-nfs, linux-rdma, netdev,
samba-technical, v9fs-developer, virtualization, John Hubbard
In-Reply-To: <20190724042518.14363-1-jhubbard@nvidia.com>
On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubbard@gmail.com wrote:
> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter.
> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when
> it is time to release the pages. That allows choosing between put_page()
> and put_user_page*().
>
> * Pass in one more piece of information to bio_release_pages: a "from_gup"
> parameter. Similar use as above.
>
> * Change the block layer, and several file systems, to use
> put_user_page*().
I think we can do this in a simple and better way. We have 5 ITER_*
types. Of those ITER_DISCARD as the name suggests never uses pages, so
we can skip handling it. ITER_PIPE is rejected іn the direct I/O path,
which leaves us with three.
Out of those ITER_BVEC needs a user page reference, so we want to call
put_user_page* on it. ITER_BVEC always already has page reference,
which means in the block direct I/O path path we alread don't take
a page reference. We should extent that handling to all other calls
of iov_iter_get_pages / iov_iter_get_pages_alloc. I think we should
just reject ITER_KVEC for direct I/O as well as we have no users and
it is rather pointless. Alternatively if we see a use for it the
callers should always have a life page reference anyway (or might
be on kmalloc memory), so we really should not take a reference either.
In other words: the only time we should ever have to put a page in
this patch is when they are user pages. We'll need to clean up
various bits of code for that, but that can be done gradually before
even getting to the actual put_user_pages conversion.
^ permalink raw reply
* Re: [PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Jian-Hong Pan @ 2019-07-24 6:13 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, Christoph Hellwig
Cc: linux-wireless, Linux Netdev List, Linux Kernel,
Linux Upstreaming Team, Daniel Drake, stable
In-Reply-To: <CAPpJ_edQRMiBcdB-dTxhti8nK0eX4GPRUOgimzWW1JC3ZZjRHw@mail.gmail.com>
Jian-Hong Pan <jian-hong@endlessm.com> 於 2019年7月11日 週四 下午1:28寫道：
>
> Jian-Hong Pan <jian-hong@endlessm.com> 於 2019年7月11日 週四 下午1:25寫道：
> >
> > Testing with RTL8822BE hardware, when available memory is low, we
> > frequently see a kernel panic and system freeze.
> >
> > First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
> >
> > rx routine starvation
> > WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> > [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> >
> > Then we see a variety of different error conditions and kernel panics,
> > such as this one (trimmed):
> >
> > rtw_pci 0000:02:00.0: pci bus timeout, check dma status
> > skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL>
> > ------------[ cut here ]------------
> > kernel BUG at net/core/skbuff.c:105!
> > invalid opcode: 0000 [#1] SMP NOPTI
> > RIP: 0010:skb_panic+0x43/0x45
> >
> > When skb allocation fails and the "rx routine starvation" is hit, the
> > function returns immediately without updating the RX ring. At this
> > point, the RX ring may continue referencing an old skb which was already
> > handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> > bad things happen.
> >
> > This patch allocates a new, data-sized skb first in RX ISR. After
> > copying the data in, we pass it to the upper layers. However, if skb
> > allocation fails, we effectively drop the frame. In both cases, the
> > original, full size ring skb is reused.
> >
> > In addition, to fixing the kernel crash, the RX routine should now
> > generally behave better under low memory conditions.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> > Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> > Cc: <stable@vger.kernel.org>
> > ---
>
> Sorry, I forget to place the version difference here.
>
> v2:
> - Allocate new data-sized skb and put data into it, then pass it to
> mac80211. Reuse the original skb in RX ring by DMA sync.
> - Modify the commit message.
> - Introduce following [PATCH v3 2/2] rtw88: pci: Use DMA sync instead
> of remapping in RX ISR.
>
> v3:
> - Same as v2.
>
> v4:
> - Fix comment: allocate a new skb for this frame, discard the frame
> if none available
>
> > drivers/net/wireless/realtek/rtw88/pci.c | 49 +++++++++++-------------
> > 1 file changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
> > index cfe05ba7280d..c415f5e94fed 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
> > u32 pkt_offset;
> > u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
> > u32 buf_desc_sz = chip->rx_buf_desc_sz;
> > + u32 new_len;
> > u8 *rx_desc;
> > dma_addr_t dma;
> >
> > @@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
> > pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> > pkt_stat.shift;
> >
> > - if (pkt_stat.is_c2h) {
> > - /* keep rx_desc, halmac needs it */
> > - skb_put(skb, pkt_stat.pkt_len + pkt_offset);
> > + /* allocate a new skb for this frame,
> > + * discard the frame if none available
> > + */
> > + new_len = pkt_stat.pkt_len + pkt_offset;
> > + new = dev_alloc_skb(new_len);
> > + if (WARN_ONCE(!new, "rx routine starvation\n"))
> > + goto next_rp;
> > +
> > + /* put the DMA data including rx_desc from phy to new skb */
> > + skb_put_data(new, skb->data, new_len);
> >
> > - /* pass offset for further operation */
> > - *((u32 *)skb->cb) = pkt_offset;
> > - skb_queue_tail(&rtwdev->c2h_queue, skb);
> > + if (pkt_stat.is_c2h) {
> > + /* pass rx_desc & offset for further operation */
> > + *((u32 *)new->cb) = pkt_offset;
> > + skb_queue_tail(&rtwdev->c2h_queue, new);
> > ieee80211_queue_work(rtwdev->hw, &rtwdev->c2h_work);
> > } else {
> > - /* remove rx_desc, maybe use skb_pull? */
> > - skb_put(skb, pkt_stat.pkt_len);
> > - skb_reserve(skb, pkt_offset);
> > -
> > - /* alloc a smaller skb to mac80211 */
> > - new = dev_alloc_skb(pkt_stat.pkt_len);
> > - if (!new) {
> > - new = skb;
> > - } else {
> > - skb_put_data(new, skb->data, skb->len);
> > - dev_kfree_skb_any(skb);
> > - }
> > - /* TODO: merge into rx.c */
> > - rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
> > + /* remove rx_desc */
> > + skb_pull(new, pkt_offset);
> > +
> > + rtw_rx_stats(rtwdev, pkt_stat.vif, new);
> > memcpy(new->cb, &rx_status, sizeof(rx_status));
> > ieee80211_rx_irqsafe(rtwdev->hw, new);
> > }
> >
> > - /* skb delivered to mac80211, alloc a new one in rx ring */
> > - new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
> > - if (WARN(!new, "rx routine starvation\n"))
> > - return;
> > -
> > - ring->buf[cur_rp] = new;
> > - rtw_pci_reset_rx_desc(rtwdev, new, ring, cur_rp, buf_desc_sz);
> > +next_rp:
> > + /* new skb delivered to mac80211, re-enable original skb DMA */
> > + rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
> >
> > /* host read next element in ring */
> > if (++cur_rp >= ring->r.len)
> > --
> > 2.22.0
> >
Gentle ping! Any comment for this patch set (v4) will be appreciated.
Jian-Hong Pan
^ permalink raw reply
* [PATCH v3] drivers: net: xgene: Remove acpi_has_method() calls
From: Kelsey Skunberg @ 2019-07-24 6:06 UTC (permalink / raw)
To: iyappan, keyur, quan, davem, netdev, linux-kernel
Cc: skunberg.kelsey, skhan, linux-kernel-mentees
In-Reply-To: <20190723185811.8548-1-skunberg.kelsey@gmail.com>
acpi_evaluate_object will already return an error if the needed method
does not exist. Remove unnecessary acpi_has_method() calls and check the
returned acpi_status for failure instead.
Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
---
Changes in v2:
- Fixed white space warnings and errors
Changes in v3:
- Resolved build errors caused by missing bracket
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 9 ++++-----
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 9 +++++----
drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c | 9 ++++-----
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 61a465097cb8..79924efd4ab7 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -694,6 +694,7 @@ bool xgene_ring_mgr_init(struct xgene_enet_pdata *p)
static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
{
struct device *dev = &pdata->pdev->dev;
+ acpi_status status;
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
@@ -712,11 +713,9 @@ static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
udelay(5);
} else {
#ifdef CONFIG_ACPI
- if (acpi_has_method(ACPI_HANDLE(&pdata->pdev->dev), "_RST")) {
- acpi_evaluate_object(ACPI_HANDLE(&pdata->pdev->dev),
- "_RST", NULL, NULL);
- } else if (acpi_has_method(ACPI_HANDLE(&pdata->pdev->dev),
- "_INI")) {
+ status = acpi_evaluate_object(ACPI_HANDLE(&pdata->pdev->dev),
+ "_RST", NULL, NULL);
+ if (ACPI_FAILURE(status)) {
acpi_evaluate_object(ACPI_HANDLE(&pdata->pdev->dev),
"_INI", NULL, NULL);
}
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c b/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
index 6453fc2ebb1f..3b3dc5b25b29 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
@@ -437,6 +437,7 @@ static void xgene_sgmac_tx_disable(struct xgene_enet_pdata *p)
static int xgene_enet_reset(struct xgene_enet_pdata *p)
{
struct device *dev = &p->pdev->dev;
+ acpi_status status;
if (!xgene_ring_mgr_init(p))
return -ENODEV;
@@ -460,12 +461,12 @@ static int xgene_enet_reset(struct xgene_enet_pdata *p)
}
} else {
#ifdef CONFIG_ACPI
- if (acpi_has_method(ACPI_HANDLE(&p->pdev->dev), "_RST"))
- acpi_evaluate_object(ACPI_HANDLE(&p->pdev->dev),
- "_RST", NULL, NULL);
- else if (acpi_has_method(ACPI_HANDLE(&p->pdev->dev), "_INI"))
+ status = acpi_evaluate_object(ACPI_HANDLE(&p->pdev->dev),
+ "_RST", NULL, NULL);
+ if (ACPI_FAILURE(status)) {
acpi_evaluate_object(ACPI_HANDLE(&p->pdev->dev),
"_INI", NULL, NULL);
+ }
#endif
}
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c b/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
index 133eb91c542e..78584089d76d 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
@@ -380,6 +380,7 @@ static void xgene_xgmac_tx_disable(struct xgene_enet_pdata *pdata)
static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
{
struct device *dev = &pdata->pdev->dev;
+ acpi_status status;
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
@@ -393,11 +394,9 @@ static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
udelay(5);
} else {
#ifdef CONFIG_ACPI
- if (acpi_has_method(ACPI_HANDLE(&pdata->pdev->dev), "_RST")) {
- acpi_evaluate_object(ACPI_HANDLE(&pdata->pdev->dev),
- "_RST", NULL, NULL);
- } else if (acpi_has_method(ACPI_HANDLE(&pdata->pdev->dev),
- "_INI")) {
+ status = acpi_evaluate_object(ACPI_HANDLE(&pdata->pdev->dev),
+ "_RST", NULL, NULL);
+ if (ACPI_FAILURE(status)) {
acpi_evaluate_object(ACPI_HANDLE(&pdata->pdev->dev),
"_INI", NULL, NULL);
}
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 8/8] net: jme: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 6:06 UTC (permalink / raw)
Cc: Guo-Fu Tseng, David S . Miller, netdev, linux-kernel,
Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/jme.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 0b668357db4d..6815bd18a477 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -3000,7 +3000,7 @@ jme_init_one(struct pci_dev *pdev,
netdev->max_mtu = MAX_ETHERNET_JUMBO_PACKET_SIZE - ETH_HLEN;
SET_NETDEV_DEV(netdev, &pdev->dev);
- pci_set_drvdata(pdev, netdev);
+ dev_set_drvdata(&pdev->dev, netdev);
/*
* init adapter info
@@ -3193,8 +3193,7 @@ jme_shutdown(struct pci_dev *pdev)
static int
jme_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct jme_adapter *jme = netdev_priv(netdev);
if (!netif_running(netdev))
@@ -3236,8 +3235,7 @@ jme_suspend(struct device *dev)
static int
jme_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct jme_adapter *jme = netdev_priv(netdev);
if (!netif_running(netdev))
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 7/8] igb: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 6:06 UTC (permalink / raw)
Cc: Jeff Kirsher, David S . Miller, intel-wired-lan, netdev,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/intel/igb/igb_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index b4df3e319467..ed301428c0ce 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3048,7 +3048,7 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
SET_NETDEV_DEV(netdev, &pdev->dev);
- pci_set_drvdata(pdev, netdev);
+ dev_set_drvdata(&pdev->dev, netdev);
adapter = netdev_priv(netdev);
adapter->netdev = netdev;
adapter->pdev = pdev;
@@ -8879,8 +8879,7 @@ static int __maybe_unused igb_resume(struct device *dev)
static int __maybe_unused igb_runtime_idle(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct igb_adapter *adapter = netdev_priv(netdev);
if (!igb_has_link(adapter))
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 6/8] i40e: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 6:06 UTC (permalink / raw)
Cc: Jeff Kirsher, David S . Miller, intel-wired-lan, netdev,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 9ebbe3da61bb..a83198a0ba51 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14938,7 +14938,7 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (is_valid_ether_addr(hw->mac.port_addr))
pf->hw_features |= I40E_HW_PORT_ID_VALID;
- pci_set_drvdata(pdev, pf);
+ dev_set_drvdata(&pdev->dev, pf);
pci_save_state(pdev);
dev_info(&pdev->dev,
@@ -15605,8 +15605,7 @@ static void i40e_shutdown(struct pci_dev *pdev)
**/
static int __maybe_unused i40e_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct i40e_pf *pf = pci_get_drvdata(pdev);
+ struct i40e_pf *pf = dev_get_drvdata(dev);
struct i40e_hw *hw = &pf->hw;
/* If we're already suspended, then there is nothing to do */
@@ -15656,8 +15655,7 @@ static int __maybe_unused i40e_suspend(struct device *dev)
**/
static int __maybe_unused i40e_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct i40e_pf *pf = pci_get_drvdata(pdev);
+ struct i40e_pf *pf = dev_get_drvdata(dev);
int err;
/* If we're not suspended, then there is nothing to do */
@@ -15674,7 +15672,7 @@ static int __maybe_unused i40e_resume(struct device *dev)
*/
err = i40e_restore_interrupt_scheme(pf);
if (err) {
- dev_err(&pdev->dev, "Cannot restore interrupt scheme: %d\n",
+ dev_err(dev, "Cannot restore interrupt scheme: %d\n",
err);
}
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 5/8] fm10k: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 6:06 UTC (permalink / raw)
Cc: Jeff Kirsher, David S . Miller, intel-wired-lan, netdev,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index e49fb51d3613..b4aa49b53c61 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -2144,7 +2144,7 @@ static int fm10k_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
SET_NETDEV_DEV(netdev, &pdev->dev);
interface = netdev_priv(netdev);
- pci_set_drvdata(pdev, interface);
+ dev_set_drvdata(&pdev->dev, interface);
interface->netdev = netdev;
interface->pdev = pdev;
@@ -2352,7 +2352,7 @@ static int fm10k_handle_resume(struct fm10k_intfc *interface)
**/
static int __maybe_unused fm10k_resume(struct device *dev)
{
- struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
+ struct fm10k_intfc *interface = dev_get_drvdata(dev);
struct net_device *netdev = interface->netdev;
struct fm10k_hw *hw = &interface->hw;
int err;
@@ -2379,7 +2379,7 @@ static int __maybe_unused fm10k_resume(struct device *dev)
**/
static int __maybe_unused fm10k_suspend(struct device *dev)
{
- struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
+ struct fm10k_intfc *interface = dev_get_drvdata(dev);
struct net_device *netdev = interface->netdev;
netif_device_detach(netdev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 4/8] e1000e: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 6:06 UTC (permalink / raw)
Cc: Jeff Kirsher, David S . Miller, intel-wired-lan, netdev,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/intel/e1000e/netdev.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index e4baa13b3cda..ad203a2a64c4 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6297,7 +6297,7 @@ static void e1000e_flush_lpic(struct pci_dev *pdev)
static int e1000e_pm_freeze(struct device *dev)
{
- struct net_device *netdev = pci_get_drvdata(to_pci_dev(dev));
+ struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
netif_device_detach(netdev);
@@ -6630,7 +6630,7 @@ static int __e1000_resume(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int e1000e_pm_thaw(struct device *dev)
{
- struct net_device *netdev = pci_get_drvdata(to_pci_dev(dev));
+ struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
e1000e_set_interrupt_capability(adapter);
@@ -6679,8 +6679,7 @@ static int e1000e_pm_resume(struct device *dev)
static int e1000e_pm_runtime_idle(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
u16 eee_lp;
@@ -7105,7 +7104,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
netdev->irq = pdev->irq;
- pci_set_drvdata(pdev, netdev);
+ dev_set_drvdata(&pdev->dev, netdev);
adapter = netdev_priv(netdev);
hw = &adapter->hw;
adapter->netdev = netdev;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 3/8] net: broadcom: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 6:06 UTC (permalink / raw)
Cc: Rasesh Mody, GR-Linux-NIC-Dev, David S . Miller, Michael Chan,
Siva Reddy Kallam, Prashant Sreedharan, netdev, linux-kernel,
Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/broadcom/bnx2.c | 8 +++-----
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 +++-----
drivers/net/ethernet/broadcom/tg3.c | 8 +++-----
3 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index dfdd14eadd57..da538a7bac14 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -8586,7 +8586,7 @@ bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
bp = netdev_priv(dev);
- pci_set_drvdata(pdev, dev);
+ dev_set_drvdata(&pdev->dev, dev);
/*
* In-flight DMA from 1st kernel could continue going in kdump kernel.
@@ -8673,8 +8673,7 @@ bnx2_remove_one(struct pci_dev *pdev)
static int
bnx2_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct bnx2 *bp = netdev_priv(dev);
if (netif_running(dev)) {
@@ -8693,8 +8692,7 @@ bnx2_suspend(struct device *device)
static int
bnx2_resume(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct bnx2 *bp = netdev_priv(dev);
if (!netif_running(dev))
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 7134d2c3eb1c..956015acd97f 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -10662,7 +10662,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->netdev_ops = &bnxt_netdev_ops;
dev->watchdog_timeo = BNXT_TX_TIMEOUT;
dev->ethtool_ops = &bnxt_ethtool_ops;
- pci_set_drvdata(pdev, dev);
+ dev_set_drvdata(&pdev->dev, dev);
rc = bnxt_alloc_hwrm_resources(bp);
if (rc)
@@ -10920,8 +10920,7 @@ static void bnxt_shutdown(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int bnxt_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct bnxt *bp = netdev_priv(dev);
int rc = 0;
@@ -10937,8 +10936,7 @@ static int bnxt_suspend(struct device *device)
static int bnxt_resume(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct bnxt *bp = netdev_priv(dev);
int rc = 0;
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 4c404d2213f9..282031dc89b3 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -17918,7 +17918,7 @@ static int tg3_init_one(struct pci_dev *pdev,
tg3_init_coal(tp);
- pci_set_drvdata(pdev, dev);
+ dev_set_drvdata(&pdev->dev, dev);
if (tg3_asic_rev(tp) == ASIC_REV_5719 ||
tg3_asic_rev(tp) == ASIC_REV_5720 ||
@@ -18041,8 +18041,7 @@ static void tg3_remove_one(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int tg3_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct tg3 *tp = netdev_priv(dev);
int err = 0;
@@ -18098,8 +18097,7 @@ static int tg3_suspend(struct device *device)
static int tg3_resume(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct tg3 *tp = netdev_priv(dev);
int err = 0;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 2/8] net: atheros: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 6:05 UTC (permalink / raw)
Cc: Jay Cliburn, Chris Snook, David S . Miller, netdev, linux-kernel,
Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/atheros/alx/main.c | 8 +++-----
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 ++++------
drivers/net/ethernet/atheros/atlx/atl1.c | 8 +++-----
3 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet/atheros/alx/main.c
index e3538ba7d0e7..73a20b106892 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1749,7 +1749,7 @@ static int alx_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
alx->msg_enable = NETIF_MSG_LINK | NETIF_MSG_HW | NETIF_MSG_IFUP |
NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR | NETIF_MSG_WOL;
hw = &alx->hw;
- pci_set_drvdata(pdev, alx);
+ dev_set_drvdata(&pdev->dev, alx);
hw->hw_addr = pci_ioremap_bar(pdev, 0);
if (!hw->hw_addr) {
@@ -1879,8 +1879,7 @@ static void alx_remove(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int alx_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct alx_priv *alx = pci_get_drvdata(pdev);
+ struct alx_priv *alx = dev_get_drvdata(dev);
if (!netif_running(alx->dev))
return 0;
@@ -1891,8 +1890,7 @@ static int alx_suspend(struct device *dev)
static int alx_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct alx_priv *alx = pci_get_drvdata(pdev);
+ struct alx_priv *alx = dev_get_drvdata(dev);
struct alx_hw *hw = &alx->hw;
int err;
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index be7f9cebb675..16481eb5c422 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -2422,8 +2422,7 @@ static int atl1c_close(struct net_device *netdev)
static int atl1c_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = &adapter->hw;
u32 wufc = adapter->wol;
@@ -2437,7 +2436,7 @@ static int atl1c_suspend(struct device *dev)
if (wufc)
if (atl1c_phy_to_ps_link(hw) != 0)
- dev_dbg(&pdev->dev, "phy power saving failed");
+ dev_dbg(dev, "phy power saving failed");
atl1c_power_saving(hw, wufc);
@@ -2447,8 +2446,7 @@ static int atl1c_suspend(struct device *dev)
#ifdef CONFIG_PM_SLEEP
static int atl1c_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct atl1c_adapter *adapter = netdev_priv(netdev);
AT_WRITE_REG(&adapter->hw, REG_WOL_CTRL, 0);
@@ -2503,7 +2501,7 @@ static const struct net_device_ops atl1c_netdev_ops = {
static int atl1c_init_netdev(struct net_device *netdev, struct pci_dev *pdev)
{
SET_NETDEV_DEV(netdev, &pdev->dev);
- pci_set_drvdata(pdev, netdev);
+ dev_set_drvdata(&pdev->dev, netdev);
netdev->netdev_ops = &atl1c_netdev_ops;
netdev->watchdog_timeo = AT_TX_WATCHDOG;
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c
index b5c6dc914720..8b9df5f8795b 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -2754,8 +2754,7 @@ static int atl1_close(struct net_device *netdev)
#ifdef CONFIG_PM_SLEEP
static int atl1_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct atl1_adapter *adapter = netdev_priv(netdev);
struct atl1_hw *hw = &adapter->hw;
u32 ctrl = 0;
@@ -2780,7 +2779,7 @@ static int atl1_suspend(struct device *dev)
val = atl1_get_speed_and_duplex(hw, &speed, &duplex);
if (val) {
if (netif_msg_ifdown(adapter))
- dev_printk(KERN_DEBUG, &pdev->dev,
+ dev_printk(KERN_DEBUG, dev,
"error getting speed/duplex\n");
goto disable_wol;
}
@@ -2837,8 +2836,7 @@ static int atl1_suspend(struct device *dev)
static int atl1_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct atl1_adapter *adapter = netdev_priv(netdev);
iowrite32(0, adapter->hw.hw_addr + REG_WOL_CTRL);
--
2.20.1
^ permalink raw reply related
* Re: [bpf-next 2/6] tcp: add skb-less helpers to retrieve SYN cookie
From: kbuild test robot @ 2019-07-24 6:05 UTC (permalink / raw)
To: Petar Penkov
Cc: kbuild-all, netdev, bpf, davem, ast, daniel, edumazet, lmb, sdf,
Petar Penkov
In-Reply-To: <20190723002042.105927-3-ppenkov.kernel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]
Hi Petar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Petar-Penkov/Introduce-a-BPF-helper-to-generate-SYN-cookies/20190723-235628
base: https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-randconfig-e004-201929 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
ld: net/ipv4/tcp_input.o: in function `tcp_get_syncookie':
>> net/ipv4/tcp_input.c:6538: undefined reference to `__cookie_v6_init_sequence'
vim +6538 net/ipv4/tcp_input.c
6509
6510 u16 tcp_get_syncookie(struct request_sock_ops *rsk_ops,
6511 const struct tcp_request_sock_ops *af_ops,
6512 struct sock *sk, void *iph, struct tcphdr *th,
6513 u32 *cookie)
6514 {
6515 u16 mss = 0;
6516 #ifdef CONFIG_SYN_COOKIES
6517 bool is_v4 = rsk_ops->family == AF_INET;
6518 struct tcp_sock *tp = tcp_sk(sk);
6519
6520 if (sock_net(sk)->ipv4.sysctl_tcp_syncookies != 2 &&
6521 !inet_csk_reqsk_queue_is_full(sk))
6522 return 0;
6523
6524 if (!tcp_syn_flood_action(sk, rsk_ops->slab_name))
6525 return 0;
6526
6527 if (sk_acceptq_is_full(sk)) {
6528 NET_INC_STATS(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
6529 return 0;
6530 }
6531
6532 mss = tcp_parse_mss_option(th, tp->rx_opt.user_mss);
6533 if (!mss)
6534 mss = af_ops->mss_clamp;
6535
6536 tcp_synq_overflow(sk);
6537 *cookie = is_v4 ? __cookie_v4_init_sequence(iph, th, &mss)
> 6538 : __cookie_v6_init_sequence(iph, th, &mss);
6539 #endif
6540 return mss;
6541 }
6542
---
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: 34310 bytes --]
^ permalink raw reply
* [PATCH net-next v2 1/8] net: 3com: 3c59x: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 6:05 UTC (permalink / raw)
Cc: Steffen Klassert, David S . Miller, netdev, linux-kernel,
Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
drivers/net/ethernet/3com/3c59x.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index 147051404194..a0960c05833d 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -847,8 +847,7 @@ static void poll_vortex(struct net_device *dev)
static int vortex_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *ndev = pci_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
if (!ndev || !netif_running(ndev))
return 0;
@@ -861,8 +860,7 @@ static int vortex_suspend(struct device *dev)
static int vortex_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *ndev = pci_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
int err;
if (!ndev || !netif_running(ndev))
@@ -1222,7 +1220,7 @@ static int vortex_probe1(struct device *gendev, void __iomem *ioaddr, int irq,
/* if we are a PCI driver, we store info in pdev->driver_data
* instead of a module list */
if (pdev)
- pci_set_drvdata(pdev, dev);
+ dev_set_drvdata(&pdev->dev, dev);
if (edev)
eisa_set_drvdata(edev, dev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 0/8] Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 6:05 UTC (permalink / raw)
Cc: Steffen Klassert, David S . Miller, Jay Cliburn, Chris Snook,
Rasesh Mody, Michael Chan, Siva Reddy Kallam, Prashant Sreedharan,
GR-Linux-NIC-Dev, Jeff Kirsher, Guo-Fu Tseng, intel-wired-lan,
netdev, linux-kernel, Chuhong Yuan
These patches use dev_get_drvdata instead of
using to_pci_dev + pci_get_drvdata to make
code simpler where possible.
Changelog:
v1 -> v2:
- Change pci_set_drvdata to dev_set_drvdata
to keep consistency.
Chuhong Yuan (8):
net: 3com: 3c59x: Use dev_get_drvdata
net: atheros: Use dev_get_drvdata
net: broadcom: Use dev_get_drvdata
e1000e: Use dev_get_drvdata where possible
fm10k: Use dev_get_drvdata
i40e: Use dev_get_drvdata
igb: Use dev_get_drvdata where possible
net: jme: Use dev_get_drvdata
drivers/net/ethernet/3com/3c59x.c | 8 +++-----
drivers/net/ethernet/atheros/alx/main.c | 8 +++-----
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 ++++------
drivers/net/ethernet/atheros/atlx/atl1.c | 8 +++-----
drivers/net/ethernet/broadcom/bnx2.c | 8 +++-----
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 +++-----
drivers/net/ethernet/broadcom/tg3.c | 8 +++-----
drivers/net/ethernet/intel/e1000e/netdev.c | 9 ++++-----
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 +++---
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 ++++------
drivers/net/ethernet/intel/igb/igb_main.c | 5 ++---
drivers/net/ethernet/jme.c | 8 +++-----
12 files changed, 38 insertions(+), 58 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
From: Kelsey Skunberg @ 2019-07-24 5:56 UTC (permalink / raw)
To: David Miller
Cc: iyappan, keyur, quan, netdev, linux-kernel, bjorn, skhan,
linux-kernel-mentees
In-Reply-To: <20190723.140739.379654507424022463.davem@davemloft.net>
On Tue, Jul 23, 2019 at 02:07:39PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 23 Jul 2019 14:06:46 -0700 (PDT)
>
> > From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> > Date: Tue, 23 Jul 2019 12:58:11 -0600
> >
> >> acpi_evaluate_object will already return an error if the needed method
> >> does not exist. Remove unnecessary acpi_has_method() calls and check the
> >> returned acpi_status for failure instead.
> >>
> >> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> >> ---
> >> Changes in v2:
> >> - Fixed white space warnings and errors
> >
> > Applied to net-next.
>
> Wow did you even build test this? Reverted...
>
This patch has definitely been a mess, so thank you for your time and
sticking with me here. I thought my build tests included these files,
though discovered they did not. Since submitting v2, I was able to reproduce the
same errors you listed and corrected the problem in v3.
I also realized my .git/post-commit file needed to be fixed, so the white
space problem in v1 should also not be a problem in the future.
Please let me know if you notice anything else I can improve on. I will
learn from my mistakes and really appreciate advice. Thank you again, David.
Best Regards,
Kelsey
^ permalink raw reply
* Re: kernel v5.3.0-rc1
From: Heiner Kallweit @ 2019-07-24 5:48 UTC (permalink / raw)
To: Bob Gleitsmann, netdev
In-Reply-To: <ed5c39e4-e364-ccca-0a9e-8d0b4d648bfd@bellsouth.net>
On 24.07.2019 03:38, Bob Gleitsmann wrote:
> Hello,
>
>
> I had problems with network functionality in kernel v5.3.0-rc1. I was
> not able to ping local devices with ip address or internet points by
> name. I have been testing git kernels for a while and this is the first
> time this has happened, i.e., it didn't happen with v5.2.0. One
> interesting thing is that simply rebooting with a good kernel doesn't
> fix the problem. The machine has to be powered off and restarted.
>
> It was clear that network names were not being resolved.
>
> I can provide more details and try different things to help track down
> the problem. I'm using x86-64 system, gentoo linux, r8169 PHY.
>
Thanks for reporting. For one known issue there's a fix pending for 5.3-rc2:
1a03bb532934 ("r8169: fix RTL8168g PHY init")
You could apply it on top of 5.3-rc1 or test linux-next.
If this doesn't help then at least a full dmesg log is needed.
>
> Best Wishes,
>
>
> Bob Gleitsmann
>
>
Heiner
^ permalink raw reply
* Re: [PATCH] mt76_init_sband_2g: null check the allocation
From: Kalle Valo @ 2019-07-24 5:39 UTC (permalink / raw)
To: Navid Emamdoost
Cc: emamd001, kjlu, smccaman, secalert, Jakub Kicinski,
David S. Miller, Matthias Brugger, linux-wireless, netdev,
linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20190723221954.9233-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> writes:
> devm_kzalloc may fail and return NULL. So the null check is needed.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> ---
> drivers/net/wireless/mediatek/mt7601u/init.c | 3 +++
> 1 file changed, 3 insertions(+)
The prefix in the title should be "mt7601u:".
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 03/12] block: bio_release_pages: use flags arg instead of bool
From: Christoph Hellwig @ 2019-07-24 5:30 UTC (permalink / raw)
To: john.hubbard
Cc: Andrew Morton, Alexander Viro, Anna Schumaker, David S . Miller,
Dominique Martinet, Eric Van Hensbergen, Jason Gunthorpe,
Jason Wang, Jens Axboe, Latchesar Ionkov, Michael S . Tsirkin,
Miklos Szeredi, Trond Myklebust, Christoph Hellwig,
Matthew Wilcox, linux-mm, LKML, ceph-devel, kvm, linux-block,
linux-cifs, linux-fsdevel, linux-nfs, linux-rdma, netdev,
samba-technical, v9fs-developer, virtualization, John Hubbard,
Christoph Hellwig, Jérôme Glisse, Minwoo Im
In-Reply-To: <20190724042518.14363-4-jhubbard@nvidia.com>
On Tue, Jul 23, 2019 at 09:25:09PM -0700, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> In commit d241a95f3514 ("block: optionally mark pages dirty in
> bio_release_pages"), new "bool mark_dirty" argument was added to
> bio_release_pages.
>
> In upcoming work, another bool argument (to indicate that the pages came
> from get_user_pages) is going to be added. That's one bool too many,
> because it's not desirable have calls of the form:
All pages releases by bio_release_pages should come from
get_get_user_pages, so I don't really see the point here.
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Ji-Ze Hong (Peter Hong) @ 2019-07-24 5:19 UTC (permalink / raw)
To: Saeed Mahameed, peter_hong@fintek.com.tw, wg@grandegger.com,
mkl@pengutronix.de
Cc: hpeter+linux_kernel@gmail.com, f.suligoi@asem.it,
linux-can@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <bb38703fa94f19578ac67f763bb1a0ad34196757.camel@mellanox.com>
Hi,
Saeed Mahameed 於 2019/7/24 上午 05:38 寫道:
> On Mon, 2019-07-22 at 14:22 +0800, Ji-Ze Hong (Peter Hong) wrote:
>> This patch add support for Fintek PCIE to 2 CAN controller support
>>
>> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com
>>>
>> ---
>> Changelog:
>> v2:
>> 1: Fix comment on the spinlock with write access.
>> 2: Use ARRAY_SIZE instead of F81601_PCI_MAX_CHAN.
>> 3: Check the strap pin outside the loop.
>> 4: Fix the cleanup issue in f81601_pci_add_card().
>> 5: Remove unused "channels" in struct f81601_pci_card.
>>
>> drivers/net/can/sja1000/Kconfig | 8 ++
>> drivers/net/can/sja1000/Makefile | 1 +
>> drivers/net/can/sja1000/f81601.c | 215
>> +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 224 insertions(+)
>> create mode 100644 drivers/net/can/sja1000/f81601.c
>>
>> diff --git a/drivers/net/can/sja1000/Kconfig
>> b/drivers/net/can/sja1000/Kconfig
>> index f6dc89927ece..8588323c5138 100644
>> --- a/drivers/net/can/sja1000/Kconfig
>> +++ b/drivers/net/can/sja1000/Kconfig
>> @@ -101,4 +101,12 @@ config CAN_TSCAN1
>> IRQ numbers are read from jumpers JP4 and JP5,
>> SJA1000 IO base addresses are chosen heuristically (first
>> that works).
>>
>> +config CAN_F81601
>> + tristate "Fintek F81601 PCIE to 2 CAN Controller"
>> + depends on PCI
>> + help
>> + This driver adds support for Fintek F81601 PCIE to 2 CAN
>> Controller.
>> + It had internal 24MHz clock source, but it can be changed by
>> + manufacturer. We can use modinfo to get usage for parameters.
>> + Visit http://www.fintek.com.tw to get more information.
>> endif
>> diff --git a/drivers/net/can/sja1000/Makefile
>> b/drivers/net/can/sja1000/Makefile
>> index 9253aaf9e739..6f6268543bd9 100644
>> --- a/drivers/net/can/sja1000/Makefile
>> +++ b/drivers/net/can/sja1000/Makefile
>> @@ -13,3 +13,4 @@ obj-$(CONFIG_CAN_PEAK_PCMCIA) += peak_pcmcia.o
>> obj-$(CONFIG_CAN_PEAK_PCI) += peak_pci.o
>> obj-$(CONFIG_CAN_PLX_PCI) += plx_pci.o
>> obj-$(CONFIG_CAN_TSCAN1) += tscan1.o
>> +obj-$(CONFIG_CAN_F81601) += f81601.o
>> diff --git a/drivers/net/can/sja1000/f81601.c
>> b/drivers/net/can/sja1000/f81601.c
>> new file mode 100644
>> index 000000000000..3c378de8764d
>> --- /dev/null
>> +++ b/drivers/net/can/sja1000/f81601.c
>> @@ -0,0 +1,215 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Fintek F81601 PCIE to 2 CAN controller driver
>> + *
>> + * Copyright (C) 2019 Peter Hong <peter_hong@fintek.com.tw>
>> + * Copyright (C) 2019 Linux Foundation
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/delay.h>
>> +#include <linux/slab.h>
>> +#include <linux/pci.h>
>> +#include <linux/can/dev.h>
>> +#include <linux/io.h>
>> +#include <linux/version.h>
>> +
>> +#include "sja1000.h"
>> +
>> +#define F81601_PCI_MAX_CHAN 2
>> +
>> +#define F81601_DECODE_REG 0x209
>> +#define F81601_IO_MODE BIT(7)
>> +#define F81601_MEM_MODE BIT(6)
>> +#define F81601_CFG_MODE BIT(5)
>> +#define F81601_CAN2_INTERNAL_CLK BIT(3)
>> +#define F81601_CAN1_INTERNAL_CLK BIT(2)
>> +#define F81601_CAN2_EN BIT(1)
>> +#define F81601_CAN1_EN BIT(0)
>> +
>> +#define F81601_TRAP_REG 0x20a
>> +#define F81601_CAN2_HAS_EN BIT(4)
>> +
>> +struct f81601_pci_card {
>> + void __iomem *addr;
>> + spinlock_t lock; /* use this spin lock only for write access
>> */
>> + struct pci_dev *dev;
>> + struct net_device *net_dev[F81601_PCI_MAX_CHAN];
>> +};
>> +
>> +static const struct pci_device_id f81601_pci_tbl[] = {
>> + { PCI_DEVICE(0x1c29, 0x1703) },
>> + {},
>> +};
>> +
>> +MODULE_DEVICE_TABLE(pci, f81601_pci_tbl);
>> +
>> +static bool internal_clk = 1;
>> +module_param(internal_clk, bool, 0444);
>> +MODULE_PARM_DESC(internal_clk, "Use internal clock, default 1
>> (24MHz)");
>> +
>> +static unsigned int external_clk;
>> +module_param(external_clk, uint, 0444);
>> +MODULE_PARM_DESC(external_clk, "External Clock, must spec when
>> internal_clk = 0");
>> +
>> +static u8 f81601_pci_read_reg(const struct sja1000_priv *priv, int
>> port)
>> +{
>> + return readb(priv->reg_base + port);
>> +}
>> +
>> +static void f81601_pci_write_reg(const struct sja1000_priv *priv,
>> int port,
>> + u8 val)
>> +{
>> + struct f81601_pci_card *card = priv->priv;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&card->lock, flags);
>> + writeb(val, priv->reg_base + port);
>> + readb(priv->reg_base);
>> + spin_unlock_irqrestore(&card->lock, flags);
>> +}
>> +
>> +static void f81601_pci_del_card(struct pci_dev *pdev)
>> +{
>> + struct f81601_pci_card *card = pci_get_drvdata(pdev);
>> + struct net_device *dev;
>> + int i = 0;
>> +
>> + for (i = 0; i < ARRAY_SIZE(card->net_dev); i++) {
>> + dev = card->net_dev[i];
>> + if (!dev)
>> + continue;
>> +
>> + dev_info(&pdev->dev, "%s: Removing %s\n", __func__,
>> dev->name);
>> +
>> + unregister_sja1000dev(dev);
>> + free_sja1000dev(dev);
>> + }
>> +
>> + pcim_iounmap(pdev, card->addr);
>> +}
>> +
>> +/* Probe F81601 based device for the SJA1000 chips and register each
>> + * available CAN channel to SJA1000 Socket-CAN subsystem.
>> + */
>> +static int f81601_pci_add_card(struct pci_dev *pdev,
>> + const struct pci_device_id *ent)
>> +{
>> + struct sja1000_priv *priv;
>> + struct net_device *dev;
>> + struct f81601_pci_card *card;
>
> nit, reverse xmas tree.
>
>> + int err, i, count;
>> + u8 tmp;
>> +
>> + if (pcim_enable_device(pdev) < 0) {
>> + dev_err(&pdev->dev, "Failed to enable PCI device\n");
>> + return -ENODEV;
>> + }
>> +
>> + dev_info(&pdev->dev, "Detected card at slot #%i\n",
>> + PCI_SLOT(pdev->devfn));
>> +
>> + card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
>> + if (!card)
>> + return -ENOMEM;
>> +
>> + card->dev = pdev;
>> + spin_lock_init(&card->lock);
>> +
>> + pci_set_drvdata(pdev, card);
>> +
>> + tmp = F81601_IO_MODE | F81601_MEM_MODE | F81601_CFG_MODE |
>> + F81601_CAN2_EN | F81601_CAN1_EN;
>> +
>> + if (internal_clk) {
>> + tmp |= F81601_CAN2_INTERNAL_CLK |
>> F81601_CAN1_INTERNAL_CLK;
>> +
>> + dev_info(&pdev->dev,
>> + "F81601 running with internal clock:
>> 24Mhz\n");
>> + } else {
>> + dev_info(&pdev->dev,
>> + "F81601 running with external clock: %dMhz\n",
>> + external_clk / 1000000);
>> + }
>> +
>> + pci_write_config_byte(pdev, F81601_DECODE_REG, tmp);
>> +
>> + card->addr = pcim_iomap(pdev, 0, pci_resource_len(pdev, 0));
>> +
>> + if (!card->addr) {
>> + err = -ENOMEM;
>> + dev_err(&pdev->dev, "%s: Failed to remap BAR\n",
>> __func__);
>> + goto failure_cleanup;
>> + }
>> +
>> + /* read CAN2_HW_EN strap pin to detect how many CANBUS do we
>> have */
>> + count = ARRAY_SIZE(card->net_dev);
>> + pci_read_config_byte(pdev, F81601_TRAP_REG, &tmp);
>> + if (!(tmp & F81601_CAN2_HAS_EN))
>> + count = 1;
>> +
>> + /* Detect available channels */
>> + for (i = 0; i < count; i++) {
>> + dev = alloc_sja1000dev(0);
>> + if (!dev) {
>> + err = -ENOMEM;
>> + goto failure_cleanup;
>> + }
>> +
>
> don't you need to rollback and cleanup/unregister previously allocated
> devs ?
>
I'll do cleanup when errors jump to failure_cleanup label and do
f81601_pci_del_card().
>> + priv = netdev_priv(dev);
>> + priv->priv = card;
>> + priv->irq_flags = IRQF_SHARED;
>> + priv->reg_base = card->addr + 0x80 * i;
>> + priv->read_reg = f81601_pci_read_reg;
>> + priv->write_reg = f81601_pci_write_reg;
>> +
>> + if (internal_clk)
>> + priv->can.clock.freq = 24000000 / 2;
>> + else
>> + priv->can.clock.freq = external_clk / 2;
>> +
>> + priv->ocr = OCR_TX0_PUSHPULL | OCR_TX1_PUSHPULL;
>> + priv->cdr = CDR_CBP;
>> +
>> + SET_NETDEV_DEV(dev, &pdev->dev);
>> + dev->dev_id = i;
>> + dev->irq = pdev->irq;
>> +
>> + /* Register SJA1000 device */
>> + err = register_sja1000dev(dev);
>> + if (err) {
>> + dev_err(&pdev->dev,
>> + "%s: Registering device failed: %x\n",
>> __func__,
>> + err);
>> + free_sja1000dev(dev);
>> + goto failure_cleanup;
>> + }
>> +
>> + card->net_dev[i] = dev;
>> + dev_info(&pdev->dev, "Channel #%d, %s at 0x%p, irq
>> %d\n", i,
>> + dev->name, priv->reg_base, dev->irq);
>> + }
>> +
>> + return 0;
>> +
>> +failure_cleanup:
>> + dev_err(&pdev->dev, "%s: failed: %d. Cleaning Up.\n", __func__,
>> err);
>> + f81601_pci_del_card(pdev);
--
With Best Regards,
Peter Hong
^ permalink raw reply
* Re: [PATCH] qca8k: enable port flow control
From: xiaofeis @ 2019-07-24 5:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, vkoul, netdev, linux-arm-msm, bjorn.andersson,
vivien.didelot, f.fainelli, niklas.cassel, xiazha
In-Reply-To: <20190719131306.GA24930@lunn.ch>
Hi Andrew
Thanks for your comments. I have sent a new patch based on net-next
tree.
Thanks
Xiaofeis
On 2019-07-19 21:13, Andrew Lunn wrote:
> On Fri, Jul 19, 2019 at 10:53:11AM +0800, xiaofeis wrote:
>> Set phy device advertising to enable MAC flow control.
>>
>> Change-Id: Ibf0f554b072fc73136ec9f7ffb90c20b25a4faae
>> Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
>
> Hi Xiaofei
>
> What tree is this patch against? I don't think it is net-next. It
> actually looks to be an old tree. Please rebase to David Millers
> net-next. Patches to that tree are closed at the moment, due to the
> merge window. You can post an RFC, or wait until it opens again.
>
> Thanks
> Andrew
^ permalink raw reply
* [PATCH v2] net: dsa: qca8k: enable port flow control
From: xiaofeis @ 2019-07-24 5:02 UTC (permalink / raw)
To: davem
Cc: vkoul, netdev, andrew, linux-arm-msm, bjorn.andersson,
vivien.didelot, f.fainelli, niklas.cassel, xiazha, xiaofeis
Set phy device advertising to enable MAC flow control.
Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
---
drivers/net/dsa/qca8k.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
index 232e8cc..c5ac426 100644
--- a/drivers/net/dsa/qca8k.c
+++ b/drivers/net/dsa/qca8k.c
@@ -2,7 +2,7 @@
/*
* Copyright (C) 2009 Felix Fietkau <nbd@nbd.name>
* Copyright (C) 2011-2012 Gabor Juhos <juhosg@openwrt.org>
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015, 2019, The Linux Foundation. All rights reserved.
* Copyright (c) 2016 John Crispin <john@phrozen.org>
*/
@@ -935,6 +935,8 @@
qca8k_port_set_status(priv, port, 1);
priv->port_sts[port].enabled = 1;
+ phy->advertising |= ADVERTISED_Pause | ADVERTISED_Asym_Pause;
+
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] qed: Add API for flashing the nvm attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-24 4:51 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190724045141.27703-1-skalluru@marvell.com>
The patch adds driver interface for reading the NVM config request and
update the attributes on nvm config flash partition.
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 65 ++++++++++++++++++++++++++++++
include/linux/qed/qed_if.h | 1 +
2 files changed, 66 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..54f00d2 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -67,6 +67,8 @@
#define QED_ROCE_QPS (8192)
#define QED_ROCE_DPIS (8)
#define QED_RDMA_SRQS QED_ROCE_QPS
+#define QED_NVM_CFG_SET_FLAGS 0xE
+#define QED_NVM_CFG_SET_PF_FLAGS 0x1E
static char version[] =
"QLogic FastLinQ 4xxxx Core Module qed " DRV_MODULE_VERSION "\n";
@@ -2227,6 +2229,66 @@ static int qed_nvm_flash_image_validate(struct qed_dev *cdev,
return 0;
}
+/* Binary file format -
+ * /----------------------------------------------------------------------\
+ * 0B | 0x5 [command index] |
+ * 4B | Entity ID | Reserved | Number of config attributes |
+ * 8B | Config ID | Length | Value |
+ * | |
+ * \----------------------------------------------------------------------/
+ * There can be several Cfg_id-Length-Value sets as specified by 'Number of...'.
+ * Entity ID - A non zero entity value for which the config need to be updated.
+ */
+static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
+{
+ struct qed_hwfn *hwfn = QED_LEADING_HWFN(cdev);
+ u8 entity_id, len, buf[32];
+ struct qed_ptt *ptt;
+ u16 cfg_id, count;
+ int rc = 0, i;
+ u32 flags;
+
+ ptt = qed_ptt_acquire(hwfn);
+ if (!ptt)
+ return -EAGAIN;
+
+ /* NVM CFG ID attribute header */
+ *data += 4;
+ entity_id = **data;
+ *data += 2;
+ count = *((u16 *)*data);
+ *data += 2;
+
+ DP_VERBOSE(cdev, NETIF_MSG_DRV,
+ "Read config ids: entity id %02x num _attrs = %0d\n",
+ entity_id, count);
+ /* NVM CFG ID attributes */
+ for (i = 0; i < count; i++) {
+ cfg_id = *((u16 *)*data);
+ *data += 2;
+ len = **data;
+ (*data)++;
+ memcpy(buf, *data, len);
+ *data += len;
+
+ flags = entity_id ? QED_NVM_CFG_SET_PF_FLAGS :
+ QED_NVM_CFG_SET_FLAGS;
+
+ DP_VERBOSE(cdev, NETIF_MSG_DRV,
+ "cfg_id = %d len = %d\n", cfg_id, len);
+ rc = qed_mcp_nvm_set_cfg(hwfn, ptt, cfg_id, entity_id, flags,
+ buf, len);
+ if (rc) {
+ DP_ERR(cdev, "Error %d configuring %d\n", rc, cfg_id);
+ break;
+ }
+ }
+
+ qed_ptt_release(hwfn, ptt);
+
+ return rc;
+}
+
static int qed_nvm_flash(struct qed_dev *cdev, const char *name)
{
const struct firmware *image;
@@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev *cdev, const char *name)
rc = qed_nvm_flash_image_access(cdev, &data,
&check_resp);
break;
+ case QED_NVM_FLASH_CMD_NVM_CFG_ID:
+ rc = qed_nvm_flash_cfg_write(cdev, &data);
+ break;
default:
DP_ERR(cdev, "Unknown command %08x\n", cmd_type);
rc = -EINVAL;
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index eef02e6..23805ea 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -804,6 +804,7 @@ enum qed_nvm_flash_cmd {
QED_NVM_FLASH_CMD_FILE_DATA = 0x2,
QED_NVM_FLASH_CMD_FILE_START = 0x3,
QED_NVM_FLASH_CMD_NVM_CHANGE = 0x4,
+ QED_NVM_FLASH_CMD_NVM_CFG_ID = 0x5,
QED_NVM_FLASH_CMD_NVM_MAX,
};
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox