Re: KASAN: use-after-free Read in decode_session6
syzbot has bisected this issue to:
commit bcd623d8e9fa5f82bbd8cd464dc418d24139157b
Author: Xin Long
Date: Thu Oct 29 07:05:05 2020 +
sctp: call sk_setup_caps in sctp_packet_transmit instead
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14df9cb850
start commit: 68bb4665 Merge branch 'l2-multicast-forwarding-for-ocelot-..
git tree: net-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=16df9cb850
console output: https://syzkaller.appspot.com/x/log.txt?x=12df9cb850
kernel config: https://syzkaller.appspot.com/x/.config?x=eac680ae76558a0e
dashboard link: https://syzkaller.appspot.com/bug?extid=5be8aebb1b7dfa90ef31
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1128639850
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11bbf39850
Reported-by: syzbot+5be8aebb1b7dfa90e...@syzkaller.appspotmail.com
Fixes: bcd623d8e9fa ("sctp: call sk_setup_caps in sctp_packet_transmit instead")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[RESEND PATCH v2] usb: gadget: configfs: Fix use-after-free issue with udc_name
From: Eddie Hung
There is a use-after-free issue, if access udc_name
in function gadget_dev_desc_UDC_store after another context
free udc_name in function unregister_gadget.
Context 1:
gadget_dev_desc_UDC_store()->unregister_gadget()->
free udc_name->set udc_name to NULL
Context 2:
gadget_dev_desc_UDC_show()-> access udc_name
Call trace:
dump_backtrace+0x0/0x340
show_stack+0x14/0x1c
dump_stack+0xe4/0x134
print_address_description+0x78/0x478
__kasan_report+0x270/0x2ec
kasan_report+0x10/0x18
__asan_report_load1_noabort+0x18/0x20
string+0xf4/0x138
vsnprintf+0x428/0x14d0
sprintf+0xe4/0x12c
gadget_dev_desc_UDC_show+0x54/0x64
configfs_read_file+0x210/0x3a0
__vfs_read+0xf0/0x49c
vfs_read+0x130/0x2b4
SyS_read+0x114/0x208
el0_svc_naked+0x34/0x38
Add mutex_lock to protect this kind of scenario.
Signed-off-by: Eddie Hung
Signed-off-by: Macpaul Lin
Reviewed-by: Peter Chen
Cc: sta...@vger.kernel.org
---
Changes for v2:
- Fix typo %s/contex/context, Thanks Peter.
drivers/usb/gadget/configfs.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index cbff3b02840d..8501b27f3c95 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -230,9 +230,16 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct
config_item *item,
static ssize_t gadget_dev_desc_UDC_show(struct config_item *item, char *page)
{
- char *udc_name = to_gadget_info(item)->composite.gadget_driver.udc_name;
+ struct gadget_info *gi = to_gadget_info(item);
+ char *udc_name;
+ int ret;
+
+ mutex_lock(>lock);
+ udc_name = gi->composite.gadget_driver.udc_name;
+ ret = sprintf(page, "%s\n", udc_name ?: "");
+ mutex_unlock(>lock);
- return sprintf(page, "%s\n", udc_name ?: "");
+ return ret;
}
static int unregister_gadget(struct gadget_info *gi)
--
2.26.2
Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM
On 10/31/20 7:45 AM, Daniel Vetter wrote: On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote: On 10/30/20 3:08 AM, Daniel Vetter wrote: ... By removing this check from this location, and changing from pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up losing the check entirely. Is that intended? If so it could use a comment somewhere to explain why. Yeah this wasn't intentional. I think I needed to drop the _locked version to prep for FOLL_LONGTERM, and figured _fast is always better. But I didn't realize that _fast doesn't have the vma checks, gup.c got me a bit confused. Actually, I thought that the change to _fast was a very nice touch, btw. I'll remedy this in all the patches where this applies (because a VM_IO | VM_PFNMAP can point at struct page backed memory, and that exact use-case is what we want to stop with the unsafe_follow_pfn work since it wreaks things like cma or security). Aside: I do wonder whether the lack for that check isn't a problem. VM_IO | VM_PFNMAP generally means driver managed, which means the driver isn't going to consult the page pin count or anything like that (at least not necessarily) when revoking or moving that memory, since we're assuming it's totally under driver control. So if pup_fast can get into such a mapping, we might have a problem. -Daniel Yes. I don't know why that check is missing from the _fast path. Probably just an oversight, seeing as how it's in the slow path. Maybe the appropriate response here is to add a separate patch that adds the check. I wonder if I'm overlooking something, but it certainly seems correct to do that. thanks, -- John Hubbard NVIDIA
[PATCH] btrfs: fix boolreturn.cocci warnings
From: kernel test robot
fs/btrfs/space-info.c:810:9-10: WARNING: return of 0/1 in function
'need_preemptive_reclaim' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
Fixes: fc96d3794eb2 ("btrfs: rename need_do_async_reclaim")
CC: Josef Bacik
Signed-off-by: kernel test robot
---
tree: https://github.com/kdave/btrfs-devel.git for-next-20201030
head: 757db2d191a0eb51ffb9acf023e31393d731b0a9
commit: fc96d3794eb2f38f91dc1647ab55967190b68482 [14921/14978] btrfs: rename
need_do_async_reclaim
space-info.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/btrfs/space-info.c
+++ b/fs/btrfs/space-info.c
@@ -807,10 +807,10 @@ static inline bool need_preemptive_recla
/* If we're just plain full then async reclaim just slows us down. */
if ((space_info->bytes_used + space_info->bytes_reserved) >= thresh)
- return 0;
+ return false;
if (!btrfs_calc_reclaim_metadata_size(fs_info, space_info))
- return 0;
+ return false;
return (used >= thresh && !btrfs_fs_closing(fs_info) &&
!test_bit(BTRFS_FS_STATE_REMOUNTING, _info->fs_state));
Re: [PATCH 5/5] crypto: hisilicon/hpre - add 'CURVE25519' algorithm
Hi Meng, Thank you for the patch! Yet something to improve: [auto build test ERROR on cryptodev/master] [also build test ERROR on crypto/master v5.10-rc1 next-20201030] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Meng-Yu/crypto-hisilicon-hpre-add-something-for-Kunpeng-930/20201031-143748 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master config: x86_64-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/5bfec963e8d2806a362f1f9da490543d939baf26 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Meng-Yu/crypto-hisilicon-hpre-add-something-for-Kunpeng-930/20201031-143748 git checkout 5bfec963e8d2806a362f1f9da490543d939baf26 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> ld: drivers/crypto/hisilicon/hpre/hpre_crypto.o:(.rodata+0x1860): multiple >> definition of `curve25519_null_point'; >> lib/crypto/curve25519-generic.o:(.rodata+0x40): first defined here --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] arm64: qcom: sc7180: trogdor: Add ADC nodes and thermal zone for charger thermistor
Hi Matthias, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.10-rc1 next-20201030] [cannot apply to robh/for-next agross-msm/qcom/for-next linux/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Matthias-Kaehlcke/arm64-qcom-sc7180-trogdor-Add-ADC-nodes-and-thermal-zone-for-charger-thermistor/20201031-222833 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 5fc6b075e165f641fbc366b58b578055762d5f8c config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/04224534546d82fd16d3edc39120b1eee3b1cc54 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Matthias-Kaehlcke/arm64-qcom-sc7180-trogdor-Add-ADC-nodes-and-thermal-zone-for-charger-thermistor/20201031-222833 git checkout 04224534546d82fd16d3edc39120b1eee3b1cc54 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi:761.1-15 Label or path >> pm6150_adc_tm not found >> FATAL ERROR: Syntax error parsing input tree --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v2 31/39] docs: ABI: cleanup several ABI documents
On Fri, Oct 30, 2020 at 08:40:50AM +0100, Mauro Carvalho Chehab wrote: > There are some ABI documents that, while they don't generate > any warnings, they have issues when parsed by get_abi.pl script > on its output result. > > Address them, in order to provide a clean output. > ... > .../ABI/testing/sysfs-driver-input-exc3000| 2 + Acked-by: Dmitry Torokhov Thanks. -- Dmitry
Re: [PATCH v2 00/15] timers: clean up ARCH_GETTIMEOFFSET, LEGACY_TIMER_TICK
On Fri, 30 Oct 2020, Arnd Bergmann wrote: > CONFIG_ARCH_GETTIMEOFFSET has been gradually phased out from all > platforms, with only ARM EBSA110 recently. As this has no more known > users, the first three patches remove EBSA110 along with one platform > specific driver and the ARCH_GETTIMEOFFSET infrastructure. > The CONFIG_ARCH_GETTIMEOFFSET patches weren't part of v1. Is there some kind of dependency here?
Business Opportunity Urgent Response
Good Day My Good Brother. Let me start by introducing myself I am Mr. Ahmed Kobani from Burkina Faso, I am writing you this letter based on latest development in my bank which I we like to bring you in. The sum of Fifteen Million Five Hundred Thousand United State Dollars ($ 15.5Million) this is legitimate Transition after the transfer we will share it, 60% for me and 40% for you. Let me know if you Can you help me, kindly Contact me for more details if you are interested in the deal. Waiting to hear from you urgent. Best Regards Ahmed Kobani
From the kindness of our heart!! You have been selected to receive (£1,000,000.00 British Pound)
Dear Beneficiary, You have been selected to receive (£1,000,000.00 British Pound) as charity donation/grant from Patrick and Frances Connolly. Therefore, you are required to contact her through email for more details patrickcon2...@gmail.com -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[PATCH] asm-generic: barrier.h: fix ALPHA builds when SMP is not enabled
uses barrier() but needs to #include
to get a generic definition of it to fix
build errors in arch/alpha/ builds when CONFIG_SMP is not enabled.
Fixes build errors like this (there are several like this):
[49 in the kernel config that was supplied by the 0day bot]
In file included from ../arch/alpha/include/asm/barrier.h:21,
from ../arch/alpha/include/asm/atomic.h:6,
from ../include/linux/atomic.h:7,
from ../include/linux/dcache.h:5,
from ../fs/proc/util.c:1:
../arch/alpha/include/asm/atomic.h: In function 'atomic_add_return_relaxed':
../include/asm-generic/barrier.h:78:18: error: implicit declaration of function
'barrier' [-Werror=implicit-function-declaration]
78 | #define smp_mb() barrier()
| ^~~
Fixes: 885df91ca357 ("Create asm-generic/barrier.h")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: David Howells
Cc: Arnd Bergmann
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: linux-al...@vger.kernel.org
---
include/asm-generic/barrier.h |1 +
1 file changed, 1 insertion(+)
--- linux-next-20201030.orig/include/asm-generic/barrier.h
+++ linux-next-20201030/include/asm-generic/barrier.h
@@ -13,6 +13,7 @@
#ifndef __ASSEMBLY__
+#include
#include
#ifndef nop
Re: KASAN: use-after-free Read in do_set_interface
It cannot be reproducible, unfortunately. Thanks, Kyungtae Kim On Sat, Oct 31, 2020 at 9:40 PM Alan Stern wrote: > > On Wed, Oct 28, 2020 at 04:51:09PM -0400, Kyungtae Kim wrote: > > We report a bug (in linux-5.8.13) found by FuzzUSB (a modified version > > of syzkaller). > > > > The bug happened when accessing a freed instance of struct fsg_dev > > (i.e., fsg->bulk_in) in do_set_interface() (line 2245). > > > > == > > BUG: KASAN: use-after-free in do_set_interface.part.7+0xa6b/0xd90 > > drivers/usb/gadget/function/f_mass_storage.c:2245 > > Read of size 8 at addr 88806bc940f8 by task file-storage/2063 > > > > CPU: 3 PID: 2063 Comm: file-storage Not tainted 5.8.13 #4 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0xa7/0xea lib/dump_stack.c:118 > > print_address_description.constprop.8+0x3f/0x60 mm/kasan/report.c:383 > > kasan_report.cold.11+0x20/0x37 mm/kasan/report.c:513 > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:146 > > do_set_interface.part.7+0xa6b/0xd90 > > drivers/usb/gadget/function/f_mass_storage.c:2245 > > do_set_interface drivers/usb/gadget/function/f_mass_storage.c:2202 [inline] > > handle_exception drivers/usb/gadget/function/f_mass_storage.c:2426 [inline] > > fsg_main_thread+0x12c7/0x59f1 > > drivers/usb/gadget/function/f_mass_storage.c:2466 > > kthread+0x374/0x480 kernel/kthread.c:291 > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 > > Is this reproducible? Can you test patches? > > Alan Stern
Re: [PATCH] USB: gadget: hidg: fix use-after-free in f_hidg
On Wed, Oct 28, 2020 at 4:13 PM Kyungtae Kim wrote:
>
> FuzzUSB (a variant of syzkaller) found the bug
> when accessing a freed instance of struct f_hidg.
>
> Reference: https://www.spinics.net/lists/linux-usb/msg195103.html
>
> The fix uses reference count to ensure the right access to instance of f_hidg.
>
>
> BUG: KASAN: use-after-free in f_hidg_poll+0x190/0x1e0
> drivers/usb/gadget/function/f_hid.c:424
> Read of size 1 at addr 8880579260e8 by task syz-executor.5/2849
>
> CPU: 3 PID: 2849 Comm: syz-executor.5 Not tainted 5.6.11 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xce/0x128 lib/dump_stack.c:118
> print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374
> __kasan_report+0x131/0x1b0 mm/kasan/report.c:506
> kasan_report+0x12/0x20 mm/kasan/common.c:641
> __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> f_hidg_poll+0x190/0x1e0 drivers/usb/gadget/function/f_hid.c:424
> vfs_poll include/linux/poll.h:90 [inline]
> do_pollfd fs/select.c:859 [inline]
> do_poll fs/select.c:907 [inline]
> do_sys_poll+0x548/0xe20 fs/select.c:1001
> __do_sys_poll fs/select.c:1059 [inline]
> __se_sys_poll fs/select.c:1047 [inline]
> __x64_sys_poll+0x171/0x420 fs/select.c:1047
> do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4531a9
> Code: ed 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 bb 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7f07bfcd1c78 EFLAGS: 0246 ORIG_RAX: 0007
> RAX: ffda RBX: 0073bfa8 RCX: 004531a9
> RDX: 0080 RSI: 0001 RDI: 20001980
> RBP: 0003 R08: R09:
> R10: R11: 0246 R12: 004bd290
> R13: 004d2c28 R14: 7f07bfcd26d4 R15:
>
> Allocated by task 2418:
> save_stack+0x21/0x90 mm/kasan/common.c:72
> set_track mm/kasan/common.c:80 [inline]
> __kasan_kmalloc.constprop.3+0xa7/0xd0 mm/kasan/common.c:515
> kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529
> kmem_cache_alloc_trace+0xfa/0x2d0 mm/slub.c:2813
> kzalloc include/linux/slab.h:555 [inline]
> hidg_alloc+0x56/0x5e0 drivers/usb/gadget/function/f_hid.c:1091
> usb_get_function+0x58/0xc0 drivers/usb/gadget/functions.c:61
> config_usb_cfg_link+0x1ed/0x3e0 drivers/usb/gadget/configfs.c:444
> configfs_symlink+0x527/0x11d0 fs/configfs/symlink.c:202
> vfs_symlink+0x33d/0x5b0 fs/namei.c:4201
> do_symlinkat+0x11b/0x1d0 fs/namei.c:4228
> __do_sys_symlinkat fs/namei.c:4242 [inline]
> __se_sys_symlinkat fs/namei.c:4239 [inline]
> __x64_sys_symlinkat+0x73/0xb0 fs/namei.c:4239
> do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 2868:
> save_stack+0x21/0x90 mm/kasan/common.c:72
> set_track mm/kasan/common.c:80 [inline]
> kasan_set_free_info mm/kasan/common.c:337 [inline]
> __kasan_slab_free+0x135/0x190 mm/kasan/common.c:476
> kasan_slab_free+0xe/0x10 mm/kasan/common.c:485
> slab_free_hook mm/slub.c:1444 [inline]
> slab_free_freelist_hook mm/slub.c:1477 [inline]
> slab_free mm/slub.c:3034 [inline]
> kfree+0xf7/0x410 mm/slub.c:3995
> hidg_free+0x7f/0x110 drivers/usb/gadget/function/f_hid.c:1069
> usb_put_function+0x38/0x50 drivers/usb/gadget/functions.c:87
> config_usb_cfg_unlink+0x2db/0x3b0 drivers/usb/gadget/configfs.c:485
> configfs_unlink+0x3b9/0x7f0 fs/configfs/symlink.c:250
> vfs_unlink+0x287/0x570 fs/namei.c:4073
> do_unlinkat+0x4f9/0x620 fs/namei.c:4137
> __do_sys_unlink fs/namei.c:4184 [inline]
> __se_sys_unlink fs/namei.c:4182 [inline]
> __x64_sys_unlink+0x42/0x50 fs/namei.c:4182
> do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
>
> Signed-off-by: Kyungtae Kim
> Reported-and-tested-by: Kyungtae Kim
>
> ---
> drivers/usb/gadget/function/f_hid.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_hid.c
> b/drivers/usb/gadget/function/f_hid.c
> index 1125f4715830..e900b51c075a 100644
> --- a/drivers/usb/gadget/function/f_hid.c
> +++ b/drivers/usb/gadget/function/f_hid.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "u_f.h"
> #include "u_hid.h"
> @@ -44,6 +45,7 @@ struct f_hidg {
> unsigned short report_desc_length;
> char*report_desc;
> unsigned short report_length;
> + struct kref kref;
>
> /* recv report */
> struct list_headcompleted_out_req;
> @@ -427,9 +429,21 @@ static __poll_t f_hidg_poll(struct file *file,
> poll_table *wait)
> #undef WRITE_COND
[PATCH] arm64: dts: meson: add watchdog to g12-common dtsi
G12 vendor kernels show the watchdog on the same address as AXG
so add the node to meson-g12-common.dtsi. GX boards inherit the
same from meson-gx.dtsi.
v2 fix typo in node name (s/wtd/wdt)
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 1e83ec5b8c91..314095b79a45 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -2179,6 +2179,12 @@
amlogic,channel-interrupts = <64 65 66 67 68 69
70 71>;
};
+ watchdog: wdt@f0d0 {
+ compatible = "amlogic,meson-gxbb-wdt";
+ reg = <0x0 0xf0d0 0x0 0x10>;
+ clocks = <>;
+ };
+
spicc0: spi@13000 {
compatible = "amlogic,meson-g12a-spicc";
reg = <0x0 0x13000 0x0 0x44>;
--
2.17.1
Re: [PATCH 1/5] arm64: dts: imx8mn: Enable Asynchronous Sample Rate Converter
On Mon, Oct 19, 2020 at 12:45:24PM -0500, Adam Ford wrote:
> The driver exists for the Enhanced Asynchronous Sample Rate Converter
> (EASRC) Controller, but there isn't a device tree entry for it.
>
> On the vendor kernel, they put this on a spba-bus for SDMA support.
>
> Add the the node for the spba-bus with the easrc node inside.
>
> Signed-off-by: Adam Ford
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> index 746faf1cf2fb..7d34281332e1 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> @@ -246,6 +246,34 @@ aips1: bus@3000 {
> #size-cells = <1>;
> ranges;
>
> + spba-bus@3000 {
spba: bus@3000
> + compatible = "fsl,spba-bus", "simple-bus";
"fsl,spba-bus" is undocumented. Document it or drop it.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x3000 0x10>;
> + ranges;
> +
> + easrc: easrc@300C {
> + compatible = "fsl,imx8mn-easrc";
> + reg = <0x300C 0x1>;
> + interrupts = IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < IMX8MN_CLK_ASRC_ROOT>;
> + clock-names = "mem";
> + dmas = < 16 23 0> , < 17 23
> 0>,
> +< 18 23 0> , < 19 23
> 0>,
> +< 20 23 0> , < 21 23
> 0>,
> +< 22 23 0> , < 23 23
> 0>;
> + dma-names = "ctx0_rx", "ctx0_tx",
> + "ctx1_rx", "ctx1_tx",
> + "ctx2_rx", "ctx2_tx",
> + "ctx3_rx", "ctx3_tx";
> + fsl,easrc-ram-script-name =
> "imx/easrc/easrc-imx8mn.bin";
Undocumented property?
Shawn
> + fsl,asrc-rate = <8000>;
> + fsl,asrc-width = <16>;
> + status = "disabled";
> + };
> + };
> +
> gpio1: gpio@3020 {
> compatible = "fsl,imx8mn-gpio",
> "fsl,imx35-gpio";
> reg = <0x3020 0x1>;
> --
> 2.25.1
>
Re: [PATCH net-next] selftests/net: timestamping: add ptp v2 support
On Sat, Oct 31, 2020 at 11:40:40AM -0700, Jakub Kicinski wrote: > On Thu, 29 Oct 2020 21:09:31 +0200 Grygorii Strashko wrote: > > The timestamping tool is supporting now only PTPv1 (IEEE-1588 2002) while > > modern HW often supports also/only PTPv2. > > > > Hence timestamping tool is still useful for sanity testing of PTP drivers > > HW timestamping capabilities it's reasonable to upstate it to support > > PTPv2. This patch adds corresponding support which can be enabled by using > > new parameter "PTPV2". > > > > Signed-off-by: Grygorii Strashko > > CC: Richard Acked-by: Richard Cochran
Re: [PATCH] net: ethernet: ti: cpsw: disable PTPv1 hw timestamping advertisement
On Sat, Oct 31, 2020 at 11:40:42AM -0700, Jakub Kicinski wrote:
> On Thu, 29 Oct 2020 21:09:10 +0200 Grygorii Strashko wrote:
> > The TI CPTS does not natively support PTPv1, only PTPv2. But, as it
> > happens, the CPTS can provide HW timestamp for PTPv1 Sync messages, because
> > CPTS HW parser looks for PTP messageType id in PTP message octet 0 which
> > value is 0 for PTPv1. As result, CPTS HW can detect Sync messages for PTPv1
> > and PTPv2 (Sync messageType = 0 for both), but it fails for any other PTPv1
> > messages (Delay_req/resp) and will return PTP messageType id 0 for them.
> >
> > The commit e9523a5a32a1 ("net: ethernet: ti: cpsw: enable
> > HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter") added PTPv1 hw timestamping
> > advertisement by mistake, only to make Linux Kernel "timestamping" utility
> > work, and this causes issues with only PTPv1 compatible HW/SW - Sync HW
> > timestamped, but Delay_req/resp are not.
> >
> > Hence, fix it disabling PTPv1 hw timestamping advertisement, so only PTPv1
> > compatible HW/SW can properly roll back to SW timestamping.
> >
> > Fixes: e9523a5a32a1 ("net: ethernet: ti: cpsw: enable
> > HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter")
> > Signed-off-by: Grygorii Strashko
>
> CC: Richard
Acked-by: Richard Cochran
Re: [PATCH v2 2/2] reboot: fix parsing of reboot cpu number
On Fri, Oct 30, 2020 at 3:30 PM Petr Mladek wrote:
>
> On Tue 2020-10-27 14:35:45, Matteo Croce wrote:
> > From: Matteo Croce
> >
> > The kernel cmdline reboot= argument allows to specify the CPU used
> > for rebooting, with the syntax `s` among the other flags, e.g.
> >
> > reboot=soft,s4
> > reboot=warm,s31,force
> >
> > In the early days the parsing was done with simple_strtoul(), later
> > deprecated in favor of the safer kstrtoint() which handles overflow.
> >
> > But kstrtoint() returns -EINVAL if there are non-digit characters
> > in a string, so if this flag is not the last given, it's silently
> > ignored as well as the subsequent ones.
> >
> > To fix it, revert the usage of simple_strtoul(), which is no longer
> > deprecated, and restore the old behaviour.
> >
> > While at it, merge two identical code blocks into one.
>
> > --- a/kernel/reboot.c
> > +++ b/kernel/reboot.c
> > @@ -552,25 +552,19 @@ static int __init reboot_setup(char *str)
> >
> > case 's':
> > {
> > - int rc;
> > -
> > - if (isdigit(*(str+1))) {
> > - rc = kstrtoint(str+1, 0, _cpu);
> > - if (rc)
> > - return rc;
> > - if (reboot_cpu >= num_possible_cpus()) {
> > - reboot_cpu = 0;
> > - return -ERANGE;
> > - }
> > - } else if (str[1] == 'm' && str[2] == 'p' &&
> > -isdigit(*(str+3))) {
> > - rc = kstrtoint(str+3, 0, _cpu);
> > - if (rc)
> > - return rc;
> > - if (reboot_cpu >= num_possible_cpus()) {
> > - reboot_cpu = 0;
>
> ^^
>
> > + int cpu;
> > +
> > + /*
> > + * reboot_cpu is s[mp] with being the
> > processor
> > + * to be used for rebooting. Skip 's' or 'smp' prefix.
> > + */
> > + str += str[1] == 'm' && str[2] == 'p' ? 3 : 1;
> > +
> > + if (isdigit(str[0])) {
> > + cpu = simple_strtoul(str, NULL, 0);
> > + if (cpu >= num_possible_cpus())
> > return -ERANGE;
> > - }
> > + reboot_cpu = cpu;
>
> The original value stays when the new one is out of range. It is
> small functional change that should get mentioned in the commit
> message or better fixed separately.
>
Hi,
I didn't understand, the original value is 0 since reboot_cpu is global.
reboot_setup() is only called once at boot to parse the cmdline,
indeed it's __init.
I don't know any way to call it more than once (exept passing multiple
reboot= arguments)
> Hmm, I suggest to split this into 3 patches and switch the order:
>
> + 1st patch should simply revert the commit 616feab75397
>("kernel/reboot.c: convert simple_strtoul to kstrtoint").
>
> + 2nd patch should merge the two branches without any
> functional change.
>
> + 3rd patch should add the check for num_possible_cpus()
> and update the value only when it is valid.
>
> I am sorry that I did not suggested this when reviewed v1.
> I have missed this functional change at that time.
>
Np :)
Bye,
--
per aspera ad upstream
Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
On Sun, Nov 01, 2020 at 01:27:35AM +, Jessica Clarke wrote:
> On 1 Nov 2020, at 01:22, Rich Felker wrote:
> > On Sat, Oct 31, 2020 at 04:30:44PM -0700, Andy Lutomirski wrote:
> >> cc: some libc folks
> >>
> >> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
> >>>
> >>> POSIX specifies that the first field of the supplied msgp, namely mtype,
> >>> is a long, not a __kernel_long_t, and it's a user-defined struct due to
> >>> the variable-length mtext field so we can't even bend the spec and make
> >>> it a __kernel_long_t even if we wanted to. Thus we must use the compat
> >>> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
> >>> msgrcv respectively.
> >>
> >> This is a mess.
> >>
> >> include/uapi/linux/msg.h has:
> >>
> >> /* message buffer for msgsnd and msgrcv calls */
> >> struct msgbuf {
> >>__kernel_long_t mtype; /* type of message */
> >>char mtext[1]; /* message text */
> >> };
> >>
> >> Your test has:
> >>
> >> struct msg_long {
> >>long mtype;
> >>char mtext[8];
> >> };
> >>
> >> struct msg_long_ext {
> >>struct msg_long msg_long;
> >>char mext[4];
> >> };
> >>
> >> and I'm unclear as to exactly what you're trying to do there with the
> >> "mext" part.
> >>
> >> POSIX says:
> >>
> >> The application shall ensure that the argument msgp points to a
> >> user-
> >> defined buffer that contains first a field of type long specifying
> >> the
> >> type of the message, and then a data portion that holds the data
> >> bytes
> >> of the message. The structure below is an example of what this
> >> user-de‐
> >> fined buffer might look like:
> >>
> >> struct mymsg {
> >> long mtype; /* Message type. */
> >> char mtext[1];/* Message text. */
> >> }
> >>
> >> NTP has this delightful piece of code:
> >>
> >> 44 typedef union {
> >> 45 struct msgbuf msgp;
> >> 46 struct {
> >> 47 long mtype;
> >> 48 int code;
> >> 49 struct timeval tv;
> >> 50 } msgb;
> >> 51 } MsgBuf;
> >>
> >> bluefish has:
> >>
> >> struct small_msgbuf {
> >> long mtype;
> >> char mtext[MSQ_QUEUE_SMALL_SIZE];
> >> } small_msgp;
> >>
> >>
> >> My laptop has nothing at all in /dev/mqueue.
> >>
> >> So I don't really know what the right thing to do is. Certainly if
> >> we're going to apply this patch, we should also fix the header. I
> >> almost think we should *delete* struct msgbuf from the headers, since
> >> it's all kinds of busted, but that will break the NTP build. Ideally
> >> we would go back in time and remove it from the headers.
> >>
> >> Libc people, any insight? We can probably fix the bug without
> >> annoying anyone given how lightly x32 is used and how lightly POSIX
> >> message queues are used.
> >
> > If it's that outright wrong and always has been, I feel like the old
> > syscall numbers should just be deprecated and new ones assigned.
> > Otherwise, there's no way for userspace to be safe against data
> > corruption when run on older kernels. If there's a new syscall number,
> > libc can just use the new one unconditionally (giving ENOSYS on
> > kernels where it would be broken) or have a x32-specific
> > implementation that makes the old syscall and performs translation if
> > the new one fails with ENOSYS.
>
> That doesn't really help broken code continue to work reliably, as
> upgrading libc will just pull in the new syscall for a binary that's
> expecting the broken behaviour, unless you do symbol versioning, but
> then it'll just break when you next recompile the code, and there's no
> way for that to be diagnosed given the *application* has to define the
> type. But given it's application-defined I really struggle to see how
> any code out there is actually expecting the current x32 behaviour as
> you'd have to go really out of your way to find out that x32 is broken
> and needs __kernel_long_t. I don't think there's any way around just
> technically breaking ABI whilst likely really fixing ABI in 99.999% of
> cases (maybe 100%).
I'm not opposed to "breaking ABI" here because the current syscall
doesn't work unless someone wrote bogus x32-specific code to work
around it being wrong. I don't particularly want to preserve any of
the current behavior.
What I am somewhat opposed to is making a situation where an updated
libc can't be safe against getting run on a kernel with a broken
version of the syscall and silently corrupting data. I'm flexible
about how avoiding tha tis achieved.
Rich
Re: KASAN: use-after-free Read in do_set_interface
On Wed, Oct 28, 2020 at 04:51:09PM -0400, Kyungtae Kim wrote: > We report a bug (in linux-5.8.13) found by FuzzUSB (a modified version > of syzkaller). > > The bug happened when accessing a freed instance of struct fsg_dev > (i.e., fsg->bulk_in) in do_set_interface() (line 2245). > > == > BUG: KASAN: use-after-free in do_set_interface.part.7+0xa6b/0xd90 > drivers/usb/gadget/function/f_mass_storage.c:2245 > Read of size 8 at addr 88806bc940f8 by task file-storage/2063 > > CPU: 3 PID: 2063 Comm: file-storage Not tainted 5.8.13 #4 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0xa7/0xea lib/dump_stack.c:118 > print_address_description.constprop.8+0x3f/0x60 mm/kasan/report.c:383 > kasan_report.cold.11+0x20/0x37 mm/kasan/report.c:513 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:146 > do_set_interface.part.7+0xa6b/0xd90 > drivers/usb/gadget/function/f_mass_storage.c:2245 > do_set_interface drivers/usb/gadget/function/f_mass_storage.c:2202 [inline] > handle_exception drivers/usb/gadget/function/f_mass_storage.c:2426 [inline] > fsg_main_thread+0x12c7/0x59f1 > drivers/usb/gadget/function/f_mass_storage.c:2466 > kthread+0x374/0x480 kernel/kthread.c:291 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Is this reproducible? Can you test patches? Alan Stern
Re: [BUG] Error applying setting, reverse things back on lot of devices
Hello Michał,
On Sat, Oct 24, 2020 at 01:53:07PM +0200, Michał Mirosław wrote:
> On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
> > On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> > > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> > > > [5.796585] dcdc4: supplied by regulator-dummy
> > > > [5.801647] vcc-dram: supplied by regulator-dummy
> > > > [5.806470] vcc-gmac-phy: failed to get the current voltage: -EINVAL
> > > > [5.812839] axp20x-regulator axp20x-regulator: Failed to register
> > > > dc1sw
> > > > [5.820291] axp20x-regulator: probe of axp20x-regulator failed with
> > > > error -22
> > >
> > > I have just saw thoses 3 lines which are probably the real problem.
> > > I have started a new bisect with this error, but it is hitting the same
> > > "crash range" the first one.
> > >
> >
> > I have bisected the problem to commit
> > aea6cb99703e17019e025aa71643b4d3e0a24413 ("regulator: resolve supply after
> > creating regulator")
> > Reverting this fix my problem.
>
> Can you try the hack below?
>
> Best Regards,
> Michał Mirosław
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index a4ffd71696da..9ad091f5f1ab 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1169,6 +1169,9 @@ static int machine_constraints_voltage(struct
> regulator_dev *rdev,
> }
>
> if (current_uV < 0) {
> + if (current_uV == -EINVAL && rdev->supply_name)
> + return -EPROBE_DEFER;
> +
> rdev_err(rdev,
>"failed to get the current voltage: %pe\n",
>ERR_PTR(current_uV));
I did hit the same problem on sun8i-a83t-tbs-a711.dts tablet.
The patch helps on top of v5.9.2, and on linus/master.
regards,
o.
Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
On 1 Nov 2020, at 01:22, Rich Felker wrote:
> On Sat, Oct 31, 2020 at 04:30:44PM -0700, Andy Lutomirski wrote:
>> cc: some libc folks
>>
>> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
>>>
>>> POSIX specifies that the first field of the supplied msgp, namely mtype,
>>> is a long, not a __kernel_long_t, and it's a user-defined struct due to
>>> the variable-length mtext field so we can't even bend the spec and make
>>> it a __kernel_long_t even if we wanted to. Thus we must use the compat
>>> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
>>> msgrcv respectively.
>>
>> This is a mess.
>>
>> include/uapi/linux/msg.h has:
>>
>> /* message buffer for msgsnd and msgrcv calls */
>> struct msgbuf {
>>__kernel_long_t mtype; /* type of message */
>>char mtext[1]; /* message text */
>> };
>>
>> Your test has:
>>
>> struct msg_long {
>>long mtype;
>>char mtext[8];
>> };
>>
>> struct msg_long_ext {
>>struct msg_long msg_long;
>>char mext[4];
>> };
>>
>> and I'm unclear as to exactly what you're trying to do there with the
>> "mext" part.
>>
>> POSIX says:
>>
>> The application shall ensure that the argument msgp points to a user-
>> defined buffer that contains first a field of type long specifying the
>> type of the message, and then a data portion that holds the data bytes
>> of the message. The structure below is an example of what this user-de‐
>> fined buffer might look like:
>>
>> struct mymsg {
>> long mtype; /* Message type. */
>> char mtext[1];/* Message text. */
>> }
>>
>> NTP has this delightful piece of code:
>>
>> 44 typedef union {
>> 45 struct msgbuf msgp;
>> 46 struct {
>> 47 long mtype;
>> 48 int code;
>> 49 struct timeval tv;
>> 50 } msgb;
>> 51 } MsgBuf;
>>
>> bluefish has:
>>
>> struct small_msgbuf {
>> long mtype;
>> char mtext[MSQ_QUEUE_SMALL_SIZE];
>> } small_msgp;
>>
>>
>> My laptop has nothing at all in /dev/mqueue.
>>
>> So I don't really know what the right thing to do is. Certainly if
>> we're going to apply this patch, we should also fix the header. I
>> almost think we should *delete* struct msgbuf from the headers, since
>> it's all kinds of busted, but that will break the NTP build. Ideally
>> we would go back in time and remove it from the headers.
>>
>> Libc people, any insight? We can probably fix the bug without
>> annoying anyone given how lightly x32 is used and how lightly POSIX
>> message queues are used.
>
> If it's that outright wrong and always has been, I feel like the old
> syscall numbers should just be deprecated and new ones assigned.
> Otherwise, there's no way for userspace to be safe against data
> corruption when run on older kernels. If there's a new syscall number,
> libc can just use the new one unconditionally (giving ENOSYS on
> kernels where it would be broken) or have a x32-specific
> implementation that makes the old syscall and performs translation if
> the new one fails with ENOSYS.
That doesn't really help broken code continue to work reliably, as
upgrading libc will just pull in the new syscall for a binary that's
expecting the broken behaviour, unless you do symbol versioning, but
then it'll just break when you next recompile the code, and there's no
way for that to be diagnosed given the *application* has to define the
type. But given it's application-defined I really struggle to see how
any code out there is actually expecting the current x32 behaviour as
you'd have to go really out of your way to find out that x32 is broken
and needs __kernel_long_t. I don't think there's any way around just
technically breaking ABI whilst likely really fixing ABI in 99.999% of
cases (maybe 100%).
Jess
Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
On Sat, Oct 31, 2020 at 04:30:44PM -0700, Andy Lutomirski wrote:
> cc: some libc folks
>
> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
> >
> > POSIX specifies that the first field of the supplied msgp, namely mtype,
> > is a long, not a __kernel_long_t, and it's a user-defined struct due to
> > the variable-length mtext field so we can't even bend the spec and make
> > it a __kernel_long_t even if we wanted to. Thus we must use the compat
> > syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
> > msgrcv respectively.
>
> This is a mess.
>
> include/uapi/linux/msg.h has:
>
> /* message buffer for msgsnd and msgrcv calls */
> struct msgbuf {
> __kernel_long_t mtype; /* type of message */
> char mtext[1]; /* message text */
> };
>
> Your test has:
>
> struct msg_long {
> long mtype;
> char mtext[8];
> };
>
> struct msg_long_ext {
> struct msg_long msg_long;
> char mext[4];
> };
>
> and I'm unclear as to exactly what you're trying to do there with the
> "mext" part.
>
> POSIX says:
>
>The application shall ensure that the argument msgp points to a user-
>defined buffer that contains first a field of type long specifying the
>type of the message, and then a data portion that holds the data bytes
>of the message. The structure below is an example of what this user-de‐
>fined buffer might look like:
>
>struct mymsg {
>long mtype; /* Message type. */
>char mtext[1];/* Message text. */
>}
>
> NTP has this delightful piece of code:
>
>44 typedef union {
>45 struct msgbuf msgp;
>46 struct {
>47 long mtype;
>48 int code;
>49 struct timeval tv;
>50 } msgb;
>51 } MsgBuf;
>
> bluefish has:
>
> struct small_msgbuf {
> long mtype;
> char mtext[MSQ_QUEUE_SMALL_SIZE];
> } small_msgp;
>
>
> My laptop has nothing at all in /dev/mqueue.
>
> So I don't really know what the right thing to do is. Certainly if
> we're going to apply this patch, we should also fix the header. I
> almost think we should *delete* struct msgbuf from the headers, since
> it's all kinds of busted, but that will break the NTP build. Ideally
> we would go back in time and remove it from the headers.
>
> Libc people, any insight? We can probably fix the bug without
> annoying anyone given how lightly x32 is used and how lightly POSIX
> message queues are used.
If it's that outright wrong and always has been, I feel like the old
syscall numbers should just be deprecated and new ones assigned.
Otherwise, there's no way for userspace to be safe against data
corruption when run on older kernels. If there's a new syscall number,
libc can just use the new one unconditionally (giving ENOSYS on
kernels where it would be broken) or have a x32-specific
implementation that makes the old syscall and performs translation if
the new one fails with ENOSYS.
Rich
Re: [PATCH 2/5] arm64: defconfig: Enable ASRC and EASRC
On Mon, Oct 19, 2020 at 12:45:25PM -0500, Adam Ford wrote: > The i.MX8M Nano supports the EASRC driver, and it requires ASRC. > Enable both of them as modules. > > Signed-off-by: Adam Ford Applied, thanks.
[PATCH 2/2] extcon: fsa9480: Support TI TSU6111 variant
The Texas Instruments TSU6111 is compatible to the
FSA880/FSA9480.
Signed-off-by: Linus Walleij
---
drivers/extcon/extcon-fsa9480.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/extcon/extcon-fsa9480.c b/drivers/extcon/extcon-fsa9480.c
index 8405512f5199..08bdedbcdb0d 100644
--- a/drivers/extcon/extcon-fsa9480.c
+++ b/drivers/extcon/extcon-fsa9480.c
@@ -364,6 +364,7 @@ MODULE_DEVICE_TABLE(i2c, fsa9480_id);
static const struct of_device_id fsa9480_of_match[] = {
{ .compatible = "fcs,fsa9480", },
{ .compatible = "fcs,fsa880", },
+ { .compatible = "ti,tsu6111", },
{ },
};
MODULE_DEVICE_TABLE(of, fsa9480_of_match);
--
2.26.2
[PATCH 1/2] extcon: fsa9480: Rewrite bindings in YAML and extend
This rewrites the FSA9480 DT bindings using YAML and
extends them with the compatible TI TSU6111.
I chose to name the file fcs,fsa880 since this is the
first switch, later versions are improvements.
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij
---
.../bindings/extcon/extcon-fsa9480.txt| 21
.../bindings/extcon/fcs,fsa880.yaml | 52 +++
2 files changed, 52 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
create mode 100644 Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml
diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
deleted file mode 100644
index 624bd76f468e..
--- a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-FAIRCHILD SEMICONDUCTOR FSA9480 MICROUSB SWITCH
-
-The FSA9480 is a USB port accessory detector and switch. The FSA9480 is fully
-controlled using I2C and enables USB data, stereo and mono audio, video,
-microphone, and UART data to use a common connector port.
-
-Required properties:
- - compatible : Must be one of
- "fcs,fsa9480"
- "fcs,fsa880"
- - reg : Specifies i2c slave address. Must be 0x25.
- - interrupts : Should contain one entry specifying interrupt signal of
- interrupt parent to which interrupt pin of the chip is connected.
-
- Example:
- musb@25 {
- compatible = "fcs,fsa9480";
- reg = <0x25>;
- interrupt-parent = <>;
- interrupts = <7 0>;
- };
diff --git a/Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml
b/Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml
new file mode 100644
index ..ef6a246a1337
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/extcon/fcs,fsa880.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fairchild Semiconductor FSA880, FSA9480 and compatibles
+
+maintainers:
+ - Linus Walleij
+
+description:
+ The FSA880 and FSA9480 are USB port accessory detectors and switches.
+ The switch is fully controlled using I2C and enables USB data, stereo
+ and mono audio, video, microphone, and UART data to use a common
+ connector port. Compatible switches exist from other manufacturers.
+
+properties:
+ compatible:
+enum:
+ - fcs,fsa880
+ - fcs,fsa9480
+ - ti,tsu6111
+
+ reg:
+maxItems: 1
+description: The I2C address for an FSA880 compatible device is
+ usually 0x25.
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+usb-switch@25 {
+compatible = "fcs,fsa880";
+reg = <0x25>;
+interrupt-parent = <>;
+interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+};
+};
--
2.26.2
[PATCH] ARM: dts: sun8i: v40: bananapi-m2-berry: Fix ethernet node
Ethernet PHY on BananaPi M2 Berry provides RX and TX delays. Fix ethernet
node to reflect that fact.
Fixes: 27e81e1970a8 ("ARM: dts: sun8i: v40: bananapi-m2-berry: Enable GMAC
ethernet controller")
Signed-off-by: Pablo Greco
---
arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
index 15c22b06fc4b..3ab6f47cea4f 100644
--- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
+++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
@@ -120,7 +120,7 @@
pinctrl-names = "default";
pinctrl-0 = <_rgmii_pins>;
phy-handle = <>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-supply = <_dc1sw>;
status = "okay";
};
--
2.18.4
[PATCH] ARM: dts: sun7i: bananapi: Enable RGMII RX/TX delay on Ethernet PHY
The Ethernet PHY on the Bananapi M1 has the RX and TX delays enabled on
the PHY, using pull-ups on the RXDLY and TXDLY pins.
Fix the phy-mode description to correct reflect this so that the
implementation doesn't reconfigure the delays incorrectly. This
happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
rx/tx delay config").
Fixes: 8a5b272fbf44 ("ARM: dts: sun7i: Add Banana Pi board")
Signed-off-by: Pablo Greco
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index bb3987e101c2..0b3d9ae75650 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -132,7 +132,7 @@
pinctrl-names = "default";
pinctrl-0 = <_rgmii_pins>;
phy-handle = <>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-supply = <_gmac_3v3>;
status = "okay";
};
--
2.18.4
[PATCH] ARM: dts: sun8i: r40: bananapi-m2-berry: Fix dcdc1 regulator
DCDC1 regulator powers many different subsystems. While some of them can
work at 3.0 V, some of them can not. For example, VCC-HDMI can only work
between 3.24 V and 3.36 V. According to OS images provided by the board
manufacturer this regulator should be set to 3.3 V.
Set DCDC1 and DCDC1SW to 3.3 V in order to fix this.
Fixes: 23edc168bd98 ("ARM: dts: sun8i: Add board dts file for Banana Pi M2
Berry")
Fixes: 27e81e1970a8 ("ARM: dts: sun8i: v40: bananapi-m2-berry: Enable GMAC
ethernet controller")
Signed-off-by: Pablo Greco
---
arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
index 3ab6f47cea4f..47954551f573 100644
--- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
+++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
@@ -198,16 +198,16 @@
};
_dc1sw {
- regulator-min-microvolt = <300>;
- regulator-max-microvolt = <300>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
regulator-name = "vcc-gmac-phy";
};
_dcdc1 {
regulator-always-on;
- regulator-min-microvolt = <300>;
- regulator-max-microvolt = <300>;
- regulator-name = "vcc-3v0";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-3v3";
};
_dcdc2 {
--
2.18.4
Re: [PATCH net-next] net: bridge: mcast: fix stub definition of br_multicast_querier_exists
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sun, 1 Nov 2020 02:08:45 +0200 you wrote:
> The commit cited below has changed only the functional prototype of
> br_multicast_querier_exists, but forgot to do that for the stub
> prototype (the one where CONFIG_BRIDGE_IGMP_SNOOPING is disabled).
>
> Fixes: 955062b03fa6 ("net: bridge: mcast: add support for raw L2 multicast
> groups")
> Reported-by: kernel test robot
> Signed-off-by: Vladimir Oltean
>
> [...]
Here is the summary with links:
- [net-next] net: bridge: mcast: fix stub definition of
br_multicast_querier_exists
https://git.kernel.org/netdev/net-next/c/c43fd36f7fec
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: possible deadlock in do_fcntl
syzbot has bisected this issue to:
commit e918188611f073063415f40fae568fa4d86d9044
Author: Boqun Feng
Date: Fri Aug 7 07:42:20 2020 +
locking: More accurate annotations for read_lock()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1292881a50
start commit: 4e78c578 Add linux-next specific files for 20201030
git tree: linux-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=1192881a50
console output: https://syzkaller.appspot.com/x/log.txt?x=1692881a50
kernel config: https://syzkaller.appspot.com/x/.config?x=83318758268dc331
dashboard link: https://syzkaller.appspot.com/bug?extid=e6d5398a02c516ce5e70
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b24ecc50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13c0151250
Reported-by: syzbot+e6d5398a02c516ce5...@syzkaller.appspotmail.com
Fixes: e918188611f0 ("locking: More accurate annotations for read_lock()")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH] staging: fbtft: fb_watterott: fix usleep_range is preferred over udelay
Fix the checkpath.pl issue on fb_watterott.c. write_vmem and write_vmem_8bit functions are within non-atomic context and can safely use usleep_range. see Documentation/timers/timers-howto.txt Signed-off-by: Hassan Shahbazi --- drivers/staging/fbtft/fb_watterott.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/fbtft/fb_watterott.c b/drivers/staging/fbtft/fb_watterott.c index 76b25df376b8..afcc86a17995 100644 --- a/drivers/staging/fbtft/fb_watterott.c +++ b/drivers/staging/fbtft/fb_watterott.c @@ -84,7 +84,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, size_t len) par->txbuf.buf, 10 + par->info->fix.line_length); if (ret < 0) return ret; - udelay(300); + usleep_range(300, 310); } return 0; @@ -124,7 +124,7 @@ static int write_vmem_8bit(struct fbtft_par *par, size_t offset, size_t len) par->txbuf.buf, 10 + par->info->var.xres); if (ret < 0) return ret; - udelay(700); + usleep_range(700, 710); } return 0; -- 2.25.1
Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
On 31 Oct 2020, at 23:30, Andy Lutomirski wrote:
>
> cc: some libc folks
>
> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
>>
>> POSIX specifies that the first field of the supplied msgp, namely mtype,
>> is a long, not a __kernel_long_t, and it's a user-defined struct due to
>> the variable-length mtext field so we can't even bend the spec and make
>> it a __kernel_long_t even if we wanted to. Thus we must use the compat
>> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
>> msgrcv respectively.
>
> This is a mess.
>
> include/uapi/linux/msg.h has:
>
> /* message buffer for msgsnd and msgrcv calls */
> struct msgbuf {
>__kernel_long_t mtype; /* type of message */
>char mtext[1]; /* message text */
> };
Yeah that's just wrong, POSIX is very clear it's a plain long.
> Your test has:
>
> struct msg_long {
>long mtype;
>char mtext[8];
> };
>
> struct msg_long_ext {
>struct msg_long msg_long;
>char mext[4];
> };
>
> and I'm unclear as to exactly what you're trying to do there with the
> "mext" part.
The intent was to show that, despite the 8 being passed to
msgsnd/msgrcv (due to the `char mtext[8]`), an extra 4 bytes were being
copied when using long, namely mext, and that using __kernel_long_t was
giving the behaviour that should be observed for long, since the 4
bytes of mext in the destination buffer were left untouched and thus
still 0 from the memset.
> POSIX says:
>
> The application shall ensure that the argument msgp points to a user-
> defined buffer that contains first a field of type long specifying the
> type of the message, and then a data portion that holds the data bytes
> of the message. The structure below is an example of what this user-de‐
> fined buffer might look like:
>
> struct mymsg {
> long mtype; /* Message type. */
> char mtext[1];/* Message text. */
> }
>
> NTP has this delightful piece of code:
>
> 44 typedef union {
> 45 struct msgbuf msgp;
> 46 struct {
> 47 long mtype;
> 48 int code;
> 49 struct timeval tv;
> 50 } msgb;
> 51 } MsgBuf;
I was initially concerned by that, since msgbuf is a thing that FreeBSD
also defines but is completely different (used for console messages),
but it appears that adjtime.h, where that is defined, is only used in
libntp/adjtime.c and adjtimed/adjtimed.c, with the former only
including it if NEED_HPUX_ADJTIME, and the latter only being enabled by
configure.ac for HP-UX. So I do not believe that code has ever been
compiled on Linux (though that doesn't mean it's good code for HP-UX!).
> bluefish has:
>
> struct small_msgbuf {
> long mtype;
> char mtext[MSQ_QUEUE_SMALL_SIZE];
> } small_msgp;
Which is standards-conforming but unfortunately currently causes memory
corruption for the 4 bytes after it, just like any other correct user
of msgsend/msgrecv on x32.
> My laptop has nothing at all in /dev/mqueue.
>
> So I don't really know what the right thing to do is. Certainly if
> we're going to apply this patch, we should also fix the header. I
> almost think we should *delete* struct msgbuf from the headers, since
> it's all kinds of busted, but that will break the NTP build. Ideally
> we would go back in time and remove it from the headers.
I agree that it should not be in the header. Failing that though we
could change the type as it is just wrong on x32 and as you say nobody
should notice (and if anything it'll be because things *start* working).
> Libc people, any insight? We can probably fix the bug without
> annoying anyone given how lightly x32 is used and how lightly POSIX
> message queues are used.
That is my hope...
Jess
>>
>> Due to erroneously including the first 4 bytes of mtext in the mtype
>> this would previously also cause non-zero msgtyp arguments for msgrcv to
>> search for the wrong messages, and if sharing message queues between x32
>> and non-x32 (i386 or x86_64) processes this would previously cause mtext
>> to "move" and, depending on the direction and ABI combination, lose the
>> first 4 bytes.
>>
>> Signed-off-by: Jessica Clarke
>> ---
>>
>> I have verified that the test at the end of [1] now gives the correct
>> result on x32 ("PAYL" not "PAY" as I erroneously claimed it should be in
>> the above email) and that both i386 and amd64 give the same output with
>> that test as before.
>>
>> [1] <1156938f-a9a3-4ee9-b059-2294a0b9f...@jrtc27.com>
>>
>> Changes since v1:
>> * Uses the same syscall numbers for x32 as amd64 and the current x32
>> rather than (further) breaking ABI by allocating new ones from the
>> legacy x32 range
>>
>> arch/x86/entry/syscalls/syscall_64.tbl | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
>> b/arch/x86/entry/syscalls/syscall_64.tbl
>> index f30d6ae9a..f462123f3 100644
>> ---
[PATCH net-next] net: bridge: mcast: fix stub definition of br_multicast_querier_exists
The commit cited below has changed only the functional prototype of
br_multicast_querier_exists, but forgot to do that for the stub
prototype (the one where CONFIG_BRIDGE_IGMP_SNOOPING is disabled).
Fixes: 955062b03fa6 ("net: bridge: mcast: add support for raw L2 multicast
groups")
Reported-by: kernel test robot
Signed-off-by: Vladimir Oltean
---
net/bridge/br_private.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 4c691c371884..891f3b05ffa4 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -1013,7 +1013,8 @@ static inline bool br_multicast_is_router(struct
net_bridge *br)
}
static inline bool br_multicast_querier_exists(struct net_bridge *br,
- struct ethhdr *eth)
+ struct ethhdr *eth,
+ const struct
net_bridge_mdb_entry *mdb)
{
return false;
}
--
2.25.1
arch/powerpc/lib/sstep.c:1172:21: error: variable 'suffix' set but not used
Hi Jordan,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c2dc4c073fb71b50904493657a7622b481b346e3
commit: 650b55b707fdfa764e9f2b81314d3eb4216fb962 powerpc: Add prefixed
instructions to instruction data type
date: 6 months ago
config: powerpc-allnoconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=650b55b707fdfa764e9f2b81314d3eb4216fb962
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 650b55b707fdfa764e9f2b81314d3eb4216fb962
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/powerpc/lib/sstep.c: In function 'analyse_instr':
>> arch/powerpc/lib/sstep.c:1172:21: error: variable 'suffix' set but not used
>> [-Werror=unused-but-set-variable]
1172 | unsigned int word, suffix;
| ^~
arch/powerpc/lib/sstep.c:1168:31: error: variable 'rc' set but not used
[-Werror=unused-but-set-variable]
1168 | unsigned int opcode, ra, rb, rc, rd, spr, u;
| ^~
cc1: all warnings being treated as errors
vim +/suffix +1172 arch/powerpc/lib/sstep.c
1153
1154 /*
1155 * Decode an instruction, and return information about it in *op
1156 * without changing *regs.
1157 * Integer arithmetic and logical instructions, branches, and barrier
1158 * instructions can be emulated just using the information in *op.
1159 *
1160 * Return value is 1 if the instruction can be emulated just by
1161 * updating *regs with the information in *op, -1 if we need the
1162 * GPRs but *regs doesn't contain the full register set, or 0
1163 * otherwise.
1164 */
1165 int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
1166struct ppc_inst instr)
1167 {
1168 unsigned int opcode, ra, rb, rc, rd, spr, u;
1169 unsigned long int imm;
1170 unsigned long int val, val2;
1171 unsigned int mb, me, sh;
> 1172 unsigned int word, suffix;
1173 long ival;
1174
1175 word = ppc_inst_val(instr);
1176 suffix = ppc_inst_suffix(instr);
1177
1178 op->type = COMPUTE;
1179
1180 opcode = ppc_inst_primary_opcode(instr);
1181 switch (opcode) {
1182 case 16:/* bc */
1183 op->type = BRANCH;
1184 imm = (signed short)(word & 0xfffc);
1185 if ((word & 2) == 0)
1186 imm += regs->nip;
1187 op->val = truncate_if_32bit(regs->msr, imm);
1188 if (word & 1)
1189 op->type |= SETLK;
1190 if (branch_taken(word, regs, op))
1191 op->type |= BRTAKEN;
1192 return 1;
1193 #ifdef CONFIG_PPC64
1194 case 17:/* sc */
1195 if ((word & 0xfe2) == 2)
1196 op->type = SYSCALL;
1197 else
1198 op->type = UNKNOWN;
1199 return 0;
1200 #endif
1201 case 18:/* b */
1202 op->type = BRANCH | BRTAKEN;
1203 imm = word & 0x03fc;
1204 if (imm & 0x0200)
1205 imm -= 0x0400;
1206 if ((word & 2) == 0)
1207 imm += regs->nip;
1208 op->val = truncate_if_32bit(regs->msr, imm);
1209 if (word & 1)
1210 op->type |= SETLK;
1211 return 1;
1212 case 19:
1213 switch ((word >> 1) & 0x3ff) {
1214 case 0: /* mcrf */
1215 op->type = COMPUTE + SETCC;
1216 rd = 7 - ((word >> 23) & 0x7);
1217 ra = 7 - ((word >> 18) & 0x7);
1218 rd *= 4;
1219 ra *= 4;
1220 val = (regs->ccr >> ra) & 0xf;
1221 op->ccval = (regs->ccr & ~(0xfUL << rd)) | (val
<< rd);
1222 return 1;
1223
1224 case 16:/* bclr */
1225 case 528: /* bcctr */
Re: [PATCH v4 00/17] Add VFIO mediated device support and DEV-MSI support for the idxd driver
Hi Thomas, On Sat, Oct 31, 2020 at 03:50:43AM +0100, Thomas Gleixner wrote: > Ashok, > > < skip a lot of non-sensical arguments> Ouch!.. Didn't mean to awaken you like this :-).. apologies.. profusely! > > Just because there is historical precendence which does not care about > the differentiation of subsystems is not an argument at all to make the > same mistakes which have been made years ago. > > IDXD is just infrastructure which provides the base for a variety of > different functionalities. Very similar to what multi function devices > provide. In fact IDXD is pretty much a MFD facility. I'm only asking this to better understand the thought process. I don't intend to be defensive, I have my hands tied back.. so we will do what you say best fits per your recommendation. Not my intend to dig a deeper hole than I have already dug! :-( IDXD is just a glorified DMA engine, data mover. It also does a few other things. In that sense its a multi-function facility. But doesn't do different functional pieces like PCIe multi-function device in that sense. i.e it doesn't do other storage and network in that sense. > > Sticking all of it into dmaengine is sloppy at best. The dma engine > related part of IDXD is only a part of the overall functionality. dmaengine is the basic non-transformational data-mover. Doing other operations or transformations are just the glorified data-mover part. But fundamentally not different. > > I'm well aware that it is conveniant to just throw everything into > drivers/myturf/ but that does neither make it reviewable nor > maintainable. That's true, when we add lot of functionality in one place. IDXD doing mdev support is not offering new functioanlity. SRIOV PF drivers that support PF/VF mailboxes are part of PF drivers today. IDXD mdev is preciely playing that exact role. If we are doing this just to improve review effectiveness, Now we would need some parent driver, and these sub-drivers registering seemed like a bit of over-engineering when these sub-drivers actually are an extension of the base driver and offer nothing more than extending sub-device partitions of IDXD for guest drivers. These look and feel like IDXD, not another device interface. In that sense if we move PF/VF mailboxes as separate drivers i thought it feels a bit odd. Please don't take it the wrong way. Cheers, Ashok
Re: [PATCH v2 0/4] perf: Fix perf_event_attr::exclusive rotation
On Thu, Oct 29, 2020 at 05:27:19PM +0100, Peter Zijlstra wrote: > Hi, > > Andi recently added exclusive event group support to tools/perf: > > https://lkml.kernel.org/r/20201014144255.22699-1-a...@firstfloor.org > > and promptly found that they didn't work as specified. > > (sorry for the resend, I forgot LKML the first time) hm, it's too late for me to check ;-) but should I be able to do this with exclusive event.. running both command at the same time: $ sudo ./perf stat -e cycles:e -I 1000 # time counts unit events 1.002430650 33,946,849 cycles:e 2.004920725502,399,986 cycles:e (67.57%) 3.007087631859,745,048 cycles:e (50.00%) 4.009078254845,860,723 cycles:e (50.00%) 5.011086104838,457,275 cycles:e (50.00%) $ sudo ./perf stat -e cycles:e -I 1000 # time counts unit events 1.001665466848,973,404 cycles:e (50.01%) 2.003658048856,505,255 cycles:e (50.00%) 3.005658022842,737,973 cycles:e (50.00%) 4.007657797844,800,598 cycles:e (50.00%) jirka
Re: [PATCH] s390/smp: Move rcu_cpu_starting() earlier
On Sat, 2020-10-31 at 19:37 +0100, Heiko Carstens wrote: > On Wed, Oct 28, 2020 at 02:27:42PM -0400, Qian Cai wrote: > > The call to rcu_cpu_starting() in smp_init_secondary() is not early > > enough in the CPU-hotplug onlining process, which results in lockdep > > splats as follows: > > > > WARNING: suspicious RCU usage > > - > > kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!! > > > > other info that might help us debug this: > > > > RCU used illegally from offline CPU! > > rcu_scheduler_active = 1, debug_locks = 1 > > no locks held by swapper/1/0. > > > > Call Trace: > > show_stack+0x158/0x1f0 > > dump_stack+0x1f2/0x238 > > __lock_acquire+0x2640/0x4dd0 > > lock_acquire+0x3a8/0xd08 > > _raw_spin_lock_irqsave+0xc0/0xf0 > > clockevents_register_device+0xa8/0x528 > > init_cpu_timer+0x33e/0x468 > > smp_init_secondary+0x11a/0x328 > > smp_start_secondary+0x82/0x88 > > > > This is avoided by moving the call to rcu_cpu_starting up near the > > beginning of the smp_init_secondary() function. Note that the > > raw_smp_processor_id() is required in order to avoid calling into > > lockdep before RCU has declared the CPU to be watched for readers. > > > > Link: > > https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/ > > Signed-off-by: Qian Cai > > --- > > arch/s390/kernel/smp.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > Could you provide the config you used? I'm wondering why I can't > reproduce this even though I have lot's of debug options enabled. https://cailca.coding.net/public/linux/mm/git/files/master/s390.config Essentially, I believe it requires CONFIG_PROVE_RCU_LIST=y. Also, it occurs to me that this only starts to happen after the commit mentioned in the above link.
Re: [PATCH net-next] net: dlci: Deprecate the DLCI driver (aka the Frame Relay layer)
On Sat, Oct 31, 2020 at 2:41 PM Arnd Bergmann wrote: > > I think it can just go in the bin directly. I actually submitted a couple of > patches to clean up drivers/net/wan last year but didn't follow up > with a new version after we decided that x.25 is still needed, see > https://lore.kernel.org/netdev/20191209151256.2497534-1-a...@arndb.de/ > > I can resubmit if you like. Should we also remove the two macro definitions in "include/uapi/linux/sockios.h" (SIOCADDDLCI / SIOCDELDLCI), too? It seems to be not included in your original patch.
Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
cc: some libc folks
On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
>
> POSIX specifies that the first field of the supplied msgp, namely mtype,
> is a long, not a __kernel_long_t, and it's a user-defined struct due to
> the variable-length mtext field so we can't even bend the spec and make
> it a __kernel_long_t even if we wanted to. Thus we must use the compat
> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
> msgrcv respectively.
This is a mess.
include/uapi/linux/msg.h has:
/* message buffer for msgsnd and msgrcv calls */
struct msgbuf {
__kernel_long_t mtype; /* type of message */
char mtext[1]; /* message text */
};
Your test has:
struct msg_long {
long mtype;
char mtext[8];
};
struct msg_long_ext {
struct msg_long msg_long;
char mext[4];
};
and I'm unclear as to exactly what you're trying to do there with the
"mext" part.
POSIX says:
The application shall ensure that the argument msgp points to a user-
defined buffer that contains first a field of type long specifying the
type of the message, and then a data portion that holds the data bytes
of the message. The structure below is an example of what this user-de‐
fined buffer might look like:
struct mymsg {
long mtype; /* Message type. */
char mtext[1];/* Message text. */
}
NTP has this delightful piece of code:
44 typedef union {
45 struct msgbuf msgp;
46 struct {
47 long mtype;
48 int code;
49 struct timeval tv;
50 } msgb;
51 } MsgBuf;
bluefish has:
struct small_msgbuf {
long mtype;
char mtext[MSQ_QUEUE_SMALL_SIZE];
} small_msgp;
My laptop has nothing at all in /dev/mqueue.
So I don't really know what the right thing to do is. Certainly if
we're going to apply this patch, we should also fix the header. I
almost think we should *delete* struct msgbuf from the headers, since
it's all kinds of busted, but that will break the NTP build. Ideally
we would go back in time and remove it from the headers.
Libc people, any insight? We can probably fix the bug without
annoying anyone given how lightly x32 is used and how lightly POSIX
message queues are used.
--Andy
>
> Due to erroneously including the first 4 bytes of mtext in the mtype
> this would previously also cause non-zero msgtyp arguments for msgrcv to
> search for the wrong messages, and if sharing message queues between x32
> and non-x32 (i386 or x86_64) processes this would previously cause mtext
> to "move" and, depending on the direction and ABI combination, lose the
> first 4 bytes.
>
> Signed-off-by: Jessica Clarke
> ---
>
> I have verified that the test at the end of [1] now gives the correct
> result on x32 ("PAYL" not "PAY" as I erroneously claimed it should be in
> the above email) and that both i386 and amd64 give the same output with
> that test as before.
>
> [1] <1156938f-a9a3-4ee9-b059-2294a0b9f...@jrtc27.com>
>
> Changes since v1:
> * Uses the same syscall numbers for x32 as amd64 and the current x32
>rather than (further) breaking ABI by allocating new ones from the
>legacy x32 range
>
> arch/x86/entry/syscalls/syscall_64.tbl | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
> b/arch/x86/entry/syscalls/syscall_64.tbl
> index f30d6ae9a..f462123f3 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -77,8 +77,10 @@
> 66 common semctl sys_semctl
> 67 common shmdt sys_shmdt
> 68 common msgget sys_msgget
> -69 common msgsnd sys_msgsnd
> -70 common msgrcv sys_msgrcv
> +69 64 msgsnd sys_msgsnd
> +69 x32 msgsnd compat_sys_msgsnd
> +70 64 msgrcv sys_msgrcv
> +70 x32 msgrcv compat_sys_msgrcv
> 71 common msgctl sys_msgctl
> 72 common fcntl sys_fcntl
> 73 common flock sys_flock
> --
> 2.28.0
>
Re: [RESEND PATCH v5] net: macb: add support for high speed interface
On Thu, 29 Oct 2020 13:47:07 +0100 Parshuram Thombare wrote: > This patch adds support for 10GBASE-R interface to the linux driver for > Cadence's ethernet controller. > This controller has separate MAC's and PCS'es for low and high speed paths. > High speed PCS supports 100M, 1G, 2.5G, 5G and 10G through rate adaptation > implementation. However, since it doesn't support auto negotiation, linux > driver is modified to support 10GBASE-R instead of USXGMII. > > Signed-off-by: Parshuram Thombare Applied, thanks!
Re: [PATCH net-next v2] net/usb/r8153_ecm: support ECM mode for RTL8153
On Fri, 30 Oct 2020 11:23:08 +0800 Hayes Wang wrote: > Support ECM mode based on cdc_ether with relative mii functions, > when CONFIG_USB_RTL8152 is not set, or the device is not supported > by r8152 driver. > > Signed-off-by: Hayes Wang Can you describe the use case in more detail? AFAICT r8152 defines a match for the exact same device. Does it not mean that which driver is used will be somewhat random if both are built? > +/* Define these values to match your device */ > +#define VENDOR_ID_REALTEK0x0bda > +#define VENDOR_ID_MICROSOFT 0x045e > +#define VENDOR_ID_SAMSUNG0x04e8 > +#define VENDOR_ID_LENOVO 0x17ef > +#define VENDOR_ID_LINKSYS0x13b1 > +#define VENDOR_ID_NVIDIA 0x0955 > +#define VENDOR_ID_TPLINK 0x2357 $ git grep 0x2357 | grep -i tplink drivers/net/usb/cdc_ether.c:#define TPLINK_VENDOR_ID0x2357 drivers/net/usb/r8152.c:#define VENDOR_ID_TPLINK0x2357 drivers/usb/serial/option.c:#define TPLINK_VENDOR_ID0x2357 $ git grep 0x17ef | grep -i lenovo drivers/hid/hid-ids.h:#define USB_VENDOR_ID_LENOVO 0x17ef drivers/hid/wacom.h:#define USB_VENDOR_ID_LENOVO0x17ef drivers/net/usb/cdc_ether.c:#define LENOVO_VENDOR_ID0x17ef drivers/net/usb/r8152.c:#define VENDOR_ID_LENOVO0x17ef Time to consolidate those vendor id defines perhaps?
Re: [PATCH 01/15] iio: accel: remove unnecessary CONFIG_PM_SLEEP
On Sat, Oct 31, 2020 at 11:05:11AM +, Jonathan Cameron wrote: On Fri, 30 Oct 2020 22:34:10 +0800 Coiby Xu wrote: On Thu, Oct 29, 2020 at 07:06:40PM +0200, Andy Shevchenko wrote: >On Thu, Oct 29, 2020 at 4:42 PM Jonathan Cameron wrote: >> On Thu, 29 Oct 2020 15:48:56 +0800 >> Coiby Xu wrote: > >> Please put a cover letter on your next series explaining the context. >> In this particular case some of the replies you have gotten are >> general at it is a lot easier to find these sorts of things via >> replying to the cover letter. > >Looking at the number of duplicate messages I would suggest that one >needs to go through documentation on how to use git format-patch and >git send-email. > Thank you for the suggestion! Actually it's a tree-wide change and it seems the kernel community prefer individual patches or series for subsystems having the same maintainer over a huge patch set so I wrote some scripts to automate the process. That's why you see ~50 emails with almost the same commit message. The only difference of these commit messages is the name of PM macro. When doing a bit set like this, it's worth sending out a small subset first to shake out issue like those seen here. Once those get merged then send out out the reset. Thank you for the suggestion! Actually I've held off another ~150 emails and these ~200 emails were only part of work. I thought it's better to reach 4 or 5 subsystem to collect sufficient feedbacks considering some subsystems may respond slow. But I didn't realize a better way is to cut down the size of patch set sent to a subsystem. Thanks, Jonathan >-- >With Best Regards, >Andy Shevchenko -- Best regards, Coiby -- Best regards, Coiby
Re: [PATCH net-next] net: add in_softirq() debug checking in napi_consume_skb()
On Thu, 29 Oct 2020 19:34:48 +0800 Yunsheng Lin wrote:
> The current semantic for napi_consume_skb() is that caller need
> to provide non-zero budget when calling from NAPI context, and
> breaking this semantic will cause hard to debug problem, because
> _kfree_skb_defer() need to run in atomic context in order to push
> the skb to the particular cpu' napi_alloc_cache atomically.
>
> So add a in_softirq() debug checking in napi_consume_skb() to catch
> this kind of error.
>
> Suggested-by: Eric Dumazet
> Signed-off-by: Yunsheng Lin
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 1ba8f01..1834007 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -897,6 +897,10 @@ void napi_consume_skb(struct sk_buff *skb, int budget)
> return;
> }
>
> + DEBUG_NET_WARN(!in_softirq(),
> +"%s is called with non-zero budget outside softirq
> context.\n",
> +__func__);
Can't we use lockdep instead of defining our own knobs?
Like this maybe?
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index f5594879175a..5253a167d00c 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -594,6 +594,14 @@ do {
\
this_cpu_read(hardirqs_enabled)));\
} while (0)
+#define lockdep_assert_in_softirq()\
+do { \
+ WARN_ON_ONCE(__lockdep_enabled && \
+(softirq_count() == 0 || \
+ this_cpu_read(hardirq_context))); \
+} while (0)
> if (!skb_unref(skb))
> return;
>
Re: [PATCH net-next v6 1/5] net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
On Sat, Oct 31, 2020 at 12:48 PM Willem de Bruijn wrote: > > Returning code in branches vs an error jump label seems more of a > personal preference, and to me does not pass the benefit/cost threshold. This patch is necessary for the 2nd and 5th patch in this series, because the 2nd and 5th patch would add a lot of places where we need to "error out" and drop the frame. Without this patch, the 2nd and 5th patch would add a lot of useless code. The 2nd patch is also necessary for the 5th patch, because otherwise I would not know how to produce the 5th patch. The logic is so convoluted for me. And it seems to me that the simplest way for me would make all code to follow the logic of eth_type_trans. The patch series was actually a single patch previously: http://patchwork.ozlabs.org/project/netdev/patch/20201017051951.363514-1-xie.he.0...@gmail.com/ I splitted it to make changes I do clearer. But really these patches should be as a whole. It's really hard for me to do the 5th patch without the 1st and 2nd patch.
Re: [PATCH net-next] net: dlci: Deprecate the DLCI driver (aka the Frame Relay layer)
On Sat, 31 Oct 2020 22:41:30 +0100 Arnd Bergmann wrote: > On Sat, Oct 31, 2020 at 5:53 PM Jakub Kicinski wrote: > > > > On Fri, 30 Oct 2020 22:10:42 -0700 Xie He wrote: > > > > The usual way of getting rid of old code is to move it to staging/ > > > > for a few releases then delete it, like Arnd just did with wimax. > > > > > > Oh. OK. But I see "include/linux/if_frad.h" is included in > > > "net/socket.c", and there's still some code in "net/socket.c" related > > > to it. If we move all these files to "staging/", we need to change the > > > "include" line in "net/socket.c" to point to the new location, and we > > > still need to keep a little code in "net/socket.c". So I think if we > > > move it to "staging/", we can't do this in a clean way. > > > > I'd just place that code under appropriate #ifdef CONFIG_ so we don't > > forget to remove it later. It's just the dlci_ioctl_hook, right? > > > > Maybe others have better ideas, Arnd? > > I think it can just go in the bin directly. Ack, fine by me. > I actually submitted a couple of patches to clean up drivers/net/wan > last year but didn't follow up with a new version after we decided > that x.25 is still needed, see > https://lore.kernel.org/netdev/20191209151256.2497534-1-a...@arndb.de/ > > I can resubmit if you like. Let's just leave it at DLCI/SDLA for now, we can revisit once Dave is back :)
Re: [PATCH] pci: mediatek: fix warning in msi.h
Frank, On Sat, Oct 31 2020 at 15:03, Frank Wunderlich wrote: > From: Frank Wunderlich > > 5.10 shows these warnings on bootup while enabling pcie > at least on bananapi-r2: > > [6.161730] WARNING: CPU: 2 PID: 73 at include/linux/msi.h:213 > pci_msi_setup_ > msi_irqs.constprop.0+0x78/0x80 > > [6.724607] WARNING: CPU: 2 PID: 73 at include/linux/msi.h:219 > free_msi_irqs+ > > fix this by selecting PCI_MSI_ARCH_FALLBACKS for MTK PCIe driver That's not a fix. It's just supressing the warning. PCI_MSI_ARCH_FALLBACKS is only valid for 1) Architectures which implement the fallbacks 2) Outdated PCI controller drivers on architectures without #1 which implement the deprecated msi_controller mechanism. That is handled in the weak arch fallback implementation. The mediatek PCIE driver does not qualify for #2. It's purely irq domain based. So there is something else going wrong. The PCI device which tries to allocate MSIs does not have an irq domain associated which makes it run into that warning. If you enable PCI_MSI_ARCH_FALLBACKS then the MSI allocation fails silently. So it's just papering over the underlying problem. So it needs to be figured out why the domain association is not there. Thanks, tglx
Re: [GIT PULL] flexible array conversions for 5.10-rc2
The pull request you sent on Fri, 30 Oct 2020 17:13:42 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git > tags/flexible-array-conversions-5.10-rc2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/53760f9b74a3412c1b67a20b0e8dbf7c3cebfc45 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] vhost,vdpa: fixes
The pull request you sent on Sat, 31 Oct 2020 15:59:40 -0400: > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c2dc4c073fb71b50904493657a7622b481b346e3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it
On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav wrote: > > [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.ya...@ti.com/ > > Ping. Any comments on the series? >From the UBIFS point of view I'd like to avoid as many device specific settings as possible. We check already for NOR flash, checking for NOR *and* SPI_NOR_NO_MULTI_PASS_PP feels a bit clumsy. Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP? This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail in the mtd framework? -- Thanks, //richard
Re: [PATCH] MIPS: Kconfig: fix a few trivial spelling mistakes
On Wed, Oct 28, 2020 at 9:01 PM Colin King wrote: > > From: Colin Ian King > > There are a few spelling mistakes in the Kconfig, fix these. > > Signed-off-by: Colin Ian King > --- > arch/mips/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH net-next] net: dlci: Deprecate the DLCI driver (aka the Frame Relay layer)
On Sat, Oct 31, 2020 at 5:53 PM Jakub Kicinski wrote: > > On Fri, 30 Oct 2020 22:10:42 -0700 Xie He wrote: > > > The usual way of getting rid of old code is to move it to staging/ > > > for a few releases then delete it, like Arnd just did with wimax. > > > > Oh. OK. But I see "include/linux/if_frad.h" is included in > > "net/socket.c", and there's still some code in "net/socket.c" related > > to it. If we move all these files to "staging/", we need to change the > > "include" line in "net/socket.c" to point to the new location, and we > > still need to keep a little code in "net/socket.c". So I think if we > > move it to "staging/", we can't do this in a clean way. > > I'd just place that code under appropriate #ifdef CONFIG_ so we don't > forget to remove it later. It's just the dlci_ioctl_hook, right? > > Maybe others have better ideas, Arnd? I think it can just go in the bin directly. I actually submitted a couple of patches to clean up drivers/net/wan last year but didn't follow up with a new version after we decided that x.25 is still needed, see https://lore.kernel.org/netdev/20191209151256.2497534-1-a...@arndb.de/ I can resubmit if you like. Arnd
Re: [PATCH v8 -tip 08/26] sched/fair: Snapshot the min_vruntime of CPUs on force idle
On Fri, Oct 30, 2020 at 09:41:12AM +0100, Peter Zijlstra wrote:
> On Thu, Oct 29, 2020 at 10:42:29PM -0400, Joel Fernandes wrote:
>
> > Forgot to ask, do you also need to do the task_vruntime_update() for
> > the unconstrained pick?
>
> Humm.. interesting case.
>
> Yes, however... since in that case the picks aren't synchronized it's a
> wee bit dodgy. I'll throw it on the pile together with SMT4.
Ok. I threw it into the patch below anyway to not take any chances. I got the
version of your patch to a point where the perf is looking good (there's
still some room for improvement, but I am much much happier with the tests).
The changes are:
- Fix but in !(fib && !fi) thingie.
- Pass prio_less with with force-idle information ... prio_less() is called
from various paths. We need to be careful what we pass it. Its possible we
select idle on something, but we are not done with selection yet - we
continue doing prio_less(). So just pass it fi_before.
- During enqueue, prio_less is used then, we may need to sync even then.
- Make cfs_prio_less sync even when !fi.
- Sync the min_vruntime for unconstrained picks and during prio_less() even
when the core is not in FI. Clarify why you feel for its dodgy for sync'ing
when unconstrained?
> Also, I'm still hoping you can make this form work:
>
>
> https://lkml.kernel.org/r/20201026093131.gf2...@hirez.programming.kicks-ass.net
>
> (note that the put_prev_task() needs an additional rq argument)
>
> That's both simpler code and faster.
Sure, I'll give that a go soon.
(This is based on our older 4.19 kernel, so the task_tick_fair() bit needed
changes to make it work - which aren't needed in v8).
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 711f8a78a947..c15fd5bbc707 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -97,7 +97,7 @@ static inline int __task_prio(struct task_struct *p)
*/
/* real prio, less is less */
-static inline bool prio_less(struct task_struct *a, struct task_struct *b)
+static inline bool prio_less(struct task_struct *a, struct task_struct *b,
bool in_fi)
{
int pa = __task_prio(a), pb = __task_prio(b);
@@ -112,7 +112,7 @@ static inline bool prio_less(struct task_struct *a, struct
task_struct *b)
return !dl_time_before(a->dl.deadline, b->dl.deadline);
if (pa == MAX_RT_PRIO + MAX_NICE) /* fair */
- return cfs_prio_less(a, b);
+ return cfs_prio_less(a, b, in_fi);
return false;
}
@@ -126,7 +126,7 @@ static inline bool __sched_core_less(struct task_struct *a,
struct task_struct *
return false;
/* flip prio, so high prio is leftmost */
- if (prio_less(b, a))
+ if (prio_less(b, a, task_rq(a)->core->core_forceidle))
return true;
return false;
@@ -4025,7 +4025,7 @@ void sched_core_irq_exit(void)
* - Else returns idle_task.
*/
static struct task_struct *
-pick_task(struct rq *rq, const struct sched_class *class, struct task_struct
*max)
+pick_task(struct rq *rq, const struct sched_class *class, struct task_struct
*max, bool in_fi)
{
struct task_struct *class_pick, *cookie_pick;
unsigned long cookie = rq->core->core_cookie;
@@ -4040,7 +4040,7 @@ pick_task(struct rq *rq, const struct sched_class *class,
struct task_struct *ma
* higher priority than max.
*/
if (max && class_pick->core_cookie &&
- prio_less(class_pick, max))
+ prio_less(class_pick, max, in_fi))
return idle_sched_class.pick_task(rq);
return class_pick;
@@ -4059,13 +4059,15 @@ pick_task(struct rq *rq, const struct sched_class
*class, struct task_struct *ma
* the core (so far) and it must be selected, otherwise we must go with
* the cookie pick in order to satisfy the constraint.
*/
- if (prio_less(cookie_pick, class_pick) &&
- (!max || prio_less(max, class_pick)))
+ if (prio_less(cookie_pick, class_pick, in_fi) &&
+ (!max || prio_less(max, class_pick, in_fi)))
return class_pick;
return cookie_pick;
}
+extern void task_vruntime_update(struct rq *rq, struct task_struct *p, bool
in_fi);
+
static struct task_struct *
pick_next_task(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
@@ -4141,15 +4143,6 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
update_rq_clock(rq_i);
}
- if (!fi_before) {
- for_each_cpu(i, smt_mask) {
- struct rq *rq_i = cpu_rq(i);
-
- /* Reset the snapshot if core is no longer in
force-idle. */
- rq_i->cfs.min_vruntime_fi = rq_i->cfs.min_vruntime;
- }
- }
-
/*
* Try and select tasks for each sibling in decending sched_class
* order.
@@
[PATCH v3] net: usb: usbnet: update __usbnet_{read|write}_cmd() to use new API
Currently, __usbnet_{read|write}_cmd() use usb_control_msg().
However, this could lead to potential partial reads/writes being
considered valid, and since most of the callers of
usbnet_{read|write}_cmd() don't take partial reads/writes into account
(only checking for negative error number is done), and this can lead to
issues.
However, the new usb_control_msg_{send|recv}() APIs don't allow partial
reads and writes.
Using the new APIs also relaxes the return value checking that must
be done after usbnet_{read|write}_cmd() is called.
Signed-off-by: Anant Thazhemadam
---
Changes in v3:
* Aligned continuation lines after the opening brackets
Changes in v2:
* Fix build error
drivers/net/usb/usbnet.c | 52
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index bf6c58240bd4..b2df3417a41c 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1982,64 +1982,32 @@ EXPORT_SYMBOL(usbnet_link_change);
static int __usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, void *data, u16 size)
{
- void *buf = NULL;
- int err = -ENOMEM;
netdev_dbg(dev->net, "usbnet_read_cmd cmd=0x%02x reqtype=%02x"
" value=0x%04x index=0x%04x size=%d\n",
cmd, reqtype, value, index, size);
- if (size) {
- buf = kmalloc(size, GFP_KERNEL);
- if (!buf)
- goto out;
- }
-
- err = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
- cmd, reqtype, value, index, buf, size,
- USB_CTRL_GET_TIMEOUT);
- if (err > 0 && err <= size) {
-if (data)
-memcpy(data, buf, err);
-else
-netdev_dbg(dev->net,
-"Huh? Data requested but thrown away.\n");
-}
- kfree(buf);
-out:
- return err;
+ return usb_control_msg_recv(dev->udev, 0,
+ cmd, reqtype, value, index, data, size,
+ USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
}
static int __usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, const void *data,
u16 size)
{
- void *buf = NULL;
- int err = -ENOMEM;
-
netdev_dbg(dev->net, "usbnet_write_cmd cmd=0x%02x reqtype=%02x"
" value=0x%04x index=0x%04x size=%d\n",
cmd, reqtype, value, index, size);
- if (data) {
- buf = kmemdup(data, size, GFP_KERNEL);
- if (!buf)
- goto out;
- } else {
-if (size) {
-WARN_ON_ONCE(1);
-err = -EINVAL;
-goto out;
-}
-}
-
- err = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
- cmd, reqtype, value, index, buf, size,
- USB_CTRL_SET_TIMEOUT);
- kfree(buf);
+ if (size && !data) {
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+ }
-out:
- return err;
+ return usb_control_msg_send(dev->udev, 0,
+ cmd, reqtype, value, index, data, size,
+ USB_CTRL_SET_TIMEOUT, GFP_KERNEL);
}
/*
--
2.25.1
Re: [GIT PULL] flexible array conversions for 5.10-rc2
On Fri, Oct 30, 2020 at 4:14 PM Gustavo A. R. Silva wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git > tags/flexible-array-conversions-5.10-rc2 So I really don't like getting these outside the merge window. These kinds of patches _can_ introduce bugs, and I see noi real upside to doing them outside the merge window once the initial "avoid lots of possible merge conflicts" bulk was done. I've taken this, but I don't want to see any more. This is very clearly "development" not "fixes". It goes into the merge window, not rc kernels. Linus
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Sat, Oct 31, 2020 at 4:04 PM Christophe Leroy wrote: > > There are also some users on 10+ year old 32-bit netbooks or > > business laptops, both x86 and Apple G4. > > The longest-lived 32-bit embedded systems with large memory > > (other than Arm) are probably NXP QorIQ P20xx/P40xx used in > > military VME bus systems, and low-end embedded systems based > > on Vortex86. > > I'm less worried about all of these because upstream kernel > > support for ppc32 and x86-32 is already bitrotting and they will > > likely get stuck on the last working kernel before the > > TI/Renesas/NXP Arm systems do. > > > > Upstream kernel support for ppc32 is bitrotting, seriously ? What do > you mean exactly ? I was thinking more of the platform support: out of the twelve 32-bit platforms in arch/powerpc/platforms/, your 8xx is the only one listed as 'maintained' or 'supported' in the maintainers list, and that seems to accurately describe the current state. Freescale seems to have practically stopped contributing to any of their 32-bit platforms in 2016 after the NXP acquisition and no longer employing either of the maintainers. Similarly, Ben seems to have stopped working on powermac in 2016, which was ten years after the last 32-bit hardware shipped for that platform. > ppc32 is actively supported, with recent addition of support of > hugepages, kasan, uaccess protection, VMAP stack, etc ... That is good to hear, I didn't know about these additions. What platforms are people using to develop these? Is this mainly your 8xx work, or is there ongoing development for platforms that need highmem? Arnd
[PATCH] media: dvbdev: Switch to new kerneldoc syntax for named variable macro argument
The syntax without dots is available since commit 43756e347f21
("scripts/kernel-doc: Add support for named variable macro arguments").
The same HTML output is produced with and without this patch.
Signed-off-by: Jonathan Neuschäfer
---
include/media/dvbdev.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/media/dvbdev.h b/include/media/dvbdev.h
index e547cbeee4310..cc85df91ee7c6 100644
--- a/include/media/dvbdev.h
+++ b/include/media/dvbdev.h
@@ -421,7 +421,7 @@ void dvb_module_release(struct i2c_client *client);
* dvb_attach - attaches a DVB frontend into the DVB core.
*
* @FUNCTION: function on a frontend module to be called.
- * @ARGS...: @FUNCTION arguments.
+ * @ARGS: @FUNCTION arguments.
*
* This ancillary function loads a frontend module in runtime and runs
* the @FUNCTION function there, with @ARGS.
--
2.28.0
Re: [PATCH v2] net: usb: usbnet: update __usbnet_{read|write}_cmd() to use new API
On 01/11/20 2:41 am, Jakub Kicinski wrote: > On Thu, 29 Oct 2020 18:52:56 +0530 Anant Thazhemadam wrote: >> +return usb_control_msg_recv(dev->udev, 0, >> + cmd, reqtype, value, index, data, size, >> + USB_CTRL_GET_TIMEOUT, GFP_KERNEL); > Please align continuation lines after the opening bracket. I will do that, and send in a v3 right away. Thanks, Anant
Re: [GIT PULL] perf tools changes for v5.10: 2nd batch
On Fri, Oct 30, 2020 at 11:59 AM Arnaldo Carvalho de Melo wrote: > > Please consider pulling, Malformed pull request, and this doesn't even seem to be fixes. Linus
[PATCH] thermal: armada: hwmon support for new DT binding.
For legacy DT binding the armada driver calls thermal_zone_device_register(), which registers the hwmon device. For new DT bindings, devm_thermal_add_hwmon_sysfs() must be called explicitly. Fixes: c9899c183921f (thermal: armada: use the resource managed registration helper alternative) Signed-off-by: Jonathan Ben-Avraham --- drivers/thermal/armada_thermal.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c index c2ebfb5be4b3..57f8d0df126f 100644 --- a/drivers/thermal/armada_thermal.c +++ b/drivers/thermal/armada_thermal.c @@ -20,6 +20,7 @@ #include #include "thermal_core.h" +#include "thermal_hwmon.h" /* Thermal Manager Control and Status Register */ #define PMU_TDC0_SW_RST_MASK (0x1 << 1) @@ -945,6 +946,10 @@ static int armada_thermal_probe(struct platform_device *pdev) */ if (irq > 0 && !priv->overheat_sensor) armada_configure_overheat_int(priv, tz, sensor->id); + + if (devm_thermal_add_hwmon_sysfs(tz)) + dev_warn(>dev, + "Failed to add hwmon sysfs attributes\n"); } /* Just complain if no overheat interrupt was set up */ -- 2.11.0
Re: [PATCH RFC 0/5] ubifs: Prevent memory oob accessing while dumping node
On Mon, Oct 19, 2020 at 5:13 AM Zhihao Cheng wrote:
>
> 在 2020/6/16 15:11, Zhihao Cheng 写道:
> > We use function ubifs_dump_node() to dump bad node caused by some
> > reasons (Such as bit flipping caused by hardware error, writing bypass
> > ubifs or unknown bugs in ubifs). The node content can not be trusted
> > anymore, so we should prevent memory out-of-bounds accessing while
> > dumping node in following situations:
> >
> > 1. bad node_len: Dumping data according to 'ch->len' which may exceed
> > the size of memory allocated for node.
> > 2. bad node content: Some kinds of node can record additional data, eg.
> > index node and orphan node, make sure the size of additional data
> > not beyond the node length.
> > 3. node_type changes: Read data according to type A, but expected type
> > B, before that, node is allocated according to type B's size. Length
> > of type A node is greater than type B node.
> >
> > Commit acc5af3efa303d5f3 ("ubifs: Fix out-of-bounds memory access caused
> > by abnormal value of node_len") handles situation 1 for data node only,
> > it would be better if we can solve problems in above situations for all
> > kinds of nodes.
> >
> > Patch 1 adds a new parameter 'node_len'(size of memory which is allocated
> > for the node) in function ubifs_dump_node(), safe dumping length of the
> > node should be: minimum(ch->len, c->ranges[node_type].max_len, node_len).
> > Besides, c->ranges[node_type].min_len can not greater than safe dumping
> > length, which may caused by node_type changes(situation 3).
> >
> > Patch 2 reverts commit acc5af3efa303d5f ("ubifs: Fix out-of-bounds memory
> > access caused by abnormal value of node_len") to prepare for patch 3.
> >
> > Patch 3 replaces modified function ubifs_dump_node() in all node dumping
> > places except for ubifs_dump_sleb().
> >
> > Patch 4 removes unused function ubifs_dump_sleb(),
> >
> > Patch 5 allows ubifs_dump_node() to dump all branches of the index node.
> >
> > Some tests after patchset applied:
> > https://bugzilla.kernel.org/show_bug.cgi?id=208203
> >
> > Zhihao Cheng (5):
> >ubifs: Limit dumping length by size of memory which is allocated for
> > the node
> >Revert "ubifs: Fix out-of-bounds memory access caused by abnormal
> > value of node_len"
> >ubifs: Pass node length in all node dumping callers
> >ubifs: ubifs_dump_sleb: Remove unused function
> >ubifs: ubifs_dump_node: Dump all branches of the index node
> >
> > fs/ubifs/commit.c | 4 +-
> > fs/ubifs/debug.c| 111 ++--
> > fs/ubifs/debug.h| 5 +-
> > fs/ubifs/file.c | 2 +-
> > fs/ubifs/io.c | 37 +--
> > fs/ubifs/journal.c | 3 +-
> > fs/ubifs/master.c | 4 +-
> > fs/ubifs/orphan.c | 6 ++-
> > fs/ubifs/recovery.c | 6 +--
> > fs/ubifs/replay.c | 4 +-
> > fs/ubifs/sb.c | 2 +-
> > fs/ubifs/scan.c | 4 +-
> > fs/ubifs/super.c| 2 +-
> > fs/ubifs/tnc.c | 8 ++--
> > fs/ubifs/tnc_misc.c | 4 +-
> > fs/ubifs/ubifs.h| 4 +-
> > 16 files changed, 108 insertions(+), 98 deletions(-)
> >
> ping, although it is not a serious problem for ubifs, but dumping extra
> memory by formating specified ubifs img may cause security problem.
Thanks for reminding me, yes this needs fixing.
I'll give it a try and then apply it for next.
--
Thanks,
//richard
Re: [linux-sunxi] [PATCH v2] arm64: dts: allwinner: h6: PineH64 model B: Add wifi
On Fri, Oct 30, 2020 at 06:25:30PM +0100, Jernej Skrabec wrote:
> PineH64 model B contains RTL8723CS wifi+bt combo module.
>
> Since bluetooth support is not yet squared away, only wifi is enabled
> for now.
>
> Acked-by: Chen-Yu Tsai
> Signed-off-by: Jernej Skrabec
> ---
> Changes from v1:
> - added Chen-Yu tag
> - added vqmmc-supply
>
> .../dts/allwinner/sun50i-h6-pine-h64-model-b.dts | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> index f4c8966a6497..7fea1e4e2d49 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> @@ -10,6 +10,12 @@ / {
> compatible = "pine64,pine-h64-model-b", "allwinner,sun50i-h6";
>
> /delete-node/ reg_gmac_3v3;
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> + post-power-on-delay-ms = <200>;
> + };
> };
>
> _connector {
> @@ -19,3 +25,12 @@ _connector {
> {
> phy-supply = <_aldo2>;
> };
> +
> + {
> + vmmc-supply = <_cldo3>;
> + vqmmc-supply = <_aldo1>;
> + mmc-pwrseq = <_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +};
> --
Hello
Tested-by:
RTL8723CS driver probe and related iwlist commands works. (like listing
availlable channels)
But connecting to a wireless network was not successfully tested yet. (I need
to set a test network).
Regards
Re: [PATCH v2] net: usb: usbnet: update __usbnet_{read|write}_cmd() to use new API
On Thu, 29 Oct 2020 18:52:56 +0530 Anant Thazhemadam wrote: > + return usb_control_msg_recv(dev->udev, 0, > + cmd, reqtype, value, index, data, size, > + USB_CTRL_GET_TIMEOUT, GFP_KERNEL); Please align continuation lines after the opening bracket.
Re: [PATCH] checkpatch: improve handling of email comments
Try this git log grep:
$ git log --format=email -10 | \
grep -P '^(?:[\w\-]+-by:|cc:|CC:|Cc:)' | \
grep -v 'stable\@' | \
grep -P '\>.+'
This finds any signature/cc line with content after an
email address that end with a close angle bracket that
doesn't go to the stable address.
Think about what content after that close angle bracket
should and shoud not be allowed.
There are a few variants here:
o comments (optional whitespace, followed by '#' or '[' or '(' or c89)
o misuse of quote (around the whole name and address)
o Odd commas after '>' likely from defective cut'n'paste use
Then add this to the first grep to avoid the comments as above
$ git log --format=email -10 | \
grep -P '^(?:[\w\-]+-by:|cc:|CC:|Cc:)' | \
grep -v 'stable\@' | \
grep -P '\>.+' | \
grep -vP '\>\s*(?:\#|\(|/\*|\[)'
Shouldn't all these be reported?
Are they if your patch is applied?
Then look at the addresses that do not have a close angle
bracket and also have more content after the email address.
$ git log --format=email -10 | \
grep -P '^(?:[\w\-]+-by:|cc:|CC:|Cc:)' | \
grep -v 'stable@' | \
grep -vP '<[\w\.\@\+\-]+>' | \
grep -vP '[\w\.\@\+\-]+$'
What of all of these should be reported?
Happy testing...
Hi,
So I ran the tests and there are some interesting results.
The warnings were the same before and after this patch
was applied.
For illegal elements after the closing braces, there were
several errors for which no warnings were reported. These
are:
6 Cc: Peter Zijlstra ,
5 Reviewed-by: "Dietmar Eggemann "
1 Suggested-by: Julia Lawall .
1 Signed-off-by: Vishal Kulkarni "
1 Signed-off-by: Vishal Kulkarni "
1 Signed-off-by: Vishal Kulkarni "
1 Signed-off-by: Veerabhadrarao Badiganti
Link:
1 Signed-off-by: Jingle Wu .
1 Reviewed-by: Tvrtko Ursulin ,
1 Reviewed-by: Max Gurtovoy >
1 Reviewed-by: Maulik Shah Thanks, Maulik
1 Reviewed-by: Marc Zyngier Link:
https://lore.kernel.org/r/20200826112331.047917...@linutronix.de
1 Reviewed-by: David Sterba i
1 Reviewed-by: David Sterba c
1 Reviewed-by: David Sterba 3
1 Reviewed-by: Christoph Hellwig ,
1 Reviewed-by: Christian König for both.
1 Reviewed-by: Christian König .
1 Reported-by: Randy Dunlap >
1 Reported-by: Qian Cai >
1 Reported-by: Qian Cai writes:
1 Reported-by: kernel test robot for missing #include
1 Reported-by: "kernelci.org bot" "
1 Reported-by: kbuild test robot ]
1 Reported-by: Bob Sanders and the LTP
testsuite
1 Cc: Wolfram Sang ,
1 Cc: Valdis Kletnieks ,
1 Cc: Tvrtko Ursulin ,
1 CC: Stephen Rothwell ,
1 Cc: Sia, Jee Heng ;
alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org;
clang-built-li...@googlegroups.com; Nathan Chancellor
1 Cc: Robert Sesek ,
1 CC: Peter Zijlstra ,
1 Cc: Omar Sandoval ,
1 Cc: Michael Neuling
1 Cc: Maxime Ripard ,
1 Cc: "Martin K. Petersen" ,
1 Cc: Mark Scott ,
1 Cc: Mark Rutland .
1 Cc: Mark Rutland ,
1 Cc: Mark Rutland ,
1 Cc: Laurent Pinchart ,
1 Cc: Kees Cook ,
1 Cc: Jonas Karlman ,
1 Cc: Jernej Skrabec ,
1 Cc: Jason Wang ; Parav Pandit
; virtualizat...@lists.linux-foundation.org;
linux-kernel@vger.kernel.org; kernel-janit...@vger.kernel.org
1 Cc: Jann Horn ,
1 Cc: James Bottomley ,
1 Cc: Icenowy Zheng ,
1 Cc: Dan Murphy A
1 Cc: Daniel Vetter ,
1 Cc: Christoph Lameter Cc: Pekka Enberg
1 Cc: Christoph Hellwig ,
1 Cc: Christian König .
1 CC: "Chang S. Bae" ,
1 Cc: Al Viro e
1 Acked-by: Thomas Bogendoerfer A
1 Acked-by: Geert Uytterhoeven A
For cases with no closing '>', following cases were not
reported by checkpatch:
6 Cc: linux-arm-ker...@lists.infradead.org,
1 Reviewed-by: Max Gurtovoy >
1 Cc: rost...@goodmis.org,
1 Cc: linux-wirel...@vger.kernel.org,
1 Cc: dri-de...@lists.freedesktop.org,
So it's mostly extra commas at the end. But other
illegal characters were also there. Also in one or two
cases, multiple addresses were stacked together.
I think these all deserve to be reported.
Thanks,
Dwaipayan.
[PATCH] ARM: dts: imx50-kobo-aura: Add 'grp' suffix to pinctrl node names
i.MX pinctrl group nodes should have names that ends with 'grp'.
Reported-by: Krzysztof Kozlowski
Signed-off-by: Jonathan Neuschäfer
---
arch/arm/boot/dts/imx50-kobo-aura.dts | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx50-kobo-aura.dts
b/arch/arm/boot/dts/imx50-kobo-aura.dts
index a0eaf869b9135..53b3995d37e7f 100644
--- a/arch/arm/boot/dts/imx50-kobo-aura.dts
+++ b/arch/arm/boot/dts/imx50-kobo-aura.dts
@@ -139,7 +139,7 @@ {
};
{
- pinctrl_gpiokeys: gpiokeys {
+ pinctrl_gpiokeys: gpiokeysgrp {
fsl,pins = <
MX50_PAD_CSPI_MISO__GPIO4_100x0
MX50_PAD_SD2_D7__GPIO5_15 0x0
@@ -147,34 +147,34 @@ MX50_PAD_KEY_ROW0__GPIO4_10x0
>;
};
- pinctrl_i2c1: i2c1 {
+ pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX50_PAD_I2C1_SCL__I2C1_SCL 0x41fd
MX50_PAD_I2C1_SDA__I2C1_SDA 0x41fd
>;
};
- pinctrl_i2c2: i2c2 {
+ pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX50_PAD_I2C2_SCL__I2C2_SCL 0x41fd
MX50_PAD_I2C2_SDA__I2C2_SDA 0x41fd
>;
};
- pinctrl_i2c3: i2c3 {
+ pinctrl_i2c3: i2c3grp {
fsl,pins = <
MX50_PAD_I2C3_SCL__I2C3_SCL 0x41fd
MX50_PAD_I2C3_SDA__I2C3_SDA 0x41fd
>;
};
- pinctrl_leds: leds {
+ pinctrl_leds: ledsgrp {
fsl,pins = <
MX50_PAD_PWM1__GPIO6_24 0x0
>;
};
- pinctrl_sd1: sd1 {
+ pinctrl_sd1: sd1grp {
fsl,pins = <
MX50_PAD_SD1_CMD__ESDHC1_CMD0x1e4
MX50_PAD_SD1_CLK__ESDHC1_CLK0xd4
@@ -187,7 +187,7 @@ MX50_PAD_SD2_CD__GPIO5_17 0x0
>;
};
- pinctrl_sd2: sd2 {
+ pinctrl_sd2: sd2grp {
fsl,pins = <
MX50_PAD_SD2_CMD__ESDHC2_CMD0x1e4
MX50_PAD_SD2_CLK__ESDHC2_CLK0xd4
@@ -198,19 +198,19 @@ MX50_PAD_SD2_D3__ESDHC2_DAT3 0x1d4
>;
};
- pinctrl_sd2_reset: sd2-reset {
+ pinctrl_sd2_reset: sd2-resetgrp {
fsl,pins = <
MX50_PAD_ECSPI2_MOSI__GPIO4_17 0x0
>;
};
- pinctrl_sd2_vmmc: sd2-vmmc {
+ pinctrl_sd2_vmmc: sd2-vmmcgrp {
fsl,pins = <
MX50_PAD_ECSPI1_SCLK__GPIO4_12 0x0
>;
};
- pinctrl_sd3: sd3 {
+ pinctrl_sd3: sd3grp {
fsl,pins = <
MX50_PAD_SD3_CMD__ESDHC3_CMD0x1e4
MX50_PAD_SD3_CLK__ESDHC3_CLK0xd4
@@ -225,14 +225,14 @@ MX50_PAD_SD3_D7__ESDHC3_DAT7 0x1d4
>;
};
- pinctrl_uart2: uart2 {
+ pinctrl_uart2: uart2grp {
fsl,pins = <
MX50_PAD_UART2_TXD__UART2_TXD_MUX 0x1e4
MX50_PAD_UART2_RXD__UART2_RXD_MUX 0x1e4
>;
};
- pinctrl_usbphy: usbphy {
+ pinctrl_usbphy: usbphygrp {
fsl,pins = <
MX50_PAD_ECSPI2_SS0__GPIO4_19 0x0
>;
--
2.28.0
Re: [PATCH v6 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Hi Lubomir. > > > > > + select BACKLIGHT_CLASS_DEVICE > > Please use a depends - using select on a symbol with a prompt is always > > wrong. Yeah, I know you then need to enable backlight to see this > > driver. Sorry, but this is the best we can do now. > > Many other drivers can cope with depends here. > > This results in a dependency loop: > > drivers/video/fbdev/Kconfig:12:error: recursive dependency detected! > drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER > drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on > DRM_KMS_HELPER > drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by > DRM_HIMAX_HX8837 > drivers/gpu/drm/bridge/Kconfig:51: symbol DRM_HIMAX_HX8837 depends on > BACKLIGHT_CLASS_DEVICE > drivers/video/backlight/Kconfig:143:symbol BACKLIGHT_CLASS_DEVICE is > selected by FB_BACKLIGHT > drivers/video/fbdev/Kconfig:187:symbol FB_BACKLIGHT depends on FB > > Unfortunately I have no idea how to resolve it at the moment. > > I suppose I can look further into it if necessary. Or is it okay if I > leave it at select BACKLIGHT_CLASS_DEVICE for now? Sigh, leave it as a select then :-( The "sigh" is not directed at you but the mess this BACKLIGHT_CLASS_DEVICE is and the limitations of Kconfig. Sam
Re: [PATCH v2] ubifs: Fix the printing type of c->big_lpt
On Sat, Oct 31, 2020 at 9:56 AM Chengsong Ke wrote: > > Ubifs uses %d to print c->big_lpt, but c->big_lpt is a variable > of type unsigned int and should be printed with %u. Well, it is: unsigned int big_lpt:1; So, either 0 or 1. Does changing it to %u silence some static checker or is there some other problem I don't see right now? :-) Thanks, //richard
Re: INFO: rcu detected stall in sys_mount (5)
syzbot suspects this issue was fixed by commit: commit 1d0e850a49a5b56f8f3cb51e74a11e2fedb96be6 Author: David Howells Date: Fri Oct 16 12:21:14 2020 + afs: Fix cell removal bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=132fe91450 start commit: 02de58b2 Merge tag 'devicetree-fixes-for-5.9-3' of git://g.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=89ab6a0c48f30b49 dashboard link: https://syzkaller.appspot.com/bug?extid=dc8c077c7091175cbdb1 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13a4029790 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=110b7a2f90 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: afs: Fix cell removal For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH net-next] net: ipa: avoid a bogus warning
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Sat, 31 Oct 2020 10:15:24 -0500 you wrote: > The previous commit added support for IPA having up to six source > and destination resources. But currently nothing uses more than > four. (Five of each are used in a newer version of the hardware.) > > I find that in one of my build environments the compiler complains > about newly-added code in two spots. Inspection shows that the > warnings have no merit, but this compiler does not recognize that. > > [...] Here is the summary with links: - [net-next] net: ipa: avoid a bogus warning https://git.kernel.org/netdev/net-next/c/624251b4b5a0 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH net-next v6 1/5] net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
On Sat, 31 Oct 2020 15:47:28 -0400 Willem de Bruijn wrote: > On Sat, Oct 31, 2020 at 12:02 PM Xie He wrote: > > On Sat, Oct 31, 2020 at 8:18 AM Xie He wrote: > > > > Especially without that, I'm not sure this and the follow-on patch add > > > > much value. Minor code cleanups complicate backports of fixes. > > > > > > To me this is necessary, because I feel hard to do any development on > > > un-cleaned-up code. I really don't know how to add my code without > > > these clean-ups, and even if I managed to do that, I would not be > > > happy with my code. > > That is the reality of working in this space, I think. I have > frequently restructured code, fixed a bug and then worked backwards to > create a *minimal* bugfix that applies to the current code as well as > older stable branches. > > Obviously this is more of a concern for stable fixes than for new > code. But we have to keep in mind that every code churn will make > future bug fixes harder to roll out to users. That is not to say that > churn should be avoided, just that we need to balance a change's > benefit against this cost. > > > And always keeping the user interface and even the code unchanged > > contradicts my motivation of contributing to the Linux kernel. All my > > contributions are motivated by the hope to clean things up. I'm not an > > actual user of any of the code I contribute. If we adhere to the > > philosophy of not doing any clean-ups, my contributions would be > > meaningless. > > There are cleanups and cleanups. Dead code removal and deduplication > of open coded logic, for instance, are very valuable. As is, for > instance, your work in making sense of hard_header_len. Or removing the buggy uses of IFF_TX_SKB_SHARING, for that matter (which at this point I agree we should just remove from ether_setup, and let people who care re-enable it). > Returning code in branches vs an error jump label seems more of a > personal preference, and to me does not pass the benefit/cost threshold. I must agree.
Re: [PATCH] perf: increase size of buf in perf_evsel__hists_browse()
On Fri, Oct 30, 2020 at 04:54:31PM -0700, Song Liu wrote:
> Making perf with gcc-9.1.1 generates the following warning:
>
> CC ui/browsers/hists.o
> ui/browsers/hists.c: In function 'perf_evsel__hists_browse':
> ui/browsers/hists.c:3078:61: error: '%d' directive output may be \
> truncated writing between 1 and 11 bytes into a region of size \
> between 2 and 12 [-Werror=format-truncation=]
>
> 3078 | "Max event group index to sort is %d (index from 0 to %d)",
> | ^~
> ui/browsers/hists.c:3078:7: note: directive argument in the range
> [-2147483648, 8]
> 3078 | "Max event group index to sort is %d (index from 0 to %d)",
> | ^~
> In file included from /usr/include/stdio.h:937,
> from ui/browsers/hists.c:5:
>
> IOW, the string in line 3078 might be too long for buf[] of 64 bytes.
>
> Fix this by increasing the size of buf[] to 128.
>
> Fixes: dbddf1747441 ("perf report/top TUI: Support hotkeys to let user
> select any event for sorting")
> Cc: stable # v5.7+
> Cc: Jin Yao
> Cc: Jiri Olsa
> Cc: Arnaldo Carvalho de Melo
> Cc: Arnaldo Carvalho de Melo
> Signed-off-by: Song Liu
Acked-by: Jiri Olsa
jirka
> ---
> tools/perf/ui/browsers/hists.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index a07626f072087..b0e1880cf992b 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -2963,7 +2963,7 @@ static int perf_evsel__hists_browse(struct evsel
> *evsel, int nr_events,
> struct popup_action actions[MAX_OPTIONS];
> int nr_options = 0;
> int key = -1;
> - char buf[64];
> + char buf[128];
> int delay_secs = hbt ? hbt->refresh : 0;
>
> #define HIST_BROWSER_HELP_COMMON \
> --
> 2.24.1
>
Re: [PATCH net-next] net: ipa: avoid a bogus warning
On Sat, 31 Oct 2020 10:15:24 -0500 Alex Elder wrote: > The previous commit added support for IPA having up to six source > and destination resources. But currently nothing uses more than > four. (Five of each are used in a newer version of the hardware.) > > I find that in one of my build environments the compiler complains > about newly-added code in two spots. Inspection shows that the > warnings have no merit, but this compiler does not recognize that. > > ipa_main.c:457:39: warning: array index 5 is past the end of the > array (which contains 4 elements) [-Warray-bounds] > (and the same warning at line 483) > > We can make this warning go away by changing the number of elements > in the source and destination resource limit arrays--now rather than > waiting until we need it to support the newer hardware. This change > was coming soon anyway; make it now to get rid of the warning. > > Signed-off-by: Alex Elder Applied, thanks!
Re: [PATCH v3 3/9] perf mem: Support new memory event PERF_MEM_EVENTS__LOAD_STORE
On Wed, Oct 28, 2020 at 02:38:07PM +0800, Leo Yan wrote:
SNIP
> struct stat st;
>
> + /*
> + * If the event entry isn't valid, skip initialization
> + * and "e->supported" will keep false.
> + */
> + if (!e->tag)
> + continue;
> +
> scnprintf(path, PATH_MAX, "%s/devices/%s",
> mnt, e->sysfs_name);
>
> @@ -123,7 +134,7 @@ void perf_mem_events__list(void)
> struct perf_mem_event *e = perf_mem_events__ptr(j);
>
> fprintf(stderr, "%-13s%-*s%s\n",
> - e->tag,
> + e->tag ? e->tag : "",
nit, could be: e->tag ?: "",
jirka
> verbose > 0 ? 25 : 0,
> verbose > 0 ? perf_mem_events__name(j) : "",
> e->supported ? ": available" : "");
> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
> index 726a9c8103e4..5ef178278909 100644
> --- a/tools/perf/util/mem-events.h
> +++ b/tools/perf/util/mem-events.h
> @@ -28,6 +28,7 @@ struct mem_info {
> enum {
> PERF_MEM_EVENTS__LOAD,
> PERF_MEM_EVENTS__STORE,
> + PERF_MEM_EVENTS__LOAD_STORE,
> PERF_MEM_EVENTS__MAX,
> };
>
> --
> 2.17.1
>
Re: [PATCH v3 6/9] perf c2c: Support AUX trace
On Wed, Oct 28, 2020 at 02:38:10PM +0800, Leo Yan wrote:
> This patches adds the AUX callbacks in session structure, so support
> AUX trace for "perf c2c" tool.
>
> Signed-off-by: Leo Yan
> ---
> tools/perf/builtin-c2c.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
> index 4d1a08e38233..24f4af997aab 100644
> --- a/tools/perf/builtin-c2c.c
> +++ b/tools/perf/builtin-c2c.c
> @@ -369,6 +369,10 @@ static struct perf_c2c c2c = {
> .exit = perf_event__process_exit,
> .fork = perf_event__process_fork,
> .lost = perf_event__process_lost,
> + .attr = perf_event__process_attr,
> + .auxtrace_info = perf_event__process_auxtrace_info,
> + .auxtrace = perf_event__process_auxtrace,
> + .auxtrace_error = perf_event__process_auxtrace_error,
so this will process aux data, but don't you have to
say which events you want to synthesize?
like in script/report via --itrace option?
aybe arm differs from x86 in this, and it's happening
in the background.. I have no idea ;-)
jirka
> .ordered_events = true,
> .ordering_requires_timestamps = true,
> },
> --
> 2.17.1
>
Re: [PATCH v6 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Hello Sam,
thanks for your response.
On Sat, Oct 31, 2020 at 09:01:37AM +0100, Sam Ravnborg wrote:
> Hi Lubomir.
>
> On Fri, Oct 30, 2020 at 04:08:00AM +0100, Lubomir Rintel wrote:
> > Himax HX8837 is used to drive the LCD panel on OLPC platforms.
> >
> > It controls the panel backlight and is able to refresh it when the LCD
> > controller (and the rest of the plaform) is powered off.
> >
> > It also converts regular RGB color data from the LCDC so that it looks
> > reasonable on the OLPC LCD panel with a monochromatic layer on top of a
> > layer that can either reflect light (b/w sunlight readable mode) or light
> > pattern of red, green and blue pixels.
> >
> > At this point, the driver is rather basic. The self-refresh mode is not
> > supported. There's no way of independently controlling the color swizzling,
> > antialiasing or b/w conversion, but it probably isn't too useful either.
> >
> > There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
> > in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
> > DRM, so this driver doesn't replace the other one yet.
> >
> > Signed-off-by: Lubomir Rintel
> >
> > ---
> > Changes since v5:
> > (All based on feedback from Sam Ravnborg)
> > - Fix indentation in Kconfig
> > - Sort #includes
> > - Use a constant for max brightness instead of a literal
> > - Remove struct drm_panel from priv data
> > - Use dev_err() instead of DRM_ERROR
> > - Replace direct use of backlight props.brightness with
> > backlight_get_brightness()
> > - Document sentinels with { /* sentinel */ }
> > - Remove unsetting of panel->backlight
>
> Thanks, I missed a few things during the last round, so here is a few
> more comments. Only very trivial things but lets get them fixed before
> we add the driver to drm-misc-next.
>
> Sam
>
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index ef91646441b16..881780719af7c 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
> > on ARM-based platforms. Saying Y here when this driver is not needed
> > will not cause any issue.
> >
> > +config DRM_HIMAX_HX8837
> > + tristate "HiMax HX8837 OLPC Display Controller"
> > + depends on OF
> > + depends on OLPC || ARCH_MMP || COMPILE_TEST
> > + select DRM_KMS_HELPER
> > + select BACKLIGHT_LCD_SUPPORT
> Unknown symbol - "git grep BACKLIGHT_LCD_SUPPORT" only turned up one
> unrelated hit.
>
> > + select BACKLIGHT_CLASS_DEVICE
> Please use a depends - using select on a symbol with a prompt is always
> wrong. Yeah, I know you then need to enable backlight to see this
> driver. Sorry, but this is the best we can do now.
> Many other drivers can cope with depends here.
This results in a dependency loop:
drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by
DRM_HIMAX_HX8837
drivers/gpu/drm/bridge/Kconfig:51: symbol DRM_HIMAX_HX8837 depends on
BACKLIGHT_CLASS_DEVICE
drivers/video/backlight/Kconfig:143:symbol BACKLIGHT_CLASS_DEVICE is
selected by FB_BACKLIGHT
drivers/video/fbdev/Kconfig:187:symbol FB_BACKLIGHT depends on FB
Unfortunately I have no idea how to resolve it at the moment.
I suppose I can look further into it if necessary. Or is it okay if I
leave it at select BACKLIGHT_CLASS_DEVICE for now?
> > + help
> > + Enable support for HiMax HX8837 Display Controller as found in the
> > + OLPC XO laptops.
> > +
> > + If your laptop doesn't have green ears, say "N"
> I like this last comment :-)
>
> > +
> > config DRM_LONTIUM_LT9611
> > tristate "Lontium LT9611 DSI/HDMI bridge"
> > select SND_SOC_HDMI_CODEC if SND_SOC
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 2b3aff104e466..21f72df3260db 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,6 +2,7 @@
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> > +obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
> > obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> > obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
> > b/drivers/gpu/drm/bridge/himax-hx8837.c
> > new file mode 100644
> > index 0..f472e16cc331d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/himax-hx8837.c
> > @@ -0,0 +1,330 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * HiMax HX8837
[PATCH v2 3/3] module: only handle errors with the *switch* statement in module_sig_check()
Let's handle the successful call of mod_verify_sig() right after that call,
making the *switch* statement only handle the real errors, and then move
the comment from the first *case* before *switch* itself and the comment
before *default* after it. Fix the comment style, add article/comma/dash,
spell out "nomem" as "lack of memory" in these comments, while at it...
Suggested-by: Joe Perches
Signed-off-by: Sergey Shtylyov
---
Changes in version 2:
- new patch.
kernel/module.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
Index: linux/kernel/module.c
===
--- linux.orig/kernel/module.c
+++ linux/kernel/module.c
@@ -2895,17 +2895,18 @@ static int module_sig_check(struct load_
/* We truncate the module to discard the signature */
info->len -= markerlen;
err = mod_verify_sig(mod, info);
+ if (!err) {
+ info->sig_ok = true;
+ return 0;
+ }
}
+ /*
+* We don't permit modules to be loaded into the trusted kernels
+* without a valid signature on them, but if we're not enforcing,
+* certain errors are non-fatal.
+*/
switch (err) {
- case 0:
- info->sig_ok = true;
- return 0;
-
- /* We don't permit modules to be loaded into trusted kernels
-* without a valid signature on them, but if we're not
-* enforcing, certain errors are non-fatal.
-*/
case -ENODATA:
reason = "unsigned module";
break;
@@ -2916,11 +2917,12 @@ static int module_sig_check(struct load_
reason = "module with unavailable key";
break;
- /* All other errors are fatal, including nomem, unparseable
-* signatures and signature check failures - even if signatures
-* aren't required.
-*/
default:
+ /*
+* All other errors are fatal, including lack of memory,
+* unparseable signatures, and signature check failures --
+* even if signatures aren't required.
+*/
return err;
}
Re: [PATCH 5.9 00/74] 5.9.3-rc1 review
On Sat, Oct 31, 2020 at 12:35:42PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.9.3 release. > There are 74 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon, 02 Nov 2020 11:34:42 +. > Anything received after that time might be too late. > Build results: total: 154 pass: 154 fail: 0 Qemu test results: total: 426 pass: 426 fail: 0 Tested-by: Guenter Roeck Guenter
[PATCH v2 2/3] module: avoid *goto*s in module_sig_check()
Let's move the common handling of the non-fatal errors after the *switch*
statement -- this avoids *goto*s inside that *switch*...
Suggested-by: Joe Perches
Signed-off-by: Sergey Shtylyov
---
Changes in version 2:
- new patch.
kernel/module.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Index: linux/kernel/module.c
===
--- linux.orig/kernel/module.c
+++ linux/kernel/module.c
@@ -2908,20 +2908,13 @@ static int module_sig_check(struct load_
*/
case -ENODATA:
reason = "unsigned module";
- goto decide;
+ break;
case -ENOPKG:
reason = "module with unsupported crypto";
- goto decide;
+ break;
case -ENOKEY:
reason = "module with unavailable key";
- decide:
- if (is_module_sig_enforced()) {
- pr_notice("%s: loading of %s is rejected\n",
- info->name, reason);
- return -EKEYREJECTED;
- }
-
- return security_locked_down(LOCKDOWN_MODULE_SIGNATURE);
+ break;
/* All other errors are fatal, including nomem, unparseable
* signatures and signature check failures - even if signatures
@@ -2930,6 +2923,13 @@ static int module_sig_check(struct load_
default:
return err;
}
+
+ if (is_module_sig_enforced()) {
+ pr_notice("%s: loading of %s is rejected\n", info->name,
reason);
+ return -EKEYREJECTED;
+ }
+
+ return security_locked_down(LOCKDOWN_MODULE_SIGNATURE);
}
#else /* !CONFIG_MODULE_SIG */
static int module_sig_check(struct load_info *info, int flags)
Re: [PATCH 5.4 00/48] 5.4.74-rc2 review
On Sat, Oct 31, 2020 at 12:51:00PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.74 release. > There are 48 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon, 02 Nov 2020 11:42:20 +. > Anything received after that time might be too late. > Build results: total: 157 pass: 157 fail: 0 Qemu test results: total: 426 pass: 426 fail: 0 Tested-by: Guenter Roeck Guenter
Re: [PATCH 5.8 00/70] 5.8.18-rc1 review
On Sat, Oct 31, 2020 at 12:35:32PM +0100, Greg Kroah-Hartman wrote: > - > Note, this is going to be the LAST 5.8.y kernel release. After this > one, this branch is now end-of-life. Please move to the 5.9.y branch at > this point in time. > - > > This is the start of the stable review cycle for the 5.8.18 release. > There are 70 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon, 02 Nov 2020 11:34:42 +. > Anything received after that time might be too late. > Build results: total: 154 pass: 154 fail: 0 Qemu test results: total: 426 pass: 426 fail: 0 Tested-by: Guenter Roeck Guenter
[PATCH v2 1/3] module: merge repetitive strings in module_sig_check()
The 'reason' variable in module_sig_check() points to 3 strings across
the *switch* statement, all needlessly starting with the same text.
Let's put the starting text into the pr_notice() call -- it saves 21
bytes of the object code (x86 gcc 10.2.1).
Suggested-by: Joe Perches
Signed-off-by: Sergey Shtylyov
---
Changes in version 2:
- put less starting text into the pr_notice() call;
- updated the patch description accordingly, added the "Suggested-by:" tag.
kernel/module.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
Index: linux/kernel/module.c
===
--- linux.orig/kernel/module.c
+++ linux/kernel/module.c
@@ -2907,16 +2907,17 @@ static int module_sig_check(struct load_
* enforcing, certain errors are non-fatal.
*/
case -ENODATA:
- reason = "Loading of unsigned module";
+ reason = "unsigned module";
goto decide;
case -ENOPKG:
- reason = "Loading of module with unsupported crypto";
+ reason = "module with unsupported crypto";
goto decide;
case -ENOKEY:
- reason = "Loading of module with unavailable key";
+ reason = "module with unavailable key";
decide:
if (is_module_sig_enforced()) {
- pr_notice("%s: %s is rejected\n", info->name, reason);
+ pr_notice("%s: loading of %s is rejected\n",
+ info->name, reason);
return -EKEYREJECTED;
}
Re: [PATCH] proc: Provide details on indirect branch speculation
On Fri, 30 Oct 2020 17:27:54 +1100 Anand K Mistry wrote: > Similar to speculation store bypass, show information about the indirect > branch speculation mode of a task in /proc/$pid/status. Why is this considered useful?
[PATCH v2 0/3] module: refactor module_sig_check()
Here are 3 patches against the 'modules-next' branch of Jessica Yu's 'linux.git' repo. I'm doing some refactoring in module_sig_check()... [1/3] module: merge repetitive strings in module_sig_check() [2/3] module: avoid *goto*s in module_sig_check() [3/3] module: only handle errors with the *switch* statement in module_sig_check()
Re: [PATCH 4.4 010/149] f2fs: check memory boundary by insane namelen
On Thu, Aug 20, 2020 at 11:21:27AM +0200, Greg Kroah-Hartman wrote:
> From: Jaegeuk Kim
>
> [ Upstream commit 4e240d1bab1ead280ddf5eb05058dba6bbd57d10 ]
>
> If namelen is corrupted to have very long value, fill_dentries can copy
> wrong memory area.
>
> Reviewed-by: Chao Yu
> Signed-off-by: Jaegeuk Kim
> Signed-off-by: Sasha Levin
> ---
> fs/f2fs/dir.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> index 92a240616f520..5411d6667781f 100644
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@ -805,6 +805,16 @@ bool f2fs_fill_dentries(struct dir_context *ctx, struct
> f2fs_dentry_ptr *d,
> de_name.name = d->filename[bit_pos];
> de_name.len = le16_to_cpu(de->name_len);
>
> + /* check memory boundary before moving forward */
> + bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
> + if (unlikely(bit_pos > d->max)) {
> + f2fs_msg(F2FS_I_SB(d->inode)->sb, KERN_WARNING,
> + "%s: corrupted namelen=%d, run fsck to fix.",
> + __func__, le16_to_cpu(de->name_len));
> + set_sbi_flag(F2FS_I_SB(d->inode)->sb->s_fs_info,
> SBI_NEED_FSCK);
> + return -EINVAL;
> + }
> +
> if (f2fs_encrypted_inode(d->inode)) {
> int save_len = fstr->len;
> int ret;
> @@ -829,7 +839,6 @@ bool f2fs_fill_dentries(struct dir_context *ctx, struct
> f2fs_dentry_ptr *d,
> le32_to_cpu(de->ino), d_type))
> return true;
>
> - bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
> ctx->pos = start_pos + bit_pos;
This buggy backport broke f2fs encryption in 4.4-stable, due to a missing
prerequisite commit
(https://lkml.kernel.org/stable/20201031195809.377983-1-ebigg...@kernel.org/).
Why didn't this backport get Cc'ed to the subsystem mailing list? It wasn't
even a clean cherry pick.
- Eric
[GIT PULL] vhost,vdpa: fixes
The following changes since commit 88a0d60c6445f315fbcfff3db792021bb3a67b28: MAINTAINERS: add URL for virtio-mem (2020-10-21 10:48:11 -0400) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 0c86d774883fa17e7c81b0c8838b88d06c2c911e: vdpasim: allow to assign a MAC address (2020-10-30 04:04:35 -0400) vhost,vdpa: fixes Fixes all over the place. A new UAPI is borderline: can also be considered a new feature but also seems to be the only way we could come up with to fix addressing for userspace - and it seems important to switch to it now before userspace making assumptions about addressing ability of devices is set in stone. Signed-off-by: Michael S. Tsirkin Dan Carpenter (1): vhost_vdpa: Return -EFAULT if copy_from_user() fails Jason Wang (3): vdpa: introduce config op to get valid iova range vhost: vdpa: report iova range vdpa_sim: implement get_iova_range() Jing Xiangfeng (1): vdpa/mlx5: Fix error return in map_direct_mr() Laurent Vivier (3): vdpa_sim: Fix DMA mask vdpasim: fix MAC address configuration vdpasim: allow to assign a MAC address Michael S. Tsirkin (1): Revert "vhost-vdpa: fix page pinning leakage in error path" Zhu Lingshan (1): vdpa: handle irq bypass register failure case drivers/vdpa/mlx5/core/mr.c | 5 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 33 +++- drivers/vhost/vdpa.c | 167 ++- include/linux/vdpa.h | 15 include/uapi/linux/vhost.h | 4 + include/uapi/linux/vhost_types.h | 9 +++ 6 files changed, 154 insertions(+), 79 deletions(-)
Re: [GIT PULL] SCSI fixes for 5.10-rc1
The pull request you sent on Fri, 30 Oct 2020 10:28:38 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/67ff377bc30cd4eb91f0454adb9dcb1f4de280f2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] dma-mapping fix for 5.10
The pull request you sent on Sat, 31 Oct 2020 10:38:23 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.10-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bb3540be73ca1e483aa977d859960895fe85372d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v6 08/52] dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and statistics sub-device
28.10.2020 18:26, Rob Herring пишет:
> On Tue, Oct 27, 2020 at 11:18:34PM +0300, Dmitry Osipenko wrote:
>> 27.10.2020 22:44, Krzysztof Kozlowski пишет:
>>> On Tue, Oct 27, 2020 at 10:22:19PM +0300, Dmitry Osipenko wrote:
27.10.2020 12:02, Krzysztof Kozlowski пишет:
>> @@ -31,17 +32,34 @@ Example:
>> ...
>> };
>>
>> +emc_bw_dfs_opp_table: emc_opp_table1 {
> Hyphens for node name.
We already use underscores for the Tegra CPU OPP table.
https://elixir.bootlin.com/linux/v5.10-rc1/source/arch/arm/boot/dts/tegra20-cpu-opp.dtsi#L4
What makes you think that hyphens will be a better choice? Is it a
documented naming convention?
>>>
>>> Unfortunately that's the source of confusion also for me because
>>> Devicetree spec mentions both of them (and does not specify preferences).
>>>
>>> The choice of dashes/hyphens comes now explicitly from all dtschema
>>> files. Previously, the documentation were emails from Rob. :)
>>
>> Okay, I'll change it in v7. So far I haven't seen warnings about it from
>> the schema-checker.
>
> dtc with W=2 will warn.
>
> The bigger issue is the name should be generic.
Indeed, thanks. I'll correct the name.
Re: [GIT PULL] dma-mapping fix for 5.10
On Sat, Oct 31, 2020 at 2:40 AM Christoph Hellwig wrote:
>
> dma-mapping fix for 5.10:
>
> - fix an integer overflow on 32-bit platforms in the new DMA range code
>(Geert Uytterhoeven)
So this is just a stylistic nit, and has no impact on this pull (which
I've done). But looking at the patch, it triggers one of my "this is
wrong" patterns.
In particular, this:
u64 dma_start = 0;
...
for (dma_start = ~0ULL; r->size; r++) {
is actually completely bogus in theory, and it's a horribly horribly
bad pattern to have.
The thing that I hate about that parttern is "~0ULL", which is simply wrong.
The correct pattern for "all bits set" is ~0. NOTHING ELSE. No extra
letters at the end.
Why? Because using an unsigned type is wrong, and will not extend the
bits up to a potentially bigger size.
So adding that "ULL" is not just three extra characters to type, it
actually _detracts_ from the code and makes it more fragile and
potentially wrong.
It so happens, that yes, in the kernel, "ull" us 64-bit, and you get
the right results. So the code _works_. But it's wrong, and it now
requires that the types match exactly (ie it would not be broken if
somebody ever were to say "I want to use use 128-bit dma addresses and
u128").
Another example is using "~0ul", which would give different results on
a 32-bit kernel and a 64-bit kernel. Again: DON'T DO THAT.
I repeat: the right thing to do for "all bits set" is just a plain ~0
or -1. Either of those are fine (technically assumes a 2's complement
machine, but let's just be honest: that's a perfectly fine assumption,
and -1 might be preferred by some because it makes that sign extension
behavior of the integer constant more obvious).
Don't try to do anything clever or anything else, because it's going
to be strictly worse.
The old code that that patch removed was "technically correct", but
just pointless, and actually shows the problem:
for (dma_start = ~(dma_addr_t)0; r->size; r++) {
the above is indeed a correct way to say "I want all bits set in a
dma_addr_t", but while correct, it is - once again - strictly inferior
to just using "~0".
Why? Because "~0" works regardless of type. IOW, exactly *because*
people used the wrong pattern for "all bits set", that patch was now
(a) bigger than necessary and (b) much more ilkely to cause bugs (ie I
could have imagined people changing just the type of the variable
without changing the initialization).
So in that tiny three-line patch there were actually several examples
of why "~0" is the right pattern to use for "all bits set". Because it
JustWorks(tm) in ways other patterns do not.
And if you have a compiler that complains about assigning -1 or ~0 to
an unsigned variable, get rid of that piece of garbage. You're almost
certainly either using some warning flag that you shouldn't be using,
or the compiler writer didn't know what they were doing.
Linus
[PATCH] erofs: derive atime instead of leaving it empty
From: Gao Xiang
EROFS has _only one_ ondisk timestamp (ctime is currently
documented and recorded, we might also record mtime instead
with a new compat feature if needed) for each extended inode
since EROFS isn't mainly for archival purposes so no need to
keep all timestamps on disk especially for Android scenarios
due to security concerns. Also, romfs/cramfs don't have their
own on-disk timestamp, and squashfs only records mtime instead.
Let's also derive access time from ondisk timestamp rather than
leaving it empty, and if mtime/atime for each file are really
needed for specific scenarios as well, we can also use xattrs
to record them then.
Reported-by: nl6720
[ Gao Xiang: It'd be better to backport for user-friendly concern. ]
Fixes: 431339ba9042 ("staging: erofs: add inode operations")
Cc: stable # 4.19+
Signed-off-by: Gao Xiang
---
fs/erofs/inode.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c
index 139d0bed42f8..3e21c0e8adae 100644
--- a/fs/erofs/inode.c
+++ b/fs/erofs/inode.c
@@ -107,11 +107,9 @@ static struct page *erofs_read_inode(struct inode *inode,
i_gid_write(inode, le32_to_cpu(die->i_gid));
set_nlink(inode, le32_to_cpu(die->i_nlink));
- /* ns timestamp */
- inode->i_mtime.tv_sec = inode->i_ctime.tv_sec =
- le64_to_cpu(die->i_ctime);
- inode->i_mtime.tv_nsec = inode->i_ctime.tv_nsec =
- le32_to_cpu(die->i_ctime_nsec);
+ /* extended inode has its own timestamp */
+ inode->i_ctime.tv_sec = le64_to_cpu(die->i_ctime);
+ inode->i_ctime.tv_nsec = le32_to_cpu(die->i_ctime_nsec);
inode->i_size = le64_to_cpu(die->i_size);
@@ -149,11 +147,9 @@ static struct page *erofs_read_inode(struct inode *inode,
i_gid_write(inode, le16_to_cpu(dic->i_gid));
set_nlink(inode, le16_to_cpu(dic->i_nlink));
- /* use build time to derive all file time */
- inode->i_mtime.tv_sec = inode->i_ctime.tv_sec =
- sbi->build_time;
- inode->i_mtime.tv_nsec = inode->i_ctime.tv_nsec =
- sbi->build_time_nsec;
+ /* use build time for compact inodes */
+ inode->i_ctime.tv_sec = sbi->build_time;
+ inode->i_ctime.tv_nsec = sbi->build_time_nsec;
inode->i_size = le32_to_cpu(dic->i_size);
if (erofs_inode_is_data_compressed(vi->datalayout))
@@ -167,6 +163,11 @@ static struct page *erofs_read_inode(struct inode *inode,
goto err_out;
}
+ inode->i_mtime.tv_sec = inode->i_ctime.tv_sec;
+ inode->i_atime.tv_sec = inode->i_ctime.tv_sec;
+ inode->i_mtime.tv_nsec = inode->i_ctime.tv_nsec;
+ inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec;
+
if (!nblks)
/* measure inode.i_blocks as generic filesystems */
inode->i_blocks = roundup(inode->i_size, EROFS_BLKSIZ) >> 9;
--
2.24.0
Re: [PATCH net-next v6 1/5] net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
On Sat, Oct 31, 2020 at 12:02 PM Xie He wrote: > > On Sat, Oct 31, 2020 at 8:18 AM Xie He wrote: > > > > > Especially without that, I'm not sure this and the follow-on patch add > > > much value. Minor code cleanups complicate backports of fixes. > > > > To me this is necessary, because I feel hard to do any development on > > un-cleaned-up code. I really don't know how to add my code without > > these clean-ups, and even if I managed to do that, I would not be > > happy with my code. That is the reality of working in this space, I think. I have frequently restructured code, fixed a bug and then worked backwards to create a *minimal* bugfix that applies to the current code as well as older stable branches. Obviously this is more of a concern for stable fixes than for new code. But we have to keep in mind that every code churn will make future bug fixes harder to roll out to users. That is not to say that churn should be avoided, just that we need to balance a change's benefit against this cost. > And always keeping the user interface and even the code unchanged > contradicts my motivation of contributing to the Linux kernel. All my > contributions are motivated by the hope to clean things up. I'm not an > actual user of any of the code I contribute. If we adhere to the > philosophy of not doing any clean-ups, my contributions would be > meaningless. There are cleanups and cleanups. Dead code removal and deduplication of open coded logic, for instance, are very valuable. As is, for instance, your work in making sense of hard_header_len. Returning code in branches vs an error jump label seems more of a personal preference, and to me does not pass the benefit/cost threshold. FWIW, there is lots of code that I would jump at the opportunity to restructure. Starting with skb_segment, probably. Obviously, all this is just one opinion on the topic.
Re: [PATCH] net: atm: fix update of position index in lec_seq_next
On Tue, 27 Oct 2020 11:49:25 + Colin King wrote:
> From: Colin Ian King
>
> The position index in leq_seq_next is not updated when the next
> entry is fetched an no more entries are available. This causes
> seq_file to report the following error:
>
> "seq_file: buggy .next function lec_seq_next [lec] did not update
> position index"
>
> Fix this by always updating the position index.
>
> [ Note: this is an ancient 2002 bug, the sha is from the
> tglx/history repo ]
>
> Fixes 4aea2cbff417 ("[ATM]: Move lan seq_file ops to lec.c [1/3]")
> Signed-off-by: Colin Ian King
Applied, very sneaky there with the lack of a colon on the Fixes tag :)
BTW looking at seq_read() it seems to eat the potential error code from
->next, doesn't it?
@@ -254,9 +254,11 @@ ssize_t seq_read(struct file *file, char __user *buf,
size_t size, loff_t *ppos)
}
m->op->stop(m, p);
n = min(m->count, size);
- err = copy_to_user(buf, m->buf, n);
- if (err)
- goto Efault;
+ if (n) {
+ err = copy_to_user(buf, m->buf, n);
+ if (err)
+ goto Efault;
+ }
copied += n;
m->count -= n;
m->from = n;
Maybe? Or at least:
@@ -239,10 +239,8 @@ ssize_t seq_read(struct file *file, char __user *buf,
size_t size, loff_t *ppos)
m->op->next);
m->index++;
}
- if (!p || IS_ERR(p)) {
- err = PTR_ERR(p);
+ if (!p || IS_ERR(p))
break;
- }
if (m->count >= size)
break;
err = m->op->show(m, p);
dmaengine: pl330 rare NULL pointer dereference in pl330_tasklet
Hi all, I hit quite rare issue with pl330 DMA driver, difficult to reproduce (actually failed to do so): Happened during early reboot [ OK ] Stopped target Graphical Interface. [ OK ] Stopped target Multi-User System. [ OK ] Stopped target RPC Port Mapper. Stopping OpenSSH Daemonti[ 75.447904] 8<--- cut here --- [ 75.449506] Unable to handle kernel NULL pointer dereference at virtual address 000c ... [ 75.690850] [] (pl330_tasklet) from [] (tasklet_action_common+0x88/0x1f4) [ 75.699340] [] (tasklet_action_common) from [] (__do_softirq+0x108/0x428) [ 75.707850] [] (__do_softirq) from [] (run_ksoftirqd+0x2c/0x4c) [ 75.715486] [] (run_ksoftirqd) from [] (smpboot_thread_fn+0x13c/0x24c) [ 75.723693] [] (smpboot_thread_fn) from [] (kthread+0x13c/0x16c) [ 75.731390] [] (kthread) from [] (ret_from_fork+0x14/0x2c) Full log: https://krzk.eu/#/builders/20/builds/954/steps/22/logs/serial0 1. Arch ARM Linux 2. multi_v7_defconfig 3. Odroid HC1, ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC 4. systemd, boot up with static IP set in kernel command line 5. No swap 6. Kernel, DTB and initramfs are downloaded with TFTP 7. NFS root (NFS client) mounted from a NFSv4 server Since I was not able to reproduce it, obviously I did not run bisect. If anyone has ideas, please share. Best regards, Krzysztof
Re: [PATCH] sfp: Fix error handing in sfp_probe()
On Sat, Oct 31, 2020 at 11:10:53AM +0800, YueHaibing wrote:
> gpiod_to_irq() never return 0, but returns negative in
> case of error, check it and set gpio_irq to 0.
>
> Fixes: 73970055450e ("sfp: add SFP module support")
> Signed-off-by: YueHaibing
Reviewed-by: Andrew Lunn
Andrew
Re: [PATCH bpf-next 2/5] bpf: Implement get_current_task_btf and RET_PTR_TO_BTF_ID
Hi KP, I love your patch! Perhaps something to improve: [auto build test WARNING on bpf-next/master] url: https://github.com/0day-ci/linux/commits/KP-Singh/Implement-task_local_storage/20201028-010549 base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master config: i386-randconfig-s002-20201031 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-68-g49c98aa3-dirty # https://github.com/0day-ci/linux/commit/238fab90058acf3437ecf912b49b4fc11249fdef git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review KP-Singh/Implement-task_local_storage/20201028-010549 git checkout 238fab90058acf3437ecf912b49b4fc11249fdef # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> kernel/trace/bpf_trace.c:1032:29: sparse: sparse: symbol >> 'bpf_get_current_task_btf_proto' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[RFC PATCH] bpf: bpf_get_current_task_btf_proto can be static
Signed-off-by: kernel test robot
---
bpf_trace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 7b48aa1c695ab8..e4515b0f62a8d3 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1029,7 +1029,7 @@ BPF_CALL_0(bpf_get_current_task_btf)
BTF_ID_LIST_SINGLE(bpf_get_current_btf_ids, struct, task_struct)
-const struct bpf_func_proto bpf_get_current_task_btf_proto = {
+static const struct bpf_func_proto bpf_get_current_task_btf_proto = {
.func = bpf_get_current_task_btf,
.gpl_only = true,
.ret_type = RET_PTR_TO_BTF_ID,
Re: [PATCH v4 2/2] fs: ext4: Modify inode-test.c to use KUnit parameterized testing feature
Hi Arpitha, Thank you for the patch! Yet something to improve: [auto build test ERROR on ext4/dev] [also build test ERROR on linus/master v5.10-rc1 next-20201030] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Arpitha-Raghunandan/kunit-Support-for-Parameterized-Testing/20201028-015018 base: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev config: x86_64-randconfig-a005-20201031 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 72ddd559b8aafef402091f8e192e025022e4ebef) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://github.com/0day-ci/linux/commit/2de1e52708cd83d1dc4c718876683f6809045a98 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Arpitha-Raghunandan/kunit-Support-for-Parameterized-Testing/20201028-015018 git checkout 2de1e52708cd83d1dc4c718876683f6809045a98 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> fs/ext4/inode-test.c:214:1: error: returning 'typeof ((test_data)[0]) *' >> (aka 'const struct timestamp_expectation *') from a function with result >> type 'void *' discards qualifiers >> [-Werror,-Wincompatible-pointer-types-discards-qualifiers] KUNIT_ARRAY_PARAM(ext4_inode, test_data); ^~~~ include/kunit/test.h:1735:10: note: expanded from macro 'KUNIT_ARRAY_PARAM' return __next - (array) < ARRAY_SIZE((array)) ? __next : NULL; \ ^~ 1 error generated. vim +214 fs/ext4/inode-test.c 213 > 214 KUNIT_ARRAY_PARAM(ext4_inode, test_data); 215 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] net: ethernet: ti: cpsw: disable PTPv1 hw timestamping advertisement
On Thu, 29 Oct 2020 21:09:10 +0200 Grygorii Strashko wrote:
> The TI CPTS does not natively support PTPv1, only PTPv2. But, as it
> happens, the CPTS can provide HW timestamp for PTPv1 Sync messages, because
> CPTS HW parser looks for PTP messageType id in PTP message octet 0 which
> value is 0 for PTPv1. As result, CPTS HW can detect Sync messages for PTPv1
> and PTPv2 (Sync messageType = 0 for both), but it fails for any other PTPv1
> messages (Delay_req/resp) and will return PTP messageType id 0 for them.
>
> The commit e9523a5a32a1 ("net: ethernet: ti: cpsw: enable
> HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter") added PTPv1 hw timestamping
> advertisement by mistake, only to make Linux Kernel "timestamping" utility
> work, and this causes issues with only PTPv1 compatible HW/SW - Sync HW
> timestamped, but Delay_req/resp are not.
>
> Hence, fix it disabling PTPv1 hw timestamping advertisement, so only PTPv1
> compatible HW/SW can properly roll back to SW timestamping.
>
> Fixes: e9523a5a32a1 ("net: ethernet: ti: cpsw: enable
> HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter")
> Signed-off-by: Grygorii Strashko
CC: Richard
> diff --git a/drivers/net/ethernet/ti/cpsw_ethtool.c
> b/drivers/net/ethernet/ti/cpsw_ethtool.c
> index 4d02c5135611..4619c3a950b0 100644
> --- a/drivers/net/ethernet/ti/cpsw_ethtool.c
> +++ b/drivers/net/ethernet/ti/cpsw_ethtool.c
> @@ -728,7 +728,6 @@ int cpsw_get_ts_info(struct net_device *ndev, struct
> ethtool_ts_info *info)
> (1 << HWTSTAMP_TX_ON);
> info->rx_filters =
> (1 << HWTSTAMP_FILTER_NONE) |
> - (1 << HWTSTAMP_FILTER_PTP_V1_L4_EVENT) |
> (1 << HWTSTAMP_FILTER_PTP_V2_EVENT);
> return 0;
> }
> diff --git a/drivers/net/ethernet/ti/cpsw_priv.c
> b/drivers/net/ethernet/ti/cpsw_priv.c
> index 51cc29f39038..31c5e36ff706 100644
> --- a/drivers/net/ethernet/ti/cpsw_priv.c
> +++ b/drivers/net/ethernet/ti/cpsw_priv.c
> @@ -639,13 +639,10 @@ static int cpsw_hwtstamp_set(struct net_device *dev,
> struct ifreq *ifr)
> break;
> case HWTSTAMP_FILTER_ALL:
> case HWTSTAMP_FILTER_NTP_ALL:
> - return -ERANGE;
> case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
> case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
> case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
> - priv->rx_ts_enabled = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
> - cfg.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
> - break;
> + return -ERANGE;
> case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
> case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
> case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
Re: [PATCH net-next] selftests/net: timestamping: add ptp v2 support
On Thu, 29 Oct 2020 21:09:31 +0200 Grygorii Strashko wrote:
> The timestamping tool is supporting now only PTPv1 (IEEE-1588 2002) while
> modern HW often supports also/only PTPv2.
>
> Hence timestamping tool is still useful for sanity testing of PTP drivers
> HW timestamping capabilities it's reasonable to upstate it to support
> PTPv2. This patch adds corresponding support which can be enabled by using
> new parameter "PTPV2".
>
> Signed-off-by: Grygorii Strashko
CC: Richard
> diff --git a/tools/testing/selftests/net/timestamping.c
> b/tools/testing/selftests/net/timestamping.c
> index f4bb4fef0f39..21091be70688 100644
> --- a/tools/testing/selftests/net/timestamping.c
> +++ b/tools/testing/selftests/net/timestamping.c
> @@ -59,7 +59,8 @@ static void usage(const char *error)
> " SOF_TIMESTAMPING_SOFTWARE - request reporting of software
> time stamps\n"
> " SOF_TIMESTAMPING_RAW_HARDWARE - request reporting of raw HW
> time stamps\n"
> " SIOCGSTAMP - check last socket time stamp\n"
> -" SIOCGSTAMPNS - more accurate socket time stamp\n");
> +" SIOCGSTAMPNS - more accurate socket time stamp\n"
> +" PTPV2 - use PTPv2 messages\n");
> exit(1);
> }
>
> @@ -115,13 +116,28 @@ static const unsigned char sync[] = {
> 0x00, 0x00, 0x00, 0x00
> };
>
> -static void sendpacket(int sock, struct sockaddr *addr, socklen_t addr_len)
> +static const unsigned char sync_v2[] = {
> + 0x00, 0x02, 0x00, 0x2C,
> + 0x00, 0x00, 0x02, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0xFF,
> + 0xFE, 0x00, 0x00, 0x00,
> + 0x00, 0x01, 0x00, 0x01,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> +};
> +
> +static void sendpacket(int sock, struct sockaddr *addr, socklen_t addr_len,
> int ptpv2)
> {
> + size_t sync_len = ptpv2 ? sizeof(sync_v2) : sizeof(sync);
> + const void *sync_p = ptpv2 ? sync_v2 : sync;
> struct timeval now;
> int res;
>
> - res = sendto(sock, sync, sizeof(sync), 0,
> - addr, addr_len);
> + res = sendto(sock, sync_p, sync_len, 0, addr, addr_len);
> gettimeofday(, 0);
> if (res < 0)
> printf("%s: %s\n", "send", strerror(errno));
> @@ -134,9 +150,11 @@ static void sendpacket(int sock, struct sockaddr *addr,
> socklen_t addr_len)
> static void printpacket(struct msghdr *msg, int res,
> char *data,
> int sock, int recvmsg_flags,
> - int siocgstamp, int siocgstampns)
> + int siocgstamp, int siocgstampns, int ptpv2)
> {
> struct sockaddr_in *from_addr = (struct sockaddr_in *)msg->msg_name;
> + size_t sync_len = ptpv2 ? sizeof(sync_v2) : sizeof(sync);
> + const void *sync_p = ptpv2 ? sync_v2 : sync;
> struct cmsghdr *cmsg;
> struct timeval tv;
> struct timespec ts;
> @@ -210,10 +228,9 @@ static void printpacket(struct msghdr *msg, int res,
> "probably SO_EE_ORIGIN_TIMESTAMPING"
> #endif
> );
> - if (res < sizeof(sync))
> + if (res < sync_len)
> printf(" => truncated data?!");
> - else if (!memcmp(sync, data + res -
> sizeof(sync),
> - sizeof(sync)))
> + else if (!memcmp(sync_p, data + res - sync_len,
> sync_len))
> printf(" => GOT OUR DATA BACK
> (HURRAY!)");
> break;
> }
> @@ -257,7 +274,7 @@ static void printpacket(struct msghdr *msg, int res,
> }
>
> static void recvpacket(int sock, int recvmsg_flags,
> -int siocgstamp, int siocgstampns)
> +int siocgstamp, int siocgstampns, int ptpv2)
> {
> char data[256];
> struct msghdr msg;
> @@ -288,7 +305,7 @@ static void recvpacket(int sock, int recvmsg_flags,
> } else {
> printpacket(, res, data,
> sock, recvmsg_flags,
> - siocgstamp, siocgstampns);
> + siocgstamp, siocgstampns, ptpv2);
> }
> }
>
> @@ -300,6 +317,7 @@ int main(int argc, char **argv)
> int siocgstamp = 0;
> int siocgstampns = 0;
> int ip_multicast_loop = 0;
> + int ptpv2 = 0;
> char *interface;
> int i;
> int enabled = 1;
> @@ -335,6 +353,8 @@ int main(int argc, char **argv)
> siocgstampns = 1;
> else if (!strcasecmp(argv[i], "IP_MULTICAST_LOOP"))
> ip_multicast_loop = 1;
> + else if (!strcasecmp(argv[i], "PTPV2"))
> + ptpv2 = 1;
>
Re: [PATCH] s390/smp: Move rcu_cpu_starting() earlier
On Wed, Oct 28, 2020 at 02:27:42PM -0400, Qian Cai wrote: > The call to rcu_cpu_starting() in smp_init_secondary() is not early > enough in the CPU-hotplug onlining process, which results in lockdep > splats as follows: > > WARNING: suspicious RCU usage > - > kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!! > > other info that might help us debug this: > > RCU used illegally from offline CPU! > rcu_scheduler_active = 1, debug_locks = 1 > no locks held by swapper/1/0. > > Call Trace: > show_stack+0x158/0x1f0 > dump_stack+0x1f2/0x238 > __lock_acquire+0x2640/0x4dd0 > lock_acquire+0x3a8/0xd08 > _raw_spin_lock_irqsave+0xc0/0xf0 > clockevents_register_device+0xa8/0x528 > init_cpu_timer+0x33e/0x468 > smp_init_secondary+0x11a/0x328 > smp_start_secondary+0x82/0x88 > > This is avoided by moving the call to rcu_cpu_starting up near the > beginning of the smp_init_secondary() function. Note that the > raw_smp_processor_id() is required in order to avoid calling into > lockdep before RCU has declared the CPU to be watched for readers. > > Link: > https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/ > Signed-off-by: Qian Cai > --- > arch/s390/kernel/smp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Could you provide the config you used? I'm wondering why I can't reproduce this even though I have lot's of debug options enabled. I will apply it anyway after rc2 has been released, just curious.
