* 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
* Re: [PATCH 1/2] dt-bindings: watchdog: Add arm,smc-wdt watchdog arm,smc-wdt compatible
From: Guenter Roeck @ 2020-02-20 15:43 UTC (permalink / raw)
To: Evan Benn
Cc: xingyu.chen, Julius Werner, Rob Herring, LKML, devicetree,
David S. Miller, Jonathan Cameron, Mauro Carvalho Chehab,
Wim Van Sebroeck, Greg Kroah-Hartman, Mark Rutland,
linux-watchdog
In-Reply-To: <CAKz_xw2hvHL=a4s37dmuCTWDbxefQFR3rfcaNiWYJY4T+jqabA@mail.gmail.com>
On Thu, Feb 20, 2020 at 05:41:09PM +1100, Evan Benn wrote:
> Dear Xingyu,
>
> Could this driver also cover your usecase? I am not familiar with
> meson, but it seems like the meson calls could
> be replaced with arm_smccc calls. Then this driver will cover both
> chips. I am not sure if your firmware is upstream
> somewhere, but this might be adapted;
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3405
>
FWIW, the Meson driver has more functionality.
Guenter
> Thanks
>
>
> On Thu, Feb 20, 2020 at 10:20 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Wed, Feb 19, 2020 at 03:04:54PM -0800, Julius Werner wrote:
> > > > You are not the first 'watchdog in firmware accessed via an SMC call'.
> > > > Is there some more detail about what implementation this is? Part of
> > > > TF-A? Defined by some spec (I can dream)?
> > >
> > > This is just some random implementation written by me because we
> > > needed one. I would like it to be the new generic implementation, but
> > > it sounds like people here prefer the naming to be MediaTek specific
> > > (at least for now). The other SMC watchdog we're aware of is
> > > imx_sc_wdt but unfortunately that seems to hardcode platform-specific
> >
> > There is one more pending, for Meson SMC.
> >
> > https://patchwork.kernel.org/project/linux-watchdog/list/?series=227733
> >
> > Unfortunately it uses Meson firmware API functions, though it has pretty
> > much the same functionality since those ultimately end up calling
> > arm_smccc_smc().
> >
> > Guenter
> >
> > > details in the interface (at least in the pretimeout SMC) so we can't
> > > just expand that. With this driver I tried to directly wrap the kernel
> > > watchdog interface so it should be platform-agnostic and possible to
> > > expand this driver to other platforms later if desired. The SMC
> > > function ID would still always have to be platform-specific,
> > > unfortunately (but we could pass it in through the device tree), since
> > > the Arm SMC spec doesn't really leave any room for OS-generic SMCs
> > > like this.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v1] drm/i915: Use intel_plane_data_rate for min_cdclk calculation
From: Ville Syrjälä @ 2020-02-20 15:43 UTC (permalink / raw)
To: Stanislav Lisovskiy; +Cc: jani.nikula, intel-gfx
In-Reply-To: <20200220152347.2530-1-stanislav.lisovskiy@intel.com>
On Thu, Feb 20, 2020 at 05:23:47PM +0200, Stanislav Lisovskiy wrote:
> There seems to be a bit of confusing redundancy in a way, how
> plane data rate/min cdclk are calculated.
> In fact both min cdclk, pixel rate and plane data rate are all
> part of the same formula as per BSpec.
>
> However currently we have intel_plane_data_rate, which is used
> to calculate plane data rate and which is also used in bandwidth
> calculations. However for calculating min_cdclk we have another
> piece of code, doing almost same calculation, but a bit differently
> and in a different place. However as both are actually part of same
> formula, probably would be wise to use plane data rate calculations
> as a basis anyway, thus avoiding code duplication and possible bugs
> related to this.
>
> Another thing is that I've noticed that during min_cdclk calculations
> we account for plane scaling, while for plane data rate, we don't.
> crtc->pixel_rate seems to account only for pipe ratio, however it is
> clearly stated in BSpec that plane data rate also need to account
> plane ratio as well.
>
> So what this commit does is:
> - Adds a plane ratio calculation to intel_plane_data_rate
> - Removes redundant calculations from skl_plane_min_cdclk which is
> used for gen9+ and now uses intel_plane_data_rate as a basis from
> there as well.
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 16 ++++++-
> drivers/gpu/drm/i915/display/intel_sprite.c | 46 +++++++++++--------
> 2 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index c86d7a35c816..702dfa14d112 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -133,15 +133,27 @@ intel_plane_destroy_state(struct drm_plane *plane,
> kfree(plane_state);
> }
>
> +
> +
> unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> unsigned int cpp;
> + unsigned int src_w, src_h, dst_w, dst_h;
>
> if (!plane_state->uapi.visible)
> return 0;
>
> + src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
> + src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> + dst_w = drm_rect_width(&plane_state->uapi.dst);
> + dst_h = drm_rect_height(&plane_state->uapi.dst);
> +
> + /* Downscaling limits the maximum pixel rate */
> + dst_w = min(src_w, dst_w);
> + dst_h = min(src_h, dst_h);
> +
> cpp = fb->format->cpp[0];
>
> /*
> @@ -153,7 +165,9 @@ unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
> if (fb->format->is_yuv && fb->format->num_planes > 1)
> cpp *= 4;
>
> - return cpp * crtc_state->pixel_rate;
> + return DIV64_U64_ROUND_UP(mul_u32_u32(cpp * crtc_state->pixel_rate,
> + src_w * src_h),
> + mul_u32_u32(dst_w, dst_h));
You don't need a 64bit divisor for this.
> }
>
> int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 7abeefe8dce5..75afb78ff1b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -330,24 +330,34 @@ bool icl_is_hdr_plane(struct drm_i915_private *dev_priv, enum plane_id plane_id)
> }
>
> static void
> -skl_plane_ratio(const struct intel_crtc_state *crtc_state,
> - const struct intel_plane_state *plane_state,
> - unsigned int *num, unsigned int *den)
> +skl_plane_bpp_constraints(const struct intel_crtc_state *crtc_state,
> + const struct intel_plane_state *plane_state,
> + unsigned int *num, unsigned int *den)
> {
> struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev);
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> + unsigned int cpp = fb->format->cpp[0];
> +
> + /*
> + * Based on HSD#:1408715493
> + * NV12 cpp == 4, P010 cpp == 8
> + *
> + * FIXME what is the logic behind this?
> + */
> + if (fb->format->is_yuv && fb->format->num_planes > 1)
> + cpp *= 4;
This is ugly. I think we need a plane pixel rate instead of
abusing the data rate as the pixel rate like this.
>
> if (fb->format->cpp[0] == 8) {
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> *num = 10;
> - *den = 8;
> + *den = 8 * cpp;
> } else {
> *num = 9;
> - *den = 8;
> + *den = 8 * cpp;
> }
> } else {
> *num = 1;
> - *den = 1;
> + *den = cpp;
> }
> }
>
> @@ -355,27 +365,23 @@ static int skl_plane_min_cdclk(const struct intel_crtc_state *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev);
> - unsigned int pixel_rate = crtc_state->pixel_rate;
> - unsigned int src_w, src_h, dst_w, dst_h;
> unsigned int num, den;
> + struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
>
> - skl_plane_ratio(crtc_state, plane_state, &num, &den);
> + skl_plane_bpp_constraints(crtc_state, plane_state, &num, &den);
>
> /* two pixels per clock on glk+ */
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> den *= 2;
>
> - src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
> - src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> - dst_w = drm_rect_width(&plane_state->uapi.dst);
> - dst_h = drm_rect_height(&plane_state->uapi.dst);
> -
> - /* Downscaling limits the maximum pixel rate */
> - dst_w = min(src_w, dst_w);
> - dst_h = min(src_h, dst_h);
> -
> - return DIV64_U64_ROUND_UP(mul_u32_u32(pixel_rate * num, src_w * src_h),
> - mul_u32_u32(den, dst_w * dst_h));
> + /*
> + * intel_atomic_check_planes has already been called by this
> + * time in intel_atomic_check, so use calculated plane
> + * data rate as a basis, in order not to have duplicate code.
> + * According to BSpec, plane data rate is anyway used as
> + * a basis for this calculation.
> + */
> + return DIV64_U64_ROUND_UP(crtc_state->data_rate[plane->id] * num, den);
> }
>
> static unsigned int
> --
> 2.24.1.485.gad05a3d8e5
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2] xfs: fix iclog release error check race with shutdown
From: Christoph Hellwig @ 2020-02-20 15:43 UTC (permalink / raw)
To: Brian Foster; +Cc: Darrick J. Wong, Dave Chinner, linux-xfs
In-Reply-To: <20200220124144.GA48977@bfoster>
On Thu, Feb 20, 2020 at 07:41:44AM -0500, Brian Foster wrote:
> I wasn't planning on a v3. The discussion to this point has been
> centered around the xfs_force_shutdown() call in the associated function
> (which is orthogonal to the bug). v1 is technically correct, but
> Christoph suggested to restore historical behavior wrt to the shutdown
> call. v2 does that, but is a bit superfluous in that the iclog error
> state with the lock held implies shutdown has already occurred. This is
> harmless (unless we're worried about shutdown performance or
> something..), but I think Dave indicated he preferred v1 based on that
> reasoning.
>
> Functionally I don't think it matters either way and at this point I
> have no preference between v1 or v2. They fix the same problem. Do note
> that v2 does have the Fixed: tag I missed with v1 (as well as a R-b)...
I'm fine with v1 after all this discussion, and volunteer to clean up
all the ioerr handling for the log code after this fix goes in.
That being said as noted in one of my replies I think we also need to
add the same check in the other caller of __xlog_state_release_iclog.
^ permalink raw reply
* [PATCH] selinux-testsuite: Allow nfs test script to close cleanly
From: Richard Haines @ 2020-02-20 15:43 UTC (permalink / raw)
To: selinux; +Cc: Richard Haines
Whenever 'make test' fails, close cleanly.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
---
tools/nfs.sh | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/tools/nfs.sh b/tools/nfs.sh
index 314f898..f99c76b 100755
--- a/tools/nfs.sh
+++ b/tools/nfs.sh
@@ -1,4 +1,16 @@
#!/bin/sh -e
+
+# If 'make test' fails, close down cleanly
+function err_exit() {
+ popd
+ umount /mnt/selinux-testsuite
+ exportfs -u localhost:$MOUNT
+ rmdir /mnt/selinux-testsuite
+ systemctl stop nfs-server
+}
+
+trap 'err_exit' EXIT
+
MOUNT=`stat --print %m .`
TESTDIR=`pwd`
systemctl start nfs-server
--
2.24.1
^ permalink raw reply related
* [dpdk-dev] [PATCH v2] app/testpmd: fix return value in portlist parser
From: Hariprasad Govindharajan @ 2020-02-20 15:43 UTC (permalink / raw)
To: Wenzhuo Lu, Jingjing Wu, Bernard Iremonger
Cc: dev, ferruh.yigit, stephen, david.marchand,
Hariprasad Govindharajan
In-Reply-To: <1582205191-14105-1-git-send-email-hariprasad.govindharajan@intel.com>
The function parse_port_list() is designed to return
unsigned int value. After sanitizing the inputs,
it is returning -1. Changed it to return 0.
Fixes: 2df00d562d20 ("app/testpmd: add --portlist option")
Cc: hariprasad.govindharajan@intel.com
Signed-off-by: Hariprasad Govindharajan <hariprasad.govindharajan@intel.com>
---
app/test-pmd/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 9d95202..91db508 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2642,7 +2642,7 @@ parse_port_list(const char *list, unsigned int *values, unsigned int maxsize)
unsigned int marked[maxsize];
if (list == NULL || values == NULL)
- return -1;
+ return 0;
for (i = 0; i < (int)maxsize; i++)
marked[i] = 0;
--
2.7.4
^ permalink raw reply related
* Re: [meta-oe][PATCH] mraa: upgrade 2.0.0 -> 2.1.0
From: Khem Raj @ 2020-02-20 15:43 UTC (permalink / raw)
To: Wang Mingyu; +Cc: openembeded-devel
In-Reply-To: <1582191622-130680-3-git-send-email-wangmy@cn.fujitsu.com>
fails on musl/x86
http://errors.yoctoproject.org/Errors/Details/391870/
On Wed, Feb 19, 2020 at 6:29 PM Wang Mingyu <wangmy@cn.fujitsu.com> wrote:
>
> Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
> ---
> meta-oe/recipes-extended/mraa/mraa_git.bb | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta-oe/recipes-extended/mraa/mraa_git.bb b/meta-oe/recipes-extended/mraa/mraa_git.bb
> index 6d42c6771..745e4e3b9 100644
> --- a/meta-oe/recipes-extended/mraa/mraa_git.bb
> +++ b/meta-oe/recipes-extended/mraa/mraa_git.bb
> @@ -3,10 +3,10 @@ HOMEPAGE = "https://github.com/intel-iot-devkit/mraa"
> SECTION = "libs"
>
> LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=4b92a3b497d7943042a6db40c088c3f2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=91e7de50a8d3cf01057f318d72460acd"
>
please describe why this changed in commit msg
> -SRCREV = "967585c9ea0e1a8818d2172d2395d8502f6180a2"
> -PV = "2.0.0+git${SRCPV}"
> +SRCREV = "e15ce6fbc76148ba8835adc92196b0d0a3f245e7"
> +PV = "2.1.0+git${SRCPV}"
>
> SRC_URI = "git://github.com/intel-iot-devkit/${BPN}.git;protocol=http \
> "
> --
> 2.17.1
>
>
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
^ permalink raw reply
* Re: [PATCH v2 3/3] tipc: fix issue of calling smp_processor_id() in preemptible
From: Xin Long @ 2020-02-20 15:44 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Ying Xue, David Miller, netdev, Hillf Danton, tipc-discussion,
syzkaller-bugs, Jakub Kicinski, jmaloy
In-Reply-To: <CACT4Y+ZN_1OPukSwp6U4Z7o=8g5SsDhFZD9rtnD8CRObYZgYYg@mail.gmail.com>
On Wed, Feb 19, 2020 at 4:34 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Wed, Feb 19, 2020 at 9:29 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Mon, Aug 12, 2019 at 9:44 AM Ying Xue <ying.xue@windriver.com> wrote:
> > >
> > > syzbot found the following issue:
> > >
> > > [ 81.119772][ T8612] BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor834/8612
> > > [ 81.136212][ T8612] caller is dst_cache_get+0x3d/0xb0
> > > [ 81.141450][ T8612] CPU: 0 PID: 8612 Comm: syz-executor834 Not tainted 5.2.0-rc6+ #48
> > > [ 81.149435][ T8612] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > > [ 81.159480][ T8612] Call Trace:
> > > [ 81.162789][ T8612] dump_stack+0x172/0x1f0
> > > [ 81.167123][ T8612] debug_smp_processor_id+0x251/0x280
> > > [ 81.172479][ T8612] dst_cache_get+0x3d/0xb0
> > > [ 81.176928][ T8612] tipc_udp_xmit.isra.0+0xc4/0xb80
> > > [ 81.182046][ T8612] ? kasan_kmalloc+0x9/0x10
> > > [ 81.186531][ T8612] ? tipc_udp_addr2str+0x170/0x170
> > > [ 81.191641][ T8612] ? __copy_skb_header+0x2e8/0x560
> > > [ 81.196750][ T8612] ? __skb_checksum_complete+0x3f0/0x3f0
> > > [ 81.202364][ T8612] ? netdev_alloc_frag+0x1b0/0x1b0
> > > [ 81.207452][ T8612] ? skb_copy_header+0x21/0x2b0
> > > [ 81.212282][ T8612] ? __pskb_copy_fclone+0x516/0xc90
> > > [ 81.217470][ T8612] tipc_udp_send_msg+0x29a/0x4b0
In tipc_bearer_xmit_skb(), b->media->send_msg()/tipc_udp_send_msg()
is called under rcu_read_lock(), which is already ensure it's a
non-preemptible context.
What I saw here is imbalance rcu_read_(un)lock() call somewhere.
> > > [ 81.222400][ T8612] tipc_bearer_xmit_skb+0x16c/0x360
> > > [ 81.227585][ T8612] tipc_enable_bearer+0xabe/0xd20
> > > [ 81.232606][ T8612] ? __nla_validate_parse+0x2d0/0x1ee0
> > > [ 81.238048][ T8612] ? tipc_bearer_xmit_skb+0x360/0x360
> > > [ 81.243401][ T8612] ? nla_memcpy+0xb0/0xb0
> > > [ 81.247710][ T8612] ? nla_memcpy+0xb0/0xb0
> > > [ 81.252020][ T8612] ? __nla_parse+0x43/0x60
> > > [ 81.256417][ T8612] __tipc_nl_bearer_enable+0x2de/0x3a0
> > > [ 81.261856][ T8612] ? __tipc_nl_bearer_enable+0x2de/0x3a0
> > > [ 81.267467][ T8612] ? tipc_nl_bearer_disable+0x40/0x40
> > > [ 81.272848][ T8612] ? unwind_get_return_address+0x58/0xa0
> > > [ 81.278501][ T8612] ? lock_acquire+0x16f/0x3f0
> > > [ 81.283190][ T8612] tipc_nl_bearer_enable+0x23/0x40
> > > [ 81.288300][ T8612] genl_family_rcv_msg+0x74b/0xf90
> > > [ 81.293404][ T8612] ? genl_unregister_family+0x790/0x790
> > > [ 81.298935][ T8612] ? __lock_acquire+0x54f/0x5490
> > > [ 81.303852][ T8612] ? __netlink_lookup+0x3fa/0x7b0
> > > [ 81.308865][ T8612] genl_rcv_msg+0xca/0x16c
> > > [ 81.313266][ T8612] netlink_rcv_skb+0x177/0x450
> > > [ 81.318043][ T8612] ? genl_family_rcv_msg+0xf90/0xf90
> > > [ 81.323311][ T8612] ? netlink_ack+0xb50/0xb50
> > > [ 81.327906][ T8612] ? lock_acquire+0x16f/0x3f0
> > > [ 81.332589][ T8612] ? kasan_check_write+0x14/0x20
> > > [ 81.337511][ T8612] genl_rcv+0x29/0x40
> > > [ 81.341485][ T8612] netlink_unicast+0x531/0x710
> > > [ 81.346268][ T8612] ? netlink_attachskb+0x770/0x770
> > > [ 81.351374][ T8612] ? _copy_from_iter_full+0x25d/0x8c0
> > > [ 81.356765][ T8612] ? __sanitizer_cov_trace_cmp8+0x18/0x20
> > > [ 81.362479][ T8612] ? __check_object_size+0x3d/0x42f
> > > [ 81.367667][ T8612] netlink_sendmsg+0x8ae/0xd70
> > > [ 81.372415][ T8612] ? netlink_unicast+0x710/0x710
> > > [ 81.377520][ T8612] ? aa_sock_msg_perm.isra.0+0xba/0x170
> > > [ 81.383051][ T8612] ? apparmor_socket_sendmsg+0x2a/0x30
> > > [ 81.388530][ T8612] ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
> > > [ 81.394775][ T8612] ? security_socket_sendmsg+0x8d/0xc0
> > > [ 81.400240][ T8612] ? netlink_unicast+0x710/0x710
> > > [ 81.405161][ T8612] sock_sendmsg+0xd7/0x130
> > > [ 81.409561][ T8612] ___sys_sendmsg+0x803/0x920
> > > [ 81.414220][ T8612] ? copy_msghdr_from_user+0x430/0x430
> > > [ 81.419667][ T8612] ? _raw_spin_unlock_irqrestore+0x6b/0xe0
> > > [ 81.425461][ T8612] ? debug_object_active_state+0x25d/0x380
> > > [ 81.431255][ T8612] ? __lock_acquire+0x54f/0x5490
> > > [ 81.436174][ T8612] ? kasan_check_read+0x11/0x20
> > > [ 81.441208][ T8612] ? _raw_spin_unlock_irqrestore+0xa4/0xe0
> > > [ 81.447008][ T8612] ? mark_held_locks+0xf0/0xf0
> > > [ 81.451768][ T8612] ? __call_rcu.constprop.0+0x28b/0x720
> > > [ 81.457298][ T8612] ? call_rcu+0xb/0x10
> > > [ 81.461353][ T8612] ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
> > > [ 81.467589][ T8612] ? __fget_light+0x1a9/0x230
> > > [ 81.472249][ T8612] ? __fdget+0x1b/0x20
> > > [ 81.476301][ T8612] ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
> > > [ 81.482545][ T8612] __sys_sendmsg+0x105/0x1d0
> > > [ 81.487115][ T8612] ? __ia32_sys_shutdown+0x80/0x80
> > > [ 81.492208][ T8612] ? blkcg_maybe_throttle_current+0x5e2/0xfb0
> > > [ 81.498272][ T8612] ? trace_hardirqs_on_thunk+0x1a/0x1c
> > > [ 81.503726][ T8612] ? do_syscall_64+0x26/0x680
> > > [ 81.508385][ T8612] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > [ 81.514444][ T8612] ? do_syscall_64+0x26/0x680
> > > [ 81.519110][ T8612] __x64_sys_sendmsg+0x78/0xb0
> > > [ 81.523862][ T8612] do_syscall_64+0xfd/0x680
> > > [ 81.528352][ T8612] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > [ 81.534234][ T8612] RIP: 0033:0x444679
> > > [ 81.538114][ T8612] Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 1b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > [ 81.557709][ T8612] RSP: 002b:00007fff0201a8b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > > [ 81.566147][ T8612] RAX: ffffffffffffffda RBX: 00000000004002e0 RCX: 0000000000444679
> > > [ 81.574108][ T8612] RDX: 0000000000000000 RSI: 0000000020000580 RDI: 0000000000000003
> > > [ 81.582152][ T8612] RBP: 00000000006cf018 R08: 0000000000000001 R09: 00000000004002e0
> > > [ 81.590113][ T8612] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000402320
> > > [ 81.598089][ T8612] R13: 00000000004023b0 R14: 0000000000000000 R15: 0000000000
> > >
> > > In commit e9c1a793210f ("tipc: add dst_cache support for udp media")
> > > dst_cache_get() was introduced to be called in tipc_udp_xmit(). But
> > > smp_processor_id() called by dst_cache_get() cannot be invoked in
> > > preemptible context, as a result, the complaint above was reported.
> > >
> > > Fixes: e9c1a793210f ("tipc: add dst_cache support for udp media")
> > > Reported-by: syzbot+1a68504d96cd17b33a05@syzkaller.appspotmail.com
> > > Signed-off-by: Hillf Danton <hdanton@sina.com>
> > > Signed-off-by: Ying Xue <ying.xue@windriver.com>
> >
> > Hi,
> >
> > Was this ever merged?
> > The bug is still open, alive and kicking:
> > https://syzkaller.appspot.com/bug?extid=1a68504d96cd17b33a05
> >
> > and one of the top crashers currently.
> > Along with few other top crashers, these bugs prevent most of the
> > other kernel testing from happening.
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
> +jmaloy new email address
>
> > > ---
> > > net/tipc/udp_media.c | 12 +++++++++---
> > > 1 file changed, 9 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
> > > index 287df687..ca3ae2e 100644
> > > --- a/net/tipc/udp_media.c
> > > +++ b/net/tipc/udp_media.c
> > > @@ -224,6 +224,8 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
> > > struct udp_bearer *ub;
> > > int err = 0;
> > >
> > > + local_bh_disable();
> > > +
> > > if (skb_headroom(skb) < UDP_MIN_HEADROOM) {
> > > err = pskb_expand_head(skb, UDP_MIN_HEADROOM, 0, GFP_ATOMIC);
> > > if (err)
> > > @@ -237,9 +239,12 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
> > > goto out;
> > > }
> > >
> > > - if (addr->broadcast != TIPC_REPLICAST_SUPPORT)
> > > - return tipc_udp_xmit(net, skb, ub, src, dst,
> > > - &ub->rcast.dst_cache);
> > > + if (addr->broadcast != TIPC_REPLICAST_SUPPORT) {
> > > + err = tipc_udp_xmit(net, skb, ub, src, dst,
> > > + &ub->rcast.dst_cache);
> > > + local_bh_enable();
> > > + return err;
> > > + }
> > >
> > > /* Replicast, send an skb to each configured IP address */
> > > list_for_each_entry_rcu(rcast, &ub->rcast.list, list) {
> > > @@ -259,6 +264,7 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
> > > err = 0;
> > > out:
> > > kfree_skb(skb);
> > > + local_bh_enable();
> > > return err;
> > > }
> > >
> > > --
> > > 2.7.4
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/1565595162-1383-4-git-send-email-ying.xue%40windriver.com.
^ permalink raw reply
* Re: [PATCH v9 0/3] Acceptance test: Add "boot_linux" acceptance test
From: Cleber Rosa @ 2020-02-20 15:43 UTC (permalink / raw)
To: qemu-devel
Cc: Fam Zheng, Eduardo Habkost, Alex Bennée,
Wainer dos Santos Moschetta, Willian Rampazzo,
Philippe Mathieu-Daudé, Beraldo Leal
In-Reply-To: <20200220020652.16276-1-crosa@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
On Wed, Feb 19, 2020 at 09:06:49PM -0500, Cleber Rosa wrote:
>
> Changes from v8:
> ================
>
...
> * Bumped pycdlib version to 1.9.0, which contains an endianess bug that
> was seen on s390x hosts.
I meant, "which contains a bug *fix*". Hopefully not introducing bugs on
purpose! :)
- Cleber.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] selinux: Add xfs quota command types
From: Christoph Hellwig @ 2020-02-20 15:44 UTC (permalink / raw)
To: Richard Haines; +Cc: darrick.wong, sds, paul, linux-xfs, selinux
In-Reply-To: <20200220153234.152426-2-richard_c_haines@btinternet.com>
On Thu, Feb 20, 2020 at 03:32:34PM +0000, Richard Haines wrote:
> 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>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ 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.