* Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 15:34 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200220142759.GA13686@intel.com>
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some stats for the whole series:
> > >
> > > 64bit sizeof(struct drm_display_mode):
> > > 200 -> 136 bytes (-32%)
> > >
> > > 64bit bloat-o-meter -c drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > > Function old new delta
> > > ...
> > > Total: Before=189430, After=188779, chg -0.34%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=11667, After=11667, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 1000 680 -320
> > > edid_est_modes 3400 2312 -1088
> > > edid_cea_modes_193 5400 3672 -1728
> > > drm_dmt_modes 17600 11968 -5632
> > > edid_cea_modes_1 25400 17272 -8128
> > > Total: Before=71239, After=54343, chg -23.72%
> > >
> > >
> > > 64bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > > ...
> > > Total: Before=272336, After=254789, chg -6.44%
> > >
> > >
> > > 32bit sizeof(struct drm_display_mode):
> > > 184 -> 120 bytes (-34%)
> > >
> > > 32bit bloat-o-meter -c drm.ko
> > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > > Function old new delta
> > > ...
> > > Total: Before=172359, After=171734, chg -0.36%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=4227, After=4227, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 920 600 -320
> > > edid_est_modes 3128 2040 -1088
> > > edid_cea_modes_193 4968 3240 -1728
> > > drm_dmt_modes 16192 10560 -5632
> > > edid_cea_modes_1 23368 15240 -8128
> > > Total: Before=59230, After=42334, chg -28.53%
> > >
> > > 32bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > > ...
> > > Total: Before=235816, After=218295, chg -7.43%
> > >
> > >
> > > Some ideas for further reduction:
> > > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > > struct but would often require a heap alloc for the name (though
> > > typical mode name is <10 bytes so still overall win perhaps)
> > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > > place where we have to preserve the user provided name, elsewhere
> > > could pehaps just generate on demand? Not sure how tricky this
> > > would get.
> >
> > The series does some great work, with future work reaching the cache
> > line for 64bit.
> > Doing much more than that might be an overkill IMHO.
> >
> > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> > avoiding the heap alloc/calc on demand fun.
> > While also ensuring the name is sufficiently large for the next decade or so.
>
> Unfortunately it's part of the uabi. So can't change it without some
> risk of userspace breakage.
>
> The least demanding option is probably to nuke export_head. We need
> one bit to replace it, which we can get by either:
> - stealing from eg. mode->type, or perhaps mode->private_flags
> - nuke private_flags outright and replace it with a bool for this
> purpose
Looks like getting rid of private_flags is going to be pretty
straightforward. I'll post patches for that once this first series
lands.
--
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: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 15:34 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200220142759.GA13686@intel.com>
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some stats for the whole series:
> > >
> > > 64bit sizeof(struct drm_display_mode):
> > > 200 -> 136 bytes (-32%)
> > >
> > > 64bit bloat-o-meter -c drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > > Function old new delta
> > > ...
> > > Total: Before=189430, After=188779, chg -0.34%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=11667, After=11667, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 1000 680 -320
> > > edid_est_modes 3400 2312 -1088
> > > edid_cea_modes_193 5400 3672 -1728
> > > drm_dmt_modes 17600 11968 -5632
> > > edid_cea_modes_1 25400 17272 -8128
> > > Total: Before=71239, After=54343, chg -23.72%
> > >
> > >
> > > 64bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > > ...
> > > Total: Before=272336, After=254789, chg -6.44%
> > >
> > >
> > > 32bit sizeof(struct drm_display_mode):
> > > 184 -> 120 bytes (-34%)
> > >
> > > 32bit bloat-o-meter -c drm.ko
> > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > > Function old new delta
> > > ...
> > > Total: Before=172359, After=171734, chg -0.36%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=4227, After=4227, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 920 600 -320
> > > edid_est_modes 3128 2040 -1088
> > > edid_cea_modes_193 4968 3240 -1728
> > > drm_dmt_modes 16192 10560 -5632
> > > edid_cea_modes_1 23368 15240 -8128
> > > Total: Before=59230, After=42334, chg -28.53%
> > >
> > > 32bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > > ...
> > > Total: Before=235816, After=218295, chg -7.43%
> > >
> > >
> > > Some ideas for further reduction:
> > > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > > struct but would often require a heap alloc for the name (though
> > > typical mode name is <10 bytes so still overall win perhaps)
> > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > > place where we have to preserve the user provided name, elsewhere
> > > could pehaps just generate on demand? Not sure how tricky this
> > > would get.
> >
> > The series does some great work, with future work reaching the cache
> > line for 64bit.
> > Doing much more than that might be an overkill IMHO.
> >
> > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> > avoiding the heap alloc/calc on demand fun.
> > While also ensuring the name is sufficiently large for the next decade or so.
>
> Unfortunately it's part of the uabi. So can't change it without some
> risk of userspace breakage.
>
> The least demanding option is probably to nuke export_head. We need
> one bit to replace it, which we can get by either:
> - stealing from eg. mode->type, or perhaps mode->private_flags
> - nuke private_flags outright and replace it with a bool for this
> purpose
Looks like getting rid of private_flags is going to be pretty
straightforward. I'll post patches for that once this first series
lands.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] usb: gadget: net2280: Distribute switch variables for initialization
From: Alan Stern @ 2020-02-20 15:34 UTC (permalink / raw)
To: Kees Cook
Cc: Greg Kroah-Hartman, Felipe Balbi, Alexander Potapenko, linux-usb,
linux-kernel
In-Reply-To: <20200220062315.69253-1-keescook@chromium.org>
On Wed, 19 Feb 2020, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization feature, this triggers a warning (and they
> don't get initialized). Clang's automatic stack variable initialization
> (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> doesn't initialize such variables[1]. Note that these warnings (or silent
> skipping) happen before the dead-store elimination optimization phase,
> so even when the automatic initializations are later elided in favor of
> direct initializations, the warnings remain.
>
> To avoid these problems, move such variables into the "case" where
> they're used or lift them up into the main function body.
>
> drivers/usb/gadget/udc/net2280.c: In function ‘handle_stat0_irqs_superspeed’:
> drivers/usb/gadget/udc/net2280.c:2871:22: warning: statement will never be executed [-Wswitch-unreachable]
> 2871 | struct net2280_ep *e;
> | ^
>
> [1] https://bugs.llvm.org/show_bug.cgi?id=44916
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> drivers/usb/gadget/udc/net2280.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
> index 1fd1b9186e46..cc5869363298 100644
> --- a/drivers/usb/gadget/udc/net2280.c
> +++ b/drivers/usb/gadget/udc/net2280.c
> @@ -2861,6 +2861,7 @@ static void ep_clear_seqnum(struct net2280_ep *ep)
> static void handle_stat0_irqs_superspeed(struct net2280 *dev,
> struct net2280_ep *ep, struct usb_ctrlrequest r)
> {
> + struct net2280_ep *e;
> int tmp = 0;
>
> #define w_value le16_to_cpu(r.wValue)
> @@ -2868,14 +2869,13 @@ static void handle_stat0_irqs_superspeed(struct net2280 *dev,
> #define w_length le16_to_cpu(r.wLength)
>
> switch (r.bRequest) {
> - struct net2280_ep *e;
> - u16 status;
> -
> case USB_REQ_SET_CONFIGURATION:
> dev->addressed_state = !w_value;
> goto usb3_delegate;
>
> - case USB_REQ_GET_STATUS:
> + case USB_REQ_GET_STATUS: {
> + u16 status;
> +
> switch (r.bRequestType) {
> case (USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE):
> status = dev->wakeup_enable ? 0x02 : 0x00;
> @@ -2905,7 +2905,7 @@ static void handle_stat0_irqs_superspeed(struct net2280 *dev,
> goto usb3_delegate;
> }
> break;
> -
> + }
This is an unusual use of nested blocks (i.e., a block immediately
following a "case" label, and it throws the indentation off -- there
will now be two nested closing braces at the same indentation level:
this one and the one preceding do_stall3:.
Just define status at the function level, along with e, and don't
worry about it.
Alan Stern
> case USB_REQ_CLEAR_FEATURE:
> switch (r.bRequestType) {
> case (USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE):
>
>
>
^ permalink raw reply
* Re: [PATCH] MIPS: cavium_octeon: Fix syncw generation.
From: Dmitry Golovin @ 2020-02-20 15:28 UTC (permalink / raw)
To: Nick Desaulniers, Chris Packham
Cc: Mark Tomlinson, f4bug@amsat.org, linux-kernel@vger.kernel.org,
clang-built-linux@googlegroups.com, paulburton@kernel.org,
linux-mips@vger.kernel.org
In-Reply-To: <CAKwvOdkaLRE0Ek3PnmqE2P3Urn4+pwfAp-qQdsLurwERcqNXfQ@mail.gmail.com>
18.02.2020, 20:37, "'Nick Desaulniers' via Clang Built Linux" <clang-built-linux@googlegroups.com>:
>> There is an effort underway to build the kernel with clang[1]. I'm not
>> sure what that ends up using for an assembler or if it'll even be able
>> to target mips64 anytime soon.
I have a working build for MIPS64 (only mips64r6 at the moment), the
config is based on malta_defconfig and it boots in qemu. I still don't
have a matching buildroot image, but it shouldn't be a problem.
Regards,
Dima
^ permalink raw reply
* Re: NVMe/IB support
From: Max Gurtovoy @ 2020-02-20 15:16 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Talker Alex, linux-nvme
In-Reply-To: <20200220142517.GA20993@infradead.org>
On 2/20/2020 4:25 PM, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 04:13:07PM +0200, Max Gurtovoy wrote:
>> On 2/19/2020 5:20 PM, Christoph Hellwig wrote:
>>> On Fri, Feb 07, 2020 at 03:43:22PM +0300, Talker Alex wrote:
>>>> Hi,
>>>>
>>>> is there really exist NVMe/IB solutions?
>>> All the original NVMeoF development was done on IB, just using the
>>> RDMA/CM IP based addressing.
>> I guess we can consider adding this code one day, for users that can't use
>> RDMA/CM (SRP supports both options).
> The NVMeOF RDMA transport requires RDMA/CM. But RDMA/CM can also use
> IB addressing, which should be easy enough to implement if someone
> cares.
Are you saying that if one would like to use ADRFAM == AF_IB, he must
have RDMA/CM stack that support IB addressing ?
seems little bit weird requirement...
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: Fix some off by one bugs
From: Linus Walleij @ 2020-02-20 15:14 UTC (permalink / raw)
To: Dan Carpenter, Matthias Brugger
Cc: open list:GPIO SUBSYSTEM, kernel-janitors, Sean Wang,
moderated list:ARM/Mediatek SoC support, Light Hsieh
In-Reply-To: <20200218055247.74s2xa7veqx2do34@kili.mountain>
On Tue, Feb 18, 2020 at 6:55 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> These comparisons should be >= instead of > to prevent accessing one
> element beyond the end of the hw->soc->pins[] array.
>
> Fixes: 3de7deefce69 ("pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Matthias could you have a look at this patch?
Yours,
Linus Walleij
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH v2] pinctrl: ingenic: Improve unreachable code generation
From: Josh Poimboeuf @ 2020-02-20 15:35 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, linux-gpio, linux-kernel, Peter Zijlstra,
Randy Dunlap
In the second loop of ingenic_pinconf_set(), it annotates the switch
default case as unreachable(). The annotation is technically correct,
because that same case would have resulted in an early function return
in the previous loop.
However, the compiled code is suboptimal. GCC seems to work extra hard
to ensure that the unreachable code path triggers undefined behavior.
The function would fall through to start executing whatever function
happens to be next in the compilation unit.
This is problematic because:
a) it adds unnecessary 'ensure undefined behavior' logic, and
corresponding i-cache footprint; and
b) it's less robust -- if a bug were to be introduced, falling through
to the next function would be catastrophic.
Yet another issue is that, while objtool normally understands
unreachable() annotations, there's one special case where it doesn't:
when the annotation occurs immediately after a 'ret' instruction. That
happens to be the case here because unreachable() is immediately before
the return.
Remove the unreachable() annotation and replace it with a comment. This
simplifies the code generation and changes the unreachable error path to
just silently return instead of corrupting execution.
This fixes the following objtool warning:
drivers/pinctrl/pinctrl-ingenic.o: warning: objtool: ingenic_pinconf_set() falls through to next function ingenic_pinconf_group_set()
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
drivers/pinctrl/pinctrl-ingenic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c
index 96f04d121ebd..13c7d3351ed5 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -2158,7 +2158,8 @@ static int ingenic_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
break;
default:
- unreachable();
+ /* unreachable */
+ break;
}
}
--
2.21.1
^ permalink raw reply related
* [PATCH] nvme-multipath: do not reset on unknown status
From: Keith Busch @ 2020-02-20 14:52 UTC (permalink / raw)
To: linux-nvme, hch, sagi; +Cc: Keith Busch, hare, John Meneghini
From: John Meneghini <johnm@netapp.com>
The nvme multipath error handling defaults to controller reset if the
error is unknown. There are, however, no existing nvme status codes that
indicate a reset should be used, and resetting causes unnecessary
disruption to the rest of IO.
Change nvme's error handling to first check if failover should happen.
If not, let the normal error handling take over rather than reset the
controller.
Signed-off-by: John Meneghini <johnm@netapp.com>
[changelog]
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
drivers/nvme/host/core.c | 4 +---
drivers/nvme/host/multipath.c | 21 +++++++++------------
drivers/nvme/host/nvme.h | 5 +++--
3 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 84914223c537..0eef1ef8c659 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -292,10 +292,8 @@ void nvme_complete_rq(struct request *req)
if (unlikely(status != BLK_STS_OK && nvme_req_needs_retry(req))) {
if ((req->cmd_flags & REQ_NVME_MPATH) &&
- blk_path_error(status)) {
- nvme_failover_req(req);
+ nvme_failover_req(req))
return;
- }
if (!blk_queue_dying(req->q)) {
nvme_retry_req(req);
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 797c18337d96..16df0baaeb40 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -64,17 +64,12 @@ void nvme_set_disk_name(char *disk_name, struct nvme_ns *ns,
}
}
-void nvme_failover_req(struct request *req)
+bool nvme_failover_req(struct request *req)
{
struct nvme_ns *ns = req->q->queuedata;
u16 status = nvme_req(req)->status;
unsigned long flags;
- spin_lock_irqsave(&ns->head->requeue_lock, flags);
- blk_steal_bios(&ns->head->requeue_list, req);
- spin_unlock_irqrestore(&ns->head->requeue_lock, flags);
- blk_mq_end_request(req, 0);
-
switch (status & 0x7ff) {
case NVME_SC_ANA_TRANSITION:
case NVME_SC_ANA_INACCESSIBLE:
@@ -103,15 +98,17 @@ void nvme_failover_req(struct request *req)
nvme_mpath_clear_current_path(ns);
break;
default:
- /*
- * Reset the controller for any non-ANA error as we don't know
- * what caused the error.
- */
- nvme_reset_ctrl(ns->ctrl);
- break;
+ /* This was a non-ANA error so follow the normal error path. */
+ return false;
}
+ spin_lock_irqsave(&ns->head->requeue_lock, flags);
+ blk_steal_bios(&ns->head->requeue_list, req);
+ spin_unlock_irqrestore(&ns->head->requeue_lock, flags);
+ blk_mq_end_request(req, 0);
+
kblockd_schedule_work(&ns->head->requeue_work);
+ return true;
}
void nvme_kick_requeue_lists(struct nvme_ctrl *ctrl)
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 1024fec7914c..d800b9a51c2c 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -550,7 +550,7 @@ void nvme_mpath_wait_freeze(struct nvme_subsystem *subsys);
void nvme_mpath_start_freeze(struct nvme_subsystem *subsys);
void nvme_set_disk_name(char *disk_name, struct nvme_ns *ns,
struct nvme_ctrl *ctrl, int *flags);
-void nvme_failover_req(struct request *req);
+bool nvme_failover_req(struct request *req);
void nvme_kick_requeue_lists(struct nvme_ctrl *ctrl);
int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl,struct nvme_ns_head *head);
void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id);
@@ -599,8 +599,9 @@ static inline void nvme_set_disk_name(char *disk_name, struct nvme_ns *ns,
sprintf(disk_name, "nvme%dn%d", ctrl->instance, ns->head->instance);
}
-static inline void nvme_failover_req(struct request *req)
+static inline bool nvme_failover_req(struct request *req)
{
+ return false;
}
static inline void nvme_kick_requeue_lists(struct nvme_ctrl *ctrl)
{
--
2.21.0
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply related
* Re: [PATCH -next] pinctrl: mediatek: remove set but not used variable 'e'
From: Linus Walleij @ 2020-02-20 15:14 UTC (permalink / raw)
To: YueHaibing
Cc: linux-arm-kernel, Sean Wang, linux-kernel@vger.kernel.org,
Light Hsieh, open list:GPIO SUBSYSTEM,
moderated list:ARM/Mediatek SoC support, Matthias Brugger
In-Reply-To: <20200218023625.14324-1-yuehaibing@huawei.com>
On Tue, Feb 18, 2020 at 3:36 AM YueHaibing <yuehaibing@huawei.com> wrote:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c: In function mtk_hw_pin_field_lookup:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:70:39: warning:
> variable e set but not used [-Wunused-but-set-variable]
>
> Since commit 3de7deefce69 ("pinctrl: mediatek: Check gpio pin
> number and use binary search in mtk_hw_pin_field_lookup()"),
> it is not used any more, so remove it, also remove redundant
> assignment to variable c, it will be assigned a new value later
> before used.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied with Matthias Review tag.
Yours,
Linus Walleij
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
From: linmiaohe @ 2020-02-20 15:36 UTC (permalink / raw)
To: pbonzini, rkrcmar, sean.j.christopherson, vkuznets, wanpengli,
jmattson, joro, tglx, mingo, bp, hpa
Cc: linmiaohe, kvm, linux-kernel, x86
From: Miaohe Lin <linmiaohe@huawei.com>
When get user eoi value failed, var val would be uninitialized and result
in calculating pending eoi from an uninitialized val. Initialize var val
to 0 to fix this case.
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
arch/x86/kvm/lapic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 4f14ec7525f6..7e77e94f3176 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -626,7 +626,7 @@ static inline bool pv_eoi_enabled(struct kvm_vcpu *vcpu)
static bool pv_eoi_get_pending(struct kvm_vcpu *vcpu)
{
- u8 val;
+ u8 val = 0;
if (pv_eoi_get_user(vcpu, &val) < 0)
printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
(unsigned long long)vcpu->arch.pv_eoi.msr_val);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 1/3] btrfs: Call btrfs_check_uuid_tree_entry directly in btrfs_uuid_tree_iterate
From: Josef Bacik @ 2020-02-20 15:36 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs
In-Reply-To: <20200218145609.13427-2-nborisov@suse.com>
On 2/18/20 9:56 AM, Nikolay Borisov wrote:
> btrfs_uuid_tree_iterate is called from only once place and its 2nd
> argument is always btrfs_check_uuid_tree_entry. Simplify
> btrfs_uuid_tree_iterate's signature by removing its 2nd argument and
> directly calling btrfs_check_uuid_tree_entry. Also move the latter
> into uuid-tree.h. No functional changes.
You forgot your signed-off-by
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events
From: Thomas Monjalon @ 2020-02-20 15:37 UTC (permalink / raw)
To: Ye Xiaolong, taox.zhu, Ferruh Yigit
Cc: dev, konstantin.ananyev, wenzhuo.lu, stable
In-Reply-To: <2b14bca2-f69c-bd29-8e6c-65a174ed609e@intel.com>
17/02/2020 14:01, Ferruh Yigit:
> On 2/15/2020 3:41 PM, Ye Xiaolong wrote:
> > On 01/15, taox.zhu@intel.com wrote:
> >> From: Zhu Tao <taox.zhu@intel.com>
> >>
> >> IXGBE link status task use rte alarm thread in old implementation.
> >
> > s/use/uses
> >
> >> Sometime ixgbe link status task takes up to 9 seconds. This will
> >> severely affect the rte-alarm-thread-dependent a task in the
> >> system, like interrupt or hotplug event. So replace with a
> >
> > s/a/an
> >
> >> independent thread which has the same thread affinity settings
> >> as rte interrupt.
> >>
> >> Fixes: 0408f47b ("net/ixgbe: fix busy polling while fiber link update")
> >
> > Should be:
> >
> > Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link update")
> >
> >> Cc: stable@dpdk.org
> >>
> >
> > Applied to dpdk-next-net-intel with Konstantin's ack, Thanks.
> >
>
> Shared build is failing because of missing pthread library, fixing while merging
> to next-net:
One more thing looks strange in this patch:
ixgbe_dev_cannel_link_thread
Should it be
ixgbe_dev_cancel_link_thread
?
Note: I looked at it because I am not sure multiplying the interrupt
threads is a good idea.
Basically the link status management is too long in this driver.
Instead of fixing the root cause, you move the annoying workload
somewhere else. But it is still there...
Please could you work on a long term fix?
^ permalink raw reply
* Re: [Xen-devel] [PATCH] x86/vpt: update last_guest_time with cmpxchg and drop pl_time_lock
From: Igor Druzhinin @ 2020-02-20 15:37 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, roger.pau, wl, andrew.cooper3
In-Reply-To: <86036433-0dd9-773c-3855-fb4b4697fc08@suse.com>
On 20/02/2020 08:27, Jan Beulich wrote:
> On 19.02.2020 19:52, Igor Druzhinin wrote:
>> On 19/02/2020 07:48, Jan Beulich wrote:
>>> On 20.12.2019 22:39, Igor Druzhinin wrote:
>>>> @@ -38,24 +37,22 @@ void hvm_init_guest_time(struct domain *d)
>>>> uint64_t hvm_get_guest_time_fixed(const struct vcpu *v, uint64_t at_tsc)
>>>> {
>>>> struct pl_time *pl = v->domain->arch.hvm.pl_time;
>>>> - u64 now;
>>>> + s_time_t old, new, now = get_s_time_fixed(at_tsc) + pl->stime_offset;
>>>>
>>>> /* Called from device models shared with PV guests. Be careful. */
>>>> ASSERT(is_hvm_vcpu(v));
>>>>
>>>> - spin_lock(&pl->pl_time_lock);
>>>> - now = get_s_time_fixed(at_tsc) + pl->stime_offset;
>>>> -
>>>> if ( !at_tsc )
>>>> {
>>>> - if ( (int64_t)(now - pl->last_guest_time) > 0 )
>>>> - pl->last_guest_time = now;
>>>> - else
>>>> - now = ++pl->last_guest_time;
>>>> + do {
>>>> + old = pl->last_guest_time;
>>>> + new = now > pl->last_guest_time ? now : old + 1;
>>>> + } while ( cmpxchg(&pl->last_guest_time, old, new) != old );
>>>
>>> I wonder whether you wouldn't better re-invoke get_s_time() in
>>> case you need to retry here. See how the function previously
>>> was called only after the lock was already acquired.
>>
>> If there is a concurrent writer, wouldn't it just update pl->last_guest_time
>> with the new get_s_time() and then we subsequently would just use the new
>> time on retry?
>
> Yes, it would, but the latency until the retry actually occurs
> is unknown (in particular if Xen itself runs virtualized). I.e.
> in the at_tsc == 0 case I think the value would better be
> re-calculated on every iteration.
Why does it need to be recalculated if a concurrent writer did this
for us already anyway and (get_s_time_fixed(at_tsc) + pl->stime_offset)
value is common for all of vCPUs? Yes, it might reduce jitter slightly
but overall latency could come from any point (especially in case of
rinning virtualized) and it's important just to preserve invariant that
the value is monotonic across vCPUs.
> Anther thing I notice only now are the multiple reads of
> pl->last_guest_time. Wouldn't you better do
>
> do {
> old = ACCESS_ONCE(pl->last_guest_time);
> new = now > old ? now : old + 1;
> } while ( cmpxchg(&pl->last_guest_time, old, new) != old );
>
> ?
Fair enough, although even reading it multiple times wouldn't cause
any harm as any inconsistency would be resolved by cmpxchg op. I'd
prefer to make it in a separate commit to unify it with pv_soft_rdtsc().
Igor
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 3/3] btrfs: Make btrfs_check_uuid_tree private to disk-io.c
From: Josef Bacik @ 2020-02-20 15:37 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs
In-Reply-To: <20200218145609.13427-4-nborisov@suse.com>
On 2/18/20 9:56 AM, Nikolay Borisov wrote:
> It's used only during fs mount as such it can be made private to
> disk-io.c file. Also use the occassion to move btrfs_uuid_rescan_kthread
> as btrfs_check_uuid_tree is its sole caller. No functional changes.
> ---
Forgot your signed-off-by here as well. And it's "occasion".
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* 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
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.