* RE: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
From: Jun Li @ 2020-02-20 15:37 UTC (permalink / raw)
To: Martin Kepplinger, Peter Chen, mathias.nyman@intel.com
Cc: linux-usb@vger.kernel.org, dl-linux-imx, Anson Huang,
shawnguo@kernel.org, kernel@pengutronix.de
In-Reply-To: <ddbb9543-f632-b1da-cbb8-d390fcd3b4f8@puri.sm>
> -----Original Message-----
> From: Martin Kepplinger <martin.kepplinger@puri.sm>
> Sent: 2020年2月20日 19:44
> To: Jun Li <jun.li@nxp.com>; Peter Chen <peter.chen@nxp.com>;
> mathias.nyman@intel.com
> Cc: linux-usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Anson Huang
> <anson.huang@nxp.com>; shawnguo@kernel.org; kernel@pengutronix.de
> Subject: Re: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
>
> On 20.02.20 07:31, Jun Li wrote:
> >> -----Original Message-----
> >> From: Martin Kepplinger <martin.kepplinger@puri.sm>
> >> Sent: 2020年2月20日 1:37
> >> To: Jun Li <jun.li@nxp.com>; Peter Chen <peter.chen@nxp.com>;
> >> mathias.nyman@intel.com
> >> Cc: linux-usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> >> Anson Huang <anson.huang@nxp.com>; shawnguo@kernel.org;
> >> kernel@pengutronix.de
> >> Subject: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
> >>
> >> From: Li Jun <jun.li@nxp.com>
> >>
> >> i.MX8MQ USB3 host needs XHCI_MISSING_CAS quirk to warm reset the port
> >> to enum the
> >> USB3 device plugged in while system sleep, as the port state is stuck
> >> in polling mode after resume.
> >>
> >> Signed-off-by: Li Jun <jun.li@nxp.com>
> >> Acked-by: Peter Chen <peter.chen@nxp.com>
> >> ---
> >>
> >> Hi,
> >>
> >> Because resume from S3 suspend is broken for me on imx8mq, I stumbled
> >> upon this patch in NXP's linux tree. (Please note that I'm not the
> >> author and I've not yet put my SoB tag under it). This is just a
> >> question:
> >>
> >> This patch (and the docs) clearly is missing in mainline Linux
> >> because the imx8mq devicetree description includes it (which does nothing now).
> >>
> >> I've tested this and this particular addition doesn't fix my problem:
> >>
> >> [ 84.257538] imx8mq-usb-phy 381f0040.usb-phy: bus resume
> >> [ 84.263195] imx8mq-usb-phy 382f0040.usb-phy: bus resume
> >> [ 84.268898] dwc3 38100000.usb: driver resume
> >>
> >> during resume from S3 suspend, here it still hangs.
> >
> > Is your problem a system hang? If yes, this may another issue, where
> > the hang happens? dwc3_resume_common()?
>
> exactly! I followed to the point it hangs once again and it's
>
> dwc3_core_init() called from dwc3_resume_common()'s "OTG" case.
>
> Specifically, dwc3_writel() is what I don't get past:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootl
> in.com%2Flinux%2Fv5.6-rc2%2Fsource%2Fdrivers%2Fusb%2Fdwc3%2Fcore.c%23L934&
> data=02%7C01%7Cjun.li%40nxp.com%7C130cd29875c44792d1a908d7b5fa2516%7C686ea1d3b
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C637177958284696041&sdata=mqh9MH6ESLVxKvW
> vvMq4vwt2dcTuvNopgGVdXEbbMwk%3D&reserved=0
So while dwc3 resume, the first register access cause hang.
Looks like some required clocks or power domain of USB0 is not on.
>
> do you have an idea why this writel() hangs?
I never encounter such hang on my iMX8MQ EVK board
using upstream kernel(5.x) + changes of enable USB0 port,
but I didn't try latest 5.6 kernel.
I will enable the first port based on Linux-next to give a
try on my NXP iMX8MQ EVK board, do you think I can reproduce
your problem?
Li Jun
>
> >
> > The question patch is to give a warm reset for connected USB device if
> > the link state is not connect/CAS after system resume, otherwise host
> > will wait 2s for device appear:
> >
> > [ 44.834831] usb 2-1: Waited 2000ms for CONNECT
> > ...
> > [ 45.055718] PM: resume devices took 3.132 seconds
> >
> > I will post this patch and doc(to be updated) to upstream later.
> >
>
> ok, good, thanks,
>
> martin
^ permalink raw reply
* Re: S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Martin Jansa @ 2020-02-20 15:37 UTC (permalink / raw)
To: Adrian Bunk; +Cc: openembeded-devel
In-Reply-To: <20200220151620.GA30034@localhost>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> >...
> > Any idea why these aren't shown in our build?
> >...
>
> What is your mirror configuration?
>
> Default configuration downloads the tarball from [1].
Maybe I'm missing your point, but these aren't fetch issues.
Even when bitbake fetches the tarball (with the svn repo), svn fetcher
will still do the actual checkout to WORKDIR, so it will fail the same
when fetching from upstream repo with svn or when using tarball.
Cheers,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply
* [PATCH 1/1] selinux: Add xfs quota command types
From: Richard Haines @ 2020-02-20 15:32 UTC (permalink / raw)
To: darrick.wong, sds, paul; +Cc: linux-xfs, selinux, Richard Haines
In-Reply-To: <20200220153234.152426-1-richard_c_haines@btinternet.com>
Add Q_XQUOTAOFF, Q_XQUOTAON and Q_XSETQLIM to trigger filesystem quotamod
permission check.
Add Q_XGETQUOTA, Q_XGETQSTAT, Q_XGETQSTATV and Q_XGETNEXTQUOTA to trigger
filesystem quotaget permission check.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
---
security/selinux/hooks.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 46a8f3e7d..974228313 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2145,11 +2145,18 @@ static int selinux_quotactl(int cmds, int type, int id, struct super_block *sb)
case Q_QUOTAOFF:
case Q_SETINFO:
case Q_SETQUOTA:
+ case Q_XQUOTAOFF:
+ case Q_XQUOTAON:
+ case Q_XSETQLIM:
rc = superblock_has_perm(cred, sb, FILESYSTEM__QUOTAMOD, NULL);
break;
case Q_GETFMT:
case Q_GETINFO:
case Q_GETQUOTA:
+ case Q_XGETQUOTA:
+ case Q_XGETQSTAT:
+ case Q_XGETQSTATV:
+ case Q_XGETNEXTQUOTA:
rc = superblock_has_perm(cred, sb, FILESYSTEM__QUOTAGET, NULL);
break;
default:
--
2.24.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH 2/8] x86/setup: Fix badpage= handling for memory above HYPERVISOR_VIRT_END
From: Jan Beulich @ 2020-02-20 15:38 UTC (permalink / raw)
To: David Woodhouse
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Varad Gautam, Ian Jackson,
Hongyan Xia, xen-devel, Paul Durrant, Roger Pau Monné
In-Reply-To: <20200201003303.2363081-2-dwmw2@infradead.org>
On 01.02.2020 01:32, David Woodhouse wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1758,6 +1758,18 @@ int query_page_offline(mfn_t mfn, uint32_t *status)
> return 0;
> }
>
> +static unsigned long contig_avail_pages(struct page_info *pg, unsigned long max_pages)
> +{
> + unsigned long i;
> +
> + for ( i = 0 ; i < max_pages; i++)
Nit: Stray blank before first semicolon.
> + {
> + if ( pg[i].count_info & PGC_broken )
> + break;
> + }
> + return i;
Further nits: Commonly we omit the braces in cases like this one.
We also like to have blank lines before the main return statement
of a function.
> @@ -1846,6 +1863,63 @@ static unsigned long avail_heap_pages(
> return free_pages;
> }
>
> +static void mark_bad_pages(void)
__init please
> +{
> + unsigned long bad_spfn, bad_epfn;
> + const char *p;
> + struct page_info *pg;
> +#ifdef CONFIG_X86
> + const struct platform_bad_page *badpage;
> + unsigned int i, j, array_size;
> +
> + badpage = get_platform_badpages(&array_size);
> + if ( badpage )
> + {
> + for ( i = 0; i < array_size; i++ )
> + {
> + for ( j = 0; j < 1UL << badpage->order; j++ )
Either you mean badpage[i].* here and below, or you're missing an
increment of badpage somewhere.
> + {
> + if ( mfn_valid(_mfn(badpage->mfn + j)) )
> + {
> + pg = mfn_to_page(_mfn(badpage->mfn + j));
> + pg->count_info |= PGC_broken;
> + page_list_add_tail(pg, &page_broken_list);
> + }
> + }
> + }
> + }
> +#endif
> +
> + /* Check new pages against the bad-page list. */
> + p = opt_badpage;
> + while ( *p != '\0' )
> + {
> + bad_spfn = simple_strtoul(p, &p, 0);
> + bad_epfn = bad_spfn;
> +
> + if ( *p == '-' )
> + {
> + p++;
> + bad_epfn = simple_strtoul(p, &p, 0);
> + if ( bad_epfn < bad_spfn )
> + bad_epfn = bad_spfn;
> + }
> +
> + if ( *p == ',' )
> + p++;
> + else if ( *p != '\0' )
> + break;
I think this common (with init_boot_pages()) part of parsing
would better abstracted out, such there will be just one
instance of, and hence there's no risk of things going out of
sync.
> + while ( mfn_valid(_mfn(bad_spfn)) && bad_spfn < bad_epfn )
As per init_boot_pages() as well as per the "bad_epfn = bad_spfn;"
you have further up, the range here is inclusive at its end. I'm
also uncertain about the stopping at the first !mfn_valid() -
there may well be further valid pages later on.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] Btrfs: fix deadlock during fast fsync when logging prealloc extents beyond eof
From: Josef Bacik @ 2020-02-20 15:38 UTC (permalink / raw)
To: fdmanana, linux-btrfs
In-Reply-To: <20200220132949.20571-1-fdmanana@kernel.org>
On 2/20/20 8:29 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> While logging the prealloc extents of an inode during a fast fsync we call
> btrfs_truncate_inode_items(), through btrfs_log_prealloc_extents(), while
> holding a read lock on a leaf of the inode's root (not the log root, the
> fs/subvol root), and then that function locks the file range in the inode's
> iotree. This can lead to a deadlock when:
>
> * the fsync is ranged
>
> * the file has prealloc extents beyond eof
>
> * writeback for a range different from the fsync range starts
> during the fsync
>
> * the size of the file is not sector size aligned
>
> Because when finishing an ordered extent we lock first a file range and
> then try to COW the fs/subvol tree to insert an extent item.
>
> The following diagram shows how the deadlock can happen.
>
> CPU 1 CPU 2
>
> btrfs_sync_file()
> --> for range [0, 1Mb[
>
> --> inode has a size of
> 1Mb and has 1 prealloc
> extent beyond the
> i_size, starting at offset
> 4Mb
>
> flushes all delalloc for the
> range [0Mb, 1Mb[ and waits
> for the respective ordered
> extents to complete
>
> --> before task at CPU 1 locks the
> inode, a write into file range
> [1Mb, 2Mb + 1Kb[ is made
>
> --> i_size is updated to 2Mb + 1Kb
>
> --> writeback is started for that
> range, [1Mb, 2Mb + 4Kb[
> --> end offset rounded up to
> be sector size aligned
>
> btrfs_log_dentry_safe()
> btrfs_log_inode_parent()
> btrfs_log_inode()
>
> btrfs_log_changed_extents()
> btrfs_log_prealloc_extents()
> --> does a search on the
> inode's root
> --> holds a read lock on
> leaf X
>
> btrfs_finish_ordered_io()
> --> locks range [1Mb, 2Mb + 4Kb[
> --> end offset rounded up
> to be sector size aligned
>
> --> tries to cow leaf X, through
> insert_reserved_file_extent()
> --> already locked by the
> task at CPU 1
>
> btrfs_truncate_inode_items()
>
> --> gets an i_size of
> 2Mb + 1Kb, which is
> not sector size
> aligned
>
> --> tries to lock file
> range [2Mb, (u64)-1[
> --> the start range
> is rounded down
> from 2Mb + 1K
> to 2Mb to be sector
> size aligned
>
> --> but the subrange
> [2Mb, 2Mb + 4Kb[ is
> already locked by
> task at CPU 2 which
> is waiting to get a
> write lock on leaf X
> for which we are
> holding a read lock
>
> *** deadlock ***
>
> This results in a stack trace like the following, triggered by test case
> generic/561 from fstests:
>
> [ 2779.973608] INFO: task kworker/u8:6:247 blocked for more than 120 seconds.
> [ 2779.979536] Not tainted 5.6.0-rc2-btrfs-next-53 #1
> [ 2779.984503] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 2779.990136] kworker/u8:6 D 0 247 2 0x80004000
> [ 2779.990457] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
> [ 2779.990466] Call Trace:
> [ 2779.990491] ? __schedule+0x384/0xa30
> [ 2779.990521] schedule+0x33/0xe0
> [ 2779.990616] btrfs_tree_read_lock+0x19e/0x2e0 [btrfs]
> [ 2779.990632] ? remove_wait_queue+0x60/0x60
> [ 2779.990730] btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
> [ 2779.990782] btrfs_search_slot+0x510/0x1000 [btrfs]
> [ 2779.990869] btrfs_lookup_file_extent+0x4a/0x70 [btrfs]
> [ 2779.990944] __btrfs_drop_extents+0x161/0x1060 [btrfs]
> [ 2779.990987] ? mark_held_locks+0x6d/0xc0
> [ 2779.990994] ? __slab_alloc.isra.49+0x99/0x100
> [ 2779.991060] ? insert_reserved_file_extent.constprop.19+0x64/0x300 [btrfs]
> [ 2779.991145] insert_reserved_file_extent.constprop.19+0x97/0x300 [btrfs]
> [ 2779.991222] ? start_transaction+0xdd/0x5c0 [btrfs]
> [ 2779.991291] btrfs_finish_ordered_io+0x4f4/0x840 [btrfs]
> [ 2779.991405] btrfs_work_helper+0xaa/0x720 [btrfs]
> [ 2779.991432] process_one_work+0x26d/0x6a0
> [ 2779.991460] worker_thread+0x4f/0x3e0
> [ 2779.991481] ? process_one_work+0x6a0/0x6a0
> [ 2779.991489] kthread+0x103/0x140
> [ 2779.991499] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 2779.991515] ret_from_fork+0x3a/0x50
> (...)
> [ 2780.026211] INFO: task fsstress:17375 blocked for more than 120 seconds.
> [ 2780.027480] Not tainted 5.6.0-rc2-btrfs-next-53 #1
> [ 2780.028482] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 2780.030035] fsstress D 0 17375 17373 0x00004000
> [ 2780.030038] Call Trace:
> [ 2780.030044] ? __schedule+0x384/0xa30
> [ 2780.030052] schedule+0x33/0xe0
> [ 2780.030075] lock_extent_bits+0x20c/0x320 [btrfs]
> [ 2780.030094] ? btrfs_truncate_inode_items+0xf4/0x1150 [btrfs]
> [ 2780.030098] ? rcu_read_lock_sched_held+0x59/0xa0
> [ 2780.030102] ? remove_wait_queue+0x60/0x60
> [ 2780.030122] btrfs_truncate_inode_items+0x133/0x1150 [btrfs]
> [ 2780.030151] ? btrfs_set_path_blocking+0xb2/0x160 [btrfs]
> [ 2780.030165] ? btrfs_search_slot+0x379/0x1000 [btrfs]
> [ 2780.030195] btrfs_log_changed_extents.isra.8+0x841/0x93e [btrfs]
> [ 2780.030202] ? do_raw_spin_unlock+0x49/0xc0
> [ 2780.030215] ? btrfs_get_num_csums+0x10/0x10 [btrfs]
> [ 2780.030239] btrfs_log_inode+0xf83/0x1124 [btrfs]
> [ 2780.030251] ? __mutex_unlock_slowpath+0x45/0x2a0
> [ 2780.030275] btrfs_log_inode_parent+0x2a0/0xe40 [btrfs]
> [ 2780.030282] ? dget_parent+0xa1/0x370
> [ 2780.030309] btrfs_log_dentry_safe+0x4a/0x70 [btrfs]
> [ 2780.030329] btrfs_sync_file+0x3f3/0x490 [btrfs]
> [ 2780.030339] do_fsync+0x38/0x60
> [ 2780.030343] __x64_sys_fdatasync+0x13/0x20
> [ 2780.030345] do_syscall_64+0x5c/0x280
> [ 2780.030348] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 2780.030356] RIP: 0033:0x7f2d80f6d5f0
> [ 2780.030361] Code: Bad RIP value.
> [ 2780.030362] RSP: 002b:00007ffdba3c8548 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
> [ 2780.030364] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2d80f6d5f0
> [ 2780.030365] RDX: 00007ffdba3c84b0 RSI: 00007ffdba3c84b0 RDI: 0000000000000003
> [ 2780.030367] RBP: 000000000000004a R08: 0000000000000001 R09: 00007ffdba3c855c
> [ 2780.030368] R10: 0000000000000078 R11: 0000000000000246 R12: 00000000000001f4
> [ 2780.030369] R13: 0000000051eb851f R14: 00007ffdba3c85f0 R15: 0000557a49220d90
>
> So fix this by making btrfs_truncate_inode_items() not lock the range in
> the inode's iotree when the target root is a log root, since it's not
> needed to lock the range for log roots as the protection from the inode's
> lock and log_mutex are all that's needed.
>
> Fixes: 28553fa992cb28 ("Btrfs: fix race between shrinking truncate and fiemap")
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for Reduce Docker images size
From: Patchwork @ 2020-02-20 15:38 UTC (permalink / raw)
To: Ramotowski, Maciej; +Cc: igt-dev
In-Reply-To: <20200220143237.18855-1-maciej.ramotowski@intel.com>
== Series Details ==
Series: Reduce Docker images size
URL : https://patchwork.freedesktop.org/series/73717/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4197
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/index.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and IGTPW_4197:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 1 dmesg-warn(s) 17 pass(s) 24 skip(s)
- Exec time: [0.0, 0.23] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 1 dmesg-warn(s) 30 pass(s) 11 skip(s)
- Exec time: [0.0, 6.85] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 1 dmesg-warn(s) 30 pass(s) 11 skip(s)
- Exec time: [0.44, 24.41] s
* igt@i915_pm_rps@basic-api:
- Statuses : 37 pass(s) 5 skip(s)
- Exec time: [0.0, 0.02] s
Known issues
------------
Here are the changes found in IGTPW_4197 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_close_race@basic-threads:
- fi-hsw-4770: [PASS][1] -> [TIMEOUT][2] ([fdo#112271] / [i915#1084])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-4770/igt@gem_close_race@basic-threads.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-hsw-4770/igt@gem_close_race@basic-threads.html
* igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@i915_getparams_basic@basic-subslice-total.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-tgl-y/igt@i915_getparams_basic@basic-subslice-total.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][5] -> [INCOMPLETE][6] ([fdo#106070] / [i915#424])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-n3050: [PASS][7] -> [FAIL][8] ([i915#34])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vblank.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vblank.html
#### Possible fixes ####
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][9] ([i915#585]) -> [PASS][10] +1 similar issue
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][11] ([i915#217]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [DMESG-WARN][15] ([CI#94] / [i915#402]) -> [PASS][16] +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
#### Warnings ####
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][17] ([fdo#109315]) -> [SKIP][18] ([fdo#109315] / [i915#585])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
Participating hosts (49 -> 45)
------------------------------
Additional (4): fi-kbl-soraka fi-skl-lmem fi-ivb-3770 fi-pnv-d510
Missing (8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4197
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4197: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4197/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [PATCH] arm64: dts: meson-gxbb-odroid-c2: add rc-odroid ir keymap
From: Christian Hewitt @ 2020-02-20 15:38 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
Add the rc-odroid keymap to the Odroid C2 device-tree.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 6ded279..b46ef98 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -248,6 +248,7 @@
status = "okay";
pinctrl-0 = <&remote_input_ao_pins>;
pinctrl-names = "default";
+ linux,rc-map-name = "rc-odroid";
};
&gpio_ao {
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: dts: meson-gxbb-odroid-c2: add rc-odroid ir keymap
From: Christian Hewitt @ 2020-02-20 15:38 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
Add the rc-odroid keymap to the Odroid C2 device-tree.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 6ded279..b46ef98 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -248,6 +248,7 @@
status = "okay";
pinctrl-0 = <&remote_input_ao_pins>;
pinctrl-names = "default";
+ linux,rc-map-name = "rc-odroid";
};
&gpio_ao {
--
2.7.4
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply related
* [PATCH] arm64: dts: meson-gxbb-odroid-c2: add rc-odroid ir keymap
From: Christian Hewitt @ 2020-02-20 15:38 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
Add the rc-odroid keymap to the Odroid C2 device-tree.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 6ded279..b46ef98 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -248,6 +248,7 @@
status = "okay";
pinctrl-0 = <&remote_input_ao_pins>;
pinctrl-names = "default";
+ linux,rc-map-name = "rc-odroid";
};
&gpio_ao {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* reduce dmesg spam v2
From: Christoph Hellwig @ 2020-02-20 15:39 UTC (permalink / raw)
To: linux-xfs
Hi all,
When a device keeps failing I/O (for example using dm-flakey in various
tests), we keep spamming the log for each I/O error, although the
messages are very much duplicates. Use xfs_alert_ratelimited() to reduce
the number of logged lines.
Changes sinve v1:
- use xfs_alert_ratelimited
^ permalink raw reply
* [PATCH 1/2] xfs: ratelimit xfs_buf_ioerror_alert messages
From: Christoph Hellwig @ 2020-02-20 15:39 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <20200220153921.383899-1-hch@lst.de>
Use printk_ratelimit() to limit the amount of messages printed from
xfs_buf_ioerror_alert. Without that a failing device causes a large
number of errors that doesn't really help debugging the underling
issue.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/xfs_buf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 217e4f82a44a..0ceaa172545b 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -1238,7 +1238,7 @@ xfs_buf_ioerror_alert(
struct xfs_buf *bp,
xfs_failaddr_t func)
{
- xfs_alert(bp->b_mount,
+ xfs_alert_ratelimited(bp->b_mount,
"metadata I/O error in \"%pS\" at daddr 0x%llx len %d error %d",
func, (uint64_t)XFS_BUF_ADDR(bp), bp->b_length,
-bp->b_error);
--
2.24.1
^ permalink raw reply related
* [PATCH 2/2] xfs: ratelimit xfs_discard_page messages
From: Christoph Hellwig @ 2020-02-20 15:39 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <20200220153921.383899-1-hch@lst.de>
Use printk_ratelimit() to limit the amount of messages printed from
xfs_discard_page. Without that a failing device causes a large
number of errors that doesn't really help debugging the underling
issue.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/xfs_aops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 58e937be24ce..9d9cebf18726 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -539,7 +539,7 @@ xfs_discard_page(
if (XFS_FORCED_SHUTDOWN(mp))
goto out_invalidate;
- xfs_alert(mp,
+ xfs_alert_ratelimited(mp,
"page discard on page "PTR_FMT", inode 0x%llx, offset %llu.",
page, ip->i_ino, offset);
--
2.24.1
^ permalink raw reply related
* Re: [dpdk-dev] [PATCH] cryptodev: fix missing device id range checking
From: Trahe, Fiona @ 2020-02-20 15:39 UTC (permalink / raw)
To: Dybkowski, AdamX, dev@dpdk.org, akhil.goyal@nxp.com
Cc: stable@dpdk.org, julien.meunier@nokia.com, Trahe, Fiona
In-Reply-To: <20200220150415.32091-1-adamx.dybkowski@intel.com>
> -----Original Message-----
> From: Dybkowski, AdamX <adamx.dybkowski@intel.com>
> Sent: Thursday, February 20, 2020 3:04 PM
> To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; akhil.goyal@nxp.com
> Cc: Dybkowski, AdamX <adamx.dybkowski@intel.com>; stable@dpdk.org
> Subject: [PATCH] cryptodev: fix missing device id range checking
>
> This patch adds range-checking of the device id passed from
> the user app code. It prevents out-of-range array accesses
> which in some situations resulted in an
> application crash (segfault).
>
> Fixes: 3dd4435cf473 ("cryptodev: fix checks related to device id")
> Cc: stable@dpdk.org
>
> Signed-off-by: Adam Dybkowski <adamx.dybkowski@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t] intel-ci: add a pre-merge blacklist to reduce the testing queue
From: Chris Wilson @ 2020-02-20 15:39 UTC (permalink / raw)
To: Martin Peres, igt-dev
In-Reply-To: <20200220153209.210767-1-martin.peres@linux.intel.com>
Quoting Martin Peres (2020-02-20 15:32:09)
> +###############################################################################
> +# These 8 tests are responsible for a significant portion of our execution time
> +# despite them testing a feature which is only found in older userspaces:
> +#
> +# - shard-skl: 0.1% (~15 seconds)
> +# - shard-kbl: 3.5% (~4.5 minutes)
> +# - shard-apl: 10% (~18 minutes)
> +# - shard-glk: 6.3% (~14 minutes)
> +# - shard-icl: 1.7% (~3.5 minutes)
> +# - shard-tgl: 1.6% (~3 minutes)
> +#
> +# Data acquired on 2020-02-19 by Martin Peres
> +###############################################################################
> +igt@gem_pwrite@big-.*
That is not true. They are testing the obj->mm.get_page cache which is
used for all page lookups in the driver.
It's harder to predictably exercise from userspace through other
interfaces.
So replace with a unittest for the cache :-p
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [Buildroot] [PATCH 1/2] toolchain: introduce BR2_TOOLCHAIN_HAS_GCC_BUG_93847
From: Giulio Benetti @ 2020-02-20 15:40 UTC (permalink / raw)
To: buildroot
git package fails to build for the Nios2 architecture with optimization
enabled with gcc < 9.x:
http://autobuild.buildroot.net/results/924/92484c49b655e4aa78ca52f124c6d8f605b9d06b/
It's been reported upstream:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
toolchain/Config.in | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 973c03254f..b8c2f79a36 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -159,6 +159,14 @@ config BR2_TOOLCHAIN_HAS_GCC_BUG_90620
bool
default y if BR2_microblaze
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
+# ICE: compiler error: Segmentation fault on Nios II. This bug
+# no longer exists in gcc 9.x.
+config BR2_TOOLCHAIN_HAS_GCC_BUG_93847
+ bool
+ default y if BR2_nios2
+ depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_9
+
config BR2_TOOLCHAIN_HAS_NATIVE_RPC
bool
--
2.20.1
^ permalink raw reply related
* [Buildroot] [PATCH 2/2] package/git: fix build failure due to gcc bug 93847
From: Giulio Benetti @ 2020-02-20 15:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20200220154004.126384-1-giulio.benetti@benettiengineering.com>
The git package exhibits gcc bug 93847 when built for the Nios2
architecture with optimization enabled, which causes a build failure.
As done for other packages in Buildroot work around this gcc bug by
setting optimization to -O0 if BR2_TOOLCHAIN_HAS_GCC_BUG_93847=y.
Fixes:
http://autobuild.buildroot.net/results/e22/e225e62ea2d48660df4110790664f0c3306c1ea9/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
package/git/git.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/git/git.mk b/package/git/git.mk
index a5c8669fc9..f32a2f8eb9 100644
--- a/package/git/git.mk
+++ b/package/git/git.mk
@@ -67,7 +67,7 @@ endif
GIT_CFLAGS = $(TARGET_CFLAGS)
-ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_85180),y)
+ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_85180)$(BR2_TOOLCHAIN_HAS_GCC_BUG_93847),y)
GIT_CFLAGS += -O0
endif
--
2.20.1
^ permalink raw reply related
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: mark gross @ 2020-02-20 15:40 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220142720.GA3433900@kroah.com>
On Thu, Feb 20, 2020 at 03:27:20PM +0100, speck for Greg KH wrote:
> On Thu, Feb 20, 2020 at 09:14:20AM +0100, speck for Greg KH wrote:
> > On Wed, Feb 19, 2020 at 02:45:22PM -0800, speck for mark gross wrote:
> > > From: mark gross <mgross@linux.intel.com>
> > > Subject: [PATCH 0/2] Special Register Buffer Data Sampling patch set
> > >
> > > Special Register Buffer Data Sampling is a sampling type of vulnerability that
> > > leaks data across cores sharing the HW-RNG for vulnerable processors.
> > >
> > > This leak is fixed by a microcode update and is enabled by default.
> > >
> > > This new microcode serializes processor access during execution of RDRAND
> > > or RDSEED. It ensures that the shared buffer is overwritten before it
> > > is released for reuse.
> > >
> > > The mitigation impacts the throughput of the RDRAND and RDSEED instructions
> > > and latency of RT processing running on the socket while executing RDRAND or
> > > RDSEED. The micro bechmark of calling RDRAND many times shows a 10x slowdown.
> >
> > Then we need to stop using RDRAND internally for our "give me a random
> > number api" which has spread to more and more parts of the kernel.
> >
> > Here's a patch that does so:
> > https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> > which I'm going to advise get merged now and backported to the stable
> > branches.
>
> Note, the author of that patch has reached out to me to say they found
> this same issue. He did so independantly so odds are others already
> know about this. He found it because he was wondering why rdrand was so
> slow on newer systems, and then traced things backwards like all the
> other researchers in this area.
Are you saying the author has seen the RNG data leaking across processors or
the slowdown?
>
> So, what's the timeline here? Looks like this is already "in the wild"
> from what I can tell.
>
The uCode mitigation is coming out with the 2020.1 IPU (intel platform update)
(fist ucode update of 2020) that I belive is slated for an official May
disclosure.
--mark
> greg k-h
^ permalink raw reply
* Re: [RFC PATCH v3 04/27] qcow2: Add get_l2_entry() and set_l2_entry()
From: Max Reitz @ 2020-02-20 15:39 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <a1be1f4311da643b439cb5e1924b0ddfb052f338.1577014346.git.berto@igalia.com>
[-- Attachment #1.1: Type: text/plain, Size: 712 bytes --]
On 22.12.19 12:36, Alberto Garcia wrote:
> The size of an L2 entry is 64 bits, but if we want to have subclusters
> we need extended L2 entries. This means that we have to access L2
> tables and slices differently depending on whether an image has
> extended L2 entries or not.
>
> This patch replaces all l2_slice[] accesses with calls to
> get_l2_entry() and set_l2_entry().
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2-cluster.c | 65 ++++++++++++++++++++++--------------------
> block/qcow2-refcount.c | 17 +++++------
> block/qcow2.h | 12 ++++++++
> 3 files changed, 55 insertions(+), 39 deletions(-)
Reviewed-by: Max Reitz <mreitz@redhat.com>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 20/21] btrfs: skip LOOP_NO_EMPTY_SIZE if not clustered allocation
From: Josef Bacik @ 2020-02-20 15:40 UTC (permalink / raw)
To: Naohiro Aota
Cc: linux-btrfs, David Sterba, Chris Mason, Nikolay Borisov,
Damien Le Moal, Johannes Thumshirn, Hannes Reinecke, Anand Jain,
linux-fsdevel
In-Reply-To: <20200220095631.7rlk7lmnp7np4nvg@naota.dhcp.fujisawa.hgst.com>
On 2/20/20 4:56 AM, Naohiro Aota wrote:
> On Thu, Feb 13, 2020 at 02:55:30PM -0500, Josef Bacik wrote:
>> On 2/12/20 2:20 AM, Naohiro Aota wrote:
>>> LOOP_NO_EMPTY_SIZE is solely dedicated for clustered allocation. So,
>>> we can skip this stage and go to LOOP_GIVEUP stage to indicate we gave
>>> up the allocation. This commit also moves the scope of the "clustered"
>>> variable.
>>>
>>> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
>>> ---
>>> fs/btrfs/extent-tree.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
>>> index 8f0d489f76fa..3ab0d2f5d718 100644
>>> --- a/fs/btrfs/extent-tree.c
>>> +++ b/fs/btrfs/extent-tree.c
>>> @@ -3373,6 +3373,7 @@ enum btrfs_loop_type {
>>> LOOP_CACHING_WAIT,
>>> LOOP_ALLOC_CHUNK,
>>> LOOP_NO_EMPTY_SIZE,
>>> + LOOP_GIVEUP,
>>
>> Why do we need a new loop definition here? Can we just return ENOSPC and be
>> done? You don't appear to use it anywhere, so it doesn't seem like it's
>> needed. Thanks,
>>
>> Josef
>
> This is for other allocation policy to skip unnecessary loop stages
> (e.g. LOOP_NO_EMPTY_SIZE) from an earlier stage. For example, zoned
> allocation policy can implement the code below in
> chunk_allocation_failed() to skip the following stages.
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 4badfae0c932..0a18c09b078b 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -3775,6 +3854,10 @@ static int chunk_allocation_failed(struct
> find_free_extent_ctl *ffe_ctl)
> */
> ffe_ctl->loop = LOOP_NO_EMPTY_SIZE;
> return 0;
> + case BTRFS_EXTENT_ALLOC_ZONED:
> + /* give up here */
> + ffe_ctl->loop = LOOP_GIVEUP;
> + return -ENOSPC;
> default:
> BUG();
> }
>
> But, I can keep this LOOP_GIVEUP introduction patch later with this
> zoned allocator ones.
>
Yes I'd rather they be with the real user, otherwise it's just confusing. Thanks,
Josef
^ permalink raw reply
* Re: [PATCH v2] xfs: add agf freeblocks verify in xfs_agf_verify
From: Christoph Hellwig @ 2020-02-20 15:40 UTC (permalink / raw)
To: Zheng Bin
Cc: sandeen, bfoster, dchinner, darrick.wong, linux-xfs, renxudong1,
yi.zhang
In-Reply-To: <1582197182-142137-1-git-send-email-zhengbin13@huawei.com>
On Thu, Feb 20, 2020 at 07:13:02PM +0800, Zheng Bin wrote:
> + if (be32_to_cpu(agf->agf_length) > mp->m_sb.sb_dblocks ||
> + be32_to_cpu(agf->agf_btreeblks) > be32_to_cpu(agf->agf_length) ||
> + be32_to_cpu(agf->agf_rmap_blocks) > be32_to_cpu(agf->agf_length) ||
> + be32_to_cpu(agf->agf_refcount_blocks) > be32_to_cpu(agf->agf_length) ||
This adds a > 80 char line, please properly format it.
> + be32_to_cpu(agf->agf_spare2) != 0)
> + return __this_address;
There is no need to byte swap fields if you just check if they are
non-zero.
> +
> + for (i = 0; i < ARRAY_SIZE(agf->agf_spare64); i++)
> + if (be64_to_cpu(agf->agf_spare64[i]) != 0)
> + return __this_address;
Same here.
^ permalink raw reply
* Re: [PATCH] mm/slub: Detach node lock from counting free objects
From: Roman Gushchin @ 2020-02-20 15:40 UTC (permalink / raw)
To: Wen Yang
Cc: Andrew Morton, Christoph Lameter, Pekka Enberg, David Rientjes,
Joonsoo Kim, Xunlei Pang, linux-mm, linux-kernel
In-Reply-To: <cb36f3e5-c01c-a99d-9230-af52f806e227@linux.alibaba.com>
On Thu, Feb 20, 2020 at 09:53:26PM +0800, Wen Yang wrote:
>
>
> On 2020/2/19 4:53 上午, Roman Gushchin wrote:
> > On Sun, Feb 16, 2020 at 12:15:54PM +0800, Wen Yang wrote:
> > >
> > >
> > > On 2020/2/13 6:52 上午, Andrew Morton wrote:
> > > > On Sat, 1 Feb 2020 11:15:02 +0800 Wen Yang <wenyang@linux.alibaba.com> wrote:
> > > >
> > > > > The lock, protecting the node partial list, is taken when couting the free
> > > > > objects resident in that list. It introduces locking contention when the
> > > > > page(s) is moved between CPU and node partial lists in allocation path
> > > > > on another CPU. So reading "/proc/slabinfo" can possibily block the slab
> > > > > allocation on another CPU for a while, 200ms in extreme cases. If the
> > > > > slab object is to carry network packet, targeting the far-end disk array,
> > > > > it causes block IO jitter issue.
> > > > >
> > > > > This fixes the block IO jitter issue by caching the total inuse objects in
> > > > > the node in advance. The value is retrieved without taking the node partial
> > > > > list lock on reading "/proc/slabinfo".
> > > > >
> > > > > ...
> > > > >
> > > > > @@ -1768,7 +1774,9 @@ static void free_slab(struct kmem_cache *s, struct page *page)
> > > > > static void discard_slab(struct kmem_cache *s, struct page *page)
> > > > > {
> > > > > - dec_slabs_node(s, page_to_nid(page), page->objects);
> > > > > + int inuse = page->objects;
> > > > > +
> > > > > + dec_slabs_node(s, page_to_nid(page), page->objects, inuse);
> > > >
> > > > Is this right? dec_slabs_node(..., page->objects, page->objects)?
> > > >
> > > > If no, we could simply pass the page* to inc_slabs_node/dec_slabs_node
> > > > and save a function argument.
> > > >
> > > > If yes then why?
> > > >
> > >
> > > Thanks for your comments.
> > > We are happy to improve this patch based on your suggestions.
> > >
> > >
> > > When the user reads /proc/slabinfo, in order to obtain the active_objs
> > > information, the kernel traverses all slabs and executes the following code
> > > snippet:
> > > static unsigned long count_partial(struct kmem_cache_node *n,
> > > int (*get_count)(struct page *))
> > > {
> > > unsigned long flags;
> > > unsigned long x = 0;
> > > struct page *page;
> > >
> > > spin_lock_irqsave(&n->list_lock, flags);
> > > list_for_each_entry(page, &n->partial, slab_list)
> > > x += get_count(page);
> > > spin_unlock_irqrestore(&n->list_lock, flags);
> > > return x;
> > > }
> > >
> > > It may cause performance issues.
> > >
> > > Christoph suggested "you could cache the value in the userspace application?
> > > Why is this value read continually?", But reading the /proc/slabinfo is
> > > initiated by the user program. As a cloud provider, we cannot control user
> > > behavior. If a user program inadvertently executes cat /proc/slabinfo, it
> > > may affect other user programs.
> > >
> > > As Christoph said: "The count is not needed for any operations. Just for the
> > > slabinfo output. The value has no operational value for the allocator
> > > itself. So why use extra logic to track it in potentially performance
> > > critical paths?"
> > >
> > > In this way, could we show the approximate value of active_objs in the
> > > /proc/slabinfo?
> > >
> > > Based on the following information:
> > > In the discard_slab() function, page->inuse is equal to page->total_objects;
> > > In the allocate_slab() function, page->inuse is also equal to
> > > page->total_objects (with one exception: for kmem_cache_node, page-> inuse
> > > equals 1);
> > > page->inuse will only change continuously when the obj is constantly
> > > allocated or released. (This should be the performance critical path
> > > emphasized by Christoph)
> > >
> > > When users query the global slabinfo information, we may use total_objects
> > > to approximate active_objs.
> >
> > Well, from one point of view, it makes no sense, because the ratio between
> > these two numbers is very meaningful: it's the slab utilization rate.
> >
> > On the other side, with enabled per-cpu partial lists active_objs has
> > nothing to do with the reality anyway, so I agree with you, calling
> > count_partial() is almost useless.
> >
> > That said, I wonder if the right thing to do is something like the patch below?
> >
> > Thanks!
> >
> > Roman
> >
> > --
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 1d644143f93e..ba0505e75ecc 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -2411,14 +2411,16 @@ static inline unsigned long node_nr_objs(struct kmem_cache_node *n)
> > static unsigned long count_partial(struct kmem_cache_node *n,
> > int (*get_count)(struct page *))
> > {
> > - unsigned long flags;
> > unsigned long x = 0;
> > +#ifdef CONFIG_SLUB_CPU_PARTIAL
> > + unsigned long flags;
> > struct page *page;
> > spin_lock_irqsave(&n->list_lock, flags);
> > list_for_each_entry(page, &n->partial, slab_list)
> > x += get_count(page);
> > spin_unlock_irqrestore(&n->list_lock, flags);
> > +#endif
> > return x;
> > }
> > #endif /* CONFIG_SLUB_DEBUG || CONFIG_SYSFS */
> >
>
> Hi Roman,
>
> Thanks for your comments.
>
> In the server scenario, SLUB_CPU_PARTIAL is turned on by default, and can
> improve the performance of the cloud server, as follows:
Hello, Wen!
That's exactly my point: if CONFIG_SLUB_CPU_PARTIAL is on, count_partial() is useless
anyway because the returned number is far from the reality. So if we define
active_objects == total_objects, as you basically suggest, we do not introduce any
regression. Actually I think it's even preferable to show the unrealistic uniform 100%
slab utilization rather than some very high but incorrect value.
And on real-time systems uncontrolled readings of /proc/slabinfo is less
of a concern, I hope.
Thank you!
^ permalink raw reply
* RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression policy
From: Ariel Elior @ 2020-02-20 15:40 UTC (permalink / raw)
To: Sudarsana Reddy Kalluru, Paul Menzel, GR-everest-linux-l2
Cc: netdev@vger.kernel.org, LKML, it+linux-netdev@molgen.mpg.de,
David S. Miller
In-Reply-To: <MN2PR18MB2528EC91E410FD1BE9FC3EF5D3130@MN2PR18MB2528.namprd18.prod.outlook.com>
> -----Original Message-----
> From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Sent: Thursday, February 20, 2020 11:17 AM
> To: Paul Menzel <pmenzel@molgen.mpg.de>; Ariel Elior
> <aelior@marvell.com>; GR-everest-linux-l2 <GR-everest-linux-
> l2@marvell.com>
> Cc: netdev@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; it+linux-
> netdev@molgen.mpg.de; David S. Miller <davem@davemloft.net>
> Subject: RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression
> policy
>
> Hi Paul,
> Bnx2x driver and the storm FW are tightly coupled, and the info is exchanged
> between them via shmem (i.e., common structures which might change
> between the releases). Also, FW provides some offset addresses to the driver
> which could change between the FW releases, following is one such commit,
> https://www.spinics.net/lists/netdev/msg609889.html
> Hence it's not very straight forward to provide the backward compatibility i.e.,
> newer (updated) kernel driver with the older FW.
> Currently we don’t have plans to implement the new model mentioned below.
>
> Thanks,
> Sudarsana
Hi,
There are additional reasons why backwards/forwards compatibility considerations
are not applicable here. This Fw is not nvram based, and does not reside in the
device. It is programed to the device on every driver load. The driver will
never face a device "already initialized" with a version of FW it is not
familiar with.
The device also has traditional management FW in nvram in the device with which
we have a backwards and forwards compatibility mechanism, which works just
fine.
But the FW under discussion is fastpath Fw, used to craft every packet going out
of the device and analyze and place every packet coming into the device.
Supporting multiple versions of FW would be tantamount to implementing dozens of
versions of start_xmit and napi_poll in the driver (not to mention multiple
fastpath handles of all the offloads the device supports, roce, iscsi, fcoe and
iwarp, as all of these are offloaded by the FW).
The entire device initialization sequence also changes significantly from one FW
version to the Next. All of these differences are abstracted away in the FW
file, which includes the init sequence and the compiled FW. The amount of
changes required in driver are very significant when moving from one version to
the next. Trying to keep all those versions alive concurrently would cause this
already very large driver to be 20x larger.
We don't have a method of keeping the device operational if the kernel was
upgraded but firmware tree was not updated. The best that can be done is report
the problem, which is what we do.
Thanks,
Ariel
^ permalink raw reply
* Re: [meta-oe][PATCH v1 1/4] Ply: Add recipe for git version
From: Khem Raj @ 2020-02-20 15:41 UTC (permalink / raw)
To: Leo Yan; +Cc: Daniel Thompson, Loic Poulain, openembeded-devel
In-Reply-To: <20200218052544.9467-2-leo.yan@linaro.org>
fails to build fot x86/musl
http://errors.yoctoproject.org/Errors/Details/391871/
On Mon, Feb 17, 2020 at 9:26 PM Leo Yan <leo.yan@linaro.org> wrote:
>
> Ply is a light-weight eBPF tool which compiles ply script or one-liner
> to Linux BPF programs and attaches to kprobes and tracepoints. It
> doesn't require external dependencies except libc, so it's very friendly
> for embedded system usage.
>
> This patch adds the recipe to support ply building for git version.
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> meta-oe/recipes-devtools/ply/ply_git.bb | 27 +++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 meta-oe/recipes-devtools/ply/ply_git.bb
>
> diff --git a/meta-oe/recipes-devtools/ply/ply_git.bb b/meta-oe/recipes-devtools/ply/ply_git.bb
> new file mode 100644
> index 000000000..b8295386c
> --- /dev/null
> +++ b/meta-oe/recipes-devtools/ply/ply_git.bb
> @@ -0,0 +1,27 @@
> +SUMMARY = "Ply: A light-weight dynamic tracer for eBPF"
> +HOMEPAGE = "https://github.com/iovisor/ply"
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> +
> +DEPENDS += "bison-native"
> +
> +SRC_URI = "git://github.com/iovisor/ply"
> +SRCREV = "aa5b9ac31307ec1acece818be334ef801c802a12"
> +
> +S = "${WORKDIR}/git"
> +
> +do_configure_prepend() {
> + ( cd ${S}; ./autogen.sh; cd - )
> +}
> +
> +do_configure() {
> + ( cd ${S}; ./configure --host=${TARGET_SYS} --prefix=${D}${prefix}; cd - )
> +}
> +
> +do_compile() {
> + ( cd ${S}; oe_runmake; cd - )
> +}
> +
> +do_install() {
> + ( cd ${S}; oe_runmake install; cd - )
> +}
> --
> 2.17.1
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
^ permalink raw reply
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
From: Lukasz Majewski @ 2020-02-20 15:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
In-Reply-To: <CAK8P3a2qLZBAuP-YT2=KZoP+V23TAKvw5W1_2t7rEr2RobLsWw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3254 bytes --]
Hi Arnd,
> On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> > > wrote:
> > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > > > > <lukma@denx.de> Are there any glibc issues that prevent it
> > > > > from working correctly,
> > > >
> > > > I think that the glibc wrappers for most important syscalls are
> > > > now converted.
> > > >
> > > > What is missing:
> > > >
> > > > - NTPL (threads)
> > > > - stat
> > >
> > > Do you mean that code using these will fail to work correctly with
> > > -D_TIME_BITS=64 at the moment, or that the interfaces are there
> > > but they are not y2038 safe?
> >
> > For ARM32 (branch [2]):
> >
> > - Without -D_TIME_BITS=64 defined during compilation (as we do have
> > now) the glibc is fully functional, but when you set date after
> > 03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901)
> > in the user space programs (after calling e.g. 'date').
>
> I'd actually consider intentionally breaking this for a Debian
> bootstrap, at least initially, so that any application that
> accidentally gets built without -D_TIME_BITS=64 runs into a build or
> link failure.
I do see two approaches here:
1. In glibc:
When -D_TIME_BITS=64 is set - redirections are enabled for syscall
wrappers; for example __clock_settime64 is used instead of
__clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime).
The latter is guarded by #ifdef __TIMESIZE != 64 so we could change
mechanically that __clock_settime returns -1 and sets errno to -ENOTSUPP
2. In kernel - return -ENOTSUPP when clock_settime syscall instead of
clock_settime64 is invoked.
>
> > - With -D_TIME_BITS=64 set during compilation - and using branch
> > [2] - syscalls listed in [1] will provide correct date after Y2038
> > 32 bit overflow. Other (i.e. not converted ones) will use overflow
> > date (1901 year). The glibc will also be fully functional up till
> > Y2038 overflow.
>
> Ok.
>
> > > > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> > > > some basic tests [4], but this may be not enough.
> > >
> > > This is probably something where debian-rebootstrap could help,
> > > as building and testing more user space packages will excercise
> > > additional code paths in glibc as well.
> >
> > Yes this _could_ help. Do you have any tutorial/howto similar to one
> > from [4]?
>
> Not sure, maybe Helmut has some references.
>
> > > There is also some work
> > > in Linaro to ensure that LTP tests the low-level syscall
> > > interfaces in both the time32 and time64 variants.
> >
> > Interesting. Is this work now publicly available?
>
> I think this is currently in the planning stage, but once patches
> are available, they would be posted to the ltp mailing list. Viresh
> should have more details on this.
>
> Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t] intel-ci: add a pre-merge blacklist to reduce the testing queue
From: Chris Wilson @ 2020-02-20 15:43 UTC (permalink / raw)
To: Martin Peres, igt-dev
In-Reply-To: <20200220153209.210767-1-martin.peres@linux.intel.com>
Quoting Martin Peres (2020-02-20 15:32:09)
> +###############################################################################
> +# This test is reading one file at a time while being suspended, which makes
> +# testing extremelly slow. This is somewhat of an edge case that is unlikely
> +# to be hit, hence why it could be dropped from pre-merge testing. Here are the
> +# execution time statistics:
> +#
> +# - shard-skl: 0.5% (~1 minute)
> +# - shard-kbl: 0.1% (~2 seconds)
> +# - shard-apl: 0.1% (~2 seconds)
> +# - shard-glk: 0.1% (~2 seconds)
> +# - shard-icl: 0.6% (~1.5 minutes)
> +# - shard-tgl: 0.7% (~1.5 minutes)
> +#
> +# Data acquired on 2020-02-20 by Martin Peres
> +###############################################################################
> +igt@i915_pm_rpm@debugfs-read
You can say the debugfs-read is a developer-only feature, and it is the
sysfs-read that must be kept working. However, the danger here is that
we get random errors in other tests that would have been caught by this.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.