Re: [PATCH v4 04/10] mtd: rawnand: stm32_fmc2: cleanup
Hi Christophe, Christophe Kerello wrote on Tue, 12 May 2020 08:49:54 +0200: > Hi Miquel, > > On 5/11/20 10:39 PM, Miquel Raynal wrote: > > > > Christophe Kerello wrote on Wed, 6 May 2020 > > 11:11:13 +0200: > > > >> This patch renames functions and local variables. > >> This cleanup is done to get all functions starting by stm32_fmc2_nfc > >> in the FMC2 raw NAND driver when all functions will start by > >> stm32_fmc2_ebi in the FMC2 EBI driver. > >> > >> Signed-off-by: Christophe Kerello > >> Reviewed-by: Miquel Raynal > > > > Applied to nand/next as well but for an unknown reason I had to do it > > by hand because the patch would not apply. > > > > Thanks, > > Miquèl > > > This is strange, I can apply this patch on my tree without any conflicts. > There is a compilation issue line 1301. > > @@ -1302,44 +1298,45 @@ static void stm32_fmc2_write_data(struct nand_chip > *chip, const void *buf, > > if (force_8bit && chip->options & NAND_BUSWIDTH_16) > /* Reconfigure bus width to 16-bit */ > - stm32_fmc2_set_buswidth_16(fmc2, true); > + stm32_fmc2_nfc_set_buswidth_16(nfc, true); > } > > I will rebase on top of nand/next today to check that there is no issues with > the driver. I had to do some changes manually, maibe I missed this one, but I don't remember touching this helper. Anyway, I just dropped the two last patches of your series, please reba&se now on nand/next and just resend patches 4 and 5. Also, while at it, would you mind changing the commit title to something more meaningful? "cleanup" is a bit vague and not very accurate. Maybe something like "Cosmetic change to use nfc instead of fmc2 where relevant". Thanks, Miquèl
[PATCH] mtd: offset align to block size bofore block operation
The off parameter on mtdpsore_block_*() does not align to block size,
which makes some bugs. For example, a block contains dmesg zones
with number 0 to 3. When user remove all these files, mapped to
these zones, mtdpstore is expected to check whether No.0 to No.3 is
unused then erase this block. However it check No.3 to No.6 because
it get wrongly beginning zonenum from misaligned off.
Signed-off-by: WeiXiong Liao
---
This patch bases on series v8 of pstore/blk.
Series Link:
https://lore.kernel.org/lkml/20200511233229.27745-1-keesc...@chromium.org/
drivers/mtd/mtdpstore.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/mtdpstore.c b/drivers/mtd/mtdpstore.c
index 06084eff1004..a4fe6060b960 100644
--- a/drivers/mtd/mtdpstore.c
+++ b/drivers/mtd/mtdpstore.c
@@ -27,7 +27,10 @@ static int mtdpstore_block_isbad(struct mtdpstore_context
*cxt, loff_t off)
{
int ret;
struct mtd_info *mtd = cxt->mtd;
- u64 blknum = div_u64(off, mtd->erasesize);
+ u64 blknum;
+
+ off = ALIGN_DOWN(off, mtd->erasesize);
+ blknum = div_u64(off, mtd->erasesize);
if (test_bit(blknum, cxt->badmap))
return true;
@@ -46,8 +49,10 @@ static inline int mtdpstore_panic_block_isbad(struct
mtdpstore_context *cxt,
loff_t off)
{
struct mtd_info *mtd = cxt->mtd;
- u64 blknum = div_u64(off, mtd->erasesize);
+ u64 blknum;
+ off = ALIGN_DOWN(off, mtd->erasesize);
+ blknum = div_u64(off, mtd->erasesize);
return test_bit(blknum, cxt->badmap);
}
@@ -75,9 +80,11 @@ static inline void mtdpstore_block_mark_unused(struct
mtdpstore_context *cxt,
loff_t off)
{
struct mtd_info *mtd = cxt->mtd;
- u64 zonenum = div_u64(off, cxt->info.kmsg_size);
- u32 zonecnt = cxt->mtd->erasesize / cxt->info.kmsg_size;
+ u32 zonecnt = mtd->erasesize / cxt->info.kmsg_size;
+ u64 zonenum;
+ off = ALIGN_DOWN(off, mtd->erasesize);
+ zonenum = div_u64(off, cxt->info.kmsg_size);
while (zonecnt > 0) {
dev_dbg(&mtd->dev, "mark zone %llu unused\n", zonenum);
clear_bit(zonenum, cxt->usedmap);
@@ -99,9 +106,12 @@ static inline int mtdpstore_is_used(struct
mtdpstore_context *cxt, loff_t off)
static int mtdpstore_block_is_used(struct mtdpstore_context *cxt,
loff_t off)
{
- u64 zonenum = div_u64(off, cxt->info.kmsg_size);
- u32 zonecnt = cxt->mtd->erasesize / cxt->info.kmsg_size;
+ struct mtd_info *mtd = cxt->mtd;
+ u32 zonecnt = mtd->erasesize / cxt->info.kmsg_size;
+ u64 zonenum;
+ off = ALIGN_DOWN(off, mtd->erasesize);
+ zonenum = div_u64(off, cxt->info.kmsg_size);
while (zonecnt > 0) {
if (test_bit(zonenum, cxt->usedmap))
return true;
@@ -138,9 +148,12 @@ static void mtdpstore_mark_removed(struct
mtdpstore_context *cxt, loff_t off)
static void mtdpstore_block_clear_removed(struct mtdpstore_context *cxt,
loff_t off)
{
- u64 zonenum = div_u64(off, cxt->info.kmsg_size);
- u32 zonecnt = cxt->mtd->erasesize / cxt->info.kmsg_size;
+ struct mtd_info *mtd = cxt->mtd;
+ u32 zonecnt = mtd->erasesize / cxt->info.kmsg_size;
+ u64 zonenum;
+ off = ALIGN_DOWN(off, mtd->erasesize);
+ zonenum = div_u64(off, cxt->info.kmsg_size);
while (zonecnt > 0) {
clear_bit(zonenum, cxt->rmmap);
zonenum++;
@@ -151,9 +164,12 @@ static void mtdpstore_block_clear_removed(struct
mtdpstore_context *cxt,
static int mtdpstore_block_is_removed(struct mtdpstore_context *cxt,
loff_t off)
{
- u64 zonenum = div_u64(off, cxt->info.kmsg_size);
- u32 zonecnt = cxt->mtd->erasesize / cxt->info.kmsg_size;
+ struct mtd_info *mtd = cxt->mtd;
+ u32 zonecnt = mtd->erasesize / cxt->info.kmsg_size;
+ u64 zonenum;
+ off = ALIGN_DOWN(off, mtd->erasesize);
+ zonenum = div_u64(off, cxt->info.kmsg_size);
while (zonecnt > 0) {
if (test_bit(zonenum, cxt->rmmap))
return true;
@@ -169,6 +185,7 @@ static int mtdpstore_erase_do(struct mtdpstore_context
*cxt, loff_t off)
struct erase_info erase;
int ret;
+ off = ALIGN_DOWN(off, cxt->mtd->erasesize);
dev_dbg(&mtd->dev, "try to erase off 0x%llx\n", off);
erase.len = cxt->mtd->erasesize;
erase.addr = off;
@@ -205,7 +222,6 @@ static ssize_t mtdpstore_erase(size_t size, loff_t off)
}
/* all zones are unused, erase it */
- off = ALIGN_DOWN(off, cxt->mtd->erasesize);
return mtdpstore_erase_do(cxt, off);
}
@@ -235,7 +251,6 @@ static int mtdpstore_security(struct mtdpstore_context
*cxt, loff_t off)
}
/* If there is no any empty zone, we have no way but to do erase */
- off = ALIG
Re: [PATCH v1 5/5] bus: mhi: core: Handle write lock properly in mhi_pm_m0_transition
On Mon, May 11, 2020 at 07:03:09PM -0700, Hemant Kumar wrote:
> Take write lock only to protect db_mode member of mhi channel.
> This allows rest of the mhi channels to just take read lock which
> fine grains the locking. It prevents channel readers to starve if
> they try to enter critical section after a writer.
>
> Signed-off-by: Hemant Kumar
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> drivers/bus/mhi/core/pm.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 345f197..de5abb2 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -288,14 +288,18 @@ int mhi_pm_m0_transition(struct mhi_controller
> *mhi_cntrl)
> for (i = 0; i < mhi_cntrl->max_chan; i++, mhi_chan++) {
> struct mhi_ring *tre_ring = &mhi_chan->tre_ring;
>
> - write_lock_irq(&mhi_chan->lock);
> - if (mhi_chan->db_cfg.reset_req)
> + if (mhi_chan->db_cfg.reset_req) {
> + write_lock_irq(&mhi_chan->lock);
> mhi_chan->db_cfg.db_mode = true;
> + write_unlock_irq(&mhi_chan->lock);
> + }
> +
> + read_lock_irq(&mhi_chan->lock);
>
> /* Only ring DB if ring is not empty */
> if (tre_ring->base && tre_ring->wp != tre_ring->rp)
> mhi_ring_chan_db(mhi_cntrl, mhi_chan);
> - write_unlock_irq(&mhi_chan->lock);
> + read_unlock_irq(&mhi_chan->lock);
> }
>
> mhi_cntrl->wake_put(mhi_cntrl, false);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
BUG: unable to handle kernel paging request in bitfill_aligned
Hello, syzbot found the following crash on: HEAD commit:1d3962ae Merge tag 'io_uring-5.7-2020-05-08' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1487425810 kernel config: https://syzkaller.appspot.com/x/.config?x=b0212dbee046bc1f dashboard link: https://syzkaller.appspot.com/bug?extid=00ed1cf405874e141432 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+00ed1cf405874e141...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: 888000cf5080 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD d401067 P4D d401067 PUD d402067 PMD cf4063 PTE 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 30473 Comm: syz-executor.4 Not tainted 5.7.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__writeq arch/x86/include/asm/io.h:98 [inline] RIP: 0010:bitfill_aligned drivers/video/fbdev/core/cfbfillrect.c:64 [inline] RIP: 0010:bitfill_aligned+0xfc/0x200 drivers/video/fbdev/core/cfbfillrect.c:35 Code: fd 44 89 e0 31 d2 bf 07 00 00 00 f7 f5 41 89 c4 89 c6 89 c5 e8 c5 ab b3 fd 41 83 fc 07 76 62 45 89 e7 4c 89 ed e8 44 aa b3 fd <48> 89 5d 00 48 89 5d 08 48 89 5d 10 48 89 5d 18 48 89 5d 20 48 89 RSP: 0018:c90001c474e0 EFLAGS: 00010246 RAX: 0004 RBX: RCX: c90012324000 RDX: 0004 RSI: 83bf846c RDI: 0005 RBP: 888000cf5080 R08: 888056a6a340 R09: 0040 R10: 888218d3331f R11: ed10431a6663 R12: 0030 R13: 888000cf5080 R14: R15: 0030 FS: 7fe0d9986700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 888000cf5080 CR3: 8ea77000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: cfb_fillrect+0x418/0x7a0 drivers/video/fbdev/core/cfbfillrect.c:327 vga16fb_fillrect+0x68f/0x1960 drivers/video/fbdev/vga16fb.c:951 bit_clear_margins+0x2d5/0x4a0 drivers/video/fbdev/core/bitblit.c:232 fbcon_clear_margins+0x1de/0x240 drivers/video/fbdev/core/fbcon.c:1381 fbcon_switch+0xcde/0x16f0 drivers/video/fbdev/core/fbcon.c:2363 redraw_screen+0x2ae/0x770 drivers/tty/vt/vt.c:1015 fbcon_modechanged+0x581/0x720 drivers/video/fbdev/core/fbcon.c:3000 fbcon_update_vcs+0x3a/0x50 drivers/video/fbdev/core/fbcon.c:3047 fb_set_var+0xad0/0xd40 drivers/video/fbdev/core/fbmem.c:1056 do_fb_ioctl+0x390/0x6e0 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl+0x11a/0x180 fs/ioctl.c:771 __do_sys_ioctl fs/ioctl.c:780 [inline] __se_sys_ioctl fs/ioctl.c:778 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:778 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45c829 Code: 0d b7 fb 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 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fe0d9985c78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 004e4860 RCX: 0045c829 RDX: 2000 RSI: 4601 RDI: 0003 RBP: 0078bf00 R08: R09: R10: R11: 0246 R12: R13: 02f2 R14: 004c54c8 R15: 7fe0d99866d4 Modules linked in: CR2: 888000cf5080 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v1 4/5] bus: mhi: core: Do not process SYS_ERROR if RDDM is supported
On Mon, May 11, 2020 at 07:03:08PM -0700, Hemant Kumar wrote:
> Devices that support RDDM do not require processing SYS_ERROR as it is
> deemed redundant. Avoid SYS_ERROR processing if RDDM is supported by
> the device.
>
> Signed-off-by: Hemant Kumar
> Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> drivers/bus/mhi/core/main.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 467c0ba..1f622ce 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -397,9 +397,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number,
> void *priv)
> }
> write_unlock_irq(&mhi_cntrl->pm_lock);
>
> - /* If device in RDDM don't bother processing SYS error */
> - if (mhi_cntrl->ee == MHI_EE_RDDM) {
> - if (mhi_cntrl->ee != ee) {
> + /* If device supports RDDM don't bother processing SYS error */
> + if (mhi_cntrl->rddm_image) {
> + if (mhi_cntrl->ee == MHI_EE_RDDM && mhi_cntrl->ee != ee) {
> mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_EE_RDDM);
> wake_up_all(&mhi_cntrl->state_event);
> }
> @@ -735,6 +735,11 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
> *mhi_cntrl,
> {
> enum mhi_pm_state new_state;
>
> + /* skip SYS_ERROR handling if RDDM supported */
> + if (mhi_cntrl->ee == MHI_EE_RDDM ||
> + mhi_cntrl->rddm_image)
> + break;
> +
> dev_dbg(dev, "System error detected\n");
> write_lock_irq(&mhi_cntrl->pm_lock);
> new_state = mhi_tryset_pm_state(mhi_cntrl,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
general protection fault in nfsd_reply_cache_free_locked
Hello, syzbot found the following crash on: HEAD commit:6e7f2eac Merge tag 'arm64-fixes' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1456703410 kernel config: https://syzkaller.appspot.com/x/.config?x=b0212dbee046bc1f dashboard link: https://syzkaller.appspot.com/bug?extid=a29df412692980277f9d compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a29df412692980277...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc02: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0010-0x0017] CPU: 0 PID: 27932 Comm: kworker/u4:4 Not tainted 5.7.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net RIP: 0010:nfsd_reply_cache_free_locked+0x2d/0x380 fs/nfsd/nfscache.c:122 Code: 56 41 55 41 54 49 89 fc 55 48 89 f5 53 48 89 d3 e8 08 c0 2f ff 48 8d 7d 61 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 a7 02 00 00 RSP: 0018:c90008bb7b70 EFLAGS: 00010202 RAX: dc00 RBX: 88826000 RCX: dc00 RDX: 0002 RSI: 82436ea8 RDI: 0011 RBP: ffb0 R08: 888093792400 R09: fbfff185cf3e R10: 8c2e79ef R11: fbfff185cf3d R12: 88800010 R13: 88800018 R14: R15: 88800010 FS: () GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2c531000 CR3: 685a2000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: nfsd_reply_cache_shutdown+0x150/0x350 fs/nfsd/nfscache.c:203 nfsd_exit_net+0x189/0x4c0 fs/nfsd/nfsctl.c:1504 ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186 cleanup_net+0x511/0xa50 net/core/net_namespace.c:603 process_one_work+0x965/0x16a0 kernel/workqueue.c:2268 worker_thread+0x96/0xe20 kernel/workqueue.c:2414 kthread+0x388/0x470 kernel/kthread.c:268 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Modules linked in: ---[ end trace 54f06072fc6a1afa ]--- RIP: 0010:nfsd_reply_cache_free_locked+0x2d/0x380 fs/nfsd/nfscache.c:122 Code: 56 41 55 41 54 49 89 fc 55 48 89 f5 53 48 89 d3 e8 08 c0 2f ff 48 8d 7d 61 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 a7 02 00 00 RSP: 0018:c90008bb7b70 EFLAGS: 00010202 RAX: dc00 RBX: 88826000 RCX: dc00 RDX: 0002 RSI: 82436ea8 RDI: 0011 RBP: ffb0 R08: 888093792400 R09: fbfff185cf3e R10: 8c2e79ef R11: fbfff185cf3d R12: 88800010 R13: 88800018 R14: R15: 88800010 FS: () GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2c531000 CR3: 94cfb000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH] memory/samsung: reduce unnecessary mutex lock area
On Fri, May 08, 2020 at 06:13:38AM -0700, Bernard Zhao wrote: > Maybe dmc->df->lock is unnecessary to protect function > exynos5_dmc_perf_events_check(dmc). If we have to protect, > dmc->lock is more better and more effective. > Also, it seems not needed to protect "if (ret) & dev_warn" > branch. > > Signed-off-by: Bernard Zhao > --- > drivers/memory/samsung/exynos5422-dmc.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) I checked the concurrent accesses and it looks correct. Lukasz, any review from your side? Best regards, Krzysztof
Re: [PATCH v5] streamline_config.pl: add LMC_KEEP to preserve some kconfigs
On Sun, May 10, 2020 at 10:06 AM Changbin Du wrote:
>
> Sometimes it is useful to preserve batches of configs when making
> localmodconfig. For example, I usually don't want any usb and fs
> modules to be disabled. Now we can do it by:
>
> $ make LMC_KEEP="drivers/usb:fs" localmodconfig
>
> Signed-off-by: Changbin Du
>
> ---
> v4: fix typo.
> v3: rename LOCALMODCONFIG_PRESERVE to shorter LMC_KEEP.
> v2: fix typo in documentation. (Randy Dunlap)
> ---
> Documentation/admin-guide/README.rst | 8 +++-
> scripts/kconfig/Makefile | 1 +
> scripts/kconfig/streamline_config.pl | 21 +
> 3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/README.rst
> b/Documentation/admin-guide/README.rst
> index cc6151fc0845..407aa206bb70 100644
> --- a/Documentation/admin-guide/README.rst
> +++ b/Documentation/admin-guide/README.rst
> @@ -209,10 +209,16 @@ Configuring the kernel
> store the lsmod of that machine into a file
> and pass it in as a LSMOD parameter.
>
> + Also, you can preserve modules in certain folders
> + or kconfig files by specifying their paths in
> + parameter LMC_KEEP.
> +
> target$ lsmod > /tmp/mylsmod
> target$ scp /tmp/mylsmod host:/tmp
>
> - host$ make LSMOD=/tmp/mylsmod localmodconfig
> + host$ make LSMOD=/tmp/mylsmod \
> + LMC_KEEP="drivers/usb:drivers/gpu:fs" \
> + localmodconfig
>
> The above also works when cross compiling.
>
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index c9d0a4a8efb3..e0abbf5805f5 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -123,6 +123,7 @@ help:
> @echo ' gconfig - Update current config utilising a GTK+
> based front-end'
> @echo ' oldconfig - Update current config utilising a
> provided .config as base'
> @echo ' localmodconfig - Update current config disabling modules
> not loaded'
> + @echo 'except those preserved by LMC_KEEP
> environment variable'
> @echo ' localyesconfig - Update current config converting local
> mods to core'
Just a nitpicking.
I was just about to apply this patch,
then noticed this.
This works for localyesconfig as well as
localmodconfig.
Do you want to add the note to localyesconfig too?
LMC_ is an acronym of LOCAL_MOD_CONFIG_.
Maybe it is OK because
we mostly use localmodconfig,
using localyesconfig is somewhat rare, I guess.
Just a reminder, if you want to send v6
or if you want me to pick this up as-is.
Thanks.
> @echo ' defconfig - New config with default from ARCH
> supplied defconfig'
> @echo ' savedefconfig - Save current config as ./defconfig
> (minimal config)'
> diff --git a/scripts/kconfig/streamline_config.pl
> b/scripts/kconfig/streamline_config.pl
> index e2f8504f5a2d..19857d18d814 100755
> --- a/scripts/kconfig/streamline_config.pl
> +++ b/scripts/kconfig/streamline_config.pl
> @@ -143,6 +143,7 @@ my %depends;
> my %selects;
> my %prompts;
> my %objects;
> +my %config2kfile;
> my $var;
> my $iflevel = 0;
> my @ifdeps;
> @@ -201,6 +202,7 @@ sub read_kconfig {
> if (/^\s*(menu)?config\s+(\S+)\s*$/) {
> $state = "NEW";
> $config = $2;
> + $config2kfile{"CONFIG_$config"} = $kconfig;
>
> # Add depends for 'if' nesting
> for (my $i = 0; $i < $iflevel; $i++) {
> @@ -591,6 +593,20 @@ while ($repeat) {
> }
>
> my %setconfigs;
> +my @preserved_kconfigs = split(/:/,$ENV{LMC_KEEP});
> +
> +sub in_preserved_kconfigs {
> +my $kconfig = $config2kfile{$_[0]};
> +if (!defined($kconfig)) {
> +return 0;
> +}
> +foreach my $excl (@preserved_kconfigs) {
> +if($kconfig =~ /^$excl/) {
> +return 1;
> +}
> +}
> +return 0;
> +}
>
> # Finally, read the .config file and turn off any module enabled that
> # we could not find a reason to keep enabled.
> @@ -644,6 +660,11 @@ foreach my $line (@config_file) {
> }
>
> if (/^(CONFIG.*)=(m|y)/) {
> +if (in_preserved_kconfigs($1)) {
> +dprint "Preserve config $1";
> +print;
> +next;
> +}
> if (defined($configs{$1})) {
> if ($localyesconfig) {
> $setconfigs{$1} = 'y';
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
[PATCH v3] mtd: rawnand: brcmnand: correctly verify erased pages
The current code checks that the whole OOB area is erased.
This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will
fail due to the usable OOB bytes not being 0xff.
Correct this by only checking that data and ECC bytes aren't 0xff.
Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflips")
Signed-off-by: Álvaro Fernández Rojas
---
v3: Fix commit log and merge nand_check_erased_ecc_chunk calls.
v2: Add Fixes tag
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index e4e3ceeac38f..80fe01f03516 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -2018,8 +2018,9 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd,
struct nand_chip *chip,
static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
struct nand_chip *chip, void *buf, u64 addr)
{
+ struct mtd_oob_region oobecc;
int i, sas;
- void *oob = chip->oob_poi;
+ void *oob;
int bitflips = 0;
int page = addr >> chip->page_shift;
int ret;
@@ -2035,11 +2036,19 @@ static int brcmstb_nand_verify_erased_page(struct
mtd_info *mtd,
if (ret)
return ret;
- for (i = 0; i < chip->ecc.steps; i++, oob += sas) {
+ for (i = 0; i < chip->ecc.steps; i++) {
ecc_chunk = buf + chip->ecc.size * i;
- ret = nand_check_erased_ecc_chunk(ecc_chunk,
- chip->ecc.size,
- oob, sas, NULL, 0,
+
+ if (mtd->ooblayout->ecc(mtd, i, &oobecc)) {
+ oob = NULL;
+ oobecc.length = 0;
+ } else {
+ oob = chip->oob_poi + oobecc.offset;
+ }
+
+ ret = nand_check_erased_ecc_chunk(ecc_chunk, chip->ecc.size,
+ oob, oobecc.length,
+ NULL, 0,
chip->ecc.strength);
if (ret < 0)
return ret;
--
2.26.2
Re: [PATCH v1 3/5] bus: mhi: core: Skip handling BHI irq if MHI reg access is not allowed
On Mon, May 11, 2020 at 07:03:07PM -0700, Hemant Kumar wrote:
> Driver continues handling of BHI interrupt even if MHI register access
> is not allowed. By doing so it calls the status call back and performs
> early notification for the MHI client. This is not needed when MHI
> register access is not allowed. Hence skip the handling in this case and
> return. Also add debug log to print device state, local EE and device EE
> when reg access is valid.
>
> Signed-off-by: Hemant Kumar
> Reviewed-by: Jeffrey Hugo
> ---
> drivers/bus/mhi/core/main.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 9ec9b36..467c0ba 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -369,22 +369,29 @@ irqreturn_t mhi_irq_handler(int irq_number, void *dev)
> return IRQ_HANDLED;
> }
>
> -irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *dev)
> +irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *priv)
> {
> - struct mhi_controller *mhi_cntrl = dev;
> + struct mhi_controller *mhi_cntrl = priv;
> + struct device *dev = &mhi_cntrl->mhi_dev->dev;
> enum mhi_state state = MHI_STATE_MAX;
> enum mhi_pm_state pm_state = 0;
> enum mhi_ee_type ee = 0;
>
> write_lock_irq(&mhi_cntrl->pm_lock);
> - if (MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
> - state = mhi_get_mhi_state(mhi_cntrl);
> - ee = mhi_cntrl->ee;
> - mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
> + if (!MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
> + write_unlock_irq(&mhi_cntrl->pm_lock);
write_lock is only used for protecting 'mhi_cntrl->ee' but here we are not
updating it if reg access is not valid. So there is no reason to hold this lock.
> + goto exit_intvec;
> }
>
> + state = mhi_get_mhi_state(mhi_cntrl);
> + ee = mhi_cntrl->ee;
> + mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
But it is needed here.
Thanks,
Mani
> + dev_dbg(dev, "local ee:%s device ee:%s dev_state:%s\n",
> + TO_MHI_EXEC_STR(mhi_cntrl->ee), TO_MHI_EXEC_STR(ee),
> + TO_MHI_STATE_STR(state));
> +
> if (state == MHI_STATE_SYS_ERR) {
> - dev_dbg(&mhi_cntrl->mhi_dev->dev, "System error detected\n");
> + dev_dbg(dev, "System error detected\n");
> pm_state = mhi_tryset_pm_state(mhi_cntrl,
> MHI_PM_SYS_ERR_DETECT);
> }
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
Re: [PATCH v4 04/10] mtd: rawnand: stm32_fmc2: cleanup
Hi Miquel, On 5/11/20 10:39 PM, Miquel Raynal wrote: Christophe Kerello wrote on Wed, 6 May 2020 11:11:13 +0200: This patch renames functions and local variables. This cleanup is done to get all functions starting by stm32_fmc2_nfc in the FMC2 raw NAND driver when all functions will start by stm32_fmc2_ebi in the FMC2 EBI driver. Signed-off-by: Christophe Kerello Reviewed-by: Miquel Raynal Applied to nand/next as well but for an unknown reason I had to do it by hand because the patch would not apply. Thanks, Miquèl This is strange, I can apply this patch on my tree without any conflicts. There is a compilation issue line 1301. @@ -1302,44 +1298,45 @@ static void stm32_fmc2_write_data(struct nand_chip *chip, const void *buf, if (force_8bit && chip->options & NAND_BUSWIDTH_16) /* Reconfigure bus width to 16-bit */ - stm32_fmc2_set_buswidth_16(fmc2, true); + stm32_fmc2_nfc_set_buswidth_16(nfc, true); } I will rebase on top of nand/next today to check that there is no issues with the driver. Regards, Christophe Kerello.
Re: [PATCH V4] f2fs: Avoid double lock for cp_rwsem during checkpoint
On 2020/5/12 11:24, Jaegeuk Kim wrote:
> On 05/12, Chao Yu wrote:
>> On 2020/5/12 6:11, Jaegeuk Kim wrote:
>>> On 05/11, Chao Yu wrote:
On 2020/5/10 3:03, Jaegeuk Kim wrote:
> On 05/09, Chao Yu wrote:
>> On 2020/5/9 0:10, Jaegeuk Kim wrote:
>>> Hi Sayali,
>>>
>>> In order to address the perf regression, how about this?
>>>
>>> >From 48418af635884803ffb35972df7958a2e6649322 Mon Sep 17 00:00:00 2001
>>> From: Jaegeuk Kim
>>> Date: Fri, 8 May 2020 09:08:37 -0700
>>> Subject: [PATCH] f2fs: avoid double lock for cp_rwsem during checkpoint
>>>
>>> There could be a scenario where f2fs_sync_node_pages gets
>>> called during checkpoint, which in turn tries to flush
>>> inline data and calls iput(). This results in deadlock as
>>> iput() tries to hold cp_rwsem, which is already held at the
>>> beginning by checkpoint->block_operations().
>>>
>>> Call stack :
>>>
>>> Thread AThread B
>>> f2fs_write_checkpoint()
>>> - block_operations(sbi)
>>> - f2fs_lock_all(sbi);
>>> - down_write(&sbi->cp_rwsem);
>>>
>>> - open()
>>> - igrab()
>>> - write() write inline data
>>> - unlink()
>>> - f2fs_sync_node_pages()
>>> - if (is_inline_node(page))
>>> - flush_inline_data()
>>>- ilookup()
>>> page = f2fs_pagecache_get_page()
>>> if (!page)
>>> goto iput_out;
>>> iput_out:
>>> -close()
>>> -iput()
>>>iput(inode);
>>>- f2fs_evict_inode()
>>> - f2fs_truncate_blocks()
>>> - f2fs_lock_op()
>>>- down_read(&sbi->cp_rwsem);
>>>
>>> Fixes: 2049d4fcb057 ("f2fs: avoid multiple node page writes due to
>>> inline_data")
>>> Signed-off-by: Sayali Lokhande
>>> Signed-off-by: Jaegeuk Kim
>>> ---
>>> fs/f2fs/node.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>>> index 1db8cabf727ef..626d7daca09de 100644
>>> --- a/fs/f2fs/node.c
>>> +++ b/fs/f2fs/node.c
>>> @@ -1870,8 +1870,8 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
>>> goto continue_unlock;
>>> }
>>>
>>> - /* flush inline_data */
>>> - if (is_inline_node(page)) {
>>> + /* flush inline_data, if it's not sync path. */
>>> + if (do_balance && is_inline_node(page)) {
>>
>> IIRC, this flow was designed to avoid running out of free space issue
>> during checkpoint:
>>
>> 2049d4fcb057 ("f2fs: avoid multiple node page writes due to inline_data")
>>
>> The sceanrio is:
>> 1. create fully node blocks
>> 2. flush node blocks
>> 3. write inline_data for all the node blocks again
>> 4. flush node blocks redundantly
>>
>> I guess this may cause failing one case of fstest.
>
> Yeah, actually I was hitting 204 failure, and thus, revised like this.
> Now, I don't see any regression in fstest.
>
> >From 8f1882acfb0a5fc43e5a2bbd576a8f3c681a7d2c Mon Sep 17 00:00:00 2001
> From: Sayali Lokhande
> Date: Thu, 30 Apr 2020 16:28:29 +0530
> Subject: [PATCH] f2fs: Avoid double lock for cp_rwsem during checkpoint
>
> There could be a scenario where f2fs_sync_node_pages gets
> called during checkpoint, which in turn tries to flush
> inline data and calls iput(). This results in deadlock as
> iput() tries to hold cp_rwsem, which is already held at the
> beginning by checkpoint->block_operations().
>
> Call stack :
>
> Thread A Thread B
> f2fs_write_checkpoint()
> - block_operations(sbi)
> - f2fs_lock_all(sbi);
> - down_write(&sbi->cp_rwsem);
>
> - open()
> - igrab()
> - write() write inline data
> - unlink()
> - f2fs_sync_node_pages()
> - if (is_inline_node(page))
> - flush_inline_data()
>- ilookup()
> page = f2fs_pagecache_get_page()
> if (!page)
> goto iput_out;
> iput_out:
> -close()
> -iput()
>iput(inode);
>- f2fs_evict_inode()
> - f2fs_truncate_blocks()
> - f2fs_lock_op()
>- down_read(&sbi->cp_rwsem);
>
> Fixes: 2049d4fcb057 ("f2fs: avoid multiple node page writes due to
> inline_data")
> Signed-off-by: Sayali Lokhande
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/checkpoint.c | 9 -
> fs/f2fs/f2fs.h | 4 ++--
> fs/
Re: [PATCH] mm, swap: Use prandom_u32_max()
On Tue 12-05-20 14:41:46, Huang Ying wrote: > To improve the code readability and get random number with higher > quality. I understand the readability argument but why should prandom_u32_max (which I was not aware of) provide a higher quality randomness? > Signed-off-by: "Huang, Ying" > Cc: Michal Hocko > Cc: Minchan Kim > Cc: Tim Chen > Cc: Hugh Dickins To the change itself Acked-by: Michal Hocko > --- > mm/swapfile.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/swapfile.c b/mm/swapfile.c > index a0a123e59ce6..2ec8b21201d6 100644 > --- a/mm/swapfile.c > +++ b/mm/swapfile.c > @@ -3220,7 +3220,7 @@ SYSCALL_DEFINE2(swapon, const char __user *, > specialfile, int, swap_flags) >* select a random position to start with to help wear leveling >* SSD >*/ > - p->cluster_next = 1 + (prandom_u32() % p->highest_bit); > + p->cluster_next = 1 + prandom_u32_max(p->highest_bit); > nr_cluster = DIV_ROUND_UP(maxpages, SWAPFILE_CLUSTER); > > cluster_info = kvcalloc(nr_cluster, sizeof(*cluster_info), > -- > 2.26.2 -- Michal Hocko SUSE Labs
Re: signal quality and cable diagnostic
On Mon, May 11, 2020 at 04:59:26PM +0200, Michal Kubecek wrote: > On Mon, May 11, 2020 at 04:13:10PM +0200, Oleksij Rempel wrote: > > > > I continue to work on TJA11xx PHY and need to export some additional > > cable diagnostic/link stability information: Signal Quality Index (SQI). > > The PHY data sheet describes it as following [1]: > > > > 6.10.3 Link stability > > > > The signal-to-noise ratio is the parameter used to estimate link > > stability. The PMA Receive function monitors the signal-to-noise ratio > > continuously. Once the signal-to-noise ratio falls below a configurable > > threshold (SQI_FAILLIMIT), the link status is set to FAIL and > > communication is interrupted. The TJA1100 allows for adjusting the > > sensitivity of the PMA Receive function by configuring this threshold. > > The microcontroller can always check the current value of the > > signal-to-noise ratio via the SMI, allowing it to track a possible > > degradation in link stability. > > > > > > Since this functionality is present at least on TJA11xx PHYs and > > mandatory according to Open Alliance[2], I hope this functionality is > > present on other 100/1000Base-T1 PHYs. So may be some common abstraction > > is possible. What would be the best place to provide it for the user > > space? According to the [2] SQI, is the part of Dynamic Channel Quality > > (DCQ) together with Mean Square Error (MSE) and Peak MSE value (pMSE). > > IIUC these would be read-only parameters describing current state of the > link which can be queried at any time. If this is the case, adding them > as attributes to ETHTOOL_MSG_LINKSTATE_GET_REPLY message seems most > fitting. ok > As for getting / setting the threshold, perhaps ETHTOOL_MSG_LINKINFO_GET > and ETHTOOL_MSG_LINKINFO_SET. Unless you expect more configurable > parameters like this in which case we may want to consider adding new > request type (e.g. link params or link management). Currently in my short term todo are: - SQI - PHY undervoltage - PHY overtemerature So far, I have no idea for PHY health diagnostic. If we consider at least the mandatory properties listed in the opensig, then we would get following list: - DCQ (dynamic channel group) - SQI (Signal Quality Index) - HDD (Harness defect detection group) - OS (Open/Short detection) - implemented, cable test request. - LQ (Link Quality) - LTT (Link-training time. The time of the last link training) - LFL (Link Failures and Losses. Number of link losses since the last power cycle) - COM (communication ready) - implemented? - POL (Polarity detection & correction) - DET (Polarity detect) I personally would add RE_ERR counter in this list as well. Probably some one, soon or later, will try to implement them. If I see it correctly, some of this properties are already implemented within other request types. Is it worth to a add a new request type for the rest of them? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v1 2/5] bus: mhi: core: Handle disable transitions in state worker
On Mon, May 11, 2020 at 07:03:06PM -0700, Hemant Kumar wrote:
> Mission mode transition is handled by state worker thread but
> power off is not. There is a possibility while mission mode
> transition is in progress which calls MHI client driver probe,
> power off is issued by MHI controller. This results into client
> driver probe and remove running in parallel and causes use after
> free situation. By queuing disable transition work when mission
> mode is in progress prevents the race condition.
>
> Signed-off-by: Hemant Kumar
> Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> drivers/bus/mhi/core/init.c | 1 +
> drivers/bus/mhi/core/internal.h | 1 +
> drivers/bus/mhi/core/pm.c | 11 ++-
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 3a853c5..12207cc 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -35,6 +35,7 @@
> [DEV_ST_TRANSITION_SBL] = "SBL",
> [DEV_ST_TRANSITION_MISSION_MODE] = "MISSION_MODE",
> [DEV_ST_TRANSITION_SYS_ERR] = "SYS_ERR",
> + [DEV_ST_TRANSITION_DISABLE] = "DISABLE",
> };
>
> const char * const mhi_state_str[MHI_STATE_MAX] = {
> diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
> index f01283b..b1f640b 100644
> --- a/drivers/bus/mhi/core/internal.h
> +++ b/drivers/bus/mhi/core/internal.h
> @@ -387,6 +387,7 @@ enum dev_st_transition {
> DEV_ST_TRANSITION_SBL,
> DEV_ST_TRANSITION_MISSION_MODE,
> DEV_ST_TRANSITION_SYS_ERR,
> + DEV_ST_TRANSITION_DISABLE,
> DEV_ST_TRANSITION_MAX,
> };
>
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index d9964d4..345f197 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -657,6 +657,10 @@ void mhi_pm_st_worker(struct work_struct *work)
> mhi_pm_disable_transition
> (mhi_cntrl, MHI_PM_SYS_ERR_PROCESS);
> break;
> + case DEV_ST_TRANSITION_DISABLE:
> + mhi_pm_disable_transition
> + (mhi_cntrl, MHI_PM_SHUTDOWN_PROCESS);
> + break;
> default:
> break;
> }
> @@ -1011,7 +1015,12 @@ void mhi_power_down(struct mhi_controller *mhi_cntrl,
> bool graceful)
> to_mhi_pm_state_str(MHI_PM_LD_ERR_FATAL_DETECT),
> to_mhi_pm_state_str(mhi_cntrl->pm_state));
> }
> - mhi_pm_disable_transition(mhi_cntrl, MHI_PM_SHUTDOWN_PROCESS);
> +
> + mhi_queue_state_transition(mhi_cntrl, DEV_ST_TRANSITION_DISABLE);
> +
> + /* Wait for shutdown to complete */
> + flush_work(&mhi_cntrl->st_worker);
> +
> mhi_deinit_free_irq(mhi_cntrl);
>
> if (!mhi_cntrl->pre_init) {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
Re: [PATCH v4 10/10] loop: Add LOOP_CONFIGURE ioctl
Hi Jens,
What do you think of this series?
Thanks,
Martijn
On Wed, Apr 29, 2020 at 4:03 PM Martijn Coenen wrote:
>
> This allows userspace to completely setup a loop device with a single
> ioctl, removing the in-between state where the device can be partially
> configured - eg the loop device has a backing file associated with it,
> but is reading from the wrong offset.
>
> Besides removing the intermediate state, another big benefit of this
> ioctl is that LOOP_SET_STATUS can be slow; the main reason for this
> slowness is that LOOP_SET_STATUS(64) calls blk_mq_freeze_queue() to
> freeze the associated queue; this requires waiting for RCU
> synchronization, which I've measured can take about 15-20ms on this
> device on average.
>
> In addition to doing what LOOP_SET_STATUS can do, LOOP_CONFIGURE can
> also be used to:
> - Set the correct block size immediately by setting
> loop_config.block_size (avoids LOOP_SET_BLOCK_SIZE)
> - Explicitly request direct I/O mode by setting LO_FLAGS_DIRECT_IO
> in loop_config.info.lo_flags (avoids LOOP_SET_DIRECT_IO)
> - Explicitly request read-only mode by setting LO_FLAGS_READ_ONLY
> in loop_config.info.lo_flags
>
> Here's setting up ~70 regular loop devices with an offset on an x86
> Android device, using LOOP_SET_FD and LOOP_SET_STATUS:
>
> vsoc_x86:/system/apex # time for i in `seq 30 100`;
> do losetup -r -o 4096 /dev/block/loop$i com.android.adbd.apex; done
> 0m03.40s real 0m00.02s user 0m00.03s system
>
> Here's configuring ~70 devices in the same way, but using a modified
> losetup that uses the new LOOP_CONFIGURE ioctl:
>
> vsoc_x86:/system/apex # time for i in `seq 30 100`;
> do losetup -r -o 4096 /dev/block/loop$i com.android.adbd.apex; done
> 0m01.94s real 0m00.01s user 0m00.01s system
>
> Signed-off-by: Martijn Coenen
> ---
> drivers/block/loop.c | 107 +++---
> include/uapi/linux/loop.h | 21
> 2 files changed, 99 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index cfbdd99fdb1a..a353ce55fd18 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -241,6 +241,19 @@ loop_validate_size(loff_t size)
> return 0;
> }
>
> +/**
> + * loop_validate_block_size() - validates the passed in block size
> + * @bsize: size to validate
> + */
> +static int
> +loop_validate_block_size(unsigned short bsize)
> +{
> + if (bsize < 512 || bsize > PAGE_SIZE || !is_power_of_2(bsize))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> /**
> * loop_set_size() - sets device size and notifies userspace
> * @lo: struct loop_device to set the size for
> @@ -1063,23 +1076,24 @@ loop_set_status_from_info(struct loop_device *lo,
> return 0;
> }
>
> -static int loop_set_fd(struct loop_device *lo, fmode_t mode,
> - struct block_device *bdev, unsigned int arg)
> +static int loop_configure(struct loop_device *lo, fmode_t mode,
> + struct block_device *bdev,
> + const struct loop_config *config)
> {
> struct file *file;
> struct inode*inode;
> struct address_space *mapping;
> struct block_device *claimed_bdev = NULL;
> - int lo_flags = 0;
> int error;
> loff_t size;
> boolpartscan;
> + unsigned short bsize;
>
> /* This is safe, since we have a reference from open(). */
> __module_get(THIS_MODULE);
>
> error = -EBADF;
> - file = fget(arg);
> + file = fget(config->fd);
> if (!file)
> goto out;
>
> @@ -1088,7 +1102,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t
> mode,
> * here to avoid changing device under exclusive owner.
> */
> if (!(mode & FMODE_EXCL)) {
> - claimed_bdev = bd_start_claiming(bdev, loop_set_fd);
> + claimed_bdev = bd_start_claiming(bdev, loop_configure);
> if (IS_ERR(claimed_bdev)) {
> error = PTR_ERR(claimed_bdev);
> goto out_putf;
> @@ -1110,44 +1124,58 @@ static int loop_set_fd(struct loop_device *lo,
> fmode_t mode,
> mapping = file->f_mapping;
> inode = mapping->host;
>
> - if (!(file->f_mode & FMODE_WRITE) || !(mode & FMODE_WRITE) ||
> - !file->f_op->write_iter)
> - lo_flags |= LO_FLAGS_READ_ONLY;
> -
> size = get_loop_size(lo, file);
> error = loop_validate_size(size);
> if (error)
> goto out_unlock;
> +
> + if ((config->info.lo_flags & ~LOOP_CONFIGURE_SETTABLE_FLAGS) != 0) {
> + error = -EINVAL;
> + goto out_unlock;
> + }
> +
> + if (config->block_size) {
> + error = loop_validate_block_size(config->block_size);
> + if (error)
> +
Re: [PATCH v1 1/5] bus: mhi: core: Remove the system error worker thread
On Mon, May 11, 2020 at 07:03:05PM -0700, Hemant Kumar wrote:
> Remove the system error worker thread and instead have the
> execution environment worker handle that transition to serialize
> processing and avoid any possible race conditions during
> shutdown.
>
> Signed-off-by: Hemant Kumar
> Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> drivers/bus/mhi/core/init.c | 2 +-
> drivers/bus/mhi/core/internal.h | 3 ++-
> drivers/bus/mhi/core/main.c | 6 +++---
> drivers/bus/mhi/core/pm.c | 32 ++--
> include/linux/mhi.h | 2 --
> 5 files changed, 20 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 6882206..3a853c5 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -34,6 +34,7 @@
> [DEV_ST_TRANSITION_READY] = "READY",
> [DEV_ST_TRANSITION_SBL] = "SBL",
> [DEV_ST_TRANSITION_MISSION_MODE] = "MISSION_MODE",
> + [DEV_ST_TRANSITION_SYS_ERR] = "SYS_ERR",
> };
>
> const char * const mhi_state_str[MHI_STATE_MAX] = {
> @@ -834,7 +835,6 @@ int mhi_register_controller(struct mhi_controller
> *mhi_cntrl,
> spin_lock_init(&mhi_cntrl->transition_lock);
> spin_lock_init(&mhi_cntrl->wlock);
> INIT_WORK(&mhi_cntrl->st_worker, mhi_pm_st_worker);
> - INIT_WORK(&mhi_cntrl->syserr_worker, mhi_pm_sys_err_worker);
> init_waitqueue_head(&mhi_cntrl->state_event);
>
> mhi_cmd = mhi_cntrl->mhi_cmd;
> diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
> index 80b32c2..f01283b 100644
> --- a/drivers/bus/mhi/core/internal.h
> +++ b/drivers/bus/mhi/core/internal.h
> @@ -386,6 +386,7 @@ enum dev_st_transition {
> DEV_ST_TRANSITION_READY,
> DEV_ST_TRANSITION_SBL,
> DEV_ST_TRANSITION_MISSION_MODE,
> + DEV_ST_TRANSITION_SYS_ERR,
> DEV_ST_TRANSITION_MAX,
> };
>
> @@ -587,7 +588,7 @@ enum mhi_pm_state __must_check mhi_tryset_pm_state(
> int mhi_queue_state_transition(struct mhi_controller *mhi_cntrl,
> enum dev_st_transition state);
> void mhi_pm_st_worker(struct work_struct *work);
> -void mhi_pm_sys_err_worker(struct work_struct *work);
> +void mhi_pm_sys_err_handler(struct mhi_controller *mhi_cntrl);
> void mhi_fw_load_worker(struct work_struct *work);
> int mhi_ready_state_transition(struct mhi_controller *mhi_cntrl);
> void mhi_ctrl_ev_task(unsigned long data);
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 6a80666..9ec9b36 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -406,7 +406,7 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number,
> void *dev)
> if (MHI_IN_PBL(ee))
> mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_FATAL_ERROR);
> else
> - schedule_work(&mhi_cntrl->syserr_worker);
> + mhi_pm_sys_err_handler(mhi_cntrl);
> }
>
> exit_intvec:
> @@ -734,7 +734,7 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
> *mhi_cntrl,
> MHI_PM_SYS_ERR_DETECT);
> write_unlock_irq(&mhi_cntrl->pm_lock);
> if (new_state == MHI_PM_SYS_ERR_DETECT)
> -
> schedule_work(&mhi_cntrl->syserr_worker);
> + mhi_pm_sys_err_handler(mhi_cntrl);
> break;
> }
> default:
> @@ -920,7 +920,7 @@ void mhi_ctrl_ev_task(unsigned long data)
> }
> write_unlock_irq(&mhi_cntrl->pm_lock);
> if (pm_state == MHI_PM_SYS_ERR_DETECT)
> - schedule_work(&mhi_cntrl->syserr_worker);
> + mhi_pm_sys_err_handler(mhi_cntrl);
> }
> }
>
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 3cc238a..d9964d4 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -449,19 +449,8 @@ static void mhi_pm_disable_transition(struct
> mhi_controller *mhi_cntrl,
> to_mhi_pm_state_str(transition_state));
>
> /* We must notify MHI control driver so it can clean up first */
> - if (transition_state == MHI_PM_SYS_ERR_PROCESS) {
> - /*
> - * If controller supports RDDM, we do not process
> - * SYS error state, instead we will jump directly
> - * to RDDM state
> - */
> - if (mhi_cntrl->rddm_image) {
> - dev_dbg(dev,
> - "Controller supports RDDM, so skip SYS_ERR\n");
> - return;
> - }
> + if (transition_state == MHI_PM_SYS_ERR_PROCESS)
> mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_SYS_ERROR);
> - }
>
>
Re: [PATCH 3/3] ALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295
On Tue, 12 May 2020 08:15:28 +0200, Jian-Hong Pan wrote: > > The ASUS UX581LV laptop's audio (1043:19e1) with ALC295 can't detect the > headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk > applied. > > Signed-off-by: Jian-Hong Pan Applied, thanks. Takashi
Re: [PATCH 1/3] ALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295
On Tue, 12 May 2020 08:15:24 +0200, Jian-Hong Pan wrote: > > From: Chris Chiu > > The ASUS laptop GL503VM with ALC295 can't detect the headset microphone. > The headset microphone does not work until pin 0x19 is enabled for it. > > Signed-off-by: Chris Chiu > Signed-off-by: Daniel Drake > Signed-off-by: Jian-Hong Pan Applied, thanks. Takashi
Re: [PATCH 2/3] ALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295
On Tue, 12 May 2020 08:15:26 +0200, Jian-Hong Pan wrote: > > The ASUS laptop UX550GE with ALC295 can't detect the headset microphone > until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied. > > Signed-off-by: Jian-Hong Pan > Signed-off-by: Daniel Drake Applied, thanks. Takashi
RE: [PATCH v7 3/7] i3c: master: add i3c_secondary_master_register
>Can you really select the bus mode without knowing the I3C devices you >have on the bus? Or maybe that's a preliminary initialization which is >then updated when you receive DEFSLVS events. I think we can select bus mode based on knowledge of I2C devices on the bus. I was expecting to support different I2C devices information on main master and secondary masters. But that seems problematic for mastership requests. As IMO for mastership acquire and yield to work, all master capable devices should be operating in same bus mode. In previous patch set I tried approach of all devices using same (Pure) bus mode during initialization and updating it on DEFSLVS reception. But this can cause issue for hot joining devices as current master would have already switched it's bus mode to something other than pure mode, and hot join would not work. To me it's seems for mastership handover to work, we need all masters to have complete I2C device list on the bus. >I suspect you'll have to request bus ownership first, which means >they're not really usable, just registered to the I2C subsystem. This >might lead to a whole bunch of problems when drivers will try to send >messages to the I2C devices and receive ETIMEDOUT/EBUSY errors. We'll >probably need some updates to the I2C framework if we want I2C to play >nicely with bus handover, but I think we can keep that for later. I'd >suggest to forget about I2C for now and mark that as a limitation (no >I2C devs on secondary masters). Correct, here I2C devices are just registered. Irrespective of the device type (I2C/I3C) to which master want to communicate with, bus has to be acquired. Regards, Parshuram Thombare
[PATCH] mm, swap: Use prandom_u32_max()
To improve the code readability and get random number with higher quality. Signed-off-by: "Huang, Ying" Cc: Michal Hocko Cc: Minchan Kim Cc: Tim Chen Cc: Hugh Dickins --- mm/swapfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index a0a123e59ce6..2ec8b21201d6 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -3220,7 +3220,7 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags) * select a random position to start with to help wear leveling * SSD */ - p->cluster_next = 1 + (prandom_u32() % p->highest_bit); + p->cluster_next = 1 + prandom_u32_max(p->highest_bit); nr_cluster = DIV_ROUND_UP(maxpages, SWAPFILE_CLUSTER); cluster_info = kvcalloc(nr_cluster, sizeof(*cluster_info), -- 2.26.2
[PATCH] devfreq: Use lockdep asserts instead of manual checks for locked mutex
Instead of warning when mutex_is_locked(), just use the lockdep
framework. The code is smaller and checks could be disabled for
production environments (it is useful only during development).
Put asserts at beginning of function, even before validating arguments.
The behavior of update_devfreq() is now changed because lockdep assert
will only print a warning, not return with EINVAL.
Signed-off-by: Krzysztof Kozlowski
---
drivers/devfreq/devfreq.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index ef3d2bc3d1ac..52b9c3e141f3 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -60,12 +60,12 @@ static struct devfreq *find_device_devfreq(struct device
*dev)
{
struct devfreq *tmp_devfreq;
+ lockdep_assert_held(&devfreq_list_lock);
+
if (IS_ERR_OR_NULL(dev)) {
pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
return ERR_PTR(-EINVAL);
}
- WARN(!mutex_is_locked(&devfreq_list_lock),
-"devfreq_list_lock must be locked.");
list_for_each_entry(tmp_devfreq, &devfreq_list, node) {
if (tmp_devfreq->dev.parent == dev)
@@ -258,12 +258,12 @@ static struct devfreq_governor
*find_devfreq_governor(const char *name)
{
struct devfreq_governor *tmp_governor;
+ lockdep_assert_held(&devfreq_list_lock);
+
if (IS_ERR_OR_NULL(name)) {
pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
return ERR_PTR(-EINVAL);
}
- WARN(!mutex_is_locked(&devfreq_list_lock),
-"devfreq_list_lock must be locked.");
list_for_each_entry(tmp_governor, &devfreq_governor_list, node) {
if (!strncmp(tmp_governor->name, name, DEVFREQ_NAME_LEN))
@@ -289,12 +289,12 @@ static struct devfreq_governor
*try_then_request_governor(const char *name)
struct devfreq_governor *governor;
int err = 0;
+ lockdep_assert_held(&devfreq_list_lock);
+
if (IS_ERR_OR_NULL(name)) {
pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
return ERR_PTR(-EINVAL);
}
- WARN(!mutex_is_locked(&devfreq_list_lock),
-"devfreq_list_lock must be locked.");
governor = find_devfreq_governor(name);
if (IS_ERR(governor)) {
@@ -392,10 +392,7 @@ int update_devfreq(struct devfreq *devfreq)
int err = 0;
u32 flags = 0;
- if (!mutex_is_locked(&devfreq->lock)) {
- WARN(true, "devfreq->lock must be locked by the caller.\n");
- return -EINVAL;
- }
+ lockdep_assert_held(&devfreq->lock);
if (!devfreq->governor)
return -EINVAL;
--
2.17.1
[PATCH rdma-next 0/2] Fix kasan compilation warnings
From: Leon Romanovsky Hi, The following two fixes are adding missing function prototypes declarations to internal kasan header in order to eliminate compilation warnings. Thanks Leon Romanovsky (2): kasan: fix compilation warnings due to missing function prototypes kasan: add missing prototypes to fix compilation warnings mm/kasan/common.c | 3 --- mm/kasan/kasan.h | 15 +++ 2 files changed, 15 insertions(+), 3 deletions(-) -- 2.26.2
Re: [PATCH v2] usb: raw-gadget: fix gadget endpoint selection
Greg Kroah-Hartman writes: > On Sat, May 09, 2020 at 11:02:13AM +0300, Felipe Balbi wrote: >> >> Hi, >> >> Andrey Konovalov writes: >> >> here you're changing userspace ABI. Aren't we going to possibly break >> >> some existing applications? >> > >> > Hi Felipe, >> > >> > I've been working on tests for Raw Gadget for the last few weeks [1], >> > which revealed a few problems with the interface. This isn't yet >> > included into any released kernel, so my hope that changing the ABI is >> > OK during the rc stage. >> >> Fair enough. If that's okay with Greg, it's okay with me, but then how >> do we include it into the -rc seen as it's not really a fix? >> >> Greg, are you okay with me including such large patches during the -rc? >> They essentially add new IOCTLs to the raw-gadget interface. > > Yes, as the driver only went in for -rc1, it's fine to add fixes like > this so late as we don't want to ship a -final with it in broken form. Thanks, I'll prepare a pull request containing it. cheers -- balbi signature.asc Description: PGP signature
[PATCH rdma-next 2/2] kasan: add missing prototypes to fix compilation warnings
From: Leon Romanovsky
Use internal kasan header to declare missing prototypes to fix the
following compilation warnings.
mm/kasan/report.c:457:6: warning: no previous prototype for 'report_enabled'
[-Wmissing-prototypes]
457 | bool report_enabled(void)
| ^~
mm/kasan/report.c:482:6: warning: no previous prototype for '__kasan_report'
[-Wmissing-prototypes]
482 | void __kasan_report(unsigned long addr, size_t size, bool is_write,
unsigned long ip)
| ^~
Fixes: 57b78a62e7f2 ("x86/uaccess, kasan: Fix KASAN vs SMAP")
Signed-off-by: Leon Romanovsky
---
mm/kasan/common.c | 3 ---
mm/kasan/kasan.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2906358e42f0..cbb119224330 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -613,9 +613,6 @@ void kasan_free_shadow(const struct vm_struct *vm)
}
#endif
-extern void __kasan_report(unsigned long addr, size_t size, bool is_write,
unsigned long ip);
-extern bool report_enabled(void);
-
bool kasan_report(unsigned long addr, size_t size, bool is_write, unsigned
long ip)
{
unsigned long flags = user_access_save();
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index d428e588c700..02d54a1d0b2d 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -153,6 +153,9 @@ bool check_memory_region(unsigned long addr, size_t size,
bool write,
void *find_first_bad_addr(void *addr, size_t size);
const char *get_bug_type(struct kasan_access_info *info);
+bool report_enabled(void);
+void __kasan_report(unsigned long addr, size_t size, bool is_write,
+ unsigned long ip);
bool kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip);
void kasan_report_invalid_free(void *object, unsigned long ip);
--
2.26.2
Re: MAINTAINERS: Wrong ordering in VIRTIO BALLOON
On 12.05.20 07:21, Lukas Bulwahn wrote:
> Hi David,
>
> with your commit 6d6b93b9afd8 ("MAINTAINERS: Add myself as virtio-balloon
> co-maintainer"), visible on next-20200508, ./scripts/checkpatch.pl -f
> MAINTAINERS complains:
>
> WARNING: Misordered MAINTAINERS entry - list file patterns in alphabetic order
> #17982: FILE: MAINTAINERS:17982:
> +F: include/uapi/linux/virtio_balloon.h
> +F: include/linux/balloon_compaction.h
>
> This is due to wrong ordering of the entries in your submission. If you
> would like me to send you a patch fixing that, please just let me know.
>
> It is a recent addition to checkpatch.pl to report ordering problems in
> MAINTAINERS, so you might have not seen that at submission time.
Thanks for the notification Lukas,
b962ee8622d0 ("checkpatch: additional MAINTAINER section entry ordering
checks") is not in Linus' tree yet AFAIKS.
I can see that 3b50142d8528 ("MAINTAINERS: sort field names for all
entries") is upstream. I do wonder if we should just do another batch
update after the checkpatch patch is upstream instead, I guess more will
pile up?
@mst, joe, what do you prefer?
1. I can resend the original patch.
2. Lukas can send a fixup that we might want to squash.
3. We wait until the checkpatch change goes upstream and to a final
batch update.
--
Thanks,
David / dhildenb
Re: [PATCH v2 0/3] arm64: perf_event: Fix time offset prior to epoch
Hi Peter,
On Mon, May 11, 2020 at 11:25:19AM +0200, Peter Zijlstra wrote:
> On Mon, May 11, 2020 at 11:22:00AM +0200, Peter Zijlstra wrote:
>
> > (_completely_ untested)
> >
> > ---
> > arch/arm64/kernel/perf_event.c | 27 ++-
> > include/linux/sched_clock.h| 28
> > kernel/time/sched_clock.c | 41
> > +
> > 3 files changed, 59 insertions(+), 37 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> > index 4d7879484cec..81a49a916660 100644
> > --- a/arch/arm64/kernel/perf_event.c
> > +++ b/arch/arm64/kernel/perf_event.c
> > @@ -1165,28 +1165,37 @@ device_initcall(armv8_pmu_driver_init)
> > void arch_perf_update_userpage(struct perf_event *event,
> >struct perf_event_mmap_page *userpg, u64 now)
> > {
> > - u32 freq;
> > - u32 shift;
> > + struct clock_read_data *rd;
> > + unsigned int seq;
> >
> > /*
> > * Internal timekeeping for enabled/running/stopped times
> > * is always computed with the sched_clock.
> > */
> > - freq = arch_timer_get_rate();
> > userpg->cap_user_time = 1;
> > + userpg->cap_user_time_zero = 1;
> > +
> > + do {
> > + rd = sched_clock_read_begin(&seq);
> > +
> > + userpg->time_mult = rd->mult;
> > + userpg->time_shift = rd->shift;
> > + userpg->time_offset = rd->epoch_ns;
>
> ^^^ wants to be time_zero
>
> > +
> > + userpg->time_zero -= (rd->epoch_cyc * rd->shift) >> rd->shift;
> > +
> > + } while (sched_clock_read_retry(seq));
> > +
> > + userpg->time_offset = userpf->time_zero - now;
> >
> > - clocks_calc_mult_shift(&userpg->time_mult, &shift, freq,
> > - NSEC_PER_SEC, 0);
>
> And that ^^^ was complete crap.
>
> > /*
> > * time_shift is not expected to be greater than 31 due to
> > * the original published conversion algorithm shifting a
> > * 32-bit value (now specifies a 64-bit value) - refer
> > * perf_event_mmap_page documentation in perf_event.h.
> > */
> > - if (shift == 32) {
> > - shift = 31;
> > + if (userpg->time_shift == 32) {
> > + userpg->time_shift = 31;
> > userpg->time_mult >>= 1;
> > }
> > - userpg->time_shift = (u16)shift;
> > - userpg->time_offset = -now;
> > }
I have verified this change, it works as expected on my Arm64 board.
Also paste the updated code which makes building success with minor
fixing.
I am not sure how to proceed, will you merge this? Or you want me to
send out formal patches (or only for the Arm64 part)?
P.s. it's shame I still missed you guys suggestion in prvious thread
even though you have provide enough ifno, and thank you for the helping!
---8<---
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 4d7879484cec..5a34e9264c5b 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
/* ARMv8 Cortex-A53 specific event types. */
@@ -1165,28 +1166,26 @@ device_initcall(armv8_pmu_driver_init)
void arch_perf_update_userpage(struct perf_event *event,
struct perf_event_mmap_page *userpg, u64 now)
{
- u32 freq;
- u32 shift;
+ struct clock_read_data *rd;
+ unsigned int seq;
/*
* Internal timekeeping for enabled/running/stopped times
* is always computed with the sched_clock.
*/
- freq = arch_timer_get_rate();
userpg->cap_user_time = 1;
+ userpg->cap_user_time_zero = 1;
- clocks_calc_mult_shift(&userpg->time_mult, &shift, freq,
- NSEC_PER_SEC, 0);
- /*
-* time_shift is not expected to be greater than 31 due to
-* the original published conversion algorithm shifting a
-* 32-bit value (now specifies a 64-bit value) - refer
-* perf_event_mmap_page documentation in perf_event.h.
-*/
- if (shift == 32) {
- shift = 31;
- userpg->time_mult >>= 1;
- }
- userpg->time_shift = (u16)shift;
- userpg->time_offset = -now;
+ do {
+ rd = sched_clock_read_begin(&seq);
+
+ userpg->time_mult = rd->mult;
+ userpg->time_shift = rd->shift;
+ userpg->time_zero = rd->epoch_ns;
+
+ userpg->time_zero -= (rd->epoch_cyc * rd->mult) >> rd->shift;
+
+ } while (sched_clock_read_retry(seq));
+
+ userpg->time_offset = userpg->time_zero - now;
}
diff --git a/include/linux/sched_clock.h b/include/linux/sched_clock.h
index 0bb04a96a6d4..528718e4ed52 100644
--- a/include/linux/sched_clock.h
+++ b/include/linux/sched_clock.h
@@ -6,6 +6,34 @@
#define LINUX_SCHED_CLOCK
#ifdef CONFIG_GENERIC_SCHED_CLOCK
+/**
+ * struct clock_read_data -
Re: net/sonic: Fix some resource leaks in error handling paths
> Markus, if you were to write a patch to improve upon coding-style.rst, > who should review it? All involved contributors have got chances to provide constructive comments. I would be curious who will actually dare to contribute further ideas for this area. > If you are unable to write or review such a patch, how can you hope to > adjudicate compliance? I can also try to achieve more improvements here to see how the available software documentation will evolve. Regards, Markus
[PATCH rdma-next 1/2] kasan: fix compilation warnings due to missing function prototypes
From: Leon Romanovsky
__asan_report_* function generates the following warnings while compiling
kernel, add them to the internal header to be aligned with other __asan_*
function prototypes.
mm/kasan/generic_report.c:130:6: warning: no previous prototype for
'__asan_report_load1_noabort' [-Wmissing-prototypes]
130 | void __asan_report_load##size##_noabort(unsigned long addr) \
| ^~
mm/kasan/generic_report.c:143:1: note: in expansion of macro
'DEFINE_ASAN_REPORT_LOAD'
143 | DEFINE_ASAN_REPORT_LOAD(1);
| ^~~
<...>
mm/kasan/generic_report.c:137:6: warning: no previous prototype for
'__asan_report_store1_noabort' [-Wmissing-prototypes]
137 | void __asan_report_store##size##_noabort(unsigned long addr) \
| ^~~
mm/kasan/generic_report.c:148:1: note: in expansion of macro
'DEFINE_ASAN_REPORT_STORE'
148 | DEFINE_ASAN_REPORT_STORE(1);
| ^~~~
Fixes: 0b24becc810d ("kasan: add kernel address sanitizer infrastructure")
Signed-off-by: Leon Romanovsky
---
mm/kasan/kasan.h | 12
1 file changed, 12 insertions(+)
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index e8f37199d885..d428e588c700 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -230,15 +230,27 @@ void __asan_load16(unsigned long addr);
void __asan_store16(unsigned long addr);
void __asan_load1_noabort(unsigned long addr);
+void __asan_report_load1_noabort(unsigned long addr);
void __asan_store1_noabort(unsigned long addr);
+void __asan_report_store1_noabort(unsigned long addr);
void __asan_load2_noabort(unsigned long addr);
+void __asan_report_load2_noabort(unsigned long addr);
void __asan_store2_noabort(unsigned long addr);
+void __asan_report_store2_noabort(unsigned long addr);
void __asan_load4_noabort(unsigned long addr);
+void __asan_report_load4_noabort(unsigned long addr);
void __asan_store4_noabort(unsigned long addr);
+void __asan_report_store4_noabort(unsigned long addr);
void __asan_load8_noabort(unsigned long addr);
+void __asan_report_load8_noabort(unsigned long addr);
void __asan_store8_noabort(unsigned long addr);
+void __asan_report_store8_noabort(unsigned long addr);
void __asan_load16_noabort(unsigned long addr);
+void __asan_report_load16_noabort(unsigned long addr);
void __asan_store16_noabort(unsigned long addr);
+void __asan_report_store16_noabort(unsigned long addr);
+void __asan_report_load_n_noabort(unsigned long addr, size_t size);
+void __asan_report_store_n_noabort(unsigned long addr, size_t size);
void __asan_set_shadow_00(const void *addr, size_t size);
void __asan_set_shadow_f1(const void *addr, size_t size);
--
2.26.2
Re: [PATCH v2 09/14] net: ethernet: mtk-eth-mac: new driver
pon., 11 maj 2020 o 21:24 Florian Fainelli napisał(a):
>
>
>
> On 5/11/2020 8:07 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> > family. For now we only support full-duplex.
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
>
> [snip]
>
> > +static int mtk_mac_ring_pop_tail(struct mtk_mac_ring *ring,
> > + struct mtk_mac_ring_desc_data *desc_data)
> > +{
> > + struct mtk_mac_ring_desc *desc = &ring->descs[ring->tail];
> > + unsigned int status;
> > +
> > + /* Let the device release the descriptor. */
> > + dma_rmb();
> > + status = desc->status;
> > +
> > + if (!(status & MTK_MAC_DESC_BIT_COWN))
> > + return -1;
> > +
> > + desc_data->len = status & MTK_MAC_DESC_MSK_LEN;
> > + desc_data->flags = status & ~MTK_MAC_DESC_MSK_LEN;
> > + desc_data->dma_addr = desc->data_ptr;
> > + desc_data->skb = ring->skbs[ring->tail];
> > +
> > + desc->data_ptr = 0;
> > + desc->status = MTK_MAC_DESC_BIT_COWN;
> > + if (status & MTK_MAC_DESC_BIT_EOR)
> > + desc->status |= MTK_MAC_DESC_BIT_EOR;
>
> Don't you need a dma_wmb() for the device to observe the new descriptor
> here?
>
HW has released the descriptor (set the COWN bit) and I just clear all
other bits here really. Yeah, I guess it won't hurt to make sure.
> [snip]
>
> > +static void mtk_mac_dma_unmap_tx(struct mtk_mac_priv *priv,
> > + struct mtk_mac_ring_desc_data *desc_data)
> > +{
> > + struct device *dev = mtk_mac_get_dev(priv);
> > +
> > + return dma_unmap_single(dev, desc_data->dma_addr,
> > + desc_data->len, DMA_TO_DEVICE);
>
> If you stored a pointer to the sk_buff you transmitted, then you would
> need an expensive read to the descriptor to determine the address and
> length, and you would also not be at the mercy of the HW putting
> incorrect values there.
>
You mean store the mapped addresses? Yeah I can do that but I'll still
need to read the descriptor memory to verify it was released by HW.
> sp
> > +static void mtk_mac_dma_init(struct mtk_mac_priv *priv)
> > +{
> > + struct mtk_mac_ring_desc *desc;
> > + unsigned int val;
> > + int i;
> > +
> > + priv->descs_base = (struct mtk_mac_ring_desc *)priv->ring_base;
> > +
> > + for (i = 0; i < MTK_MAC_NUM_DESCS_TOTAL; i++) {
> > + desc = &priv->descs_base[i];
> > +
> > + memset(desc, 0, sizeof(*desc));
> > + desc->status = MTK_MAC_DESC_BIT_COWN;
> > + if ((i == MTK_MAC_NUM_TX_DESCS - 1) ||
> > + (i == MTK_MAC_NUM_DESCS_TOTAL - 1))
> > + desc->status |= MTK_MAC_DESC_BIT_EOR;
> > + }
> > +
> > + mtk_mac_ring_init(&priv->tx_ring, priv->descs_base, 0);
> > + mtk_mac_ring_init(&priv->rx_ring,
> > + priv->descs_base + MTK_MAC_NUM_TX_DESCS,
> > + MTK_MAC_NUM_RX_DESCS);
> > +
> > + /* Set DMA pointers. */
> > + val = (unsigned int)priv->dma_addr;
>
> You would probably add a WARN_ON() or something that catches the upper
> 32-bits of the dma_addr being set, see my comment about the DMA mask
> setting.
>
Can it still happen if I check the return value of dma_set_mask_and_coherent()?
> [snip]
>
> > +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> > +{
> > + struct net_device *ndev = priv_to_netdev(priv);
> > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > + int ret;
> > +
> > + for (;;) {
> > + mtk_mac_lock(priv);
> > +
> > + if (!mtk_mac_ring_descs_available(ring)) {
> > + mtk_mac_unlock(priv);
> > + break;
> > + }
> > +
> > + ret = mtk_mac_tx_complete_one(priv);
> > + if (ret) {
> > + mtk_mac_unlock(priv);
> > + break;
> > + }
> > +
> > + if (netif_queue_stopped(ndev))
> > + netif_wake_queue(ndev);
> > +
> > + mtk_mac_unlock(priv);
> > + }
>
> Where do you increment the net_device statistics to indicate the bytes
> and packets transmitted?
>
I don't. I use the counters provided by HW for that.
> [snip]
>
> > + mtk_mac_set_mode_rmii(priv);
> > +
> > + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
>
> Your code assumes that DMA addresses are not going to be >= 4GB so you
> should be checking this function's return code and abort here otherwise
> your driver will fail in surprisingly difficult ways to debug.
Sure, thanks.
Bart
[PATCH] scsi: hisi_sas: display correct proc_name in sysfs
The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase it is
not initialized in scsi_host_template. It looks like:
[root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name
(null)
While the other driver's entry looks like:
linux-vnMQMU:~ # cat /sys/class/scsi_host/host0/proc_name
megaraid_sas
Cc: John Garry
Cc: Xiang Chen
Signed-off-by: Jason Yan
---
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 1 +
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 1 +
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index fa25766502a2..c205bff20943 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1757,6 +1757,7 @@ static struct device_attribute *host_attrs_v1_hw[] = {
static struct scsi_host_template sht_v1_hw = {
.name = DRV_NAME,
+ .proc_name = DRV_NAME,
.module = THIS_MODULE,
.queuecommand = sas_queuecommand,
.target_alloc = sas_target_alloc,
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index e05faf315dcd..c725cffe141e 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -3533,6 +3533,7 @@ static struct device_attribute *host_attrs_v2_hw[] = {
static struct scsi_host_template sht_v2_hw = {
.name = DRV_NAME,
+ .proc_name = DRV_NAME,
.module = THIS_MODULE,
.queuecommand = sas_queuecommand,
.target_alloc = sas_target_alloc,
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 374885aa8d77..59b1421607dd 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -3071,6 +3071,7 @@ static int debugfs_set_bist_v3_hw(struct hisi_hba
*hisi_hba, bool enable)
static struct scsi_host_template sht_v3_hw = {
.name = DRV_NAME,
+ .proc_name = DRV_NAME,
.module = THIS_MODULE,
.queuecommand = sas_queuecommand,
.target_alloc = sas_target_alloc,
--
2.21.3
Re: [PATCH] ASoC: rsnd: add interrupt support for SSI BUSIF buffer
Hi Yongbo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v5.7-rc4 next-20200508]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Yongbo-Zhang/ASoC-rsnd-add-interrupt-support-for-SSI-BUSIF-buffer/20200509-035713
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
for-next
:: branch date: 6 hours ago
:: commit date: 6 hours ago
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
cppcheck warnings: (new ones prefixed by >>)
>> sound/soc/sh/rcar/ssi.c:531:1: warning: Unmatched '{'. Configuration: ''.
>> [syntaxError]
{
^
>> sound/soc/sh/rcar/ssi.c:531:1: warning: Unmatched '{'. Configuration:
>> 'DEBUG'. [syntaxError]
{
^
#
https://github.com/0day-ci/linux/commit/391d452251464b78f72ba3a1fd9b6091b3d4a942
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 391d452251464b78f72ba3a1fd9b6091b3d4a942
vim +531 sound/soc/sh/rcar/ssi.c
ae5c322303fff5 Kuninori Morimoto 2013-07-21 527
ae5c322303fff5 Kuninori Morimoto 2013-07-21 528 static int
rsnd_ssi_quit(struct rsnd_mod *mod,
2c0fac19de2cd7 Kuninori Morimoto 2015-06-15 529 struct
rsnd_dai_stream *io,
690602fcd85385 Kuninori Morimoto 2015-01-15 530 struct
rsnd_priv *priv)
ae5c322303fff5 Kuninori Morimoto 2013-07-21 @531 {
ae5c322303fff5 Kuninori Morimoto 2013-07-21 532struct rsnd_ssi *ssi =
rsnd_mod_to_ssi(mod);
ae5c322303fff5 Kuninori Morimoto 2013-07-21 533struct device *dev =
rsnd_priv_to_dev(priv);
391d452251464b Yongbo Zhang 2020-05-08 534int is_tdm,
is_tdm_split;
391d452251464b Yongbo Zhang 2020-05-08 535int id =
rsnd_mod_id(mod);
391d452251464b Yongbo Zhang 2020-05-08 536int i;
391d452251464b Yongbo Zhang 2020-05-08 537u32 sys_int_enable = 0;
391d452251464b Yongbo Zhang 2020-05-08 538
391d452251464b Yongbo Zhang 2020-05-08 539is_tdm =
rsnd_runtime_is_tdm(io);
391d452251464b Yongbo Zhang 2020-05-08 540is_tdm_split=
rsnd_runtime_is_tdm_split(io);
ae5c322303fff5 Kuninori Morimoto 2013-07-21 541
fd9adcfdc1434f Kuninori Morimoto 2016-02-18 542if
(!rsnd_ssi_is_run_mods(mod, io))
fd9adcfdc1434f Kuninori Morimoto 2016-02-18 543return 0;
fd9adcfdc1434f Kuninori Morimoto 2016-02-18 544
e5d9cfc6f5fe56 Andrzej Hajda 2015-12-24 545if (!ssi->usrcnt) {
c0ea089dbad47a Kuninori Morimoto 2018-10-30 546dev_err(dev,
"%s usrcnt error\n", rsnd_mod_name(mod));
e5d9cfc6f5fe56 Andrzej Hajda 2015-12-24 547return -EIO;
e5d9cfc6f5fe56 Andrzej Hajda 2015-12-24 548}
e7d850dd10f4e6 Kuninori Morimoto 2015-10-26 549
26d34b11af6a34 Kuninori Morimoto 2016-02-18 550
rsnd_ssi_master_clk_stop(mod, io);
e7d850dd10f4e6 Kuninori Morimoto 2015-10-26 551
e7d850dd10f4e6 Kuninori Morimoto 2015-10-26 552rsnd_mod_power_off(mod);
e7d850dd10f4e6 Kuninori Morimoto 2015-10-26 553
e7d850dd10f4e6 Kuninori Morimoto 2015-10-26 554ssi->usrcnt--;
e7d850dd10f4e6 Kuninori Morimoto 2015-10-26 555
203cdf51f28820 Kuninori Morimoto 2018-06-12 556if (!ssi->usrcnt) {
203cdf51f28820 Kuninori Morimoto 2018-06-12 557ssi->cr_own
= 0;
203cdf51f28820 Kuninori Morimoto 2018-06-12 558ssi->cr_mode
= 0;
203cdf51f28820 Kuninori Morimoto 2018-06-12 559ssi->wsr
= 0;
203cdf51f28820 Kuninori Morimoto 2018-06-12 560}
203cdf51f28820 Kuninori Morimoto 2018-06-12 561
391d452251464b Yongbo Zhang 2020-05-08 562/* disable busif buffer
over/under run interrupt. */
391d452251464b Yongbo Zhang 2020-05-08 563if (is_tdm ||
is_tdm_split) {
391d452251464b Yongbo Zhang 2020-05-08 564switch (id) {
391d452251464b Yongbo Zhang 2020-05-08 565case 0:
391d452251464b Yongbo Zhang 2020-05-08 566case 1:
391d452251464b Yongbo Zhang 2020-05-08 567case 2:
391d452251464b Yongbo Zhang 2020-05-08 568case 3:
391d452251464b Yongbo Zhang 2020-05-08 569case 4:
391d452251464b Yongbo Zhang 2020-05-08 570for (i
= 0; i < 4; i++) {
391d452251464b Yongbo Zhang 2020-05-08 571
sys_int_enable = rsnd_mod_read(mod,
391d452251464b Yongbo Zhang 2020-05-08 572
SSI_SYS_INT_ENABLE(i * 2));
391d452251464b Yongbo Zhang 2020-05-08 573
RE: [EXT] Re: [PATCH v1 net-next 3/3] net: dsa: felix: add support Credit Based Shaper(CBS) for hardware offload
Hi Jakub, On Mon, 11 May 2020 22:34:32 Jakub Kicinski wrote: > > +int vsc9959_qos_port_cbs_set(struct dsa_switch *ds, int port, > > + struct tc_cbs_qopt_offload *cbs_qopt) > > static I will update this in v2, thanks. Regards, Xiaoliang Yang
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Mon, 2020-05-11 at 21:56 +0200, Lars-Peter Clausen wrote: > [External] > > On 5/11/20 4:56 PM, Ardelean, Alexandru wrote: > > On Mon, 2020-05-11 at 15:58 +0200, Lars-Peter Clausen wrote: > > > [External] > > > > > > On 5/11/20 3:24 PM, Ardelean, Alexandru wrote: > > > > On Mon, 2020-05-11 at 13:03 +, Ardelean, Alexandru wrote: > > > > > [External] > > > > > > > > > > On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote: > > > > > > [External] > > > > > > > > > > > > On 5/11/20 12:33 PM, Ardelean, Alexandru wrote: > > > > > > > On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote: > > > > > > > > [External] > > > > > > > > > > > > > > > > On Sat, 9 May 2020 10:52:14 +0200 > > > > > > > > Lars-Peter Clausen wrote: > > > > > > > > > > > > > > > > > On 5/8/20 3:53 PM, Alexandru Ardelean wrote: > > > > > > > > > > [...] > > > > > > > > > > What I don't like, is that iio:device3 has iio:buffer3:0 (to > > > > > > > > > > 3). > > > > > > > > > > This is because the 'buffer->dev.parent = &indio_dev->dev'. > > > > > > > > > > But I do feel this is correct. > > > > > > > > > > So, now I don't know whether to leave it like that or > > > > > > > > > > symlink to > > > > > > > > > > shorter > > > > > > > > > > versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'. > > > > > > > > > > The reason for naming the IIO buffer devices to > > > > > > > > > > 'iio:bufferX:Y' > > > > > > > > > > is > > > > > > > > > > mostly to make the names unique. It would have looked weird > > > > > > > > > > to > > > > > > > > > > do > > > > > > > > > > '/dev/buffer1' if I would have named the buffer devices > > > > > > > > > > 'bufferX'. > > > > > > > > > > > > > > > > > > > > So, now I'm thinking of whether all this is acceptable. > > > > > > > > > > Or what is acceptable? > > > > > > > > > > Should I symlink 'iio:device3/iio:buffer3:0' -> > > > > > > > > > > 'iio:device3/buffer0'? > > > > > > > > > > What else should I consider moving forward? > > > > > > > > > > What means forward? > > > > > > > > > > Where did I leave my beer? > > > > > > > > > Looking at how the /dev/ devices are named I think we can > > > > > > > > > provide > > > > > > > > > a > > > > > > > > > name > > > > > > > > > that is different from the dev_name() of the device. Have a > > > > > > > > > look > > > > > > > > > at > > > > > > > > > device_get_devnode() in drivers/base/core.c. We should be able > > > > > > > > > to > > > > > > > > > provide the name for the chardev through the devnode() > > > > > > > > > callback. > > > > > > > > > > > > > > > > > > While we are at this, do we want to move the new devices into > > > > > > > > > an > > > > > > > > > iio > > > > > > > > > subfolder? So iio/buffer0:0 instead of iio:buffer0:0? > > > > > > > > Possibly on the folder. I can't for the life of me remember why > > > > > > > > I > > > > > > > > decided > > > > > > > > not to do that the first time around - I'll leave it at the > > > > > > > > mysterious "it may turn out to be harder than you'd think..." > > > > > > > > Hopefully not ;) > > > > > > > I was also thinking about the /dev/iio subfolder while doing this. > > > > > > > I can copy that from /dev/input > > > > > > > They seem to do it already. > > > > > > > I don't know how difficult it would be. But it looks like a good > > > > > > > precedent. > > > > > > All you have to do is return "iio/..." from the devnode() callback. > > > > > I admit I did not look closely into drivers/input/input.c before > > > > > mentioning > > > > > this > > > > > as as good precedent. > > > > > > > > > > But, I looks like /dev/inpput is a class. > > > > > While IIO devices are a bus_type devices. > > > > > Should we start implementing an IIO class? or? > > > > What I should have highlighted [before] with this, is that there is no > > > > devnode() > > > > callback for the bus_type [type]. > > > But there is one in device_type :) > > Many thanks :) > > That worked nicely. > > > > I now have: > > > > root@analog:~# ls /dev/iio/* > > /dev/iio/iio:device0 /dev/iio/iio:device1 > > > > /dev/iio/device3: > > buffer0 buffer1 buffer2 buffer3 > > > > /dev/iio/device4: > > buffer0 > > > > > > It looks like I can shift these around as needed. > > This is just an experiment. > > I managed to move the iio devices under /dev/iio, though probably the IIO > > devices will still be around as /dev/iio:deviceX for legacy reasons. > > > > Two things remain unresolved. > > 1. The name of the IIO buffer device. > > > > root@analog:/sys/bus/iio/devices# ls iio\:device3/ > > buffer in_voltage0_test_mode name > > events in_voltage1_test_mode of_node > > iio:buffer:3:0 in_voltage_sampling_frequency power > > iio:buffer:3:1 in_voltage_scalescan_elements > > iio:buffer:3:2 in_voltage_scale_available subsystem > > iio:buffer:3:3 in_voltage_test_mode_available uevent > > > > > > Right now, each buffer device is named 'iio:buffer:X:Y'. > > One suggesttion wa
Re: [RFC PATCH v2 1/7] block: Extand commit_rqs() to do batch processing
devices will benefit from the batching so maybe the flag needs to be inverted? BLK_MQ_F_DONT_BATCHING_SUBMISSION? Actually I'd rather to not add any flag, and we may use some algorithm (maybe EWMA or other intelligent stuff, or use hctx->dispatch_busy directly) to figure out one dynamic batching number which is used to dequeue requests from scheduler or sw queue. Then just one single dispatch io code path is enough. Sounds good to me, do you plan to submit a patchset?
RE: [PATCH v7 4/7] i3c: master: add mastership handover support
>Those waits should be done in the master driver. Pass a timeout to
>->request_master() or make it a property of the i3c_master_controller
>if you like, but don't poll the status from the core.
Ok, I will move these pollings, check master has DA and MR done to
master driver method request_mastership. Then we will not need
check_events method in master driver. Every master driver can
handle mastership request process in request_mastership method.
>> +if (!ret)
>> +m->bus.cur_master = m->this;
>> +
>> +mr_req_done:
>> +i3c_bus_maintenance_unlock(&m->bus);
>> +i3c_bus_normaluse_lock(&m->bus);
>
>You should downgrade the lock instead of releasing it. I really need to
>get my head around this locking scheme because I'm pretty sure we had
>good reasons for the locking/unlocking dance Przemek had in his series.
That locking/unlocking dance was apparently because caller of
acquire_bus holds read lock to avoid device on which it is
operating does not disappear or get modified due to
maintenance activities happening inside maintenance (write) lock.
Hence, here first we unlock normaluse lock and then gets
maintenance lock.
Przemek: Was there any other reason behind that ?
Yes, I agree it is safer to combine maintenance (write) unlock and then
normaluse (read) lock, into downgrading maintenance lock to normaluse
lock in single step using downgrade_lock. I will make that change.
>> +
>> +if (!master->secondary)
>> +master->bus.cur_master = master->this;
>
>This change doesn't seem related to this patch. Looks like this should
>instead go to patch 3.
This is to initialize cur_master pointer in master object pointing to
I3C object for current master on the bus. Only main master is by default
current master at the beginning, so cur_master is initialized only
for the main master. And since set_info happens in bus_init during
master initialization this change is included in this patch.
>> +/*
>> + * Maintenance lock and master check above is used to
>> + * avoid race amongst devices sending MR requests
>> + * at the same time, as soon as ENEC MST is sent by the current
>> + * master. It ensure that only one MR request is processed,
>> + * rest MR requests on losing devices will timeout in wait MR
>> + * DONE state. And next MR requests are blocked due to DISEC MST
>> + * sent by current master in yield operation.
>> + * New master should send ENEC MST once it's work is done.
>> + * maintainanace lock is also needed for i3c_master_get_accmst_locked.
>> + */
>> +
>> +ret = i3c_master_disec_locked(m, I3C_BROADCAST_ADDR,
>> + I3C_CCC_EVENT_MR |
>> + I3C_CCC_EVENT_HJ);
>
>Isn't it taken care of at the controller level? I'm fine sending it
>here, but I suspect some controllers might actually auto-disable MRs
>once they receive one.
I think auto disable MR on receiving one, handles the case of multiple
devices sending MR requests at a same time. That is handled above using
maintenance lock and current master check.
DISEC MR, HJ is to avoid new master getting interrupted by MR or HJ
before it's use of bus is done. Once it's work is done ENEC MR, HJ is
sent using i3c_master_enable_mr_events(), may be we can
rename it to i3c_master_release_bus. It is not actual hand over of bus
but just allowing other master to acquire it.
I am not disabling MR and HJ at the hardware level. But I can add that
in acquire_bus as one more level of safety, if DISEC is disregarded for
some reason by any device.
> if (WARN_ON(m->this == m->bus.cur_master)) {
>
>And you should probably check that before send DISEC.
Sure, I will do that.
Regards,
Parshuram Thombare
RE: [EXT] Re: [PATCH v1 net-next 1/3] net: dsa: felix: qos classified based on pcp
Hi Vladimir,
On Mon, 11 May 2020 at 08:19, Vladimir Oltean wrote:
>
> The new skbedit priority offload action looks interesting to me.
> But it also raises the question of what to do in the default case where such
> rules are not installed. I think it is ok to support a
> 1-to-1 VLAN PCP to TC mapping by default? This should also be needed for
> features such as Priority Flow Control.
skbedit priority offload seems only support port based prority set now, I
haven't found how to set a priority for each port and QoS. So I set a 1-to-1
VLAN PCP to TC mapping by default.
> Xiaoliang, just a small comment in case you need to resend.
> The felix->info structure is intended to hold SoC-specific data that
> is likely to differ between chips (like for example if vsc7511 support
> ever appears in felix). But I see ANA:PORT:QOS_CFG and
> ANA:PORT:QOS_PCP_DEI_MAP_CFG are common registers, so are there any
> specific reasons why you put this in felix_vsc9959 and not in the
> common ocelot code?
All right, I have checked they are common registers, I will move
port_qos_map_init() function to felix.c.
> > + for (i = 0; i < FELIX_NUM_TC * 2; i++) {
> > + ocelot_rmw_ix(ocelot,
> > + (ANA_PORT_PCP_DEI_MAP_DP_PCP_DEI_VAL &
> > + i) |
> > +
> > ANA_PORT_PCP_DEI_MAP_QOS_PCP_DEI_VAL(i),
> > + ANA_PORT_PCP_DEI_MAP_DP_PCP_DEI_VAL |
> > + ANA_PORT_PCP_DEI_MAP_QOS_PCP_DEI_VAL_M,
> > + ANA_PORT_PCP_DEI_MAP,
> > + port, i);
>
> ANA_PORT_PCP_DEI_MAP_DP_PCP_DEI_VAL is 1 bit. Are you sure this should be % i
> and not % 2?
Because in QOS_PCP_DEI_MAP_CFG register, BIT(3) is DP value, BIT(2, 0) is QOS
value. QoS class=QOS_PCP_DEI_MAP_CFG[i].QOS_PC
P_DEI_VAL, i=8*DEI + PCP, so DP value need to be set BIT(3)&i.
Regards,
Xiaoliang Yang
[PATCH 3/3] ALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295
The ASUS UX581LV laptop's audio (1043:19e1) with ALC295 can't detect the
headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk
applied.
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index dcb97b39be6e..36832645de78 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7393,6 +7393,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE),
+ SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
--
2.26.2
Re: [PATCH -next] s390: Remove two unused inline functions
Hi Joe, On Mon, May 11, 2020 at 01:38:57PM -0700, Joe Perches wrote: > Awhile back, I posted a list of apparently unused static inline > functions in .h files treewide found by a script: > > https://lore.kernel.org/lkml/4603e761a5f39f4d97375e1e08d20d720c526341.ca...@perches.com/ > > Here are the s390 entries: > > arch/s390/include/asm/atomic_ops.h:138:static inline long > __atomic64_cmpxchg_bool(long *ptr, long old, long new) > arch/s390/include/asm/bitops.h:278:static inline void __set_bit_inv(unsigned > long nr, volatile unsigned long *ptr) > arch/s390/include/asm/bitops.h:283:static inline void > __clear_bit_inv(unsigned long nr, volatile unsigned long *ptr) > arch/s390/include/asm/cpu_mcf.h:106:static inline int > kernel_cpumcf_begin(void) > arch/s390/include/asm/cpu_mcf.h:114:static inline void kernel_cpumcf_end(void) > arch/s390/include/asm/ftrace.h:64:static inline int is_ftrace_nop(struct > ftrace_insn *insn) > arch/s390/include/asm/kvm_para.h:146:static inline long > kvm_hypercall5(unsigned long nr, unsigned long p1, > arch/s390/include/asm/kvm_para.h:175:static inline long > kvm_hypercall6(unsigned long nr, unsigned long p1, > arch/s390/include/asm/pci_dma.h:134:static inline void > invalidate_table_entry(unsigned long *entry) > arch/s390/include/asm/pci_dma.h:176:static inline int > entry_isprotected(unsigned long entry) > arch/s390/include/asm/timex.h:52:static inline void > store_clock_comparator(__u64 *time) Thanks, i take a look and prepare a patch. Regards Sven
Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
Hi, Boris, Pratyush, I stripped case 2/, we'll not treat it for now. On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Mon, 11 May 2020 09:00:35 + > > wrote: > > Hi, Pratyush, Boris, > > > > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: > > > This series adds support for octal DTR flashes in the spi-nor framework, > > > > I'm still learning about this, but I can give you my 2 cents as of now, to > > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > > because the flash may not recover from unexpected resets. Entering one of > > these modes can be: > > 1/ volatile selectable, the device return to the 1-1-1 protocol after the > > next power-on. I guess this is conditioned by the optional RESET pin, but > > I'll have to check. Also the flash can return to the 1-1-1 mode using the > > software reset or through writing to its Configuration Register, without > > power-on or power- off. > > My understanding is that there's no standard software reset procedure > that guarantees no conflict with existing 1S commands, so even the > software reset approach doesn't work here. > The software reset procedure can't protect you from unexpected resets, but the hardware with its optional reset pin can. Pratyush to confirm. cut > > > Not recovering from unexpected resets is unacceptable. One should always > > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with > > the presence of the optional RESET pin. > > Totally agree with you on that one, but we know what happens in > practice... What I proposed is to condition the entering in the state-full modes with the presence of the optional RESET pin. We would introduce an optional device tree property for the RESET pin. If hardware doesn't implement the optional RESET# signal, then we will not enter in the state-full modes. Cheers, ta
[PATCH 2/3] ALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295
The ASUS laptop UX550GE with ALC295 can't detect the headset microphone
until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 6c996df16201..dcb97b39be6e 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8003,6 +8003,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x12, 0x90a60130},
{0x17, 0x90170110},
{0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
+ {0x12, 0x90a60120},
+ {0x17, 0x90170110},
+ {0x21, 0x04211030}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
{0x12, 0x90a60130},
{0x17, 0x90170110},
--
2.26.2
[PATCH 1/3] ALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295
From: Chris Chiu
The ASUS laptop GL503VM with ALC295 can't detect the headset microphone.
The headset microphone does not work until pin 0x19 is enabled for it.
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index c16f63957c5a..6c996df16201 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6083,6 +6083,7 @@ enum {
ALC285_FIXUP_HP_GPIO_LED,
ALC285_FIXUP_HP_MUTE_LED,
ALC236_FIXUP_HP_MUTE_LED,
+ ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7216,6 +7217,15 @@ static const struct hda_fixup alc269_fixups[] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc236_fixup_hp_mute_led,
},
+ [ALC295_FIXUP_ASUS_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x01a1913c }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7993,6 +8003,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x12, 0x90a60130},
{0x17, 0x90170110},
{0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x03211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
{0x14, 0x90170110},
{0x21, 0x04211020}),
--
2.26.2
[PATCH] hpet: Fix a small information leak
hpet_info has a hole in it cause of which
we might end up leaking a few bytes.
Zero them with memset().
Fixes: 54066a57c584 ("hpet: kill BKL, add compat_ioctl")
Signed-off-by: Allen Pais
---
drivers/char/hpet.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index ed3b7dab678d..d9592eb24635 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -667,6 +667,7 @@ hpet_ioctl(struct file *file, unsigned int cmd, unsigned
long arg)
struct hpet_info info;
int err;
+ memset(&info, 0, sizeof(info));
mutex_lock(&hpet_mutex);
err = hpet_ioctl_common(file->private_data, cmd, arg, &info);
mutex_unlock(&hpet_mutex);
--
2.17.1
Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait
On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote: > > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote: > > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter > > wrote: > > > > > > It's the default. > > Thanks for catching that. > > > > > > > > Also so much for "we're not going to tell the graphics people how to > > > review their code", dma_fence is a pretty core piece of gpu driver > > > infrastructure. And it's very much uapi relevant, including piles of > > > corresponding userspace protocols and libraries for how to pass these > > > around. > > > > > > Would be great if habanalabs would not use this (from a quick look > > > it's not needed at all), since open source the userspace and playing > > > by the usual rules isn't on the table. If that's not possible (because > > > it's actually using the uapi part of dma_fence to interact with gpu > > > drivers) then we have exactly what everyone promised we'd want to > > > avoid. > > > > We don't use the uapi parts, we currently only using the fencing and > > signaling ability of this module inside our kernel code. But maybe I > > didn't understand what you request. You want us *not* to use this > > well-written piece of kernel code because it is only used by graphics > > drivers ? > > I'm sorry but I don't get this argument, if this is indeed what you meant. > > We would rather drivers using a feature that has requirements on > correct userspace implementations of the feature have a userspace that > is open source and auditable. > > Fencing is tricky, cross-device fencing is really tricky, and having > the ability for a closed userspace component to mess up other people's > drivers, think i915 shared with closed habana userspace and shared > fences, decreases ability to debug things. > > Ideally we wouldn't offer users known untested/broken scenarios, so > yes we'd prefer that drivers that intend to expose a userspace fencing > api around dma-fence would adhere to the rules of the gpu drivers. > > I'm not say you have to drop using dma-fence, but if you move towards > cross-device stuff I believe other drivers would be correct in > refusing to interact with fences from here. The flip side is if you only used dma-fence.c "because it's there", and not because it comes with an uapi attached and a cross-driver kernel internal contract for how to interact with gpu drivers, then there's really not much point in using it. It's a custom-rolled wait_queue/event thing, that's all. Without the gpu uapi and gpu cross-driver contract it would be much cleaner to just use wait_queue directly, and that's a construct all kernel developers understand, not just gpu folks. From a quick look at least habanalabs doesn't use any of these uapi/cross-driver/gpu bits. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: next/master bisection: baseline.login on jetson-tk1
Please see the bisection report below about a kernel panic.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
See the kernel Oops due to a NULL pointer followed by a panic:
https://storage.kernelci.org/next/master/next-20200511/arm/tegra_defconfig/gcc-8/lab-collabora/baseline-tegra124-jetson-tk1.html#L573
Stack trace:
<0>[2.953683] [] (__iommu_probe_device) from []
(iommu_probe_device+0x18/0x124)
<0>[2.962810] [] (iommu_probe_device) from []
(of_iommu_configure+0x154/0x1b8)
<0>[2.971853] [] (of_iommu_configure) from []
(of_dma_configure+0x144/0x2c8)
<0>[2.980722] [] (of_dma_configure) from []
(host1x_attach_driver+0x148/0x2c4)
<0>[2.989763] [] (host1x_attach_driver) from []
(host1x_driver_register_full+0x70/0xcc)
<0>[2.999585] [] (host1x_driver_register_full) from []
(host1x_drm_init+0x14/0x50)
<0>[3.008973] [] (host1x_drm_init) from []
(do_one_initcall+0x50/0x2b0)
<0>[3.017405] [] (do_one_initcall) from []
(kernel_init_freeable+0x188/0x200)
<0>[3.026361] [] (kernel_init_freeable) from []
(kernel_init+0x8/0x114)
<0>[3.034794] [] (kernel_init) from []
(ret_from_fork+0x14/0x2c)
Guillaume
On 12/05/2020 02:24, kernelci.org bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer:*
> * Reported-by: "kernelci.org bot" *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> next/master bisection: baseline.login on jetson-tk1
>
> Summary:
> Start: 4b20e7462caa6 Add linux-next specific files for 20200511
> Plain log:
> https://storage.kernelci.org/next/master/next-20200511/arm/tegra_defconfig/gcc-8/lab-collabora/baseline-tegra124-jetson-tk1.txt
> HTML log:
> https://storage.kernelci.org/next/master/next-20200511/arm/tegra_defconfig/gcc-8/lab-collabora/baseline-tegra124-jetson-tk1.html
> Result: 3eeeb45c6d044 iommu: Remove add_device()/remove_device()
> code-paths
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: next
> URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> Branch: master
> Target: jetson-tk1
> CPU arch: arm
> Lab:lab-collabora
> Compiler: gcc-8
> Config: tegra_defconfig
> Test case: baseline.login
>
> Breaking commit found:
>
> ---
> commit 3eeeb45c6d0444b368cdeba9bdafa8bbcf5370d1
> Author: Joerg Roedel
> Date: Wed Apr 29 15:37:10 2020 +0200
>
> iommu: Remove add_device()/remove_device() code-paths
>
> All drivers are converted to use the probe/release_device()
> call-backs, so the add_device/remove_device() pointers are unused and
> the code using them can be removed.
>
> Signed-off-by: Joerg Roedel
> Tested-by: Marek Szyprowski
> Acked-by: Marek Szyprowski
> Link: https://lore.kernel.org/r/20200429133712.31431-33-j...@8bytes.org
> Signed-off-by: Joerg Roedel
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 397fd4fd0c320..7f99e5ae432c6 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -220,12 +220,20 @@ static int __iommu_probe_device(struct device *dev,
> struct list_head *group_list
> return ret;
> }
>
> -static int __iommu_probe_device_helper(struct device *dev)
> +int iommu_probe_device(struct device *dev)
> {
> const struct iommu_ops *ops = dev->bus->iommu_ops;
> struct iommu_group *group;
> int ret;
>
> + if (!dev_iommu_get(dev))
> + return -ENOMEM;
> +
> + if (!try_module_get(ops->owner)) {
> + ret = -EINVAL;
> + goto err_out;
> + }
> +
> ret = __iommu_probe_device(dev, NULL);
> if (ret)
> goto err_out;
> @@ -259,75 +267,23 @@ static int __iommu_probe_device_helper(struct device
> *dev)
>
> err_release:
> iommu_release_device(dev);
> +
> err_out:
> return ret;
>
> }
&
Re: [PATCH v2 05/14] net: core: provide priv_to_netdev()
pon., 11 maj 2020 o 22:41 David Miller napisał(a): > > From: Bartosz Golaszewski > Date: Mon, 11 May 2020 17:07:50 +0200 > > > From: Bartosz Golaszewski > > > > Appropriate amount of extra memory for private data is allocated at > > the end of struct net_device. We have a helper - netdev_priv() - that > > returns its address but we don't have the reverse: a function which > > given the address of the private data, returns the address of struct > > net_device. > > > > This has caused many drivers to store the pointer to net_device in > > the private data structure, which basically means storing the pointer > > to a structure in this very structure. > > > > This patch proposes to add priv_to_netdev() - a helper which converts > > the address of the private data to the address of the associated > > net_device. > > > > Signed-off-by: Bartosz Golaszewski > > Sorry, please don't do this. We had this almost two decades ago and > explicitly removed it intentionally. > > Store the back pointer in your software state just like everyone else > does. I will if you insist but would you mind sharing some details on why it was removed? To me it still makes more sense than storing the pointer to a structure in *that* structure. Bart
Re: [PATCH net] net: broadcom: Imply BROADCOM_PHY for BCMGENET
Hi Florian,
On 11.05.2020 20:19, Florian Fainelli wrote:
> On 5/11/2020 12:21 AM, Marek Szyprowski wrote:
>> On 09.05.2020 00:32, Florian Fainelli wrote:
>>> The GENET controller on the Raspberry Pi 4 (2711) is typically
>>> interfaced with an external Broadcom PHY via a RGMII electrical
>>> interface. To make sure that delays are properly configured at the PHY
>>> side, ensure that we get a chance to have the dedicated Broadcom PHY
>>> driver (CONFIG_BROADCOM_PHY) enabled for this to happen.
>>>
>>> Fixes: 402482a6a78e ("net: bcmgenet: Clear ID_MODE_DIS in
>>> EXT_RGMII_OOB_CTRL when not needed")
>>> Reported-by: Marek Szyprowski
>>> Signed-off-by: Florian Fainelli
>>> ---
>>> David,
>>>
>>> I would like Marek to indicate whether he is okay or not with this
>>> change. Thanks!
>> It is better. It fixes the default values for ARM 32bit
>> bcm2835_defconfig and ARM 64bit defconfig, so you can add:
>>
>> Tested-by: Marek Szyprowski
>>
>> There is still an issue there. In case of ARM 64bit, when Genet driver
>> is configured as a module, BROADCOM_PHY is also set to module. When I
>> changed Genet to be built-in, BROADCOM_PHY stayed selected as module.
> OK.
>
>> This case doesn't work, as Genet driver is loaded much earlier than the
>> rootfs/initrd/etc is available, thus broadcom phy driver is not loaded
>> at all. It looks that some kind of deferred probe is missing there.
> In the absence of a specific PHY driver the Generic PHY driver gets used
> instead. This is a valid situation as I described in my other email
> because the boot loader/firmware could have left the PHY properly
> configured with the expected RGMII delays and configuration such that
> Linux does not need to be aware of anything. I suppose we could change
> the GENET driver when running on the 2711 platform to reject the PHY
> driver being "Generic PHY" on the premise that a specialized driver
> should be used instead, but that seems a bit too restrictive IMHO.
>
> Do you prefer a "select BROADCOM_PHY if ARCH_BCM2835" then?
Yes. It solves the issue after switching Genet to be built-in without
the need to change the CONFIG_BROADCOM_PHY.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH v3 1/2] mtd: rawnand: brcmnand: fix hamming oob layout
First 2 bytes are used in large-page nand.
Fixes: ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops")
Cc: sta...@vger.kernel.org
Signed-off-by: Álvaro Fernández Rojas
---
v3: invert patch order
v2: extend original comment
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index e4e3ceeac38f..1c1070111ebc 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1116,11 +1116,14 @@ static int brcmnand_hamming_ooblayout_free(struct
mtd_info *mtd, int section,
if (!section) {
/*
* Small-page NAND use byte 6 for BBI while large-page
-* NAND use byte 0.
+* NAND use bytes 0 and 1.
*/
- if (cfg->page_size > 512)
- oobregion->offset++;
- oobregion->length--;
+ if (cfg->page_size > 512) {
+ oobregion->offset += 2;
+ oobregion->length -= 2;
+ } else {
+ oobregion->length--;
+ }
}
}
--
2.26.2
[PATCH v3 2/2] mtd: rawnand: brcmnand: improve hamming oob layout
The current code generates 8 oob sections:
S1 1-5
ECC 6-8
S2 9-15
S3 16-21
ECC 22-24
S4 25-31
S5 32-37
ECC 38-40
S6 41-47
S7 48-53
ECC 54-56
S8 57-63
Change it by merging continuous sections:
S1 1-5
ECC 6-8
S2 9-21
ECC 22-24
S3 25-37
ECC 38-40
S4 41-53
ECC 54-56
S5 57-63
Fixes: ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops")
Signed-off-by: Álvaro Fernández Rojas
---
v3: invert patch order
v2: keep original comment and fix correctly skip byte 6 for small-page nand
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 37
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 1c1070111ebc..0a1d76fde37b 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1100,33 +1100,32 @@ static int brcmnand_hamming_ooblayout_free(struct
mtd_info *mtd, int section,
struct brcmnand_cfg *cfg = &host->hwcfg;
int sas = cfg->spare_area_size << cfg->sector_size_1k;
int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
+ u32 next;
- if (section >= sectors * 2)
+ if (section > sectors)
return -ERANGE;
- oobregion->offset = (section / 2) * sas;
+ next = (section * sas);
+ if (section < sectors)
+ next += 6;
- if (section & 1) {
- oobregion->offset += 9;
- oobregion->length = 7;
+ if (section) {
+ oobregion->offset = ((section - 1) * sas) + 9;
} else {
- oobregion->length = 6;
-
- /* First sector of each page may have BBI */
- if (!section) {
- /*
-* Small-page NAND use byte 6 for BBI while large-page
-* NAND use bytes 0 and 1.
-*/
- if (cfg->page_size > 512) {
- oobregion->offset += 2;
- oobregion->length -= 2;
- } else {
- oobregion->length--;
- }
+ /*
+* Small-page NAND use byte 6 for BBI while large-page
+* NAND use bytes 0 and 1.
+*/
+ if (cfg->page_size > 512) {
+ oobregion->offset = 2;
+ } else {
+ oobregion->offset = 0;
+ next--;
}
}
+ oobregion->length = next - oobregion->offset;
+
return 0;
}
--
2.26.2
[PATCH v3 0/2] mtd: rawnand: brcmnand: improve hamming oob layout
These patches improve the OOB hamming layout by reducing the number of oob sections and correctly v3: invert patch order. v2: extend original comment and correctly skip byte 6 for small-page. Álvaro Fernández Rojas (2): mtd: rawnand: brcmnand: fix hamming oob layout mtd: rawnand: brcmnand: improve hamming oob layout drivers/mtd/nand/raw/brcmnand/brcmnand.c | 34 +--- 1 file changed, 18 insertions(+), 16 deletions(-) -- 2.26.2
[PATCH v2 bpf-next 0/7] bpf, printk: add BTF-based type printing
The printk family of functions support printing specific pointer types
using %p format specifiers (MAC addresses, IP addresses, etc). For
full details see Documentation/core-api/printk-formats.rst.
This patchset proposes introducing a "print typed pointer" format
specifier "%pT"; the argument associated with the specifier is of
form "struct btf_ptr *" which consists of a .ptr value and a .type
value specifying a stringified type (e.g. "struct sk_buff") or
an .id value specifying a BPF Type Format (BTF) id identifying
the appropriate type it points to.
There is already support in kernel/bpf/btf.c for "show" functionality;
the changes here generalize that support from seq-file specific
verifier display to the more generic case and add another specific
use case; snprintf()-style rendering of type information to a
provided buffer. This support is then used to support printk
rendering of types, but the intent is to provide a function
that might be useful in other in-kernel scenarios; for example:
- ftrace could possibly utilize the function to support typed
display of function arguments by cross-referencing BTF function
information to derive the types of arguments
- oops/panic messaging could extend the information displayed to
dig into data structures associated with failing functions
The above potential use cases hint at a potential reply to
a reasonable objection that such typed display should be
solved by tracing programs, where the in kernel tracing records
data and the userspace program prints it out. While this
is certainly the recommended approach for most cases, I
believe having an in-kernel mechanism would be valuable
also.
The function the printk() family of functions rely on
could potentially be used directly for other use cases
like ftrace where we might have the BTF ids of the
pointers we wish to display; its signature is as follows:
int btf_type_snprintf_show(const struct btf *btf, u32 type_id, void *obj,
char *buf, int len, u64 flags);
So if ftrace say had the BTF ids of the types of arguments,
we see that the above would allow us to convert the
pointer data into displayable form.
To give a flavour for what the printed-out data looks like,
here we use pr_info() to display a struct sk_buff *.
struct sk_buff *skb = alloc_skb(64, GFP_KERNEL);
pr_info("%pT", BTF_PTR_TYPE(skb, "struct sk_buff"));
...gives us:
(struct sk_buff){
.transport_header = (__u16)65535,
.mac_header = (__u16)65535,
.end = (sk_buff_data_t)192,
.head = (unsigned char *)7524fd8b,
.data = (unsigned char *)7524fd8b,
.truesize = (unsigned int)768,
.users = (refcount_t){
.refs = (atomic_t){
.counter = (int)1,
},
},
}
For bpf_trace_printk() a "struct __btf_ptr *" is used as
argument; see tools/testing/selftests/bpf/progs/netif_receive_skb.c
for example usage.
The hope is that this functionality will be useful for debugging,
and possibly help facilitate the cases mentioned above in the future.
Changes since v1:
- changed format to be more drgn-like, rendering indented type info
along with type names by default (Alexei)
- zeroed values are omitted (Arnaldo) by default unless the '0'
modifier is specified (Alexei)
- added an option to print pointer values without obfuscation.
The reason to do this is the sysctls controlling pointer display
are likely to be irrelevant in many if not most tracing contexts.
Some questions on this in the outstanding questions section below...
- reworked printk format specifer so that we no longer rely on format
%pT but instead use a struct * which contains type information
(Rasmus). This simplifies the printk parsing, makes use more dynamic
and also allows specification by BTF id as well as name.
- ensured that BTF-specific printk code is bracketed by
#if ENABLED(CONFIG_BTF_PRINTF)
- removed incorrect patch which tried to fix dereferencing of resolved
BTF info for vmlinux; instead we skip modifiers for the relevant
case (array element type/size determination) (Alexei).
- fixed issues with negative snprintf format length (Rasmus)
- added test cases for various data structure formats; base types,
typedefs, structs, etc.
- tests now iterate through all typedef, enum, struct and unions
defined for vmlinux BTF and render a version of the target dummy
value which is either all zeros or all 0xff values; the idea is this
exercises the "skip if zero" and "print everything" cases.
- added support in BPF for using the %pT format specifier in
bpf_trace_printk()
- added BPF tests which ensure %pT format specifier use works (Alexei).
Outstanding issues
- currently %pT is not allowed in BPF programs when lockdown is active
prohibiting BPF_READ; is that sufficient?
- do we want to further restrict the non-obfuscated pointer format
specifier %pTx; for example blocking unprivileged BPF programs from
using it?
- likely still need a better answer for vmlinux BTF initialization
than the current approach
[PATCH v2 bpf-next 3/7] checkpatch: add new BTF pointer format specifier
checkpatch complains about unknown format specifiers, so add
the BTF format specifier we will implement in a subsequent
patch to avoid errors.
Signed-off-by: Alan Maguire
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index eac40f0..8efbb23 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6085,7 +6085,7 @@ sub process {
$specifier = $1;
$extension = $2;
$qualifier = $3;
- if ($extension !~
/[SsBKRraEehMmIiUDdgVCbGNOxtf]/ ||
+ if ($extension !~
/[SsBKRraEehMmIiUDdgVCbGNOxtfT]/ ||
($extension eq "f" &&
defined $qualifier && $qualifier
!~ /^w/)) {
$bad_specifier = $specifier;
--
1.8.3.1
[PATCH v2 bpf-next 2/7] bpf: move to generic BTF show support, apply it to seq files/strings
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show() with different
targets; the seq file or the string to be written. In the string
case we need to track additional data - length left in string to write
and length to return that we would have written (a la snprintf).
By default show will display type information, field members and
their types and values etc, and the information is indented
based upon structure depth.
Show however supports flags which modify its behaviour:
BTF_SHOW_COMPACT - suppress newline/indent.
BTF_SHOW_NONAME - suppress show of type and member names.
BTF_SHOW_PTR_RAW - do not obfuscate pointer values.
BTF_SHOW_ZERO - show zeroed values (by default they are not shown).
Signed-off-by: Alan Maguire
---
include/linux/btf.h | 33 +++
kernel/bpf/btf.c| 759 +---
2 files changed, 690 insertions(+), 102 deletions(-)
diff --git a/include/linux/btf.h b/include/linux/btf.h
index 5c1ea99..d571125 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -13,6 +13,7 @@
struct btf_member;
struct btf_type;
union bpf_attr;
+struct btf_show;
extern const struct file_operations btf_fops;
@@ -46,8 +47,40 @@ int btf_get_info_by_fd(const struct btf *btf,
const struct btf_type *btf_type_id_size(const struct btf *btf,
u32 *type_id,
u32 *ret_size);
+
+/*
+ * Options to control show behaviour.
+ * - BTF_SHOW_COMPACT: no formatting around type information
+ * - BTF_SHOW_NONAME: no struct/union member names/types
+ * - BTF_SHOW_PTR_RAW: show raw (unobfuscated) pointer values;
+ * equivalent to %px.
+ * - BTF_SHOW_ZERO: show zero-valued struct/union members; they
+ * are not displayed by default
+ */
+#define BTF_SHOW_COMPACT (1ULL << 0)
+#define BTF_SHOW_NONAME(1ULL << 1)
+#define BTF_SHOW_PTR_RAW (1ULL << 2)
+#define BTF_SHOW_ZERO (1ULL << 3)
+
void btf_type_seq_show(const struct btf *btf, u32 type_id, void *obj,
struct seq_file *m);
+
+/*
+ * Copy len bytes of string representation of obj of BTF type_id into buf.
+ *
+ * @btf: struct btf object
+ * @type_id: type id of type obj points to
+ * @obj: pointer to typed data
+ * @buf: buffer to write to
+ * @len: maximum length to write to buf
+ * @flags: show options (see above)
+ *
+ * Return: length that would have been/was copied as per snprintf, or
+ *negative error.
+ */
+int btf_type_snprintf_show(const struct btf *btf, u32 type_id, void *obj,
+ char *buf, int len, u64 flags);
+
int btf_get_fd_by_id(u32 id);
u32 btf_id(const struct btf *btf);
bool btf_member_is_reg_int(const struct btf *btf, const struct btf_type *s,
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index dcd2331..edf6455 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -281,6 +281,32 @@ static const char *btf_type_str(const struct btf_type *t)
return btf_kind_str[BTF_INFO_KIND(t->info)];
}
+/*
+ * Common data to all BTF show operations. Private show functions can add
+ * their own data to a structure containing a struct btf_show and consult it
+ * in the show callback. See btf_type_show() below.
+ */
+struct btf_show {
+ u64 flags;
+ void *target; /* target of show operation (seq file, buffer) */
+ void (*showfn)(struct btf_show *show, const char *fmt, ...);
+ const struct btf *btf;
+ /* below are used during iteration */
+ struct {
+ u8 depth;
+ u8 depth_shown;
+ u8 depth_check;
+ u8 array_member:1,
+ array_terminated:1;
+ u16 array_encoding;
+ u32 type_id;
+ const struct btf_type *type;
+ const struct btf_member *member;
+ char name[KSYM_NAME_LEN]; /* scratch space for name */
+ char type_name[KSYM_NAME_LEN]; /* scratch space for type */
+ } state;
+};
+
struct btf_kind_operations {
s32 (*check_meta)(struct btf_verifier_env *env,
const struct btf_type *t,
@@ -297,9 +323,9 @@ struct btf_kind_operations {
const struct btf_type *member_type);
void (*log_details)(struct btf_verifier_env *env,
const struct btf_type *t);
- void (*seq_show)(const struct btf *btf, const struct btf_type *t,
+ void (*show)(const struct btf *btf, const struct btf_type *t,
u32 type_id, void *data, u8 bits_offsets,
-struct seq_file *m);
+struct btf_show *show);
};
static const struct btf_kind_o
[PATCH v2 bpf-next 5/7] printk: extend test_printf to test %pT BTF-based format specifier
Add tests to verify basic type display and to iterate through all
enums, structs, unions and typedefs ensuring expected behaviour
occurs. Since test_printf can be built as a module we need to
export a BTF kind iterator function to allow us to iterate over
all names of a particular BTF kind.
These changes add up to approximately 20,000 new tests covering
all enum, struct, union and typedefs in vmlinux BTF.
Individual tests are also added for int, char, struct, enum
and typedefs which verify output is as expected.
Signed-off-by: Alan Maguire
---
include/linux/btf.h | 10 ++
kernel/bpf/btf.c| 35 ++
lib/test_printf.c | 301
3 files changed, 346 insertions(+)
diff --git a/include/linux/btf.h b/include/linux/btf.h
index 7b585ab..7fa8926 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -188,4 +188,14 @@ static inline const char *btf_name_by_offset(const struct
btf *btf,
}
#endif
+/* Following function used for testing BTF-based printk-family support */
+#ifdef CONFIG_BTF_PRINTF
+const char *btf_vmlinux_next_type_name(u8 kind, s32 *id);
+#else
+static inline const char *btf_vmlinux_next_type_name(u8 kind, s32 *id)
+{
+ return NULL;
+}
+#endif /* CONFIG_BTF_PRINTF */
+
#endif
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index edf6455..99471dc 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -5249,3 +5249,38 @@ u32 btf_id(const struct btf *btf)
{
return btf->id;
}
+
+#ifdef CONFIG_BTF_PRINTF
+/*
+ * btf_vmlinux_next_type_name(): used in test_printf.c to
+ * iterate over types for testing.
+ * Exported as test_printf can be built as a module.
+ *
+ * @kind: BTF_KIND_* value
+ * @id: pointer to last id; value/result argument. When next
+ * type name is found, we set *id to associated id.
+ * Returns:
+ * Next type name, sets *id to associated id.
+ */
+const char *btf_vmlinux_next_type_name(u8 kind, s32 *id)
+{
+ const struct btf *btf = bpf_get_btf_vmlinux();
+ const struct btf_type *t;
+ const char *name;
+
+ if (!btf || !id)
+ return NULL;
+
+ for ((*id)++; *id <= btf->nr_types; (*id)++) {
+ t = btf->types[*id];
+ if (BTF_INFO_KIND(t->info) != kind)
+ continue;
+ name = btf_name_by_offset(btf, t->name_off);
+ if (name && strlen(name) > 0)
+ return name;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(btf_vmlinux_next_type_name);
+#endif /* CONFIG_BTF_PRINTF */
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 2d9f520..d37a3a2 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -23,6 +23,9 @@
#include
#include
+#include
+#include
+#include
#include "../tools/testing/selftests/kselftest_module.h"
@@ -644,6 +647,303 @@ static void __init fwnode_pointer(void)
#endif
}
+#define__TEST_BTF(fmt, type, ptr, expected)
\
+ test(expected, "%pT"fmt, ptr)
+
+#define TEST_BTF_C(type, var, ...)\
+ do { \
+ type var = __VA_ARGS__;\
+ struct btf_ptr *ptr = BTF_PTR_TYPE(&var, type);\
+ pr_debug("type %s: %pTc", #type, ptr); \
+ __TEST_BTF("c", type, ptr, "(" #type ")" #__VA_ARGS__);\
+ } while (0)
+
+#define TEST_BTF(fmt, type, var, expected, ...)
\
+ do { \
+ type var = __VA_ARGS__;\
+ struct btf_ptr *ptr = BTF_PTR_TYPE(&var, type);\
+ pr_debug("type %s: %pT"fmt, #type, ptr); \
+ __TEST_BTF(fmt, type, ptr, expected); \
+ } while (0)
+
+#defineBTF_MAX_DATA_SIZE 65536
+
+static void __init
+btf_print_kind(u8 kind, const char *kind_name, u8 fillval)
+{
+ const char *fmt1 = "%pT", *fmt2 = "%pTN", *fmt3 = "%pT0";
+ const char *name, *fmt = fmt1;
+ int res1, res2, res3, res4;
+ char type_name[256];
+ u8 *dummy_data;
+ s32 id = 0;
+ char *buf;
+
+ dummy_data = kzalloc(BTF_MAX_DATA_SIZE, GFP_KERNEL);
+
+ /* fill our dummy data with supplied fillval. */
+ memset(dummy_data, fillval, BTF_MAX_DATA_SIZE);
+
+ buf = kzalloc(BTF_MAX_DATA_SIZE, GFP_KERNEL);
+
+ for (;;) {
+ name = btf_vmlinux_next_type_name(kind, &id);
+ if (!name)
+ break;
+
+ total_tests++;
+
+ snprintf(type_name, sizeof(type_name), "%s%s",
+kind_name, name);
+
+ res1 = snprintf(buf, BTF_MAX_DATA_
[PATCH v2 bpf-next 1/7] bpf: provide function to get vmlinux BTF information
It will be used later for BTF printk() support
Signed-off-by: Alan Maguire
---
include/linux/bpf.h | 2 ++
kernel/bpf/verifier.c | 18 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index cf4b6e4..de19a35 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1203,6 +1203,8 @@ int bpf_check(struct bpf_prog **fp, union bpf_attr *attr,
union bpf_attr __user *uattr);
void bpf_patch_call_args(struct bpf_insn *insn, u32 stack_depth);
+struct btf *bpf_get_btf_vmlinux(void);
+
/* Map specifics */
struct xdp_buff;
struct sk_buff;
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 2a1826c..c6b1ba0 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -10728,6 +10728,17 @@ static int check_attach_btf_id(struct bpf_verifier_env
*env)
}
}
+struct btf *bpf_get_btf_vmlinux(void)
+{
+ if (!btf_vmlinux && IS_ENABLED(CONFIG_DEBUG_INFO_BTF)) {
+ mutex_lock(&bpf_verifier_lock);
+ if (!btf_vmlinux)
+ btf_vmlinux = btf_parse_vmlinux();
+ mutex_unlock(&bpf_verifier_lock);
+ }
+ return btf_vmlinux;
+}
+
int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
union bpf_attr __user *uattr)
{
@@ -10761,12 +10772,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr
*attr,
env->ops = bpf_verifier_ops[env->prog->type];
is_priv = capable(CAP_SYS_ADMIN);
- if (!btf_vmlinux && IS_ENABLED(CONFIG_DEBUG_INFO_BTF)) {
- mutex_lock(&bpf_verifier_lock);
- if (!btf_vmlinux)
- btf_vmlinux = btf_parse_vmlinux();
- mutex_unlock(&bpf_verifier_lock);
- }
+ bpf_get_btf_vmlinux();
/* grab the mutex to protect few globals used by verifier */
if (!is_priv)
--
1.8.3.1
[PATCH v2 bpf-next 7/7] bpf: add tests for %pT format specifier
tests verify we get > 0 return value from bpf_trace_print()
using %pT format specifier with various modifiers/pointer
values.
Signed-off-by: Alan Maguire
---
.../selftests/bpf/prog_tests/trace_printk_btf.c| 83 ++
.../selftests/bpf/progs/netif_receive_skb.c| 81 +
2 files changed, 164 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
create mode 100644 tools/testing/selftests/bpf/progs/netif_receive_skb.c
diff --git a/tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
b/tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
new file mode 100644
index 000..d7ee158
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+
+struct result {
+ int ret;
+ int subtest;
+ int num_subtest;
+};
+
+/* return value of bpf_trace_printk()s is stored; if nonzero we failed. */
+static void on_sample(void *ctx, int cpu, void *data, __u32 size)
+{
+ struct result *resp = (struct result *)data;
+
+ *(struct result *)ctx = *resp;
+}
+
+void test_trace_printk_btf(void)
+{
+ struct result res = { 0 };
+ struct bpf_prog_load_attr attr = {
+ .file = "./netif_receive_skb.o",
+ };
+ struct perf_buffer_opts pb_opts = {};
+ struct bpf_program *prog = NULL;
+ struct perf_buffer *pb = NULL;
+ struct bpf_object *obj = NULL;
+ struct bpf_link *link = NULL;
+ struct bpf_map *perf_buf_map;
+ __u32 duration = 0;
+ int err, prog_fd;
+
+ err = bpf_prog_load_xattr(&attr, &obj, &prog_fd);
+ if (CHECK(err, "prog_load raw tp", "err %d errno %d\n", err, errno))
+ goto close_prog;
+
+ prog = bpf_object__find_program_by_title(obj,
+"tp_btf/netif_receive_skb");
+ if (CHECK(!prog, "find_prog", "prog netif_receive_skb not found\n"))
+ goto close_prog;
+
+ link = bpf_program__attach_raw_tracepoint(prog, NULL);
+ if (CHECK(IS_ERR(link), "attach_raw_tp", "err %ld\n", PTR_ERR(link)))
+ goto close_prog;
+
+ perf_buf_map = bpf_object__find_map_by_name(obj, "perf_buf_map");
+ if (CHECK(!perf_buf_map, "find_perf_buf_map", "not found\n"))
+ goto close_prog;
+
+ /* set up perf buffer */
+ pb_opts.sample_cb = on_sample;
+ pb_opts.ctx = &res;
+ pb = perf_buffer__new(bpf_map__fd(perf_buf_map), 1, &pb_opts);
+ if (CHECK(IS_ERR(pb), "perf_buf__new", "err %ld\n", PTR_ERR(pb)))
+ goto close_prog;
+
+ /* generate receive event */
+ system("ping -c 1 127.0.0.1 >/dev/null");
+
+ /* read perf buffer */
+ err = perf_buffer__poll(pb, 100);
+ if (CHECK(err < 0, "perf_buffer__poll", "err %d\n", err))
+ goto close_prog;
+
+ /*
+* Make sure netif_receive_skb program was triggered
+* and it sent expected return values from bpf_trace_printk()s
+* into ring buffer.
+*/
+ if (CHECK(res.ret <= 0,
+ "bpf_trace_printk: got return value",
+ "ret <= 0 %d test %d\n", res.ret, res.subtest))
+ goto close_prog;
+
+ CHECK(res.subtest != res.num_subtest, "check all subtests ran",
+ "only ran %d of %d tests\n", res.subtest, res.num_subtest);
+
+close_prog:
+ perf_buffer__free(pb);
+ if (!IS_ERR_OR_NULL(link))
+ bpf_link__destroy(link);
+ bpf_object__close(obj);
+}
diff --git a/tools/testing/selftests/bpf/progs/netif_receive_skb.c
b/tools/testing/selftests/bpf/progs/netif_receive_skb.c
new file mode 100644
index 000..b5148df
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/netif_receive_skb.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2020, Oracle and/or its affiliates. */
+#include
+#include
+#include
+#include
+#include
+
+char _license[] SEC("license") = "GPL";
+
+struct {
+ __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
+ __uint(key_size, sizeof(int));
+ __uint(value_size, sizeof(int));
+} perf_buf_map SEC(".maps");
+
+struct result {
+ int ret;
+ int subtest;
+ int num_subtest;
+};
+
+typedef struct {
+ int counter;
+} atomic_t;
+typedef struct refcount_struct {
+ atomic_t refs;
+} refcount_t;
+
+struct sk_buff {
+ /* field names and sizes should match to those in the kernel */
+ unsigned int len, data_len;
+ __u16 mac_len, hdr_len, queue_mapping;
+ struct net_device *dev;
+ /* order of the fields doesn't matter */
+ refcount_t users;
+ unsigned char *data;
+ char __pkt_type_offset[0];
+ char cb[48];
+};
+
+#define CHECK_PRINTK(_fmt, _p, res)\
+ do {\
+ char
[PATCH v2 bpf-next 6/7] bpf: add support for %pT format specifier for bpf_trace_printk() helper
Allow %pT[cNx0] format specifier for BTF-based display of data associated
with pointer.
Signed-off-by: Alan Maguire
---
include/uapi/linux/bpf.h | 27 ++-
kernel/trace/bpf_trace.c | 21 ++---
tools/include/uapi/linux/bpf.h | 27 ++-
3 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 9d1932e..ab3c86c 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -695,7 +695,12 @@ struct bpf_stack_build_id {
* to file *\/sys/kernel/debug/tracing/trace* from DebugFS, if
* available. It can take up to three additional **u64**
* arguments (as an eBPF helpers, the total number of arguments is
- * limited to five).
+ * limited to five), and also supports %pT (BTF-based type
+ * printing), as long as BPF_READ lockdown is not active.
+ * "%pT" takes a "struct __btf_ptr *" as an argument; it
+ * consists of a pointer value and specified BTF type string or id
+ * used to select the type for display. For more details, see
+ * Documentation/core-api/printk-formats.rst.
*
* Each time the helper is called, it appends a line to the trace.
* Lines are discarded while *\/sys/kernel/debug/tracing/trace* is
@@ -731,10 +736,10 @@ struct bpf_stack_build_id {
* The conversion specifiers supported by *fmt* are similar, but
* more limited than for printk(). They are **%d**, **%i**,
* **%u**, **%x**, **%ld**, **%li**, **%lu**, **%lx**, **%lld**,
- * **%lli**, **%llu**, **%llx**, **%p**, **%s**. No modifier (size
- * of field, padding with zeroes, etc.) is available, and the
- * helper will return **-EINVAL** (but print nothing) if it
- * encounters an unknown specifier.
+ * **%lli**, **%llu**, **%llx**, **%p**, **%pT[cNx0], **%s**.
+ * Only %pT supports modifiers, and the helper will return
+ * **-EINVAL** (but print nothing) if it encouters an unknown
+ * specifier.
*
* Also, note that **bpf_trace_printk**\ () is slow, and should
* only be used for debugging purposes. For this reason, a notice
@@ -4058,4 +4063,16 @@ struct bpf_pidns_info {
__u32 pid;
__u32 tgid;
};
+
+/*
+ * struct __btf_ptr is used for %pT (typed pointer) display; the
+ * additional type string/BTF id are used to render the pointer
+ * data as the appropriate type.
+ */
+struct __btf_ptr {
+ void *ptr;
+ const char *type;
+ __u32 id;
+};
+
#endif /* _UAPI__LINUX_BPF_H__ */
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d961428..c032c58 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -321,9 +321,12 @@ static const struct bpf_func_proto
*bpf_get_probe_write_proto(void)
return &bpf_probe_write_user_proto;
}
+#define isbtffmt(c)\
+ (c == 'T' || c == 'c' || c == 'N' || c == 'x' || c == '0')
+
/*
* Only limited trace_printk() conversion specifiers allowed:
- * %d %i %u %x %ld %li %lu %lx %lld %lli %llu %llx %p %s
+ * %d %i %u %x %ld %li %lu %lx %lld %lli %llu %llx %p %pT %s
*/
BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
u64, arg2, u64, arg3)
@@ -361,8 +364,20 @@ static const struct bpf_func_proto
*bpf_get_probe_write_proto(void)
i++;
} else if (fmt[i] == 'p' || fmt[i] == 's') {
mod[fmt_cnt]++;
- /* disallow any further format extensions */
- if (fmt[i + 1] != 0 &&
+ /*
+* allow BTF type-based printing, and disallow any
+* further format extensions.
+*/
+ if (fmt[i] == 'p' && fmt[i + 1] == 'T') {
+ int ret;
+
+ ret = security_locked_down(LOCKDOWN_BPF_READ);
+ if (unlikely(ret < 0))
+ return ret;
+ i++;
+ while (isbtffmt(fmt[i]))
+ i++;
+ } else if (fmt[i + 1] != 0 &&
!isspace(fmt[i + 1]) &&
!ispunct(fmt[i + 1]))
return -EINVAL;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9d1932e..ab3c86c 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -695,7 +695,12 @@ struct bpf_stack_build_id {
* to file *\/sys/kernel/debug/tracing/trace* from DebugFS, if
* available. It can take up to three additional **u64**
*
[PATCH v2 bpf-next 4/7] printk: add type-printing %pT format specifier which uses BTF
printk supports multiple pointer object type specifiers (printing
netdev features etc). Extend this support using BTF to cover
arbitrary types. "%pT" specifies the typed format, and the pointer
argument is a "struct btf_ptr *" where struct btf_ptr is as follows:
struct btf_ptr {
void *ptr;
const char *type;
u32 id;
};
Either the "type" string ("struct sk_buff") or the BTF "id" can be
used to identify the type to use in displaying the associated "ptr"
value. A convenience function to create and point at the struct
is provided:
printk(KERN_INFO "%pT", BTF_PTR_TYPE(skb, struct sk_buff));
When invoked, BTF information is used to traverse the sk_buff *
and display it. Support is present for structs, unions, enums,
typedefs and core types (though in the latter case there's not
much value in using this feature of course).
Default output is indented, but compact output can be specified
via the 'c' option. Type names/member values can be suppressed
using the 'N' option. Zero values are not displayed by default
but can be using the '0' option. Pointer values are obfuscated
unless the 'x' option is specified. As an example:
struct sk_buff *skb = alloc_skb(64, GFP_KERNEL);
pr_info("%pT", BTF_PTR_TYPE(skb, struct sk_buff));
...gives us:
(struct sk_buff){
.transport_header = (__u16)65535,
.mac_header = (__u16)65535,
.end = (sk_buff_data_t)192,
.head = (unsigned char *)6b71155a,
.data = (unsigned char *)6b71155a,
.truesize = (unsigned int)768,
.users = (refcount_t){
.refs = (atomic_t){
.counter = (int)1,
},
},
.extensions = (struct skb_ext *)f486a130,
}
printk output is truncated at 1024 bytes. For cases where overflow
is likely, the compact/no type names display modes may be used.
Signed-off-by: Alan Maguire
---
Documentation/core-api/printk-formats.rst | 15
include/linux/btf.h | 3 +-
include/linux/printk.h| 16 +
lib/Kconfig | 16 +
lib/vsprintf.c| 113 ++
5 files changed, 162 insertions(+), 1 deletion(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index 8ebe46b1..5c66097 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -545,6 +545,21 @@ For printing netdev_features_t.
Passed by reference.
+BTF-based printing of pointer data
+--
+If '%pT' is specified, use the struct btf_ptr * along with kernel vmlinux
+BPF Type Format (BTF) to show the typed data. For example, specifying
+
+ printk(KERN_INFO "%pT", BTF_PTR_TYPE(skb, struct_sk_buff));
+
+will utilize BTF information to traverse the struct sk_buff * and display it.
+
+Supported modifers are
+ 'c' compact output (no indentation, newlines etc)
+ 'N' do not show type names
+ 'x' show raw pointers (no obfuscation)
+ '0' show zero-valued data (it is not shown by default)
+
Thanks
==
diff --git a/include/linux/btf.h b/include/linux/btf.h
index d571125..7b585ab 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -169,10 +169,11 @@ static inline const struct btf_member
*btf_type_member(const struct btf_type *t)
return (const struct btf_member *)(t + 1);
}
+struct btf *btf_parse_vmlinux(void);
+
#ifdef CONFIG_BPF_SYSCALL
const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id);
const char *btf_name_by_offset(const struct btf *btf, u32 offset);
-struct btf *btf_parse_vmlinux(void);
struct btf *bpf_prog_get_target_btf(const struct bpf_prog *prog);
#else
static inline const struct btf_type *btf_type_by_id(const struct btf *btf,
diff --git a/include/linux/printk.h b/include/linux/printk.h
index fcde0772..3c3ea53 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -528,4 +528,20 @@ static inline void print_hex_dump_debug(const char
*prefix_str, int prefix_type,
#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
print_hex_dump_debug(prefix_str, prefix_type, 16, 1, buf, len, true)
+/**
+ * struct btf_ptr is used for %pT (typed pointer) display; the
+ * additional type string/BTF id are used to render the pointer
+ * data as the appropriate type.
+ */
+struct btf_ptr {
+ void *ptr;
+ const char *type;
+ u32 id;
+};
+
+#defineBTF_PTR_TYPE(ptrval, typeval) \
+ (&((struct btf_ptr){.ptr = ptrval, .type = #typeval}))
+
+#define BTF_PTR_ID(ptrval, idval) \
+ (&((struct btf_ptr){.ptr = ptrval, .id = idval}))
#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index 5d53f96..ac3a513 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -6,6 +6,22 @@
config BINARY_PRINTF
def_bool n
+config BTF_PRINTF
+ bool "print type information using BPF type format"
+ depends on DEBUG_INFO_BTF
+ default n
+ help
+ Print structures, unions etc po
Re: [PATCH v8 10/11] mtd: Support kmsg dumper based on pstore/blk
hi Kees Cook, On 2020/5/12 下午1:12, Kees Cook wrote: > [resend to proper CC list...] > > On Tue, May 12, 2020 at 11:12:42AM +0800, WeiXiong Liao wrote: >> hi Kees Cook, >> >> The off parameter on mtdpsore_block*() does not align to block size, >> which makes some bugs. For example, a block contains 4 dmesg zones >> and it's expected to erase this block when user remove all files on >> these zones. However it work failed since it get wrongly zonenum from >> misaligned off. > > Ah, okay. I haven't touched any of this logic. Did something change in > pstore/blk or /zone that I broke? Regardless, can you send a regular > patch for what you have below and I'll fold it into the mtdpstore > commit. > I will send a patch later. Maybe it needs to be reviewed again by MTD maintainers. And everything in pstore/blk and /zone are OK. > Thanks! > > -Kees > >> On 2020/5/12 AM 7:32, Kees Cook wrote: >>> From: WeiXiong Liao >>> >>> This introduces mtdpstore, which is similar to mtdoops but more >>> powerful. It uses pstore/blk, and aims to store panic and oops logs to >>> a flash partition, where pstore can later read back and present as files >>> in the mounted pstore filesystem. >>> >>> To make mtdpstore work, the "blkdev" of pstore/blk should be set >>> as MTD device name or MTD device number. For more details, see >>> Documentation/admin-guide/pstore-blk.rst >>> >>> This solves a number of issues: >>> - Work duplication: both of pstore and mtdoops do the same job storing >>> panic/oops log. They have very similar logic, registering to kmsg >>> dumper and storing logs to several chunks one by one. >>> - Layer violations: drivers should provides methods instead of polices. >>> MTD should provide read/write/erase operations, and allow a higher >>> level drivers to provide the chunk management, kmsg dump >>> configuration, etc. >>> - Missing features: pstore provides many additional features, including >>> presenting the logs as files, logging dump time and count, and >>> supporting other frontends like pmsg, console, etc. >>> >>> Signed-off-by: WeiXiong Liao >>> Link: >>> https://lore.kernel.org/r/1585126506-18635-12-git-send-email-liaoweixi...@allwinnertech.com >>> Signed-off-by: Kees Cook >>> --- >>> Documentation/admin-guide/pstore-blk.rst | 9 +- >>> drivers/mtd/Kconfig | 10 + >>> drivers/mtd/Makefile | 1 + >>> drivers/mtd/mtdpstore.c | 563 +++ >>> 4 files changed, 581 insertions(+), 2 deletions(-) >>> create mode 100644 drivers/mtd/mtdpstore.c >>> >>> diff --git a/Documentation/admin-guide/pstore-blk.rst >>> b/Documentation/admin-guide/pstore-blk.rst >>> index d45341e55e82..296d5027787a 100644 >>> --- a/Documentation/admin-guide/pstore-blk.rst >>> +++ b/Documentation/admin-guide/pstore-blk.rst >>> @@ -43,9 +43,9 @@ blkdev >>> ~~ >>> >>> The block device to use. Most of the time, it is a partition of block >>> device. >>> -It's required for pstore/blk. >>> +It's required for pstore/blk. It is also used for MTD device. >>> >>> -It accepts the following variants: >>> +It accepts the following variants for block device: >>> >>> 1. device number in hexadecimal represents itself; >>> no >>> leading 0x, for example b302. >>> @@ -64,6 +64,11 @@ It accepts the following variants: >>> partition with a known unique id. >>> #. : major and minor number of the device separated by a >>> colon. >>> >>> +It accepts the following variants for MTD device: >>> + >>> +1. MTD device name. "pstore" is recommended. >>> +#. MTD device number. >>> + >>> kmsg_size >>> ~ >>> >>> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig >>> index 42d401ea60ee..6ddab796216d 100644 >>> --- a/drivers/mtd/Kconfig >>> +++ b/drivers/mtd/Kconfig >>> @@ -170,6 +170,16 @@ config MTD_OOPS >>> buffer in a flash partition where it can be read back at some >>> later point. >>> >>> +config MTD_PSTORE >>> + tristate "Log panic/oops to an MTD buffer based on pstore" >>> + depends on PSTORE_BLK >>> + help >>> + This enables panic and oops messages to be logged to a circular >>> + buffer in a flash partition where it can be read back as files after >>> + mounting pstore filesystem. >>> + >>> + If unsure, say N. >>> + >>> config MTD_SWAP >>> tristate "Swap on MTD device support" >>> depends on MTD && SWAP >>> diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile >>> index 56cc60ccc477..593d0593a038 100644 >>> --- a/drivers/mtd/Makefile >>> +++ b/drivers/mtd/Makefile >>> @@ -20,6 +20,7 @@ obj-$(CONFIG_RFD_FTL) += rfd_ftl.o >>> obj-$(CONFIG_SSFDC)+= ssfdc.o >>> obj-$(CONFIG_SM_FTL) += sm_ftl.o >>> obj-$(CONFIG_MTD_OOPS) += mtdoops.o >>> +obj-$(CONFIG_MTD_PSTORE) += mtdpstore.o >>> obj-$(CONFIG_MTD_SWAP) += mtdswap.o >>> >>> nftl-objs := nftlcore.o nftlmount.o >>> diff --git a/drivers/mt
Re: [PATCH] gcc-plugins: remove always false $(if ...) in Makefile
On Sun, May 10, 2020 at 11:14 AM Kees Cook wrote:
>
> On Sun, May 10, 2020 at 11:00:44AM +0900, Masahiro Yamada wrote:
> > This is the remnant of commit c17d6179ad5a ("gcc-plugins: remove unused
> > GCC_PLUGIN_SUBDIR").
> >
> > $(if $(findstring /,$(p)),...) is always false because none of plugins
> > contains '/' in the file name.
> >
> > Clean up the code.
> >
> > Signed-off-by: Masahiro Yamada
>
> Reviewed-by: Kees Cook
>
Applied to linux-kbuild.
--
Best Regards
Masahiro Yamada
Re: stable/linux-4.4.y bisection: baseline.login on at91-sama5d4_xplained
Please see the bisection report below about a boot failure.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
It appears to be due to the fact that the network interface is
failing to get brought up:
[ 114.385000] Waiting up to 10 more seconds for network.
[ 124.355000] Sending DHCP requests ...#
..#
.#
timed out!
[ 212.355000] IP-Config: Reopening network devices...
[ 212.365000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
#
I guess the board would boot fine without network if it didn't
have ip=dhcp in the command line, so it's not strictly a kernel
boot failure but still an ethernet issue.
There wasn't any failure reported by kernelci on linux-4.9.y so
maybe this patch was applied by mistake on linux-4.4.y but I
haven't investigated enough to prove this.
Thanks,
Guillaume
On 10/05/2020 18:27, kernelci.org bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer:*
> * Reported-by: "kernelci.org bot" *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> stable/linux-4.4.y bisection: baseline.login on at91-sama5d4_xplained
>
> Summary:
> Start: e157447efd85b Linux 4.4.223
> Plain log:
> https://storage.kernelci.org/stable/linux-4.4.y/v4.4.223/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-at91-sama5d4_xplained.txt
> HTML log:
> https://storage.kernelci.org/stable/linux-4.4.y/v4.4.223/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-at91-sama5d4_xplained.html
> Result: 0d1951fa23ba0 net: phy: Avoid polling PHY with
> PHY_IGNORE_INTERRUPTS
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: stable
> URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Branch: linux-4.4.y
> Target: at91-sama5d4_xplained
> CPU arch: arm
> Lab:lab-baylibre
> Compiler: gcc-8
> Config: multi_v7_defconfig
> Test case: baseline.login
>
> Breaking commit found:
>
> ---
> commit 0d1951fa23ba0d35a4c5498ff28d1c5206d6fcdd
> Author: Florian Fainelli
> Date: Mon Jan 18 19:33:06 2016 -0800
>
> net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS
>
> commit d5c3d84657db57bd23ecd58b97f1c99dd42a7b80 upstream.
>
> Commit 2c7b49212a86 ("phy: fix the use of PHY_IGNORE_INTERRUPT") changed
> a hunk in phy_state_machine() in the PHY_RUNNING case which was not
> needed. The change essentially makes the PHY library treat PHY devices
> with PHY_IGNORE_INTERRUPT to keep polling for the PHY device, even
> though the intent is not to do it.
>
> Fix this by reverting that specific hunk, which makes the PHY state
> machine wait for state changes, and stay in the PHY_RUNNING state for as
> long as needed.
>
> Fixes: 2c7b49212a86 ("phy: fix the use of PHY_IGNORE_INTERRUPT")
> Signed-off-by: Florian Fainelli
> Signed-off-by: David S. Miller
> Signed-off-by: Greg Kroah-Hartman
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 7d2cf015c5e76..b242bec834f4b 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -912,10 +912,10 @@ void phy_state_machine(struct work_struct *work)
> phydev->adjust_link(phydev->attached_dev);
> break;
> case PHY_RUNNING:
> - /* Only register a CHANGE if we are polling or ignoring
> - * interrupts and link changed since latest checking.
> + /* Only register a CHANGE if we are polling and link changed
> + * since latest checking.
>*/
> - if (!phy_interrupt_is_valid(phydev)) {
> + if (phydev->irq == PHY_POLL) {
> old_link = phydev->link;
> err = phy_read_status(phydev);
> if (err)
> @@ -1015,8 +1015,13 @@ void phy_state_machine(struct work_struct *work)
> dev_dbg(&phydev->dev, "PHY state change %s -> %s\n",
> phy_state_to_str(old_state), phy_state_to_str(phydev->state));
>
> - queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
> -PHY_STATE_TIME * HZ);
> + /* Only re-schedule a PHY state machine change if we are polling the
> + * PHY, if PHY_IGNORE_IN
Re: [PATCH] Makefile: support compressed debug info
On Tue, May 5, 2020 at 9:47 AM Fangrui Song wrote: > > > On 2020-05-04, Sedat Dilek wrote: > >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers > > wrote: > >> > >> As debug information gets larger and larger, it helps significantly save > >> the size of vmlinux images to compress the information in the debug > >> information sections. Note: this debug info is typically split off from > >> the final compressed kernel image, which is why vmlinux is what's used > >> in conjunction with GDB. Minimizing the debug info size should have no > >> impact on boot times, or final compressed kernel image size. > >> > >> All of the debug sections will have a `C` flag set. > >> $ readelf -S > >> > >> $ bloaty vmlinux.gcc75.compressed.dwarf4 -- \ > >> vmlinux.gcc75.uncompressed.dwarf4 > >> > >> FILE SIZEVM SIZE > >> -- -- > >> +0.0% +18 [ = ] 0[Unmapped] > >> -73.3% -114Ki [ = ] 0.debug_aranges > >> -76.2% -2.01Mi [ = ] 0.debug_frame > >> -73.6% -2.89Mi [ = ] 0.debug_str > >> -80.7% -4.66Mi [ = ] 0.debug_abbrev > >> -82.9% -4.88Mi [ = ] 0.debug_ranges > >> -70.5% -9.04Mi [ = ] 0.debug_line > >> -79.3% -10.9Mi [ = ] 0.debug_loc > >> -39.5% -88.6Mi [ = ] 0.debug_info > >> -18.2% -123Mi [ = ] 0TOTAL > >> > >> $ bloaty vmlinux.clang11.compressed.dwarf4 -- \ > >> vmlinux.clang11.uncompressed.dwarf4 > >> > >> FILE SIZEVM SIZE > >> -- -- > >> +0.0% +23 [ = ] 0[Unmapped] > >> -65.6%-871 [ = ] 0.debug_aranges > >> -77.4% -1.84Mi [ = ] 0.debug_frame > >> -82.9% -2.33Mi [ = ] 0.debug_abbrev > >> -73.1% -2.43Mi [ = ] 0.debug_str > >> -84.8% -3.07Mi [ = ] 0.debug_ranges > >> -65.9% -8.62Mi [ = ] 0.debug_line > >> -86.2% -40.0Mi [ = ] 0.debug_loc > >> -42.0% -64.1Mi [ = ] 0.debug_info > >> -22.1% -122Mi [ = ] 0TOTAL > >> > > > >Hi Nick, > > > >thanks for the patch. > > > >I have slightly modified it to adapt to Linux v5.7-rc4 (what was your base?). > > > >Which linker did you use and has it an impact if you switch from > >ld.bfd to ld.lld? > > lld has supported the linker option --compress-debug-sections=zlib since > about 5.0.0 (https://reviews.llvm.org/D31941) > > >I tried a first normal run and in a 2nd one with > >CONFIG_DEBUG_INFO_COMPRESSED=y both with clang-10 and ld.lld-10. > > > >My numbers (sizes in MiB): > > > >[ diffconfig ] > > > >$ scripts/diffconfig /boot/config-5.7.0-rc4-1-amd64-clang > >/boot/config-5.7.0-rc4-2-amd64-clang > > BUILD_SALT "5.7.0-rc4-1-amd64-clang" -> "5.7.0-rc4-2-amd64-clang" > >+DEBUG_INFO_COMPRESSED y > > > >[ compiler and linker ] > > > >$ clang-10 -v > >ClangBuiltLinux clang version 10.0.1 > >(https://github.com/llvm/llvm-project > >92d5c1be9ee93850c0a8903f05f36a23ee835dc2) > >Target: x86_64-unknown-linux-gnu > >Thread model: posix > >InstalledDir: /home/dileks/src/llvm-toolchain/install/bin > >Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > >Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 > >Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > >Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > >Candidate multilib: .;@m64 > >Candidate multilib: 32;@m32 > >Candidate multilib: x32;@mx32 > >Selected multilib: .;@m64 > > > >$ ld.lld-10 -v > >LLD 10.0.1 (https://github.com/llvm/llvm-project > >92d5c1be9ee93850c0a8903f05f36a23ee835dc2) (compatible with GNU > >linkers) > > > >[ sizes vmlinux ] > > > >$ du -m 5.7.0-rc4-*/vmlinux* > >409 5.7.0-rc4-1-amd64-clang/vmlinux > >7 5.7.0-rc4-1-amd64-clang/vmlinux.compressed > >404 5.7.0-rc4-1-amd64-clang/vmlinux.o > >324 5.7.0-rc4-2-amd64-clang/vmlinux > >7 5.7.0-rc4-2-amd64-clang/vmlinux.compressed > >299 5.7.0-rc4-2-amd64-clang/vmlinux.o > > > >[ readelf (.debug_info as example) ] > > > >$ readelf -S vmlinux.o > > [33] .debug_info PROGBITS 01d6a5e8 > > 06be1ee6 0 0 1 > > > >$ readelf -S vmlinux.o > > [33] .debug_info PROGBITS 01749f18 > > 02ef04d2 C 0 0 1 <--- > >XXX: "C (compressed)" Flag > > > >Key to Flags: > > W (write), A (alloc), X (execute), M (merge), S (strings), I (info), > > L (link order), O (extra OS processing required), G (group), T (TLS), > > C (compressed), x (unknown), o (OS specific), E (exclude), > > l (large), p (processor specific) > > > >[ sizes linux-image debian packages ] > > > >$ du -m 5.7.0-rc4-*/linux-image*.deb > >47 > >5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang_5.7.0~rc4-1~bullseye+dileks1_amd64.deb > >424 > >5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang-dbg_5.7.0~rc4-1~bullseye+dileks1_amd64.deb > >
Re: [PATCH] ifcvf: move IRQ request/free to status change handlers
On 2020/5/12 上午11:38, Jason Wang wrote:
static int ifcvf_start_datapath(void *private)
{
struct ifcvf_hw *vf = ifcvf_private_to_vf(private);
@@ -118,9 +172,12 @@ static void ifcvf_vdpa_set_status(struct
vdpa_device *vdpa_dev, u8 status)
{
struct ifcvf_adapter *adapter;
struct ifcvf_hw *vf;
+ u8 status_old;
+ int ret;
vf = vdpa_to_vf(vdpa_dev);
adapter = dev_get_drvdata(vdpa_dev->dev.parent);
+ status_old = ifcvf_get_status(vf);
if (status == 0) {
ifcvf_stop_datapath(adapter);
@@ -128,7 +185,22 @@ static void ifcvf_vdpa_set_status(struct
vdpa_device *vdpa_dev, u8 status)
return;
}
- if (status & VIRTIO_CONFIG_S_DRIVER_OK) {
+ if ((status_old & VIRTIO_CONFIG_S_DRIVER_OK) &&
+ !(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
+ ifcvf_stop_datapath(adapter);
+ ifcvf_free_irq(adapter, IFCVF_MAX_QUEUE_PAIRS * 2);
+ }
+
+ if ((status & VIRTIO_CONFIG_S_DRIVER_OK) &&
+ !(status_old & VIRTIO_CONFIG_S_DRIVER_OK)) {
+ ret = ifcvf_request_irq(adapter);
+ if (ret) {
+ status = ifcvf_get_status(vf);
+ status |= VIRTIO_CONFIG_S_FAILED;
+ ifcvf_set_status(vf, status);
+ return;
+ }
+
Have a hard though on the logic here.
This depends on the status setting from guest or userspace. Which
means it can not deal with e.g when qemu or userspace is crashed? Do
we need to care this or it's a over engineering?
Thanks
If qemu crash, I guess users may re-run qmeu / re-initialize the
device, according to the spec, there should be a reset routine.
This code piece handles status change on DRIVER_OK flipping. I am not
sure I get your point, mind to give more hints?
The problem is if we don't launch new qemu instance, the interrupt
will be still there?
Ok, we reset on vhost_vdpa_release() so the following is suspicious:
With the patch, we do:
static void ifcvf_vdpa_set_status(struct vdpa_device *vdpa_dev, u8 status)
{
struct ifcvf_adapter *adapter;
struct ifcvf_hw *vf;
u8 status_old;
int ret;
vf = vdpa_to_vf(vdpa_dev);
adapter = dev_get_drvdata(vdpa_dev->dev.parent);
status_old = ifcvf_get_status(vf);
if (status == 0) {
ifcvf_stop_datapath(adapter);
ifcvf_reset_vring(adapter);
return;
}
if ((status_old & VIRTIO_CONFIG_S_DRIVER_OK) &&
!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
ifcvf_stop_datapath(adapter);
ifcvf_free_irq(adapter, IFCVF_MAX_QUEUE_PAIRS * 2);
}
...
So the handling of status == 0 looks wrong.
The OK -> !OK check should already cover the datapath stopping and irq
stuffs.
We only need to deal with vring reset and only need to do it after we
stop the datapath/irq stuffs.
Thanks
Thanks
Re: [PATCH v8 01/11] pstore/zone: Introduce common layer to manage storage zones
hi Kees Cook,
On 2020/5/12 PM 1:15, Kees Cook wrote:
> On Tue, May 12, 2020 at 11:55:20AM +0800, WeiXiong Liao wrote:
>> On 2020/5/12 AM 7:32, Kees Cook wrote:
>>> [...]
>>> +struct psz_context {
>>> + struct pstore_zone **kpszs;
>>> + unsigned int kmsg_max_cnt;
>>> + unsigned int kmsg_read_cnt;
>>> + unsigned int kmsg_write_cnt;
>>> + /*
>>> +* These counters should be calculated during recovery.
>>> +* It records the oops/panic times after crashes rather than boots.
>>> +*/
>>> + unsigned int oops_counter;
>>> + unsigned int panic_counter;
>>
>> oops/panic_counter is designed to count the crash times since the
>> linux kernel was installed. pstore/zone lookup the max counter from all
>> valid kmsg zones when recovery and saves them to oops/panic_counter.
>> However, they are unable to get real number if we remove files. It's
>> not serious, we can fix it after this series.
>
> Since the kernel was installed? I don't see a kernel version check in
> here? Or do you mean "since ever", in that it's a rolling count?
>
Yes, "since ever".
>> And since pstore supports "max_reason", should pstore/zone count for
>> other reason?
>
> For now, no. I opted to try to keep this as simple as possible a port
> from dump_oops to max_reason for now.
>
OK.
>>> +static inline int psz_kmsg_erase(struct psz_context *cxt,
>>> + struct pstore_zone *zone, struct pstore_record *record)
>>> +{
>>> + struct psz_buffer *buffer = zone->buffer;
>>> + struct psz_kmsg_header *hdr =
>>> + (struct psz_kmsg_header *)buffer->data;
>>> +
>>> + if (unlikely(!psz_ok(zone)))
>>> + return 0;
>>> + /* this zone is already updated, no need to erase */
>>> + if (record->count != hdr->counter)
>>> + return 0;
>>
>> These codes is to fix bug that user remove files on pstore filesystem
>> but kmsg zone is already updated and pstore/zone should not erase
>> zone. It work for oops and panic because the count number is increasing.
>> However, it's useless for other reason of kmsg. We can fix it after this
>> series.
>
> Okay, sounds good.
>
--
WeiXiong Liao
Re: [PATCH] Makefile: support compressed debug info
Hi Sedat, On Tue, May 5, 2020 at 1:25 AM Sedat Dilek wrote: > > On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers > wrote: > > > > As debug information gets larger and larger, it helps significantly save > > the size of vmlinux images to compress the information in the debug > > information sections. Note: this debug info is typically split off from > > the final compressed kernel image, which is why vmlinux is what's used > > in conjunction with GDB. Minimizing the debug info size should have no > > impact on boot times, or final compressed kernel image size. > > > > All of the debug sections will have a `C` flag set. > > $ readelf -S > > > > $ bloaty vmlinux.gcc75.compressed.dwarf4 -- \ > > vmlinux.gcc75.uncompressed.dwarf4 > > > > FILE SIZEVM SIZE > > -- -- > > +0.0% +18 [ = ] 0[Unmapped] > > -73.3% -114Ki [ = ] 0.debug_aranges > > -76.2% -2.01Mi [ = ] 0.debug_frame > > -73.6% -2.89Mi [ = ] 0.debug_str > > -80.7% -4.66Mi [ = ] 0.debug_abbrev > > -82.9% -4.88Mi [ = ] 0.debug_ranges > > -70.5% -9.04Mi [ = ] 0.debug_line > > -79.3% -10.9Mi [ = ] 0.debug_loc > > -39.5% -88.6Mi [ = ] 0.debug_info > > -18.2% -123Mi [ = ] 0TOTAL > > > > $ bloaty vmlinux.clang11.compressed.dwarf4 -- \ > > vmlinux.clang11.uncompressed.dwarf4 > > > > FILE SIZEVM SIZE > > -- -- > > +0.0% +23 [ = ] 0[Unmapped] > > -65.6%-871 [ = ] 0.debug_aranges > > -77.4% -1.84Mi [ = ] 0.debug_frame > > -82.9% -2.33Mi [ = ] 0.debug_abbrev > > -73.1% -2.43Mi [ = ] 0.debug_str > > -84.8% -3.07Mi [ = ] 0.debug_ranges > > -65.9% -8.62Mi [ = ] 0.debug_line > > -86.2% -40.0Mi [ = ] 0.debug_loc > > -42.0% -64.1Mi [ = ] 0.debug_info > > -22.1% -122Mi [ = ] 0TOTAL > > > > Hi Nick, > > thanks for the patch. > > I have slightly modified it to adapt to Linux v5.7-rc4 (what was your base?). > > Which linker did you use and has it an impact if you switch from > ld.bfd to ld.lld? > > I tried a first normal run and in a 2nd one with > CONFIG_DEBUG_INFO_COMPRESSED=y both with clang-10 and ld.lld-10. > > My numbers (sizes in MiB): > > [ diffconfig ] > > $ scripts/diffconfig /boot/config-5.7.0-rc4-1-amd64-clang > /boot/config-5.7.0-rc4-2-amd64-clang > BUILD_SALT "5.7.0-rc4-1-amd64-clang" -> "5.7.0-rc4-2-amd64-clang" > +DEBUG_INFO_COMPRESSED y > > [ compiler and linker ] > > $ clang-10 -v > ClangBuiltLinux clang version 10.0.1 > (https://github.com/llvm/llvm-project > 92d5c1be9ee93850c0a8903f05f36a23ee835dc2) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /home/dileks/src/llvm-toolchain/install/bin > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > Candidate multilib: .;@m64 > Candidate multilib: 32;@m32 > Candidate multilib: x32;@mx32 > Selected multilib: .;@m64 > > $ ld.lld-10 -v > LLD 10.0.1 (https://github.com/llvm/llvm-project > 92d5c1be9ee93850c0a8903f05f36a23ee835dc2) (compatible with GNU > linkers) > > [ sizes vmlinux ] > > $ du -m 5.7.0-rc4-*/vmlinux* > 409 5.7.0-rc4-1-amd64-clang/vmlinux > 7 5.7.0-rc4-1-amd64-clang/vmlinux.compressed > 404 5.7.0-rc4-1-amd64-clang/vmlinux.o > 324 5.7.0-rc4-2-amd64-clang/vmlinux > 7 5.7.0-rc4-2-amd64-clang/vmlinux.compressed > 299 5.7.0-rc4-2-amd64-clang/vmlinux.o > > [ readelf (.debug_info as example) ] > > $ readelf -S vmlinux.o > [33] .debug_info PROGBITS 01d6a5e8 >06be1ee6 0 0 1 > > $ readelf -S vmlinux.o > [33] .debug_info PROGBITS 01749f18 >02ef04d2 C 0 0 1 <--- > XXX: "C (compressed)" Flag > > Key to Flags: > W (write), A (alloc), X (execute), M (merge), S (strings), I (info), > L (link order), O (extra OS processing required), G (group), T (TLS), > C (compressed), x (unknown), o (OS specific), E (exclude), > l (large), p (processor specific) > > [ sizes linux-image debian packages ] > > $ du -m 5.7.0-rc4-*/linux-image*.deb > 47 > 5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang_5.7.0~rc4-1~bullseye+dileks1_amd64.deb > 424 > 5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang-dbg_5.7.0~rc4-1~bullseye+dileks1_amd64.deb > 47 > 5.7.0-rc4-2-amd64-clang/linux-image-5.7.0-rc4-2-amd64-clang_5.7.0~rc4-2~bullseye+dileks1_amd64.deb > 771 > 5.7.0-rc4-2-amd64-clang/linux-image-5.7.0-rc4-2-amd64-clang-dbg_5.7.0~rc4-2~bullseye+dileks1_amd64.deb > > [ sizes linux-git dir (compilation finished ] > > 5.7.0-rc4-1-am
Re: linux-next: manual merge of the vfs tree with the parisc-hd tree
On Mon, May 11, 2020 at 10:22:04PM -0700, Kees Cook wrote:
> On Tue, May 12, 2020 at 12:33:05AM +, Luis Chamberlain wrote:
> > On Mon, May 11, 2020 at 09:55:16AM +0800, Xiaoming Ni wrote:
> > > On 2020/5/11 9:11, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the vfs tree got a conflict in:
> > > >
> > > >kernel/sysctl.c
> > > >
> > > > between commit:
> > > >
> > > >b6522fa409cf ("parisc: add sysctl file interface
> > > > panic_on_stackoverflow")
> > > >
> > > > from the parisc-hd tree and commit:
> > > >
> > > >f461d2dcd511 ("sysctl: avoid forward declarations")
> > > >
> > > > from the vfs tree.
> > > >
> > > > I fixed it up (see below) and can carry the fix as necessary. This
> > > > is now fixed as far as linux-next is concerned, but any non trivial
> > > > conflicts should be mentioned to your upstream maintainer when your tree
> > > > is submitted for merging. You may also want to consider cooperating
> > > > with the maintainer of the conflicting tree to minimise any particularly
> > > > complex conflicts.
> > > >
> > >
> > >
> > > Kernel/sysctl.c contains more than 190 interface files, and there are a
> > > large number of config macro controls. When modifying the sysctl interface
> > > directly in kernel/sysctl.c , conflicts are very easy to occur.
> > >
> > > At the same time, the register_sysctl_table() provided by the system can
> > > easily add the sysctl interface, and there is no conflict of
> > > kernel/sysctl.c
> > > .
> > >
> > > Should we add instructions in the patch guide (coding-style.rst
> > > submitting-patches.rst):
> > > Preferentially use register_sysctl_table() to add a new sysctl interface,
> > > centralize feature codes, and avoid directly modifying kernel/sysctl.c ?
> >
> > Yes, however I don't think folks know how to do this well. So I think we
> > just have to do at least start ourselves, and then reflect some of this
> > in the docs. The reason that this can be not easy is that we need to
> > ensure that at an init level we haven't busted dependencies on setting
> > this. We also just don't have docs on how to do this well.
> >
> > > In addition, is it necessary to transfer the architecture-related sysctl
> > > interface to arch/xxx/kernel/sysctl.c ?
> >
> > Well here's an initial attempt to start with fs stuff in a very
> > conservative way. What do folks think?
> >
> > [...]
> > +static unsigned long zero_ul;
> > +static unsigned long long_max = LONG_MAX;
>
> I think it'd be nice to keep these in one place for others to reuse,
> though that means making them non-static. (And now that I look at them,
> I thought they were supposed to be const?)
So much spring cleaning to do. I can add the const and share it.
It seems odd to stuff this into a sysctl.h, types.h doesn't seem
right... I can't think of something proper, so I'll just move them
to sysctl.h for now.
Any thought on the approach though? I mean, I realize that this will
require more of the subsystem specific folks to look at the code and
review, but if this seems fair, I'll get the ball rolling.
Luis
Re: [PATCH -next] iommu/msm: Make msm_iommu_lock static
On Mon 11 May 19:17 PDT 2020, Samuel Zou wrote:
> Fix the following sparse warning:
>
> drivers/iommu/msm_iommu.c:37:1: warning: symbol 'msm_iommu_lock' was not
> declared.
>
> The msm_iommu_lock has only call site within msm_iommu.c
> It should be static
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Fixes: 0720d1f052dc ("msm: Add MSM IOMMU support")
> Reported-by: Hulk Robot
> Signed-off-by: Samuel Zou
> ---
> drivers/iommu/msm_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 10cd4db..3d8a635 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -34,7 +34,7 @@ __asm__ __volatile__ (
> \
> /* bitmap of the page sizes currently supported */
> #define MSM_IOMMU_PGSIZES(SZ_4K | SZ_64K | SZ_1M | SZ_16M)
>
> -DEFINE_SPINLOCK(msm_iommu_lock);
> +static DEFINE_SPINLOCK(msm_iommu_lock);
> static LIST_HEAD(qcom_iommu_devices);
> static struct iommu_ops msm_iommu_ops;
>
> --
> 2.6.2
>
Re: [v2 4/4] regulator: qcom: labibb: Add SC interrupt handling
On Fri 08 May 13:42 PDT 2020, Sumit Semwal wrote:
> From: Nisha Kumari
>
> Add Short circuit interrupt handling and recovery for the lab and
> ibb regulators on qcom platforms.
>
> The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
> notification which will be triggered on short circuit. They should
> try to enable the regulator once, and if it doesn't get enabled,
> handle shutting down the panel accordingly.
>
> Signed-off-by: Nisha Kumari
> Signed-off-by: Sumit Semwal
>
> --
> v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle it
> per-regulator instead of clearing both lab and ibb errors on either irq
> triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
> notification to clients.
> ---
> drivers/regulator/qcom-labibb-regulator.c | 103 +-
> 1 file changed, 100 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/qcom-labibb-regulator.c
> b/drivers/regulator/qcom-labibb-regulator.c
> index a9dc7c060375..3539631c9f96 100644
> --- a/drivers/regulator/qcom-labibb-regulator.c
> +++ b/drivers/regulator/qcom-labibb-regulator.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0
> // Copyright (c) 2019, The Linux Foundation. All rights reserved.
>
> +#include
> #include
> #include
> #include
> @@ -18,11 +19,15 @@
> #define REG_LABIBB_ENABLE_CTL0x46
> #define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
> #define LABIBB_CONTROL_ENABLEBIT(7)
> +#define LABIBB_STATUS1_SC_DETECT_BIT BIT(6)
>
> #define LAB_ENABLE_CTL_MASK BIT(7)
> #define IBB_ENABLE_CTL_MASK (BIT(7) | BIT(6))
>
> #define POWER_DELAY 8000
> +#define POLLING_SCP_DONE_INTERVAL_US 5000
> +#define POLLING_SCP_TIMEOUT 16000
> +
>
> struct labibb_regulator {
> struct regulator_desc desc;
> @@ -30,6 +35,8 @@ struct labibb_regulator {
> struct regmap *regmap;
> struct regulator_dev*rdev;
> u16 base;
> + int sc_irq;
> + int vreg_enabled;
> u8 type;
> };
>
> @@ -112,9 +119,10 @@ static int qcom_labibb_regulator_enable(struct
> regulator_dev *rdev)
> return ret;
> }
>
> - if (ret)
> + if (ret) {
> + reg->vreg_enabled = 1;
> return 0;
> -
> + }
>
> dev_err(reg->dev, "Can't enable %s\n", reg->desc.name);
> return -EINVAL;
> @@ -140,8 +148,10 @@ static int qcom_labibb_regulator_disable(struct
> regulator_dev *rdev)
> return ret;
> }
>
> - if (!ret)
> + if (!ret) {
> + reg->vreg_enabled = 0;
> return 0;
> + }
>
> dev_err(reg->dev, "Can't disable %s\n", reg->desc.name);
> return -EINVAL;
> @@ -153,6 +163,70 @@ static struct regulator_ops qcom_labibb_ops = {
> .is_enabled = qcom_labibb_regulator_is_enabled,
> };
>
> +
> +static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
> +{
> + int ret, count;
> + u16 reg;
> + u8 sc_err_mask;
> + unsigned int val;
> + struct labibb_regulator *labibb_reg = (struct labibb_regulator *)_reg;
No need to explicitly typecast a void *.
> + bool in_sc_err, reg_en, scp_done = false;
reg_en is unused.
> +
> + if (irq == labibb_reg->sc_irq)
When is this false?
> + reg = labibb_reg->base + REG_LABIBB_STATUS1;
> + else
> + return IRQ_HANDLED;
> +
> + sc_err_mask = LABIBB_STATUS1_SC_DETECT_BIT;
> +
> + ret = regmap_bulk_read(labibb_reg->regmap, reg, &val, 1);
Just inline reg->base + REG_LABIBB_STATUS1 in this call.
> + if (ret < 0) {
> + dev_err(labibb_reg->dev, "Read failed, ret=%d\n", ret);
> + return IRQ_HANDLED;
> + }
> + dev_dbg(labibb_reg->dev, "%s SC error triggered! STATUS1 = %d\n",
> + labibb_reg->desc.name, val);
> +
> + in_sc_err = !!(val & sc_err_mask);
> +
> + /*
> + * The SC(short circuit) fault would trigger PBS(Portable Batch
> + * System) to disable regulators for protection. This would
> + * cause the SC_DETECT status being cleared so that it's not
> + * able to get the SC fault status.
> + * Check if the regulator is enabled in the driver but
> + * disabled in hardware, this means a SC fault had happened
> + * and SCP handling is completed by PBS.
> + */
> + if (!in_sc_err) {
if (!(val & LABIBB_STATUS1_SC_DETECT_BIT)) {
> +
> + reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
> +
> + ret = regmap_read_poll_timeout(labibb_reg->regmap,
> + reg, val,
> + !(val & LABIBB_CONTROL_ENABLE),
> + POLLING_SCP_DONE_INTERVAL_US,
> +
Re: [PATCH v2] tpm: eventlog: Replace zero-length array with flexible-array member
On Fri, May 08, 2020 at 11:38:26AM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> sizeof(flexible-array-member) triggers a warning because flexible array
> members have incomplete type[1]. There are some instances of code in
> which the sizeof operator is being incorrectly/erroneously applied to
> zero-length arrays and the result is zero. Such instances may be hiding
> some bugs. So, this work (flexible-array member conversions) will also
> help to get completely rid of those sorts of issues.
>
> Also, the following issue shows up due to the flexible-array member
> having incomplete type[4]:
>
> drivers/char/tpm/eventlog/tpm2.c: In function ‘tpm2_bios_measurements_start’:
> drivers/char/tpm/eventlog/tpm2.c:54:46: error: invalid application of
> ‘sizeof’ to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
>54 | size = sizeof(struct tcg_pcr_event) - sizeof(event_header->event)
> | ^
> drivers/char/tpm/eventlog/tpm2.c: In function ‘tpm2_bios_measurements_next’:
> drivers/char/tpm/eventlog/tpm2.c:102:10: error: invalid application of
> ‘sizeof’ to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
> 102 |sizeof(event_header->event) + event_header->event_size;
> | ^
> drivers/char/tpm/eventlog/tpm2.c: In function
> ‘tpm2_binary_bios_measurements_show’:
> drivers/char/tpm/eventlog/tpm2.c:140:10: error: invalid application of
> ‘sizeof’ to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
> 140 |sizeof(event_header->event) + event_header->event_size;
> | ^
> scripts/Makefile.build:266: recipe for target
> 'drivers/char/tpm/eventlog/tpm2.o' failed
> make[3]: *** [drivers/char/tpm/eventlog/tpm2.o] Error 1
>
> As mentioned above: "Flexible array members have incomplete type, and
> so the sizeof operator may not be applied. As a quirk of the original
> implementation of zero-length arrays, sizeof evaluates to zero."[1] As
> in "sizeof(event_header->event) always evaluated to 0, so removing it
> has no effect".
>
> Lastly, make use of the struct_size() helper to deal with the
> flexible array member and its host structure.
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> [4] https://github.com/KSPP/linux/issues/43
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
--
Kees Cook
[tip:core/rcu] BUILD SUCCESS 68f0f2690e183306b52671a9ad09fb31808b0500
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/rcu branch HEAD: 68f0f2690e183306b52671a9ad09fb31808b0500 Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu elapsed time: 499m configs tested: 114 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig m68k allyesconfig sparcallyesconfig powerpc tqm8xx_defconfig riscv rv32_defconfig shedosk7705_defconfig sh lboxre2_defconfig sh se7722_defconfig xtensaxip_kc705_defconfig arm alldefconfig i386 allnoconfig i386defconfig i386 debian-10.3 i386 allyesconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20200511 i386 randconfig-a005-20200511 i386 randconfig-a003-20200511 i386 randconfig-a001-20200511 i386 randconfig-a004-20200511 i386 randconfig-a002-20200511 x86_64 randconfig-a006-20200512 x86_64 randconfig-a004-20200512 x86_64 randconfig-a002-20200512 i386 randconfig-a012-20200511 i386 randconfig-a016-20200511 i386 randconfig-a014-20200511 i386 randconfig-a011-20200511 i386 randconfig-a013-20200511 i386 randconfig-a015-20200511 i386 randconfig-a012-20200512 i386 randconfig-a016-20200512 i386 randconfig-a014-20200512 i386 randconfig-a011-20200512 i386 randconfig-a013-20200512 i386 randconfig-a015-20200512 x86_64 randconfig-a005-20200511 x86_64 randconfig-a003-20200511 x86_64 randconfig-a006-20200511 x86_64 randconfig-a004-20200511 x86_64 randconfig-a001-20200511 x86_64 randconfig-a002-20200511 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig x86_64 defconfig sparc defconf
Re: linux-next: manual merge of the vfs tree with the parisc-hd tree
On Tue, May 12, 2020 at 12:33:05AM +, Luis Chamberlain wrote:
> On Mon, May 11, 2020 at 09:55:16AM +0800, Xiaoming Ni wrote:
> > On 2020/5/11 9:11, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the vfs tree got a conflict in:
> > >
> > >kernel/sysctl.c
> > >
> > > between commit:
> > >
> > >b6522fa409cf ("parisc: add sysctl file interface
> > > panic_on_stackoverflow")
> > >
> > > from the parisc-hd tree and commit:
> > >
> > >f461d2dcd511 ("sysctl: avoid forward declarations")
> > >
> > > from the vfs tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary. This
> > > is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging. You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> > >
> >
> >
> > Kernel/sysctl.c contains more than 190 interface files, and there are a
> > large number of config macro controls. When modifying the sysctl interface
> > directly in kernel/sysctl.c , conflicts are very easy to occur.
> >
> > At the same time, the register_sysctl_table() provided by the system can
> > easily add the sysctl interface, and there is no conflict of kernel/sysctl.c
> > .
> >
> > Should we add instructions in the patch guide (coding-style.rst
> > submitting-patches.rst):
> > Preferentially use register_sysctl_table() to add a new sysctl interface,
> > centralize feature codes, and avoid directly modifying kernel/sysctl.c ?
>
> Yes, however I don't think folks know how to do this well. So I think we
> just have to do at least start ourselves, and then reflect some of this
> in the docs. The reason that this can be not easy is that we need to
> ensure that at an init level we haven't busted dependencies on setting
> this. We also just don't have docs on how to do this well.
>
> > In addition, is it necessary to transfer the architecture-related sysctl
> > interface to arch/xxx/kernel/sysctl.c ?
>
> Well here's an initial attempt to start with fs stuff in a very
> conservative way. What do folks think?
>
> [...]
> +static unsigned long zero_ul;
> +static unsigned long long_max = LONG_MAX;
I think it'd be nice to keep these in one place for others to reuse,
though that means making them non-static. (And now that I look at them,
I thought they were supposed to be const?)
--
Kees Cook
MAINTAINERS: Wrong ordering in VIRTIO BALLOON
Hi David,
with your commit 6d6b93b9afd8 ("MAINTAINERS: Add myself as virtio-balloon
co-maintainer"), visible on next-20200508, ./scripts/checkpatch.pl -f
MAINTAINERS complains:
WARNING: Misordered MAINTAINERS entry - list file patterns in alphabetic order
#17982: FILE: MAINTAINERS:17982:
+F: include/uapi/linux/virtio_balloon.h
+F: include/linux/balloon_compaction.h
This is due to wrong ordering of the entries in your submission. If you
would like me to send you a patch fixing that, please just let me know.
It is a recent addition to checkpatch.pl to report ordering problems in
MAINTAINERS, so you might have not seen that at submission time.
Best regards,
Lukas
Re: [PATCH net 2/2 RESEND] ipmr: Add lockdep expression to ipmr_for_each_table macro
On Sat, May 09, 2020 at 02:19:38PM -0700, Jakub Kicinski wrote:
> On Sat, 9 May 2020 12:52:44 +0530 Amol Grover wrote:
> > ipmr_for_each_table() uses list_for_each_entry_rcu() for
> > traversing outside of an RCU read-side critical section but
> > under the protection of pernet_ops_rwsem. Hence add the
> > corresponding lockdep expression to silence the following
> > false-positive warning at boot:
>
> Thanks for the fix, the warning has been annoying me as well!
>
> > [0.645292] =
> > [0.645294] WARNING: suspicious RCU usage
> > [0.645296] 5.5.4-stable #17 Not tainted
> > [0.645297] -
> > [0.645299] net/ipv4/ipmr.c:136 RCU-list traversed in non-reader
> > section!!
>
> please provide a fuller stack trace, it would have helped the review
>
> > Signed-off-by: Amol Grover
> > ---
> > net/ipv4/ipmr.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> > index 99c864eb6e34..950ffe9943da 100644
> > --- a/net/ipv4/ipmr.c
> > +++ b/net/ipv4/ipmr.c
> > @@ -109,9 +109,10 @@ static void mroute_clean_tables(struct mr_table *mrt,
> > int flags);
> > static void ipmr_expire_process(struct timer_list *t);
> >
> > #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
> > -#define ipmr_for_each_table(mrt, net) \
> > - list_for_each_entry_rcu(mrt, &net->ipv4.mr_tables, list, \
> > - lockdep_rtnl_is_held())
> > +#define ipmr_for_each_table(mrt, net)
> > \
> > + list_for_each_entry_rcu(mrt, &net->ipv4.mr_tables, list,\
> > + lockdep_rtnl_is_held() || \
> > + lockdep_is_held(&pernet_ops_rwsem))
>
> This is a strange condition, IMHO. How can we be fine with either
> lock.. This is supposed to be the writer side lock, one can't have
> two writer side locks..
>
> I think what is happening is this:
>
> ipmr_net_init() -> ipmr_rules_init() -> ipmr_new_table()
>
> ipmr_new_table() returns an existing table if there is one, but
> obviously none can exist at init. So a better fix would be:
>
> #define ipmr_for_each_table(mrt, net) \
> list_for_each_entry_rcu(mrt, &net->ipv4.mr_tables, list,\
> lockdep_rtnl_is_held() || \
> list_empty(&net->ipv4.mr_tables))
>
(adding Stephen)
Hi Jakub,
Thank you for your suggestion about this patch.
Here is a stack trace for ipmr.c:
[1.515015] TCP: Hash tables configured (established 8192 bind 8192)
[1.516790] UDP hash table entries: 512 (order: 3, 49152 bytes, linear)
[1.518177] UDP-Lite hash table entries: 512 (order: 3, 49152 bytes, linear)
[1.519805]
[1.520178] =
[1.520982] WARNING: suspicious RCU usage
[1.521798] 5.7.0-rc2-6-gb35af6a26b7c6f #1 Not tainted
[1.522910] -
[1.523671] net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!!
[1.525218]
[1.525218] other info that might help us debug this:
[1.525218]
[1.526731]
[1.526731] rcu_scheduler_active = 2, debug_locks = 1
[1.528004] 1 lock held by swapper/1:
[1.528714] #0: c20be1d8 (pernet_ops_rwsem){+.+.}-{3:3}, at:
register_pernet_subsys+0xd/0x30
[1.530433]
[1.530433] stack backtrace:
[1.531262] CPU: 0 PID: 1 Comm: swapper Not tainted
5.7.0-rc2-6-gb35af6a26b7c6f #1
[1.532729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[1.534305] Call Trace:
[1.534758] ? ipmr_get_table+0x3c/0x70
[1.535430] ? ipmr_new_table+0x1c/0x60
[1.536173] ? ipmr_net_init+0x7b/0x170
[1.536923] ? register_pernet_subsys+0xd/0x30
[1.537810] ? ops_init+0x1a0/0x1e0
[1.538518] ? kmem_cache_create_usercopy+0x28a/0x350
[1.539752] ? register_pernet_operations+0xc9/0x1c0
[1.540630] ? ipv4_offload_init+0x65/0x65
[1.541451] ? register_pernet_subsys+0x19/0x30
[1.542357] ? ip_mr_init+0x28/0xff
[1.543079] ? inet_init+0x17b/0x249
[1.543773] ? do_one_initcall+0xc5/0x240
[1.544532] ? parse_args+0x192/0x350
[1.545266] ? rcu_read_lock_sched_held+0x2f/0x60
[1.546180] ? trace_initcall_level+0x61/0x93
[1.547061] ? kernel_init_freeable+0x112/0x18a
[1.547978] ? kernel_init_freeable+0x12b/0x18a
[1.548974] ? rest_init+0x220/0x220
[1.549792] ? kernel_init+0x8/0x100
[1.550548] ? rest_init+0x220/0x220
[1.551288] ? schedule_tail_wrapper+0x6/0x8
[1.552136] ? rest_init+0x220/0x220
[1.552873] ? ret_from_fork+0x2e/0x38
ALso, there is a similar warning for ip6mr.c :
=
WARNING: suspicious RCU usage
5.7.0-rc4-next-20200507-syzkaller #0 Not tainted
-
net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
other info that might help us
Re: [PATCH 2/3] remoteproc: Add inline coredump functionality
On Mon 11 May 17:41 PDT 2020, risha...@codeaurora.org wrote:
> On 2020-05-11 17:30, Bjorn Andersson wrote:
> > On Mon 11 May 17:11 PDT 2020, risha...@codeaurora.org wrote:
> > > On 2020-05-07 13:21, Bjorn Andersson wrote:
> > > > On Thu 16 Apr 11:38 PDT 2020, Rishabh Bhatnagar wrote:
> > > > > diff --git a/drivers/remoteproc/remoteproc_coredump.c
> > > > > b/drivers/remoteproc/remoteproc_coredump.c
[..]
> > > > > +static ssize_t rproc_read_dump(char *buffer, loff_t offset, size_t
> > > > > count,
> > > > > + void *data, size_t header_size)
> > > > > +{
> > > > > + void *device_mem;
> > > > > + size_t data_left, copy_size, bytes_left = count;
> > > > > + unsigned long addr;
> > > > > + struct rproc_coredump_state *dump_state = data;
> > > > > + struct rproc *rproc = dump_state->rproc;
> > > > > + void *elfcore = dump_state->header;
> > > > > +
> > > > > + /* Copy the header first */
> > > > > + if (offset < header_size) {
> > > > > + copy_size = header_size - offset;
> > > > > + copy_size = min(copy_size, bytes_left);
> > > > > +
> > > > > + memcpy(buffer, elfcore + offset, copy_size);
> > > > > + offset += copy_size;
> > > > > + bytes_left -= copy_size;
> > > > > + buffer += copy_size;
> > > > > + }
> > > >
> > > > Perhaps you can take inspiration from devcd_readv() here?
> > > >
> > > > > +
> > > > > + while (bytes_left) {
> > > > > + addr = resolve_addr(offset - header_size,
> > > > > + &rproc->dump_segments, &data_left);
> > > > > + /* EOF check */
> > > > > + if (data_left == 0) {
> > > >
> > > > Afaict data_left denotes the amount of data left in this particular
> > > > segment, rather than in the entire core.
> > > >
> > > Yes, but it only returns 0 when the final segment has been copied
> > > completely. Otherwise it gives data left to copy for every segment
> > > and moves to next segment once the current one is copied.
> >
> > You're right.
> >
> > > > I think you should start by making bytes_left the minimum of the core
> > > > size and @count and then have this loop as long as bytes_left, copying
> > > > data to the buffer either from header or an appropriate segment based on
> > > > the current offset.
> > > >
> > > That would require an extra function that calculates entire core size,
> > > as its not available right now. Do you see any missed corner cases
> > > with this
> > > approach?
> >
> > You're looping over all the segments as you're building the header
> > anyways, so you could simply store this in the dump_state. I think this
> > depend more on the ability to reuse the read function between inline and
> > default coredump.
> >
> > Regards,
> > Bjorn
>
> Wouldn't the first if condition take care of "default" dump as it is?
> The header_size in that case would involve the 'header + all segments'.
Correct.
Regards,
Bjorn
Re: [PATCH v8 01/11] pstore/zone: Introduce common layer to manage storage zones
On Tue, May 12, 2020 at 11:55:20AM +0800, WeiXiong Liao wrote:
> On 2020/5/12 AM 7:32, Kees Cook wrote:
> > [...]
> > +struct psz_context {
> > + struct pstore_zone **kpszs;
> > + unsigned int kmsg_max_cnt;
> > + unsigned int kmsg_read_cnt;
> > + unsigned int kmsg_write_cnt;
> > + /*
> > +* These counters should be calculated during recovery.
> > +* It records the oops/panic times after crashes rather than boots.
> > +*/
> > + unsigned int oops_counter;
> > + unsigned int panic_counter;
>
> oops/panic_counter is designed to count the crash times since the
> linux kernel was installed. pstore/zone lookup the max counter from all
> valid kmsg zones when recovery and saves them to oops/panic_counter.
> However, they are unable to get real number if we remove files. It's
> not serious, we can fix it after this series.
Since the kernel was installed? I don't see a kernel version check in
here? Or do you mean "since ever", in that it's a rolling count?
> And since pstore supports "max_reason", should pstore/zone count for
> other reason?
For now, no. I opted to try to keep this as simple as possible a port
from dump_oops to max_reason for now.
> > +static inline int psz_kmsg_erase(struct psz_context *cxt,
> > + struct pstore_zone *zone, struct pstore_record *record)
> > +{
> > + struct psz_buffer *buffer = zone->buffer;
> > + struct psz_kmsg_header *hdr =
> > + (struct psz_kmsg_header *)buffer->data;
> > +
> > + if (unlikely(!psz_ok(zone)))
> > + return 0;
> > + /* this zone is already updated, no need to erase */
> > + if (record->count != hdr->counter)
> > + return 0;
>
> These codes is to fix bug that user remove files on pstore filesystem
> but kmsg zone is already updated and pstore/zone should not erase
> zone. It work for oops and panic because the count number is increasing.
> However, it's useless for other reason of kmsg. We can fix it after this
> series.
Okay, sounds good.
--
Kees Cook
Re: Re: signal quality and cable diagnostic
On Mon, May 11, 2020 at 09:54:35PM +0200, Andrew Lunn wrote: > On Mon, May 11, 2020 at 07:32:05PM +, Christian Herber wrote: > > On May 11, 2020 4:33:53 PM Andrew Lunn wrote: > > > > > > Are the classes part of the Open Alliance specification? Ideally we > > > want to report something standardized, not something proprietary to > > > NXP. > > > > > >Andrew > > > > Hi Andrew, > > > > > Such mechanisms are standardized and supported by pretty much all > > devices in the market. The Open Alliance specification is publicly > > available here: > > http://www.opensig.org/download/document/218/Advanced_PHY_features_for_automotive_Ethernet_V1.0.pdf > > > > As the specification is newer than the 100BASE-T1 spec, do not > > expect first generation devices to follow the register definitions > > as per Open Alliance. But for future devices, also registers should > > be same across different vendors. > > Hi Christian > > Since we are talking about a kernel/user API definition here, i don't > care about the exact registers. What is important is the > naming/representation of the information. It seems like NXP uses Class > A - Class H, where as the standard calls them SQI=0 - SQI=7. So we > should name the KAPI based on the standard, not what NXP calls them. OK, sounds good for me. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] dma-buf: fix use-after-free in dmabuffs_dname
Thank you Greg for the comments.
On 5/6/2020 2:30 PM, Greg KH wrote:
On Wed, May 06, 2020 at 02:00:10PM +0530, Charan Teja Kalla wrote:
Thank you Greg for the reply.
On 5/5/2020 3:38 PM, Greg KH wrote:
On Tue, Apr 28, 2020 at 01:24:02PM +0530, Charan Teja Reddy wrote:
The following race occurs while accessing the dmabuf object exported as
file:
P1 P2
dma_buf_release() dmabuffs_dname()
[say lsof reading /proc//fd/]
read dmabuf stored in dentry->fsdata
Free the dmabuf object
Start accessing the dmabuf structure
In the above description, the dmabuf object freed in P1 is being
accessed from P2 which is resulting into the use-after-free. Below is
the dump stack reported.
Call Trace:
kasan_report+0x12/0x20
__asan_report_load8_noabort+0x14/0x20
dmabuffs_dname+0x4f4/0x560
tomoyo_realpath_from_path+0x165/0x660
tomoyo_get_realpath
tomoyo_check_open_permission+0x2a3/0x3e0
tomoyo_file_open
tomoyo_file_open+0xa9/0xd0
security_file_open+0x71/0x300
do_dentry_open+0x37a/0x1380
vfs_open+0xa0/0xd0
path_openat+0x12ee/0x3490
do_filp_open+0x192/0x260
do_sys_openat2+0x5eb/0x7e0
do_sys_open+0xf2/0x180
Fixes: bb2bb90 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Nit, please read the documentation for how to do a Fixes: line properly,
you need more digits:
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Will update the patch
Reported-by:syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
Signed-off-by: Charan Teja Reddy
Also, any reason you didn't include the other mailing lists that
get_maintainer.pl said to?
Really sorry for not sending to complete list. Added now.
And finally, no cc: stable in the s-o-b area for an issue that needs to
be backported to older kernels?
Will update the patch.
---
drivers/dma-buf/dma-buf.c | 25 +++--
include/linux/dma-buf.h | 1 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 570c923..069d8f78 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -38,18 +39,34 @@ struct dma_buf_list {
static struct dma_buf_list db_list;
+static void dmabuf_dent_put(struct dma_buf *dmabuf)
+{
+ if (atomic_dec_and_test(&dmabuf->dent_count)) {
+ kfree(dmabuf->name);
+ kfree(dmabuf);
+ }
Why not just use a kref instead of an open-coded atomic value?
Kref approach looks cleaner. will update the patch accordingly.
+}
+
static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
{
struct dma_buf *dmabuf;
char name[DMA_BUF_NAME_LEN];
size_t ret = 0;
+ spin_lock(&dentry->d_lock);
dmabuf = dentry->d_fsdata;
+ if (!dmabuf || !atomic_add_unless(&dmabuf->dent_count, 1, 0)) {
+ spin_unlock(&dentry->d_lock);
+ goto out;
How can dmabuf not be valid here?
And isn't there already a usecount for the buffer?
dmabuf exported as file simply relies on that file's refcount, thus fput()
releases the dmabuf.
We are storing the dmabuf in the dentry->d_fsdata but there is no binding
between the dentry and the dmabuf. So, flow will be like
1) P1 calls fput(dmabuf_fd)
2) P2 trying to access the file information of P1.
Eg: lsof command trying to list out the dmabuf_fd information using
/proc//fd/dmabuf_fd
3) P1 calls the file->f_op->release(dmabuf_fd_file)(ends up in calling
dma_buf_release()), thus frees up the dmabuf buffer.
4) P2 access the dmabuf stored in the dentry->d_fsdata which was freed in
step 3.
So we need to have some refcount mechanism to avoid the use-after-free in
step 4.
Ok, but watch out, now you have 2 different reference counts for the
same structure. Keeping them coordinated is almost always an impossible
task so you need to only rely on one. If you can't use the file api,
just drop all of the reference counting logic in there and only use the
kref one.
I feel that changing the refcount logic now to dma-buf objects involve
changes in
the core dma-buf framework. NO? Instead, how about passing the user
passed name directly
in the ->d_fsdata inplace of dmabuf object? Because we just need user
passed name in the
dmabuffs_dname(). With this we can avoid the need for extra refcount on
dmabuf.
Posted patch-V2: https://lkml.org/lkml/2020/5/8/158
good luck!
greg k-h
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: [PATCH v8 10/11] mtd: Support kmsg dumper based on pstore/blk
[resend to proper CC list...] On Tue, May 12, 2020 at 11:12:42AM +0800, WeiXiong Liao wrote: > hi Kees Cook, > > The off parameter on mtdpsore_block*() does not align to block size, > which makes some bugs. For example, a block contains 4 dmesg zones > and it's expected to erase this block when user remove all files on > these zones. However it work failed since it get wrongly zonenum from > misaligned off. Ah, okay. I haven't touched any of this logic. Did something change in pstore/blk or /zone that I broke? Regardless, can you send a regular patch for what you have below and I'll fold it into the mtdpstore commit. Thanks! -Kees > On 2020/5/12 AM 7:32, Kees Cook wrote: > > From: WeiXiong Liao > > > > This introduces mtdpstore, which is similar to mtdoops but more > > powerful. It uses pstore/blk, and aims to store panic and oops logs to > > a flash partition, where pstore can later read back and present as files > > in the mounted pstore filesystem. > > > > To make mtdpstore work, the "blkdev" of pstore/blk should be set > > as MTD device name or MTD device number. For more details, see > > Documentation/admin-guide/pstore-blk.rst > > > > This solves a number of issues: > > - Work duplication: both of pstore and mtdoops do the same job storing > > panic/oops log. They have very similar logic, registering to kmsg > > dumper and storing logs to several chunks one by one. > > - Layer violations: drivers should provides methods instead of polices. > > MTD should provide read/write/erase operations, and allow a higher > > level drivers to provide the chunk management, kmsg dump > > configuration, etc. > > - Missing features: pstore provides many additional features, including > > presenting the logs as files, logging dump time and count, and > > supporting other frontends like pmsg, console, etc. > > > > Signed-off-by: WeiXiong Liao > > Link: > > https://lore.kernel.org/r/1585126506-18635-12-git-send-email-liaoweixi...@allwinnertech.com > > Signed-off-by: Kees Cook > > --- > > Documentation/admin-guide/pstore-blk.rst | 9 +- > > drivers/mtd/Kconfig | 10 + > > drivers/mtd/Makefile | 1 + > > drivers/mtd/mtdpstore.c | 563 +++ > > 4 files changed, 581 insertions(+), 2 deletions(-) > > create mode 100644 drivers/mtd/mtdpstore.c > > > > diff --git a/Documentation/admin-guide/pstore-blk.rst > > b/Documentation/admin-guide/pstore-blk.rst > > index d45341e55e82..296d5027787a 100644 > > --- a/Documentation/admin-guide/pstore-blk.rst > > +++ b/Documentation/admin-guide/pstore-blk.rst > > @@ -43,9 +43,9 @@ blkdev > > ~~ > > > > The block device to use. Most of the time, it is a partition of block > > device. > > -It's required for pstore/blk. > > +It's required for pstore/blk. It is also used for MTD device. > > > > -It accepts the following variants: > > +It accepts the following variants for block device: > > > > 1. device number in hexadecimal represents itself; > > no > > leading 0x, for example b302. > > @@ -64,6 +64,11 @@ It accepts the following variants: > > partition with a known unique id. > > #. : major and minor number of the device separated by a > > colon. > > > > +It accepts the following variants for MTD device: > > + > > +1. MTD device name. "pstore" is recommended. > > +#. MTD device number. > > + > > kmsg_size > > ~ > > > > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > > index 42d401ea60ee..6ddab796216d 100644 > > --- a/drivers/mtd/Kconfig > > +++ b/drivers/mtd/Kconfig > > @@ -170,6 +170,16 @@ config MTD_OOPS > > buffer in a flash partition where it can be read back at some > > later point. > > > > +config MTD_PSTORE > > + tristate "Log panic/oops to an MTD buffer based on pstore" > > + depends on PSTORE_BLK > > + help > > + This enables panic and oops messages to be logged to a circular > > + buffer in a flash partition where it can be read back as files after > > + mounting pstore filesystem. > > + > > + If unsure, say N. > > + > > config MTD_SWAP > > tristate "Swap on MTD device support" > > depends on MTD && SWAP > > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > > index 56cc60ccc477..593d0593a038 100644 > > --- a/drivers/mtd/Makefile > > +++ b/drivers/mtd/Makefile > > @@ -20,6 +20,7 @@ obj-$(CONFIG_RFD_FTL) += rfd_ftl.o > > obj-$(CONFIG_SSFDC)+= ssfdc.o > > obj-$(CONFIG_SM_FTL) += sm_ftl.o > > obj-$(CONFIG_MTD_OOPS) += mtdoops.o > > +obj-$(CONFIG_MTD_PSTORE) += mtdpstore.o > > obj-$(CONFIG_MTD_SWAP) += mtdswap.o > > > > nftl-objs := nftlcore.o nftlmount.o > > diff --git a/drivers/mtd/mtdpstore.c b/drivers/mtd/mtdpstore.c > > new file mode 100644 > > index ..06084eff1004 > > --- /dev/null > > +++ b/drivers/mtd/mtdpstore.c > > @@ -0,0 +1,563 @@ > > +// SPDX-License-Identifier: GPL-
RE: [PATCH v7 1/7] i3c: master: secondary master initialization document
>> Document describing secondary master initialization, >> mastership handover and DEFSLVS handling processes. > >Thanks for doing that, but you probably didn't try to compile the doc >(the formatting is all messed up). > ># make htmldocs Yes, it looks messed in email but I built html format of doc and formatting was ok. May be because some tab/space issue it is looking messed up in email. I will check that. Regards, Parshuram Thombare
Re: linux-next boot error: WARNING: suspicious RCU usage in ip6mr_get_table
On Tue, May 12, 2020 at 11:28:47AM +1000, Stephen Rothwell wrote: > Hi all, > > On Fri, 8 May 2020 04:54:02 +0530 Madhuparna Bhowmik > wrote: > > > > On Thu, May 07, 2020 at 08:50:55AM -0400, Qian Cai wrote: > > > > > > > > > > On May 7, 2020, at 5:32 AM, Dmitry Vyukov wrote: > > > > > > > > On Thu, May 7, 2020 at 11:26 AM syzbot > > > > wrote: > > > >> > > > >> Hello, > > > >> > > > >> syzbot found the following crash on: > > > >> > > > >> HEAD commit:6b43f715 Add linux-next specific files for 20200507 > > > >> git tree: linux-next > > > >> console output: > > > >> https://syzkaller.appspot.com/x/log.txt?x=16f6437010 > > > >> kernel config: > > > >> https://syzkaller.appspot.com/x/.config?x=ef9b7a80b923f328 > > > >> dashboard link: > > > >> https://syzkaller.appspot.com/bug?extid=761cff389b454aa387d2 > > > >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > >> > > > >> Unfortunately, I don't have any reproducer for this crash yet. > > > >> > > > >> IMPORTANT: if you fix the bug, please add the following tag to the > > > >> commit: > > > >> Reported-by: syzbot+761cff389b454aa38...@syzkaller.appspotmail.com > > > > > > > > > > > > +linux-next for linux-next boot breakage > > > > > > Amol, Madhuparna, Is either of you still working on this? > > > > > > >> = > > > >> WARNING: suspicious RCU usage > > > >> 5.7.0-rc4-next-20200507-syzkaller #0 Not tainted > > > >> - > > > >> net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!! > > > >> > > I had some doubt in this one, I have already mailed the maintainers, > > waiting for their reply. > > This is blocking syzbot testing of linux-next ... are we getting > anywhere? Will a patch similar to the ipmr.c one help here? > Hi Stephen, There are some discussions going on about the ipmr.c patch, I guess even ip6mr can be fixed in a similar way. Let me still confirm once. Thank you, Mahuparna > -- > Cheers, > Stephen Rothwell
Re: [PATCH] kernel: sysctl: ignore invalid taint bits introduced via kernel.tainted and taint the kernel with TAINT_USER on writes
On Mon, May 11, 2020 at 09:03:13PM -0400, Rafael Aquini wrote:
> On Tue, May 12, 2020 at 12:17:03AM +, Luis Chamberlain wrote:
> > On Mon, May 11, 2020 at 07:59:14PM -0400, Rafael Aquini wrote:
> > > On Mon, May 11, 2020 at 11:10:45PM +, Luis Chamberlain wrote:
> > > > On Mon, May 11, 2020 at 05:59:04PM -0400, Rafael Aquini wrote:
> > > > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > > > > index 8a176d8727a3..f0a4fb38ac62 100644
> > > > > --- a/kernel/sysctl.c
> > > > > +++ b/kernel/sysctl.c
> > > > > @@ -2623,17 +2623,32 @@ static int proc_taint(struct ctl_table
> > > > > *table, int write,
> > > > > return err;
> > > > >
> > > > > if (write) {
> > > > > + int i;
> > > > > +
> > > > > + /*
> > > > > + * Ignore user input that would make us committing
> > > > > + * arbitrary invalid TAINT flags in the loop below.
> > > > > + */
> > > > > + tmptaint &= (1UL << TAINT_FLAGS_COUNT) - 1;
> > > >
> > > > This looks good but we don't pr_warn() of information lost on intention.
> > > >
> > >
> > > Are you thinking in sth like:
> > >
> > > + if (tmptaint > TAINT_FLAGS_MAX) {
> > > + tmptaint &= TAINT_FLAGS_MAX;
> > > + pr_warn("proc_taint: out-of-range invalid input
> > > ignored"
> > > + " tainted_mask adjusted to 0x%x\n",
> > > tmptaint);
> > > + }
> > > ?
> >
> > Sure that would clarify this.
> >
> > > > > +
> > > > > /*
> > > > >* Poor man's atomic or. Not worth adding a primitive
> > > > >* to everyone's atomic.h for this
> > > > >*/
> > > > > - int i;
> > > > > for (i = 0; i < BITS_PER_LONG && tmptaint >> i; i++) {
> > > > > if ((tmptaint >> i) & 1)
> > > > > add_taint(i, LOCKDEP_STILL_OK);
> > > > > }
> > > > > +
> > > > > + /*
> > > > > + * Users with SYS_ADMIN capability can include any
> > > > > arbitrary
> > > > > + * taint flag by writing to this interface. If that's
> > > > > the case,
> > > > > + * we also need to mark the kernel "tainted by user".
> > > > > + */
> > > > > + add_taint(TAINT_USER, LOCKDEP_STILL_OK);
> > > >
> > > > I'm in favor of this however I'd like to hear from Ted on if it meets
> > > > the original intention. I would think he had a good reason not to add
> > > > it here.
> > > >
> > >
> > > Fair enough. The impression I got by reading Ted's original commit
> > > message is that the intent was to have TAINT_USER as the flag set
> > > via this interface, even though the code was allowing for any
> > > arbitrary value.
> >
> > That wasn't my reading, it was that the user did something very odd
> > with user input which we don't like as kernel developers, and it gives
> > us a way to prove: hey you did something stupid, sorry but I cannot
> > support your kernel panic.
> >
> > > I think it's OK to let the user fiddle with
> > > the flags, as it's been allowed since the introduction of
> > > this interface, but we need to reflect that fact in the
> > > tainting itself. Since TAINT_USER is not used anywhere,
> >
> > I see users of TAINT_USER sprinkled around
> >
>
> I meant in the original commit that introduced it
> (commit 34f5a39899f3f3e815da64f48ddb72942d86c366). Sorry I
> miscomunicated that.
>
> In its current usage, it seems that the other places adding TAINT_USER
> match with what is being proposed here: To signal when we have user
> fiddling with kernel / module parameters.
drivers/base/regmap/regmap-debugfs.c requires *manual* code changes
to compile / enable some knob. i915 complains about unsafe module
params such as module_param_cb_unsafe() core_param_unsafe(). Then
drivers/soundwire/cadence_master.c is for when a debugfs dangerous
param was used.
This still doesn't rule out the use of proc_taint() for testing taint,
and that adding it may break some tests. So even though this would
only affect some tests scripts, I can't say that adding this taint won't
cause some headaches to someone. I wouldn't encourage its use on
proc_taint() from what I can see so far.
Luis
[PATCH] perf record: Use an eventfd to wakeup when done
The setting and checking of 'done' contains a rare race where the signal
handler setting 'done' is run after checking to break the loop, but
before waiting in evlist__poll(). In this case, the main loop won't wake
up until either another signal is sent, or the perf data fd causes a
wake up.
The following simple script can trigger this condition (but you might
need to run it for several hours):
for ((i = 0; i >= 0; i++)) ; do
echo "Loop $i"
delay=$(echo "scale=4; 0.1 * $RANDOM/32768" | bc)
./perf record -- sleep 3000 >/dev/null&
pid=$!
sleep $delay
kill -TERM $pid
echo "PID $pid"
wait $pid
done
At some point, the loop will stall. Adding logging, even though perf has
received the SIGTERM and set 'done = 1', perf will remain sleeping until
a second signal is sent.
Signed-off-by: Anand K Mistry
---
tools/perf/builtin-record.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 1ab349abe90469..099ecaa66732a2 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -518,15 +519,28 @@ static int record__pushfn(struct mmap *map, void *to,
void *bf, size_t size)
static volatile int signr = -1;
static volatile int child_finished;
+static int done_fd = -1;
static void sig_handler(int sig)
{
+ u64 tmp = 1;
if (sig == SIGCHLD)
child_finished = 1;
else
signr = sig;
done = 1;
+
+ /*
+* It is possible for this signal handler to run after done is checked
+* in the main loop, but before the perf counter fds are polled. If this
+* happens, the poll() will continue to wait even though done is set,
+* and will only break out if either another signal is received, or the
+* counters are ready for read. To ensure the poll() doesn't sleep when
+* done is set, use an eventfd (done_fd) to wake up the poll().
+*/
+ if (write(done_fd, &tmp, sizeof(tmp)) < 0)
+ pr_err("failed to signal wakeup fd\n");
}
static void sigsegv_handler(int sig)
@@ -1424,6 +1438,17 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
int fd;
float ratio = 0;
+ done_fd = eventfd(0, EFD_NONBLOCK);
+ if (done_fd < 0) {
+ pr_err("Failed to create wakeup eventfd, error: %m\n");
+ return -1;
+ }
+ err = evlist__add_pollfd(rec->evlist, done_fd);
+ if (err < 0) {
+ pr_err("Failed to add wakeup eventfd to poll list\n");
+ return -1;
+ }
+
atexit(record__sig_exit);
signal(SIGCHLD, sig_handler);
signal(SIGINT, sig_handler);
--
2.26.2.645.ge9eca65c58-goog
RE: [PATCH v7 2/7] i3c: master: use i3c_master_register only for main master
>> +/** >> + * i3c_master_register() - register an I3C master > >The function should be renamed and the doc updated to reflect the fact >that it only works for primary masters: > >i3c_primary_master_register() - register a primary I3C master Sure, I will do that. >> + * @master: master used to send frames on the bus >> + * @parent: the parent device (the one that provides this I3C master >> + * controller) >> + * @ops: the master controller operations >> + * @secondary: true if you are registering a secondary master. Will return >> + * -ENOTSUPP if set to true since secondary masters are not yet >> + * supported > >This argument no longer exists. Thanks, I missed that comment. It should be removed. Regards, Parshuram Thombare
Re: [PATCH v10 08/11] KVM: x86/pmu: Add LBR feature emulation via guest LBR event
On 2020/5/8 21:09, Peter Zijlstra wrote:
On Mon, Apr 27, 2020 at 11:16:40AM +0800, Like Xu wrote:
On 2020/4/24 20:16, Peter Zijlstra wrote:
And I suppose that is why you need that horrible:
needs_guest_lbr_without_counter() thing to begin with.
Do you suggest to use event->attr.config check to replace
"needs_branch_stack(event) && is_kernel_event(event) &&
event->attr.exclude_host" check for guest LBR event ?
That's what the BTS thing does.
Thanks, I'll apply it.
Please allocate yourself an event from the pseudo event range:
event==0x00. Currently we only have umask==3 for Fixed2 and umask==4
for Fixed3, given you claim 58, which is effectively Fixed25,
umask==0x1a might be appropriate.
OK, I assume that adding one more field ".config = 0x1a00" is
efficient enough for perf_event_attr to allocate guest LBR events.
Uh what? The code is already setting .config. You just have to change it
do another value.
Thanks, I'll apply it.
Also, I suppose we need to claim 0x as an error, so that other
people won't try this again.
Does the following fix address your concern on this ?
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 2405926e2dba..32d2a3f8c51f 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -498,6 +498,9 @@ int x86_pmu_max_precise(void)
int x86_pmu_hw_config(struct perf_event *event)
{
+ if (!unlikely(event->attr.config & X86_ARCH_EVENT_MASK))
+ return -EINVAL;
+
if (event->attr.precise_ip) {
int precise = x86_pmu_max_precise();
That wouldn't work right for AMD. But yes, something like that.
Sure, I may figure it out and leave it in another thread.
Also, what happens if you fail programming due to a conflicting cpu
event? That pinned doesn't guarantee you'll get the event, it just means
you'll error instead of getting RR.
I didn't find any code checking the event state.
Error instead of RR is expected.
If the KVM fails programming due to a conflicting cpu event
the LBR registers will not be passthrough to the guest,
and KVM would return zero for any guest LBR records accesses
until the next attempt to program the guest LBR event.
Every time before cpu enters the non-root mode where irq is
disabled, the "event-> oncpu! =-1" check will be applied.
(more details in the comment around intel_pmu_availability_check())
The guests administer is supposed to know the result of guest
LBR records is inaccurate if someone is using LBR to record
guest or hypervisor on the host side.
Is this acceptable to you？
If there is anything needs to be improved, please let me know.
It might be nice to emit a pr_warn() or something on the host when this
happens. Then at least the host admin can know he wrecked things for
which guest.
Sure, I will use pr_warn () and indicate which guest it is.
If you have more comments on the patchset, please let me know.
If not, I'll spin the next version based on your current feedback.
Thanks,
Like Xu
[Patch v2] efi: cper: Add support for printing Firmware Error Record Reference
While debugging a boot failure, the following unknown error record was
seen in the boot logs.
<...>
BERT: Error records from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section type: unknown,
81212a96-09ed-4996-9471-8d729c8e69ed
[Hardware Error]: section length: 0x290
[Hardware Error]: : 0001 00020002
[Hardware Error]: 0010: 00020002 001f 0320
...
[Hardware Error]: 0020:
[Hardware Error]: 0030:
<...>
On further investigation, it was found that the error record with
UUID (81212a96-09ed-4996-9471-8d729c8e69ed) has been defined in the
UEFI Specification at least since v2.4 and has recently had additional
fields defined in v2.7 Section N.2.10 Firmware Error Record Reference.
Add support for parsing and printing the defined fields to give users
a chance to figure out what went wrong.
Signed-off-by: Punit Agrawal
Cc: Ard Biesheuvel
Cc: "Rafael J. Wysocki"
Cc: Borislav Petkov
Cc: James Morse
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
Hi Ard,
I've updated the patch based on your feedback.
As you noted, some aspects of the spec make it a bit tricky to support
all revisions in a nice way (e.g., size check) but this version should
fix existing issues.
Thanks,
Punit
v1[0] -> v2:
* Simplified error record structure definition
* Fixed size check
* Added comment to clarify offset calculation for dumped data
* Style fixes for multiline if blocks
[0]
https://lkml.kernel.org/lkml/20200427085242.2380614-1-punit1.agra...@toshiba.co.jp/
---
drivers/firmware/efi/cper.c | 62 +
include/linux/cper.h| 9 ++
2 files changed, 71 insertions(+)
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 9d2512913d25..f564e15fbc7e 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -407,6 +407,58 @@ static void cper_print_pcie(const char *pfx, const struct
cper_sec_pcie *pcie,
}
}
+static const char * const fw_err_rec_type_strs[] = {
+ "IPF SAL Error Record",
+ "SOC Firmware Error Record Type1 (Legacy CrashLog Support)",
+ "SOC Firmware Error Record Type2",
+};
+
+static void cper_print_fw_err(const char *pfx,
+ struct acpi_hest_generic_data *gdata,
+ const struct cper_sec_fw_err_rec_ref *fw_err)
+{
+ void *buf = acpi_hest_get_payload(gdata);
+ u32 offset, length = gdata->error_data_length;
+
+ printk("%s""Firmware Error Record Type: %s\n", pfx,
+ fw_err->record_type < ARRAY_SIZE(fw_err_rec_type_strs) ?
+ fw_err_rec_type_strs[fw_err->record_type] : "unknown");
+ printk("%s""Revision: %d\n", pfx, fw_err->revision);
+
+ /* Record Type based on UEFI 2.7 */
+ if (fw_err->revision == 0) {
+ printk("%s""Record Identifier: %08llx\n", pfx,
+ fw_err->record_identifier);
+ } else if (fw_err->revision == 2) {
+ printk("%s""Record Identifier: %pUl\n", pfx,
+ &fw_err->record_identifier_guid);
+ }
+
+ /*
+* The FW error record may contain trailing data beyond the
+* structure defined by the specification. As the fields
+* defined (and hence the offset of any trailing data) vary
+* with the revision, set the offset to account for this
+* variation.
+*/
+ if (fw_err->revision == 0) {
+ /* record_identifier_guid not defined */
+ offset = offsetof(struct cper_sec_fw_err_rec_ref,
+ record_identifier_guid);
+ } else if (fw_err->revision == 1) {
+ /* record_identifier not defined */
+ offset = offsetof(struct cper_sec_fw_err_rec_ref,
+ record_identifier);
+ } else {
+ offset = sizeof(*fw_err);
+ }
+
+ buf += offset;
+ length -= offset;
+
+ print_hex_dump(pfx, "", DUMP_PREFIX_OFFSET, 16, 4, buf, length, true);
+}
+
static void cper_print_tstamp(const char *pfx,
struct acpi_hest_generic_data_v300 *gdata)
{
@@ -494,6 +546,16 @@ cper_estatus_print_section(const char *pfx, struct
acpi_hest_generic_data *gdata
else
goto err_section_too_small;
#endif
+ } else if (guid_equal(sec_type, &CPER_SEC_FW_ERR_REC_REF)) {
+ struct cper_sec_fw_err_rec_ref *fw_err =
acpi_hest_get_payload(gdata);
+
+ printk("%ssection_type: Firmware Error Record Reference\n",
+ newpfx);
+ /* The minimal FW Error Record contains 16 bytes */
+
linux-next: manual merge of the sound-asoc tree with the crypto tree
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in:
sound/soc/codecs/cros_ec_codec.c
between commit:
85fc78b80f15 ("ASoC: cros_ec_codec: use crypto_shash_tfm_digest()")
from the crypto tree and commit:
a1304cba816e ("ASoC: cros_ec_codec: allocate shash_desc dynamically")
from the sound-asoc tree.
I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpNsvVFXELLN.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS
On Mon, May 4, 2020 at 5:08 PM Masahiro Yamada wrote:
>
> Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES
> because the difference is just the -r option passed to the 'rm' command.
>
> Do likewise as commit 1634f2bfdb84 ("kbuild: remove clean-dirs syntax").
>
> Signed-off-by: Masahiro Yamada
Applied to linux-kbuild.
> ---
>
> Makefile | 22 ++
> arch/um/Makefile | 2 +-
> 2 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ffd80afcd0bb..8a7c931cc0d9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1389,14 +1389,14 @@ endif # CONFIG_MODULES
> # make distclean Remove editor backup files, patch leftover files and the
> like
>
> # Directories & files removed with 'make clean'
> -CLEAN_DIRS += include/ksym
> -CLEAN_FILES += modules.builtin modules.builtin.modinfo modules.nsdeps
> +CLEAN_FILES += include/ksym \
> + modules.builtin modules.builtin.modinfo modules.nsdeps
>
> # Directories & files removed with 'make mrproper'
> -MRPROPER_DIRS += include/config include/generated \
> +MRPROPER_FILES += include/config include/generated \
> arch/$(SRCARCH)/include/generated .tmp_objdiff \
> - debian/ snap/ tar-install/
> -MRPROPER_FILES += .config .config.old .version \
> + debian snap tar-install \
> + .config .config.old .version \
> Module.symvers \
> signing_key.pem signing_key.priv signing_key.x509 \
> x509.genkey extra_certificates signing_key.x509.keyid \
> @@ -1404,12 +1404,10 @@ MRPROPER_FILES += .config .config.old .version \
> *.spec
>
> # Directories & files removed with 'make distclean'
> -DISTCLEAN_DIRS +=
> DISTCLEAN_FILES += tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
>
> # clean - Delete most, but leave enough to build external modules
> #
> -clean: rm-dirs := $(CLEAN_DIRS)
> clean: rm-files := $(CLEAN_FILES)
>
> PHONY += archclean vmlinuxclean
> @@ -1422,7 +1420,6 @@ clean: archclean vmlinuxclean
>
> # mrproper - Delete all generated files, including .config
> #
> -mrproper: rm-dirs := $(wildcard $(MRPROPER_DIRS))
> mrproper: rm-files := $(wildcard $(MRPROPER_FILES))
> mrproper-dirs := $(addprefix _mrproper_,scripts)
>
> @@ -1431,18 +1428,15 @@ $(mrproper-dirs):
> $(Q)$(MAKE) $(clean)=$(patsubst _mrproper_%,%,$@)
>
> mrproper: clean $(mrproper-dirs)
> - $(call cmd,rmdirs)
> $(call cmd,rmfiles)
>
> # distclean
> #
> -distclean: rm-dirs := $(wildcard $(DISTCLEAN_DIRS))
> distclean: rm-files := $(wildcard $(DISTCLEAN_FILES))
>
> PHONY += distclean
>
> distclean: mrproper
> - $(call cmd,rmdirs)
> $(call cmd,rmfiles)
> @find $(srctree) $(RCS_FIND_IGNORE) \
> \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
> @@ -1732,7 +1726,6 @@ $(clean-dirs):
> $(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
>
> clean: $(clean-dirs)
> - $(call cmd,rmdirs)
> $(call cmd,rmfiles)
> @find $(if $(KBUILD_EXTMOD), $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
> \( -name '*.[aios]' -o -name '*.ko' -o -name '.*.cmd' \
> @@ -1827,11 +1820,8 @@ tools/%: FORCE
> $(Q)mkdir -p $(objtree)/tools
> $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j%
> -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ $*
>
> -quiet_cmd_rmdirs = $(if $(wildcard $(rm-dirs)),CLEAN $(wildcard
> $(rm-dirs)))
> - cmd_rmdirs = rm -rf $(rm-dirs)
> -
> quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN $(wildcard
> $(rm-files)))
> - cmd_rmfiles = rm -f $(rm-files)
> + cmd_rmfiles = rm -rf $(rm-files)
>
> # Run depmod only if we have System.map and depmod is executable
> quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
> diff --git a/arch/um/Makefile b/arch/um/Makefile
> index 275f5ffdf6f0..3f27aa3ec0a6 100644
> --- a/arch/um/Makefile
> +++ b/arch/um/Makefile
> @@ -140,7 +140,7 @@ export CFLAGS_vmlinux := $(LINK-y) $(LINK_WRAPS)
> $(LD_FLAGS_CMDLINE)
> # When cleaning we don't include .config, so we don't include
> # TT or skas makefiles and don't clean skas_ptregs.h.
> CLEAN_FILES += linux x.i gmon.out
> -MRPROPER_DIRS += arch/$(SUBARCH)/include/generated
> +MRPROPER_FILES += arch/$(SUBARCH)/include/generated
>
> archclean:
> @find . \( -name '*.bb' -o -name '*.bbg' -o -name '*.da' \
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
[RFC] e1000e: Relax condition to trigger reset for ME workaround
It's an error if the value of the RX/TX tail descriptor does not match
what was written. The error condition is true regardless the duration
of the interference from ME. But the code only performs the reset if
E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have
transpired. The extra condition can lead to inconsistency between the
state of hardware as expected by the driver.
Fix this by dropping the check for number of delay iterations.
Signed-off-by: Punit Agrawal
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Hi,
The issue was noticed through code inspection while backporting the
workaround for TDT corruption. Sending it out as an RFC as I am not
familiar with the hardware internals of the e1000e.
Another unresolved question is the inherent racy nature of the
workaround - the ME could block access again after releasing the
device (i.e., BIT(E1000_ICH_FWSM_PCIM2PCI) clear) but before the
driver performs the write. Has this not been a problem?
Any feedback on the patch or the more information on the issues
appreciated.
Thanks,
Punit
drivers/net/ethernet/intel/e1000e/netdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 177c6da80c57..5ed4d7ed35b3 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -607,11 +607,11 @@ static void e1000e_update_rdt_wa(struct e1000_ring
*rx_ring, unsigned int i)
{
struct e1000_adapter *adapter = rx_ring->adapter;
struct e1000_hw *hw = &adapter->hw;
- s32 ret_val = __ew32_prepare(hw);
+ __ew32_prepare(hw);
writel(i, rx_ring->tail);
- if (unlikely(!ret_val && (i != readl(rx_ring->tail {
+ if (unlikely(i != readl(rx_ring->tail))) {
u32 rctl = er32(RCTL);
ew32(RCTL, rctl & ~E1000_RCTL_EN);
@@ -624,11 +624,11 @@ static void e1000e_update_tdt_wa(struct e1000_ring
*tx_ring, unsigned int i)
{
struct e1000_adapter *adapter = tx_ring->adapter;
struct e1000_hw *hw = &adapter->hw;
- s32 ret_val = __ew32_prepare(hw);
+ __ew32_prepare(hw);
writel(i, tx_ring->tail);
- if (unlikely(!ret_val && (i != readl(tx_ring->tail {
+ if (unlikely(i != readl(tx_ring->tail))) {
u32 tctl = er32(TCTL);
ew32(TCTL, tctl & ~E1000_TCTL_EN);
--
2.26.2
[PATCH v4 2/2] KVM: x86/pmu: Support full width counting
Intel CPUs have a new alternative MSR range (starting from MSR_IA32_PMC0)
for GP counters that allows writing the full counter width. Enable this
range from a new capability bit (IA32_PERF_CAPABILITIES.FW_WRITE[bit 13]).
The guest would query CPUID to get the counter width, and sign extends
the counter values as needed. The traditional MSRs always limit to 32bit,
even though the counter internally is larger (usually 48 bits).
When the new capability is set, use the alternative range which do not
have these restrictions. This lowers the overhead of perf stat slightly
because it has to do less interrupts to accumulate the counter value.
Signed-off-by: Like Xu
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/cpuid.c| 2 +-
arch/x86/kvm/vmx/capabilities.h | 11
arch/x86/kvm/vmx/pmu_intel.c| 46 ++---
arch/x86/kvm/vmx/vmx.c | 3 +++
arch/x86/kvm/x86.c | 1 +
6 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 35a915787559..8c3ae83f63d9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -599,6 +599,7 @@ struct kvm_vcpu_arch {
u64 ia32_xss;
u64 microcode_version;
u64 arch_capabilities;
+ u64 perf_capabilities;
/*
* Paging state of the vcpu
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 35845704cf57..411ce1b58341 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -294,7 +294,7 @@ void kvm_set_cpu_caps(void)
F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ |
0 /* DS-CPL, VMX, SMX, EST */ |
0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* Reserved */ |
- F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ |
+ F(FMA) | F(CX16) | 0 /* xTPR Update */ | F(PDCM) |
F(PCID) | 0 /* Reserved, DCA */ | F(XMM4_1) |
F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) |
0 /* Reserved*/ | F(AES) | F(XSAVE) | 0 /* OSXSAVE */ | F(AVX) |
diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index 8903475f751e..4bbd8b448d22 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -18,6 +18,8 @@ extern int __read_mostly pt_mode;
#define PT_MODE_SYSTEM 0
#define PT_MODE_HOST_GUEST 1
+#define PMU_CAP_FW_WRITES (1ULL << 13)
+
struct nested_vmx_msrs {
/*
* We only store the "true" versions of the VMX capability MSRs. We
@@ -367,4 +369,13 @@ static inline bool vmx_pt_mode_is_host_guest(void)
return pt_mode == PT_MODE_HOST_GUEST;
}
+static inline u64 vmx_get_perf_capabilities(void)
+{
+ /*
+* Since counters are virtualized, KVM would support full
+* width counting unconditionally, even if the host lacks it.
+*/
+ return PMU_CAP_FW_WRITES;
+}
+
#endif /* __KVM_X86_VMX_CAPS_H */
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index e1a303fefc16..f66a3e2e42cd 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -18,6 +18,8 @@
#include "nested.h"
#include "pmu.h"
+#define MSR_PMC_FULL_WIDTH_BIT (MSR_IA32_PMC0 - MSR_IA32_PERFCTR0)
+
static struct kvm_event_hw_type_mapping intel_arch_events[] = {
/* Index must match CPUID 0x0A.EBX bit vector */
[0] = { 0x3c, 0x00, PERF_COUNT_HW_CPU_CYCLES },
@@ -150,6 +152,14 @@ static struct kvm_pmc *intel_rdpmc_ecx_to_pmc(struct
kvm_vcpu *vcpu,
return &counters[array_index_nospec(idx, num_counters)];
}
+static inline bool fw_writes_is_enabled(struct kvm_vcpu *vcpu)
+{
+ if (!guest_cpuid_has(vcpu, X86_FEATURE_PDCM))
+ return false;
+
+ return vcpu->arch.perf_capabilities & PMU_CAP_FW_WRITES;
+}
+
static bool intel_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
@@ -162,10 +172,15 @@ static bool intel_is_valid_msr(struct kvm_vcpu *vcpu, u32
msr)
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
ret = pmu->version > 1;
break;
+ case MSR_IA32_PERF_CAPABILITIES:
+ ret = guest_cpuid_has(vcpu, X86_FEATURE_PDCM);
+ break;
default:
ret = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0) ||
get_gp_pmc(pmu, msr, MSR_P6_EVNTSEL0) ||
- get_fixed_pmc(pmu, msr);
+ get_fixed_pmc(pmu, msr) ||
+ (fw_writes_is_enabled(vcpu) &&
+ get_gp_pmc(pmu, msr, MSR_IA32_PMC0));
break;
}
@@ -203,8 +218,15 @@ static int intel_pmu_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
msr_info->data = pmu->global_ovf_ctrl;
return 0;
+ case MSR_IA32_PERF
[PATCH 1/2] KVM: x86/pmu: Tweak kvm_pmu_get_msr to pass 'struct msr_data' in
From: Wei Wang
Change kvm_pmu_get_msr() to get the msr_data struct, as the host_initiated
field from the struct could be used by get_msr. This also makes this API
consistent with kvm_pmu_set_msr. No functional changes.
Signed-off-by: Wei Wang
---
arch/x86/kvm/pmu.c | 4 ++--
arch/x86/kvm/pmu.h | 4 ++--
arch/x86/kvm/svm/pmu.c | 7 ---
arch/x86/kvm/vmx/pmu_intel.c | 19 +++
arch/x86/kvm/x86.c | 4 ++--
5 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index a5078841bdac..b86346903f2e 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -397,9 +397,9 @@ static void kvm_pmu_mark_pmc_in_use(struct kvm_vcpu *vcpu,
u32 msr)
__set_bit(pmc->idx, pmu->pmc_in_use);
}
-int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
+int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
- return kvm_x86_ops.pmu_ops->get_msr(vcpu, msr, data);
+ return kvm_x86_ops.pmu_ops->get_msr(vcpu, msr_info);
}
int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index a6c78a797cb1..ab85eed8a6cc 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -32,7 +32,7 @@ struct kvm_pmu_ops {
struct kvm_pmc *(*msr_idx_to_pmc)(struct kvm_vcpu *vcpu, u32 msr);
int (*is_valid_rdpmc_ecx)(struct kvm_vcpu *vcpu, unsigned int idx);
bool (*is_valid_msr)(struct kvm_vcpu *vcpu, u32 msr);
- int (*get_msr)(struct kvm_vcpu *vcpu, u32 msr, u64 *data);
+ int (*get_msr)(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
int (*set_msr)(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
void (*refresh)(struct kvm_vcpu *vcpu);
void (*init)(struct kvm_vcpu *vcpu);
@@ -147,7 +147,7 @@ void kvm_pmu_handle_event(struct kvm_vcpu *vcpu);
int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
int kvm_pmu_is_valid_rdpmc_ecx(struct kvm_vcpu *vcpu, unsigned int idx);
bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr);
-int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data);
+int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
void kvm_pmu_refresh(struct kvm_vcpu *vcpu);
void kvm_pmu_reset(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c
index ce0b10fe5e2b..035da07500e8 100644
--- a/arch/x86/kvm/svm/pmu.c
+++ b/arch/x86/kvm/svm/pmu.c
@@ -215,21 +215,22 @@ static struct kvm_pmc *amd_msr_idx_to_pmc(struct kvm_vcpu
*vcpu, u32 msr)
return pmc;
}
-static int amd_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
+static int amd_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct kvm_pmc *pmc;
+ u32 msr = msr_info->index;
/* MSR_PERFCTRn */
pmc = get_gp_pmc_amd(pmu, msr, PMU_TYPE_COUNTER);
if (pmc) {
- *data = pmc_read_counter(pmc);
+ msr_info->data = pmc_read_counter(pmc);
return 0;
}
/* MSR_EVNTSELn */
pmc = get_gp_pmc_amd(pmu, msr, PMU_TYPE_EVNTSEL);
if (pmc) {
- *data = pmc->eventsel;
+ msr_info->data = pmc->eventsel;
return 0;
}
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 7c857737b438..e1a303fefc16 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -184,35 +184,38 @@ static struct kvm_pmc *intel_msr_idx_to_pmc(struct
kvm_vcpu *vcpu, u32 msr)
return pmc;
}
-static int intel_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
+static int intel_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct kvm_pmc *pmc;
+ u32 msr = msr_info->index;
switch (msr) {
case MSR_CORE_PERF_FIXED_CTR_CTRL:
- *data = pmu->fixed_ctr_ctrl;
+ msr_info->data = pmu->fixed_ctr_ctrl;
return 0;
case MSR_CORE_PERF_GLOBAL_STATUS:
- *data = pmu->global_status;
+ msr_info->data = pmu->global_status;
return 0;
case MSR_CORE_PERF_GLOBAL_CTRL:
- *data = pmu->global_ctrl;
+ msr_info->data = pmu->global_ctrl;
return 0;
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
- *data = pmu->global_ovf_ctrl;
+ msr_info->data = pmu->global_ovf_ctrl;
return 0;
default:
if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0))) {
u64 val = pmc_read_counter(pmc);
- *data = val & pmu->counter_bitmask[KVM_PMC_GP];
+ msr_info->data =
+ v
Re: mmotm 2020-05-11-15-43 uploaded (mm/memcontrol.c, huge pages)
On 5/11/20 3:44 PM, Andrew Morton wrote:
> The mm-of-the-moment snapshot 2020-05-11-15-43 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
>
> You will need quilt to apply these patches to the latest Linus release (5.x
> or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
>
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
>
> This tree is partially included in linux-next. To see which patches are
> included in linux-next, consult the `series' file. Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
>
>
> A full copy of the full kernel tree with the linux-next and mmotm patches
> already applied is available through git within an hour of the mmotm
> release. Individual mmotm releases are tagged. The master branch always
> points to the latest release, so it's constantly rebasing.
>
> https://github.com/hnaz/linux-mm
>
> The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> contains daily snapshots of the -mm tree. It is updated more frequently
> than mmotm, and is untested.
>
> A git copy of this tree is also available at
>
> https://github.com/hnaz/linux-mm
on x86_64:
In file included from ../arch/x86/include/asm/atomic.h:5:0,
from ../include/linux/atomic.h:7,
from ../include/linux/page_counter.h:5,
from ../mm/memcontrol.c:25:
../mm/memcontrol.c: In function ‘memcg_stat_show’:
../include/linux/compiler.h:394:38: error: call to ‘__compiletime_assert_383’
declared with attribute error: BUILD_BUG failed
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
../include/linux/compiler.h:375:4: note: in definition of macro
‘__compiletime_assert’
prefix ## suffix();\
^~
../include/linux/compiler.h:394:2: note: in expansion of macro
‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~
../include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
../include/linux/build_bug.h:59:21: note: in expansion of macro
‘BUILD_BUG_ON_MSG’
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
^~~~
../include/linux/huge_mm.h:319:28: note: in expansion of macro ‘BUILD_BUG’
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
^
../include/linux/huge_mm.h:115:26: note: in expansion of macro ‘HPAGE_PMD_SHIFT’
#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
^~~
../include/linux/huge_mm.h:116:26: note: in expansion of macro ‘HPAGE_PMD_ORDER’
#define HPAGE_PMD_NR (1<
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.7.0-rc5-mm1 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (SUSE Linux) 7.5.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70500
CONFIG_LD_VERSION=23200
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_UAPI_HEADER_TEST=y
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_WATCH_QUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_INJECTION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_DEBUGFS=y
# end of IRQ subsystem
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
C
Re: [PATCH 1/2] kbuild: remove misleading stale FIXME comment
On Mon, May 4, 2020 at 5:08 PM Masahiro Yamada wrote:
>
> This comment was added by commit ("kbuild: Restore build nr, improve
> vmlinux link") [1].
>
> It was talking about if_changed_rule at that time. Now, it is unclear
> what to fix.
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=ea52ca1b3e3882b499cc6c043f384958b88b62ff
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
>
> Makefile | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 9ff00bfe0575..ffd80afcd0bb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1827,9 +1827,6 @@ tools/%: FORCE
> $(Q)mkdir -p $(objtree)/tools
> $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j%
> -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ $*
>
> -# FIXME Should go into a make.lib or something
> -# ===
> -
> quiet_cmd_rmdirs = $(if $(wildcard $(rm-dirs)),CLEAN $(wildcard
> $(rm-dirs)))
>cmd_rmdirs = rm -rf $(rm-dirs)
>
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 00/15] kbuild: support 'userprogs' syntax
On Wed, Apr 29, 2020 at 12:45 PM Masahiro Yamada wrote: > > > Several Makefiles use 'hostprogs' to build programs for the host > architecture where it is not appropriate to do so. > This is just because Kbuild lacks the support for building programs > for the target architecture. > > This series introduce 'userprogs' syntax and use it from > sample and bpf Makefiles. > > Sam worked on this in 2014. > https://lkml.org/lkml/2014/7/13/154 > > He used 'uapiprogs-y' but I just thought the meaning of > "UAPI programs" is unclear. > > Naming the syntax is one of the most difficult parts. > > I chose 'userprogs'. Anothor choice I had in my mind was 'targetprogs'. > > You can test this series quickly by 'make allmodconfig samples/' > > When building objects for userspace, [U] is displayed. > > masahiro@oscar:~/workspace/linux$ make allmodconfig samples/ All applied to linux-kbuild. > [snip] > AR samples/vfio-mdev/built-in.a > CC [M] samples/vfio-mdev/mtty.o > CC [M] samples/vfio-mdev/mdpy.o > CC [M] samples/vfio-mdev/mdpy-fb.o > CC [M] samples/vfio-mdev/mbochs.o > AR samples/mei/built-in.a > CC [U] samples/mei/mei-amt-version > CC [U] samples/auxdisplay/cfag12864b-example > CC [M] samples/configfs/configfs_sample.o > CC [M] samples/connector/cn_test.o > CC [U] samples/connector/ucon > CC [M] samples/ftrace/ftrace-direct.o > CC [M] samples/ftrace/ftrace-direct-too.o > CC [M] samples/ftrace/ftrace-direct-modify.o > CC [M] samples/ftrace/sample-trace-array.o > CC [U] samples/hidraw/hid-example > CC [M] samples/hw_breakpoint/data_breakpoint.o > CC [M] samples/kdb/kdb_hello.o > CC [M] samples/kfifo/bytestream-example.o > CC [M] samples/kfifo/dma-example.o > CC [M] samples/kfifo/inttype-example.o > CC [M] samples/kfifo/record-example.o > CC [M] samples/kobject/kobject-example.o > CC [M] samples/kobject/kset-example.o > CC [M] samples/kprobes/kprobe_example.o > CC [M] samples/kprobes/kretprobe_example.o > CC [M] samples/livepatch/livepatch-sample.o > CC [M] samples/livepatch/livepatch-shadow-mod.o > CC [M] samples/livepatch/livepatch-shadow-fix1.o > CC [M] samples/livepatch/livepatch-shadow-fix2.o > CC [M] samples/livepatch/livepatch-callbacks-demo.o > CC [M] samples/livepatch/livepatch-callbacks-mod.o > CC [M] samples/livepatch/livepatch-callbacks-busymod.o > CC [M] samples/rpmsg/rpmsg_client_sample.o > CC [U] samples/seccomp/bpf-fancy.o > CC [U] samples/seccomp/bpf-helper.o > LD [U] samples/seccomp/bpf-fancy > CC [U] samples/seccomp/dropper > CC [U] samples/seccomp/bpf-direct > CC [U] samples/seccomp/user-trap > CC [U] samples/timers/hpet_example > CC [M] samples/trace_events/trace-events-sample.o > CC [M] samples/trace_printk/trace-printk.o > CC [U] samples/uhid/uhid-example > CC [M] samples/v4l/v4l2-pci-skeleton.o > CC [U] samples/vfs/test-fsmount > CC [U] samples/vfs/test-statx > samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared inside > parameter list will not be visible outside of this definition or declaration >24 | #define statx foo > | ^~~ > CC [U] samples/watchdog/watchdog-simple > AR samples/built-in.a > > Changes for v2: > - Fix ARCH=i386 build error for bpfilter_umh > - Rename 'user-ccflags' to 'userccflags' > because 'user-ccflags' would conflict if an object > called 'user.o' exists in the directory. > - Support 'userldflags' > > Masahiro Yamada (14): > bpfilter: match bit size of bpfilter_umh to that of the kernel > kbuild: add infrastructure to build userspace programs > bpfilter: use 'userprogs' syntax to build bpfilter_umh > samples: seccomp: build sample programs for target architecture > kbuild: doc: document the new syntax 'userprogs' > samples: uhid: build sample program for target architecture > samples: hidraw: build sample program for target architecture > samples: connector: build sample program for target architecture > samples: vfs: build sample programs for target architecture > samples: pidfd: build sample program for target architecture > samples: mei: build sample program for target architecture > samples: auxdisplay: use 'userprogs' syntax > samples: timers: use 'userprogs' syntax > samples: watchdog: use 'userprogs' syntax > > Sam Ravnborg (1): > samples: uhid: fix warnings in uhid-example > > Documentation/kbuild/makefiles.rst | 183 + > Makefile | 13 +- > init/Kconfig | 4 +- > net/bpfilter/Makefile | 11 +- > samples/Kconfig| 26 +++- > samples/Makefile | 4 + > samples/auxdisplay/Makefile| 11 +- > samples/connector/Makefile | 12 +- > samples/hidraw/Makefile| 9 +- > samples/mei/Makefile | 9 +- > samples/pidfd/Makefile | 8 +- > samples/seccom
Re: [PATCH] bpfilter: check if $(CC) can static link in Kconfig
On Sun, May 10, 2020 at 10:04 AM Alexei Starovoitov wrote: > > On Sat, May 9, 2020 at 12:40 AM Masahiro Yamada wrote: > > > > On Fedora, linking static libraries requires the glibc-static RPM > > package, which is not part of the glibc-devel package. > > > > CONFIG_CC_CAN_LINK does not check the capability of static linking, > > so you can enable CONFIG_BPFILTER_UMH, then fail to build. > > > > HOSTLD net/bpfilter/bpfilter_umh > > /usr/bin/ld: cannot find -lc > > collect2: error: ld returned 1 exit status > > > > Add CONFIG_CC_CAN_LINK_STATIC, and make CONFIG_BPFILTER_UMH depend > > on it. > > > > Reported-by: Valdis Kletnieks > > Signed-off-by: Masahiro Yamada > > Thanks! > Acked-by: Alexei Starovoitov Applied to linux-kbuild with Alexei's Ack. -- Best Regards Masahiro Yamada
Re: [PATCH] xen/pvcalls-back: test for errors when calling backend_connect()
On 11.05.20 23:41, Stefano Stabellini wrote:
On Mon, 11 May 2020, Juergen Gross wrote:
backend_connect() can fail, so switch the device to connected only if
no error occurred.
Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling")
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
drivers/xen/pvcalls-back.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index cf4ce3e9358d..41a18ece029a 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -1088,7 +1088,8 @@ static void set_backend_state(struct xenbus_device *dev,
case XenbusStateInitialised:
switch (state) {
case XenbusStateConnected:
- backend_connect(dev);
+ if (backend_connect(dev))
+ return;
Do you think it would make sense to WARN?
There already should be an error message (either due to a failed
grant mapping or a failed memory allocation).
Juergen
[RFC] mm/vmstat: Add events for THP migration without split
Add the following new trace events which will help in validating migration
events involving PMD based THP pages.
1. THP_PMD_MIGRATION_ENTRY_SET
2. THP_PMD_MIGRATION_ENTRY_REMOVE
There are no clear method to confirm whether a THP migration happened with
out involving it's split. These trace events along with PGMIGRATE_SUCCESS
and PGMIGRATE_FAILURE will provide additional insights. After this change,
A single 2M THP (2K base page) when migrated
1. Without split
pgmigrate_success 1
pgmigrate_fail 0
thp_pmd_migration_entry_set 1
thp_pmd_migration_entry_remove 1
2. With split
pgmigrate_success 512
pgmigrate_fail 0
thp_pmd_migration_entry_set 0
thp_pmd_migration_entry_remove 0
pgmigrate_success as 1 instead of 512, provides a hint for possible THP
migration event. But then it gets mixed with normal page migrations over
time. These additional trace events provide required co-relation.
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Zi Yan
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
This is an indirect way for counting PMD migrations without split. Is there
a better method possible ? Just request for comments at the moment.
include/linux/vm_event_item.h | 4
mm/migrate.c | 1 +
mm/rmap.c | 1 +
mm/vmstat.c | 4
4 files changed, 10 insertions(+)
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index ffef0f279747..4b25102cf3ad 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -91,6 +91,10 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
THP_ZERO_PAGE_ALLOC_FAILED,
THP_SWPOUT,
THP_SWPOUT_FALLBACK,
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+ THP_PMD_MIGRATION_ENTRY_SET,
+ THP_PMD_MIGRATION_ENTRY_REMOVE,
+#endif
#endif
#ifdef CONFIG_MEMORY_BALLOON
BALLOON_INFLATE,
diff --git a/mm/migrate.c b/mm/migrate.c
index 7160c1556f79..8d50d55cbe97 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -228,6 +228,7 @@ static bool remove_migration_pte(struct page *page, struct
vm_area_struct *vma,
if (!pvmw.pte) {
VM_BUG_ON_PAGE(PageHuge(page) ||
!PageTransCompound(page), page);
remove_migration_pmd(&pvmw, new);
+ count_vm_event(THP_PMD_MIGRATION_ENTRY_REMOVE);
continue;
}
#endif
diff --git a/mm/rmap.c b/mm/rmap.c
index f79a206b271a..3c1fe3f45cb5 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1418,6 +1418,7 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
VM_BUG_ON_PAGE(PageHuge(page) ||
!PageTransCompound(page), page);
set_pmd_migration_entry(&pvmw, page);
+ count_vm_event(THP_PMD_MIGRATION_ENTRY_SET);
continue;
}
#endif
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 96d21a792b57..a5254b7ee531 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1274,6 +1274,10 @@ const char * const vmstat_text[] = {
"thp_zero_page_alloc_failed",
"thp_swpout",
"thp_swpout_fallback",
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+ "thp_pmd_migration_entry_set",
+ "thp_pmd_migration_entry_remove",
+#endif
#endif
#ifdef CONFIG_MEMORY_BALLOON
"balloon_inflate",
--
2.20.1
Re: [PATCH] x86/platform/uv: HUB RTC cleanup
On Mon, May 11, 2020 at 05:35:35PM -0500, Dimitri Sivanich wrote: > Remove unused event code and other cleanup for HUB RTC. Can you explain how this is dead? That's not entirely obvious from the patch. Also you probably want to split it the cleans into one or several additional patches and aso document them in the commit log(s). > diff --git a/arch/x86/platform/uv/uv_time.c b/arch/x86/platform/uv/uv_time.c > index 7af31b245636..1777b7164ff8 100644 > --- a/arch/x86/platform/uv/uv_time.c > +++ b/arch/x86/platform/uv/uv_time.c > @@ -1,25 +1,18 @@ > // SPDX-License-Identifier: GPL-2.0-or-later > /* > - * SGI RTC clock/timer routines. > + * HPE RTC clock routine. Might be worth mentioning this is for the UV platform? Both the old SGI and thew new HPE are not very descriptive.
Re: [PATCH 00/14] thermal core include cleanups
On 11-05-20, 17:54, Amit Kucheria wrote: > I noticed some remnants from when thermal core could be modular. While > cleaning that up, I fixed up the includes to be sorted alphabetically and > included export.h in files that were using EXPORT_SYMBOL* or THIS_MODULE > while at the same time removing inclusion of module.h from core files. > > Finally, the names of the source files for the governors and core have some > inconsistencies and the last couple of patches rename them. > > Build and boot tested on some ARM boards. Acked-by: Viresh Kumar -- viresh
Re: [PATCH v5 3/7] fpga: dfl: introduce interrupt trigger setting API
On Mon, Apr 20, 2020 at 04:11:39PM +0800, Xu Yilun wrote:
> FPGA user applications may be interested in interrupts generated by
> DFL features. For example, users can implement their own FPGA
> logics with interrupts enabled in AFU (Accelerated Function Unit,
> dynamic region of DFL based FPGA). So user applications need to be
> notified to handle these interrupts.
>
> In order to allow userspace applications to monitor interrupts,
> driver requires userspace to provide eventfds as interrupt
> notification channels. Applications then poll/select on the eventfds
> to get notified.
>
> This patch introduces a generic helper functions to do eventfds binding
> with given interrupts.
>
> Sub feature drivers are expected to use XXX_GET_IRQ_NUM to query irq
> info, and XXX_SET_IRQ to set eventfds for interrupts. This patch also
> introduces helper functions for these 2 ioctls.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Wu Hao
> Signed-off-by: Xu Yilun
> Acked-by: Wu Hao
>
> v2: use unsigned int instead of int for irq array indexes in
> dfl_fpga_set_irq_triggers()
> Improves comments for NULL fds param in dfl_fpga_set_irq_triggers()
> v3: Improve comments of dfl_fpga_set_irq_triggers()
> refines code for dfl_fpga_set_irq_triggers, delete local variable j
> v4: Introduce 2 helper functions to help handle the XXX_GET_IRQ_NUM &
> XXX_SET_IRQ ioctls for sub feature drivers.
> v5: Some minor fix for Hao's comments
> ---
> drivers/fpga/dfl.c| 156
> ++
> drivers/fpga/dfl.h| 17 +
> include/uapi/linux/fpga-dfl.h | 13
> 3 files changed, 186 insertions(+)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index b49fbed..208d8f0 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -10,7 +10,9 @@
> * Wu Hao
> * Xiao Guangrong
> */
> +#include
> #include
> +#include
>
> #include "dfl.h"
>
> @@ -534,6 +536,7 @@ static int build_info_commit_dev(struct
> build_feature_devs_info *binfo)
> unsigned int i;
>
> /* save resource information for each feature */
> + feature->dev = fdev;
> feature->id = finfo->fid;
> feature->resource_index = index;
> feature->ioaddr = finfo->ioaddr;
> @@ -1395,6 +1398,159 @@ int dfl_fpga_cdev_config_ports_vf(struct
> dfl_fpga_cdev *cdev, int num_vfs)
> }
> EXPORT_SYMBOL_GPL(dfl_fpga_cdev_config_ports_vf);
>
> +static irqreturn_t dfl_irq_handler(int irq, void *arg)
> +{
> + struct eventfd_ctx *trigger = arg;
> +
> + eventfd_signal(trigger, 1);
> + return IRQ_HANDLED;
> +}
> +
> +static int do_set_irq_trigger(struct dfl_feature *feature, unsigned int idx,
> + int fd)
> +{
> + struct platform_device *pdev = feature->dev;
> + struct eventfd_ctx *trigger;
> + int irq, ret;
> +
> + if (idx >= feature->nr_irqs)
> + return -EINVAL;
> +
> + irq = feature->irq_ctx[idx].irq;
> +
> + if (feature->irq_ctx[idx].trigger) {
> + free_irq(irq, feature->irq_ctx[idx].trigger);
> + kfree(feature->irq_ctx[idx].name);
> + eventfd_ctx_put(feature->irq_ctx[idx].trigger);
> + feature->irq_ctx[idx].trigger = NULL;
> + }
> +
> + if (fd < 0)
> + return 0;
> +
> + feature->irq_ctx[idx].name =
> + kasprintf(GFP_KERNEL, "fpga-irq[%u](%s-%llx)", idx,
> + dev_name(&pdev->dev),
> + (unsigned long long)feature->id);
> + if (!feature->irq_ctx[idx].name)
> + return -ENOMEM;
> +
> + trigger = eventfd_ctx_fdget(fd);
> + if (IS_ERR(trigger)) {
> + ret = PTR_ERR(trigger);
> + goto free_name;
> + }
> +
> + ret = request_irq(irq, dfl_irq_handler, 0,
> + feature->irq_ctx[idx].name, trigger);
> + if (!ret) {
> + feature->irq_ctx[idx].trigger = trigger;
> + return ret;
> + }
> +
> + eventfd_ctx_put(trigger);
> +free_name:
> + kfree(feature->irq_ctx[idx].name);
> +
> + return ret;
> +}
> +
> +/**
> + * dfl_fpga_set_irq_triggers - set eventfd triggers for dfl feature
> interrupts
> + *
> + * @feature: dfl sub feature.
> + * @start: start of irq index in this dfl sub feature.
> + * @count: number of irqs.
> + * @fds: eventfds to bind with irqs. unbind related irq if fds[n] is
> negative.
> + *unbind "count" specified number of irqs if fds ptr is NULL.
> + *
> + * Bind given eventfds with irqs in this dfl sub feature. Unbind related irq
> if
> + * fds[n] is negative. Unbind "count" specified number of irqs if fds ptr is
> + * NULL.
> + *
> + * Return: 0 on success, negative error code otherwise.
> + */
> +int dfl_fpga_set_irq_triggers(struct dfl_feature *feature, unsigned int
> start,
> + unsigned int count, int32_t *fds)
> +{
> + unsigned int i;
> + int
