* Re: [PATCH 0/2] Limit number of hw queues by nr_cpu_ids for virtio-blk and virtio-scsi
From: Jens Axboe @ 2019-04-10 14:18 UTC (permalink / raw)
To: Dongli Zhang, linux-scsi, virtualization, linux-block
Cc: mst, jasowang, jejb, martin.petersen, cohuck, linux-kernel
In-Reply-To: <1553682995-5682-1-git-send-email-dongli.zhang@oracle.com>
On 3/27/19 4:36 AM, Dongli Zhang wrote:
> When tag_set->nr_maps is 1, the block layer limits the number of hw queues
> by nr_cpu_ids. No matter how many hw queues are use by
> virtio-blk/virtio-scsi, as they both have (tag_set->nr_maps == 1), they
> can use at most nr_cpu_ids hw queues.
>
> In addition, specifically for pci scenario, when the 'num-queues' specified
> by qemu is more than maxcpus, virtio-blk/virtio-scsi would not be able to
> allocate more than maxcpus vectors in order to have a vector for each
> queue. As a result, they fall back into MSI-X with one vector for config
> and one shared for queues.
>
> Considering above reasons, this patch set limits the number of hw queues
> used by nr_cpu_ids for both virtio-blk and virtio-scsi.
I picked both up for 5.1.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 0/2] Limit number of hw queues by nr_cpu_ids for virtio-blk and virtio-scsi
From: Jens Axboe @ 2019-04-10 14:18 UTC (permalink / raw)
To: Dongli Zhang, linux-scsi, virtualization, linux-block
Cc: martin.petersen, mst, cohuck, linux-kernel, jejb
In-Reply-To: <1553682995-5682-1-git-send-email-dongli.zhang@oracle.com>
On 3/27/19 4:36 AM, Dongli Zhang wrote:
> When tag_set->nr_maps is 1, the block layer limits the number of hw queues
> by nr_cpu_ids. No matter how many hw queues are use by
> virtio-blk/virtio-scsi, as they both have (tag_set->nr_maps == 1), they
> can use at most nr_cpu_ids hw queues.
>
> In addition, specifically for pci scenario, when the 'num-queues' specified
> by qemu is more than maxcpus, virtio-blk/virtio-scsi would not be able to
> allocate more than maxcpus vectors in order to have a vector for each
> queue. As a result, they fall back into MSI-X with one vector for config
> and one shared for queues.
>
> Considering above reasons, this patch set limits the number of hw queues
> used by nr_cpu_ids for both virtio-blk and virtio-scsi.
I picked both up for 5.1.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v3 2/3] x86/mm: Introduce altp2m_set_entry_by_page_order
From: George Dunlap @ 2019-04-10 14:18 UTC (permalink / raw)
To: Alexandru Stefan ISAILA, xen-devel@lists.xenproject.org
Cc: tamas@tklengyel.com, wei.liu2@citrix.com,
rcojocaru@bitdefender.com, george.dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, jbeulich@suse.com,
roger.pau@citrix.com
In-Reply-To: <20190409120324.13940-2-aisaila@bitdefender.com>
On 4/9/19 1:03 PM, Alexandru Stefan ISAILA wrote:
> This patch moves common code from p2m_set_altp2m_mem_access() and
> p2m_change_altp2m_gfn() into one function
>
> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
> ---
> xen/arch/x86/mm/mem_access.c | 2 +-
> xen/include/asm-x86/p2m.h | 11 +++++++++++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index bf67ddb15a..6a22512555 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -279,7 +279,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
> gfn_t gfn2 = _gfn(gfn_l & mask);
> mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>
> - /* Note: currently it is not safe to remap to a shared entry */
> + /* Note: currently it is not safe to remap to a shared entry */
> if ( t != p2m_ram_rw )
> return -ESRCH;
>
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 6de1546d76..90a6c135a7 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -467,6 +467,17 @@ static inline mfn_t altp2m_get_gfn_type_access(
> return mfn;
> }
>
> +static inline int altp2m_set_entry_by_page_order(
> + struct p2m_domain *ap2m, unsigned long gfn, mfn_t mfn,
> + unsigned int page_order, p2m_type_t t, p2m_access_t a)
This function doesn't seem to be called anywhere in this series.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [RFC][PATCH 13/16] sched: Add core wide task selection and scheduling.
From: Aubrey Li @ 2019-04-10 14:18 UTC (permalink / raw)
To: Aaron Lu
Cc: Tim Chen, Peter Zijlstra, Ingo Molnar, Thomas Gleixner,
Paul Turner, Linus Torvalds, Linux List Kernel Mailing,
Subhra Mazumdar, Frédéric Weisbecker, Kees Cook,
Greg Kerr, Aubrey Li, Julien Desfossez
In-Reply-To: <20190410043633.GA67532@aaronlu>
On Wed, Apr 10, 2019 at 12:36 PM Aaron Lu <aaron.lu@linux.alibaba.com> wrote:
>
> On Tue, Apr 09, 2019 at 11:09:45AM -0700, Tim Chen wrote:
> > Now that we have accumulated quite a number of different fixes to your orginal
> > posted patches. Would you like to post a v2 of the core scheduler with the fixes?
>
> One more question I'm not sure: should a task with cookie=0, i.e. tasks
> that are untagged, be allowed to scheduled on the the same core with
> another tagged task?
>
> The current patch seems to disagree on this, e.g. in pick_task(),
> if max is already chosen but max->core_cookie == 0, then we didn't care
> about cookie and simply use class_pick for the other cpu. This means we
> could schedule two tasks with different cookies(one is zero and the
> other can be tagged).
>
> But then sched_core_find() only allow idle task to match with any tagged
> tasks(we didn't place untagged tasks to the core tree of course :-).
>
> Thoughts? Do I understand this correctly? If so, I think we probably
> want to make this clear before v2. I personally feel, we shouldn't allow
> untagged tasks(like kernel threads) to match with tagged tasks.
Does it make sense if we take untagged tasks as hypervisor, and different
cookie tasks as different VMs? Isolation is done between VMs, not between
VM and hypervisor.
Did you see anything harmful if an untagged task and a tagged task
run simultaneously on the same core?
Thanks,
-Aubrey
^ permalink raw reply
* Re: LPC3250 periph clock at 13MHz instead of 10.4MHz
From: Alexandre Belloni @ 2019-04-10 14:18 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Gregory CLEMENT, linux-arm-kernel
In-Reply-To: <20190410134443.GD3578@piout.net>
On 10/04/2019 15:44:43+0200, Alexandre Belloni wrote:
> Hi Vladimir,
>
> On 13/02/2019 19:21:44+0200, Vladimir Zapolskiy wrote:
> > > Am I missing something?
> > >
> >
> > I think I encountered quite a similar issue previously, but under another
> > circumstances, when I begin to modify HCLK PLL clock rate, can you check
> > my comment at https://lore.kernel.org/linux-clk/56D685F6.5060400@mleia.com/
> > and verify if it's about the same problem?
> >
> > Since the problem hits you also, I plan to spend some time on this weekend
> > to capture more details, fortunately there is a known workaround to pin
> > UART input clock rate to 13MHz, it might be desired to carve it in the code.
> >
>
> I'm pretty sure this is the same issue and that it doesn't only affect
> the UARTs but also timers.
>
> The 2.6.27.8 kernel code would indicated that the timers are only driven
> by sysclk, that is either 13MHz from the oscillator or 13.008896 from
> PLL397. I'm wondering how many other peripherals are affected.
>
You'll note that this is also true for the watchdog, the driver has:
// NOTE - the driver only uses this value if it can't get the clock rate from the clk_ drivers
#define WDOG_COUNTER_RATE 13000000 /*the counter clock is 13 MHz fixed */
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v1] lib/power: fix buffer overrun coverity issues
From: Ferruh Yigit @ 2019-04-10 14:17 UTC (permalink / raw)
To: Burakov, Anatoly, Hunt, David, dev
In-Reply-To: <477cdad2-ac7e-5d0b-3468-8844770352f0@intel.com>
On 4/10/2019 11:55 AM, Burakov, Anatoly wrote:
> On 10-Apr-19 8:52 AM, Ferruh Yigit wrote:
>> On 4/9/2019 3:40 PM, Hunt, David wrote:
>>>
>>> On 9/4/2019 12:18 PM, Burakov, Anatoly wrote:
>>>> On 09-Apr-19 10:22 AM, David Hunt wrote:
>>>>> A previous change removed the limit of 64 cores by
>>>>> moving away from 64-bit masks to char arrays. However
>>>>> this left a buffer overrun issue, where the max channels
>>>>> was defined as 64, and max cores was defined as 256. These
>>>>> should all be consistently set to RTE_MAX_LCORE.
>>>>>
>>>>> The #defines being removed are CHANNEL_CMDS_MAX_CPUS,
>>>>> CHANNEL_CMDS_MAX_CHANNELS, POWER_MGR_MAX_CPUS, and
>>>>> CHANNEL_CMDS_MAX_VM_CHANNELS, and are being replaced
>>>>> with RTE_MAX_LCORE for consistency and simplicity.
>>>>>
>>>>> Fixes: fd73630e95c1 ("examples/power: change 64-bit masks to arrays")
>>>>> Coverity issue: 337672
>>>>> Fixes: fd73630e95c1 ("examples/power: change 64-bit masks to arrays")
>>>>> Coverity issue: 337673
>>>>> Fixes: fd73630e95c1 ("examples/power: change 64-bit masks to arrays")
>>>>> Coverity issue: 337678
>>>>
>>>> No need to mention the same commit three times :)
>>>>
>>>
>>> The coverity output said to add this, so I was leaving nothing to
>>> chance... :)
>>
>> Can use comma separated list for multiple issues fixed, like:
>>
>> Coverity issue: 277209, 277215, 277225
>> Fixes: c7e9729da6b5 ("net/nfp: support CPP")
>> Cc: stable@dpdk.org
>>
>
> It makes it harder to grep for coverity issues, so -1 on the CSV.
>
If you are searching for the issue id, it will be same. I don't have strong
opinion, but both looks same to me, and this is more brief.
^ permalink raw reply
* Re: [PATCH 1/3] KVM: x86: Load SMRAM in a single shot when leaving SMM
From: Sean Christopherson @ 2019-04-10 14:17 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Radim Krčmář, Joerg Roedel, kvm, Jon Doron,
Jim Mattson, Liran Alon, Vitaly Kuznetsov
In-Reply-To: <86ae2c55-d2ce-141d-7e8c-64724c3c1694@redhat.com>
On Wed, Apr 10, 2019 at 11:19:19AM +0200, Paolo Bonzini wrote:
> On 02/04/19 17:03, Sean Christopherson wrote:
> > Ostensibly, the only motivation for having HF_SMM_MASK set throughout
> > the loading of state from the SMRAM save state area is so that the
> > memory accesses from GET_SMSTATE() are tagged with role.smm (though
> > arguably even that is unnecessary).
>
> Why is that unnecessary? If they do not have role.smm they would access
> video RAM or TSEG, not the state save area.
You're right, feel free to strike that line from the record. For some
reason I had it in my mind that enter_smm() was writing SMRAM before
setting HF_SMM_MASK.
^ permalink raw reply
* [PATCH] nvme: improve logging
From: Hannes Reinecke @ 2019-04-10 14:17 UTC (permalink / raw)
Currently nvme is very reluctant if it comes to logging anything,
_unless_ it's an ANA AEN. So this patch tries to remedy this by
decreasing the priority for the ANA AEN logging message, and improve
the logging when calling nvme_reset_ctrl().
Signed-off-by: Hannes Reinecke <hare at suse.com>
---
drivers/nvme/host/core.c | 44 +++++++++++++++++++++++++++++--------------
drivers/nvme/host/multipath.c | 5 ++++-
2 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 8d285bfcd352..98260b2c7a6f 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -94,6 +94,24 @@ static void nvme_put_subsystem(struct nvme_subsystem *subsys);
static void nvme_remove_invalid_namespaces(struct nvme_ctrl *ctrl,
unsigned nsid);
+static const char *nvme_ctrl_state_name(struct nvme_ctrl *ctrl)
+{
+ static const char *const state_name[] = {
+ [NVME_CTRL_NEW] = "new",
+ [NVME_CTRL_LIVE] = "live",
+ [NVME_CTRL_ADMIN_ONLY] = "only-admin",
+ [NVME_CTRL_RESETTING] = "resetting",
+ [NVME_CTRL_CONNECTING] = "connecting",
+ [NVME_CTRL_DELETING] = "deleting",
+ [NVME_CTRL_DEAD] = "dead",
+ };
+
+ if ((unsigned)ctrl->state < ARRAY_SIZE(state_name) &&
+ state_name[ctrl->state])
+ return state_name[ctrl->state];
+ return NULL;
+}
+
static void nvme_set_queue_dying(struct nvme_ns *ns)
{
/*
@@ -119,10 +137,17 @@ static void nvme_queue_scan(struct nvme_ctrl *ctrl)
int nvme_reset_ctrl(struct nvme_ctrl *ctrl)
{
- if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
+ if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING)) {
+ const char *state_name = nvme_ctrl_state_name(ctrl);
+
+ dev_warn(ctrl->device, "cannot reset ctrl in state %s\n",
+ state_name ? state_name : "unknown");
return -EBUSY;
- if (!queue_work(nvme_reset_wq, &ctrl->reset_work))
+ }
+ if (!queue_work(nvme_reset_wq, &ctrl->reset_work)) {
+ dev_dbg(ctrl->device, "ctrl reset already queued\n");
return -EBUSY;
+ }
return 0;
}
EXPORT_SYMBOL_GPL(nvme_reset_ctrl);
@@ -2971,19 +2996,10 @@ static ssize_t nvme_sysfs_show_state(struct device *dev,
char *buf)
{
struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
- static const char *const state_name[] = {
- [NVME_CTRL_NEW] = "new",
- [NVME_CTRL_LIVE] = "live",
- [NVME_CTRL_ADMIN_ONLY] = "only-admin",
- [NVME_CTRL_RESETTING] = "resetting",
- [NVME_CTRL_CONNECTING] = "connecting",
- [NVME_CTRL_DELETING] = "deleting",
- [NVME_CTRL_DEAD] = "dead",
- };
+ const char *state_name = nvme_ctrl_state_name(ctrl);
- if ((unsigned)ctrl->state < ARRAY_SIZE(state_name) &&
- state_name[ctrl->state])
- return sprintf(buf, "%s\n", state_name[ctrl->state]);
+ if (state_name)
+ return sprintf(buf, "%s\n", state_name);
return sprintf(buf, "unknown state\n");
}
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 503539d4616a..cca60044163b 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -81,6 +81,9 @@ void nvme_failover_req(struct request *req)
* Reset the controller for any non-ANA error as we don't know
* what caused the error.
*/
+ dev_info(ns->ctrl->device,
+ "nvme status 0x%04x, resetting controller\n",
+ status);
nvme_reset_ctrl(ns->ctrl);
break;
}
@@ -423,7 +426,7 @@ static int nvme_update_ana_state(struct nvme_ctrl *ctrl,
unsigned *nr_change_groups = data;
struct nvme_ns *ns;
- dev_info(ctrl->device, "ANA group %d: %s.\n",
+ dev_dbg(ctrl->device, "ANA group %d: %s.\n",
le32_to_cpu(desc->grpid),
nvme_ana_state_names[desc->state]);
--
2.16.4
^ permalink raw reply related
* Re: [PATCH] Add kernel_dgram_send() into logging_send_syslog_msg()
From: Sugar, David @ 2019-04-10 14:16 UTC (permalink / raw)
To: Russell Coker; +Cc: selinux-refpolicy@vger.kernel.org
In-Reply-To: <1597016.RvrILB9U20@liv>
On 4/9/19 9:39 PM, Russell Coker wrote:
> Why is a socket that everything sends to labeled as kernel_t?
>
I see, it is happening during the system booting. /dev/log and
/run/systemd/journal/socket are both labeled kernel_t early in the boot
process. At some point they are either relabeled or recreated with
devlog_t. But without this rule the system won't boot (I have tried).
Here are a small sample of the denials I get without these rules.
type=AVC msg=audit(1554904080.089:5018): avc: denied { sendto } for
pid=7559 comm="auditd" path="/dev/log"
scontext=system_u:system_r:auditd_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1554904080.155:5138): avc: denied { sendto } for
pid=7590 comm="systemd-cgroups" path="/run/systemd/journal/socket"
scontext=system_u:system_r:systemd_cgroups_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1554904080.158:5142): avc: denied { sendto } for
pid=7591 comm="systemd-update-" path="/run/systemd/journal/socket"
scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1554904467.831:181): avc: denied { sendto } for
pid=7510 comm="chronyd" path="/dev/log"
scontext=system_u:system_r:chronyd_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=1
type=AVC msg=audit(1554904467.842:190): avc: denied { sendto } for
pid=7498 comm="dbus-daemon" path="/dev/log"
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=1
type=AVC msg=audit(1554904467.850:194): avc: denied { sendto } for
pid=7521 comm="systemd-user-se" path="/run/systemd/journal/socket"
scontext=system_u:system_r:systemd_sessions_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=1
> On Wednesday, 10 April 2019 11:07:29 AM AEST Sugar, David wrote:
>> On 4/9/19 9:00 PM, Russell Coker wrote:
>>
>>> Why does the kernel need such access?
>>
>>
>> I'm not sure I understand your question. Are you asking why the
>> kernel_dgram_send() access is needed by syslog? This is because many
>> domains send messages to the journal.
>>
>> I have been adding this interface as needed throughout the policy as I'm
>> seeing issues. It was suggested to move this interface use into
>> logging_send_syslog_msg as that is the same concept and most domains log
>> already.
>>
>> This patch is mostly removing uses of kernel_dgram_send and just adding
>> it one place.
>>
>>
>>>
>>> On Wednesday, 10 April 2019 1:09:59 AM AEST Sugar, David wrote:
>>>
>>>> This patch is based on comments from previous a patch to
>>>> remove the many uses of kernel_dgram_send() and incorporate
>>>> it into logging_send_syslog_msg().
>>>>
>>>>
>>>>
>>>> Signed-off-by: Dave Sugar <dsugar@tresys.com>
>>>> ---
>>>>
>>>> policy/modules/admin/aide.te | 1 -
>>>> policy/modules/admin/usermanage.te | 5 -----
>>>> policy/modules/services/dbus.te | 3 ---
>>>> policy/modules/system/authlogin.te | 5 -----
>>>> policy/modules/system/init.if | 2 --
>>>> policy/modules/system/init.te | 3 ---
>>>> policy/modules/system/logging.if | 2 ++
>>>> policy/modules/system/logging.te | 4 ----
>>>> policy/modules/system/systemd.te | 5 -----
>>>> policy/modules/system/udev.te | 1 -
>>>> 10 files changed, 2 insertions(+), 29 deletions(-)
>>>>
>>>>
>>>>
>>>> diff --git a/policy/modules/admin/aide.te b/policy/modules/admin/aide.te
>>>> index 30deba09..f5e64a86 100644
>>>> --- a/policy/modules/admin/aide.te
>>>> +++ b/policy/modules/admin/aide.te
>>>> @@ -44,7 +44,6 @@ logging_log_filetrans(aide_t, aide_log_t, file)
>>>>
>>>> files_read_all_files(aide_t)
>>>> files_read_all_symlinks(aide_t)
>>>>
>>>>
>>>> -kernel_dgram_send(aide_t)
>>>>
>>>> kernel_read_crypto_sysctls(aide_t)
>>>>
>>>> logging_send_audit_msgs(aide_t)
>>>>
>>>> diff --git a/policy/modules/admin/usermanage.te
>>>> b/policy/modules/admin/usermanage.te
>>>>
>>> index 5753741b..4a10bf84 100644
>>>>
>>>> --- a/policy/modules/admin/usermanage.te
>>>> +++ b/policy/modules/admin/usermanage.te
>>>> @@ -366,11 +366,6 @@ userdom_read_user_tmp_files(passwd_t)
>>>>
>>>> # on user home dir
>>>> userdom_dontaudit_search_user_home_content(passwd_t)
>>>>
>>>>
>>>> -ifdef(`init_systemd',`
>>>> - # for journald /dev/log
>>>> - kernel_dgram_send(passwd_t)
>>>> -')
>>>> -
>>>>
>>>> optional_policy(`
>>>>
>>>> nscd_run(passwd_t, passwd_roles)
>>>>
>>>> ')
>>>>
>>>> diff --git a/policy/modules/services/dbus.te
>>>> b/policy/modules/services/dbus.te
>>>>
>>> index 9c085876..c05370dd 100644
>>>>
>>>> --- a/policy/modules/services/dbus.te
>>>> +++ b/policy/modules/services/dbus.te
>>>> @@ -162,9 +162,6 @@ ifdef(`init_systemd', `
>>>>
>>>> # for /run/systemd/dynamic-uid/
>>>> init_list_pids(system_dbusd_t)
>>>> init_read_runtime_symlinks(system_dbusd_t)
>>>>
>>>> -
>>>> - # for journald /dev/log
>>>> - kernel_dgram_send(system_dbusd_t)
>>>>
>>>> ')
>>>>
>>>> optional_policy(`
>>>>
>>>> diff --git a/policy/modules/system/authlogin.te
>>>> b/policy/modules/system/authlogin.te
>>>>
>>> index 28f74bac..2cf86952 100644
>>>>
>>>> --- a/policy/modules/system/authlogin.te
>>>> +++ b/policy/modules/system/authlogin.te
>>>> @@ -144,11 +144,6 @@ ifdef(`distro_ubuntu',`
>>>>
>>>> ')
>>>>
>>>> ')
>>>>
>>>>
>>>> -ifdef(`init_systemd',`
>>>> - # for journald /dev/log
>>>> - kernel_dgram_send(chkpwd_t)
>>>> -')
>>>> -
>>>>
>>>> optional_policy(`
>>>>
>>>> # apache leaks file descriptors
>>>> apache_dontaudit_rw_tcp_sockets(chkpwd_t)
>>>>
>>>> diff --git a/policy/modules/system/init.if
>>>> b/policy/modules/system/init.if
>>>> index fef2c88e..00bd4991 100644
>>>> --- a/policy/modules/system/init.if
>>>> +++ b/policy/modules/system/init.if
>>>> @@ -306,8 +306,6 @@ interface(`init_daemon_domain',`
>>>>
>>>>
>>>>
>>>> ifdef(`init_systemd',`
>>>>
>>>> init_domain($1, $2)
>>>>
>>>> - # this may be because of late labelling
>>>> - kernel_dgram_send($1)
>>>>
>>>>
>>>>
>>>> allow $1 init_t:unix_dgram_socket sendto;
>>>>
>>>> ')
>>>>
>>>> diff --git a/policy/modules/system/init.te
>>>> b/policy/modules/system/init.te
>>>> index a12d151b..3e8eb2da 100644
>>>> --- a/policy/modules/system/init.te
>>>> +++ b/policy/modules/system/init.te
>>>> @@ -272,7 +272,6 @@ ifdef(`init_systemd',`
>>>>
>>>>
>>>>
>>>> kernel_dyntrans_to(init_t)
>>>> kernel_read_network_state(init_t)
>>>>
>>>> - kernel_dgram_send(init_t)
>>>>
>>>> kernel_stream_connect(init_t)
>>>> kernel_getattr_proc(init_t)
>>>> kernel_read_fs_sysctls(init_t)
>>>>
>>>> @@ -969,8 +968,6 @@ ifdef(`init_systemd',`
>>>>
>>>> allow initrc_t systemdunit:service reload;
>>>> allow initrc_t init_script_file_type:service { stop start status
>>>> reload
>>>>
>>>> };
>>>>
>>>
>>>>
>>>> - kernel_dgram_send(initrc_t)
>>>> -
>>>>
>>>> # run systemd misc initializations
>>>> # in the initrc_t domain, as would be
>>>> # done in traditional sysvinit/upstart.
>>>>
>>>> diff --git a/policy/modules/system/logging.if
>>>> b/policy/modules/system/logging.if
>>>>
>>> index 7b7644f7..1f696b7f 100644
>>>>
>>>> --- a/policy/modules/system/logging.if
>>>> +++ b/policy/modules/system/logging.if
>>>> @@ -642,6 +642,8 @@ interface(`logging_send_syslog_msg',`
>>>>
>>>> ifdef(`init_systemd',`
>>>>
>>>> # Allow systemd-journald to check whether the process died
>>>> allow syslogd_t $1:process signull;
>>>>
>>>> +
>>>> + kernel_dgram_send($1)
>>>>
>>>> ')
>>>>
>>>> ')
>>>>
>>>>
>>>> diff --git a/policy/modules/system/logging.te
>>>> b/policy/modules/system/logging.te
>>>>
>>> index 0c5be1cd..02f268ea 100644
>>>>
>>>> --- a/policy/modules/system/logging.te
>>>> +++ b/policy/modules/system/logging.te
>>>> @@ -271,10 +271,6 @@ miscfiles_read_localization(audisp_t)
>>>>
>>>>
>>>> sysnet_dns_name_resolve(audisp_t)
>>>>
>>>>
>>>> -ifdef(`init_systemd',`
>>>> - kernel_dgram_send(audisp_t)
>>>> -')
>>>> -
>>>>
>>>> optional_policy(`
>>>>
>>>> dbus_system_bus_client(audisp_t)
>>>>
>>>> ')
>>>>
>>>> diff --git a/policy/modules/system/systemd.te
>>>> b/policy/modules/system/systemd.te
>>>>
>>> index f6455f6f..cf9241c0 100644
>>>>
>>>> --- a/policy/modules/system/systemd.te
>>>> +++ b/policy/modules/system/systemd.te
>>>> @@ -266,7 +266,6 @@
>>>> systemd_log_parse_environment(systemd_gpt_generator_t)
>>>>
>>>> allow systemd_cgroups_t self:capability net_admin;
>>>>
>>>> kernel_domtrans_to(systemd_cgroups_t, systemd_cgroups_exec_t)
>>>>
>>>> -kernel_dgram_send(systemd_cgroups_t)
>>>>
>>>> # for /proc/cmdline
>>>> kernel_read_system_state(systemd_cgroups_t)
>>>>
>>>>
>>>> @@ -642,7 +641,6 @@ manage_dirs_pattern(systemd_networkd_t,
>>>> systemd_networkd_var_run_t, systemd_netw
>>>> manage_files_pattern(systemd_networkd_t, systemd_networkd_var_run_t,
>>>> systemd_networkd_var_run_t) manage_lnk_files_pattern(systemd_networkd_t,
>>>> systemd_networkd_var_run_t, systemd_networkd_var_run_t)
>>>> -kernel_dgram_send(systemd_networkd_t)
>>>>
>>>> kernel_read_system_state(systemd_networkd_t)
>>>> kernel_read_kernel_sysctls(systemd_networkd_t)
>>>> kernel_read_network_state(systemd_networkd_t)
>>>>
>>>> @@ -667,8 +665,6 @@ auth_use_nsswitch(systemd_networkd_t)
>>>>
>>>> init_dgram_send(systemd_networkd_t)
>>>> init_read_state(systemd_networkd_t)
>>>>
>>>>
>>>> -logging_send_syslog_msg(systemd_networkd_t)
>>>> -
>>>>
>>>> miscfiles_read_localization(systemd_networkd_t)
>>>>
>>>> sysnet_read_config(systemd_networkd_t)
>>>>
>>>> @@ -945,7 +941,6 @@ init_pid_filetrans(systemd_resolved_t,
>>>> systemd_resolved_var_run_t, dir)
>>>>
>>>
>>>
>>>> dev_read_sysfs(systemd_resolved_t)
>>>>
>>>>
>>>> -kernel_dgram_send(systemd_resolved_t)
>>>>
>>>> kernel_read_crypto_sysctls(systemd_resolved_t)
>>>> kernel_read_kernel_sysctls(systemd_resolved_t)
>>>> kernel_read_net_sysctls(systemd_resolved_t)
>>>>
>>>> diff --git a/policy/modules/system/udev.te
>>>> b/policy/modules/system/udev.te
>>>> index ff564280..f00de30d 100644
>>>> --- a/policy/modules/system/udev.te
>>>> +++ b/policy/modules/system/udev.te
>>>> @@ -99,7 +99,6 @@ kernel_read_modprobe_sysctls(udev_t)
>>>>
>>>> kernel_read_kernel_sysctls(udev_t)
>>>> kernel_rw_hotplug_sysctls(udev_t)
>>>> kernel_rw_unix_dgram_sockets(udev_t)
>>>>
>>>> -kernel_dgram_send(udev_t)
>>>>
>>>> kernel_signal(udev_t)
>>>> kernel_search_debugfs(udev_t)
>>>> kernel_search_key(udev_t)
>>>>
>>>> --
>>>> 2.20.1
>>>>
>>>>
>>>>
>>>
>
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] migration: Fix handling fd protocol
From: Yury Kotov @ 2019-04-10 14:16 UTC (permalink / raw)
To: Dr. David Alan Gilbert, armbru@redhat.com, berrange@redhat.com
Cc: qemu-devel@nongnu.org, yc-core@yandex-team.ru, Juan Quintela
In-Reply-To: <20190410135725.GE2980@work-vm>
Hi,
10.04.2019, 16:58, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
> * Yury Kotov (yury-kotov@yandex-team.ru) wrote:
>> Currently such case is possible for incoming:
>> QMP: add-fd (fdset = 0, fd of some file):
>> adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
>> QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
>> ...
>> Incoming migration completes and unrefs ioc -> close(33)
>> QMP: remove-fd (fdset = 0, fd = 33):
>> removes fd from fdset 0 and qemu_close() -> close(33) => double close
>
> Well spotted! That would very rarely cause a problem, but is a race.
>
Actually, it hits for incoming case on 2 of 50 VMs on our production...
>> For outgoing migration the case is the same but getfd instead of add-fd.
>> Fix it by duping client's fd.
>>
>> Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>
>
> Note your patch hit a problem building on windows; I don't think we have
> a qemu_dup for windows.
>
Oh, I see... I'll add an ifdef for this in v2.
> However, I think this problem is wider than just migration.
> For example, I see that dump.c also uses monitor_get_fd, and it's
> dump_cleanup also does a close on the fd. So I guess it hits the same
> problem?
> Also, qmp.c in qmp_add_client does a close on the fd in some error cases
> (I've not followed the normal case).
>
> So perhaps all the users of monitor_get_fd are hitting this problem.
>
> Should we be doing the dup in monitor_get_fd?
>
Hmm, it sounds reasonable but Windows's case will remain broken.
And also using fd from fdset without qemu_open will remain broken.
Another way to fix them:
1) Add searching of monitor's fds and not duped fdset's fds to qemu_close
2) Replace broken closes to qemu_close
Regards,
Yury Kotov
> Dave
>
>> ---
>> migration/fd.c | 39 +++++++++++++++++++++++++++++++--------
>> migration/trace-events | 4 ++--
>> 2 files changed, 33 insertions(+), 10 deletions(-)
>>
>> diff --git a/migration/fd.c b/migration/fd.c
>> index a7c13df4ad..c9ff07ac41 100644
>> --- a/migration/fd.c
>> +++ b/migration/fd.c
>> @@ -15,6 +15,7 @@
>> */
>>
>> #include "qemu/osdep.h"
>> +#include "qapi/error.h"
>> #include "channel.h"
>> #include "fd.h"
>> #include "migration.h"
>> @@ -26,15 +27,27 @@
>> void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error **errp)
>> {
>> QIOChannel *ioc;
>> - int fd = monitor_get_fd(cur_mon, fdname, errp);
>> + int fd, dup_fd;
>> +
>> + fd = monitor_get_fd(cur_mon, fdname, errp);
>> if (fd == -1) {
>> return;
>> }
>>
>> - trace_migration_fd_outgoing(fd);
>> - ioc = qio_channel_new_fd(fd, errp);
>> + /* fd is previously created by qmp command 'getfd',
>> + * so client is responsible to close it. Dup it to save original value from
>> + * QIOChannel's destructor */
>> + dup_fd = qemu_dup(fd);
>> + if (dup_fd == -1) {
>> + error_setg(errp, "Cannot dup fd %s: %s (%d)", fdname, strerror(errno),
>> + errno);
>> + return;
>> + }
>> +
>> + trace_migration_fd_outgoing(fd, dup_fd);
>> + ioc = qio_channel_new_fd(dup_fd, errp);
>> if (!ioc) {
>> - close(fd);
>> + close(dup_fd);
>> return;
>> }
>>
>> @@ -55,14 +68,24 @@ static gboolean fd_accept_incoming_migration(QIOChannel *ioc,
>> void fd_start_incoming_migration(const char *infd, Error **errp)
>> {
>> QIOChannel *ioc;
>> - int fd;
>> + int fd, dup_fd;
>>
>> fd = strtol(infd, NULL, 0);
>> - trace_migration_fd_incoming(fd);
>>
>> - ioc = qio_channel_new_fd(fd, errp);
>> + /* fd is previously created by qmp command 'add-fd' or something else,
>> + * so client is responsible to close it. Dup it to save original value from
>> + * QIOChannel's destructor */
>> + dup_fd = qemu_dup(fd);
>> + if (dup_fd == -1) {
>> + error_setg(errp, "Cannot dup fd %d: %s (%d)", fd, strerror(errno),
>> + errno);
>> + return;
>> + }
>> +
>> + trace_migration_fd_incoming(fd, dup_fd);
>> + ioc = qio_channel_new_fd(dup_fd, errp);
>> if (!ioc) {
>> - close(fd);
>> + close(dup_fd);
>> return;
>> }
>>
>> diff --git a/migration/trace-events b/migration/trace-events
>> index de2e136e57..d2d30a6b3c 100644
>> --- a/migration/trace-events
>> +++ b/migration/trace-events
>> @@ -258,8 +258,8 @@ migration_exec_outgoing(const char *cmd) "cmd=%s"
>> migration_exec_incoming(const char *cmd) "cmd=%s"
>>
>> # fd.c
>> -migration_fd_outgoing(int fd) "fd=%d"
>> -migration_fd_incoming(int fd) "fd=%d"
>> +migration_fd_outgoing(int fd, int dup_fd) "fd=%d dup_fd=%d"
>> +migration_fd_incoming(int fd, int dup_fd) "fd=%d dup_fd=%d"
>>
>> # socket.c
>> migration_socket_incoming_accepted(void) ""
>> --
>> 2.21.0
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* Re: [PATCH] net: add big honking pfmemalloc OOM warning
From: Eric Dumazet @ 2019-04-10 14:16 UTC (permalink / raw)
To: Juha-Matti Tilli
Cc: LKML, netdev, Rafael Aquini, Murphy Zhou, Yongcheng Yang,
Jianhong Yin
In-Reply-To: <20190410101947.8603-1-juha-matti.tilli@foreca.com>
On Wed, Apr 10, 2019 at 3:20 AM Juha-Matti Tilli
<juha-matti.tilli@foreca.com> wrote:
>
> A system administrator is not notified (except via an obscure SNMP
> counter that most sysadmins don't know to look for) if packets are
> dropped due to out-of-memory condition when SKBs use pfmemalloc
> reserves. This can for example lead to NFS connections hanging on
> high-volume systems.
>
> Implement a ratelimited big honking out of memory warning that directs
> the sysadmin to bump up vm.min_free_kbytes in case this problem happens.
> Our experience shows that with default vm.min_free_kbytes (90112, or
> about 90 megabytes), NFS connections hang approximately once per day,
> whereas with 901120 (default multiplied by 10) NFS connections never
> hang.
>
If NFS sessions hang, then there is a bug to eventually root cause and fix.
Just telling the user : Increase the limit is the same thing than admitting :
Our limit system or TCP or NFS stacks are broken and unable to
recover, so lets disable the limit system and work around a more
serious bug.
Maybe the bug is in a NIC driver, please share more details before
adding yet another noisy signal in syslog
SNMP counters are per netns, and more useful in the modern computing
era, where a host is shared by many different containers.
>
> Signed-off-by: Juha-Matti Tilli <juha-matti.tilli@foreca.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Rafael Aquini <aquini@redhat.com>
> Cc: Murphy Zhou <xzhou@redhat.com>
> Cc: Yongcheng Yang <yoyang@redhat.com>
> Cc: Jianhong Yin <jiyin@redhat.com>
> ---
> net/core/filter.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index fc92ebc4e200..7d8ef239b9af 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -99,6 +99,8 @@ int sk_filter_trim_cap(struct sock *sk, struct sk_buff *skb, unsigned int cap)
> * helping free memory
> */
> if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC)) {
> + printk_ratelimited(KERN_WARNING
> + "dropped packet due to out-of-memory condition, please bump up vm.min_free_kbytes\n");
> NET_INC_STATS(sock_net(sk), LINUX_MIB_PFMEMALLOCDROP);
> return -ENOMEM;
> }
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH] nvme,scsi: display FC-NVMe port roles
From: Hannes Reinecke @ 2019-04-10 14:16 UTC (permalink / raw)
Currently the FC-NVMe driver is leverating the SCSI FC transport
class to access the remote ports. Which means that all FC-NVMe
remote ports will be visible to the fc transport layer, but due
to missing definitions the port roles will always be 'unknown'.
This patch adds the missing definitions to the fc transport class
to that the port roles are correctly displayed.
Signed-off-by: Hannes Reinecke <hare at suse.com>
---
drivers/nvme/host/fc.c | 2 +-
drivers/scsi/lpfc/lpfc_hbadisc.c | 10 ++++++++--
drivers/scsi/qla2xxx/qla_def.h | 5 ++++-
drivers/scsi/qla2xxx/qla_init.c | 15 +++++++++++----
drivers/scsi/qla2xxx/qla_mbx.c | 8 +++++++-
drivers/scsi/scsi_transport_fc.c | 3 +++
include/linux/nvme-fc-driver.h | 6 ------
include/scsi/scsi_transport_fc.h | 3 +++
8 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index f3b9d91ba0df..31637f8ef22e 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -14,7 +14,7 @@
#include "fabrics.h"
#include <linux/nvme-fc-driver.h>
#include <linux/nvme-fc.h>
-
+#include <scsi/scsi_transport_fc.h>
/* *************************** Data Structures/Defines ****************** */
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index aa4961a2caf8..30d393dddb3b 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -4147,9 +4147,15 @@ lpfc_register_remote_port(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp)
rdata->pnode = lpfc_nlp_get(ndlp);
if (ndlp->nlp_type & NLP_FCP_TARGET)
- rport_ids.roles |= FC_RPORT_ROLE_FCP_TARGET;
+ rport_ids.roles |= FC_PORT_ROLE_FCP_TARGET;
if (ndlp->nlp_type & NLP_FCP_INITIATOR)
- rport_ids.roles |= FC_RPORT_ROLE_FCP_INITIATOR;
+ rport_ids.roles |= FC_PORT_ROLE_FCP_INITIATOR;
+ if (ndlp->nlp_type & NLP_NVME_INITIATOR)
+ rport_ids.roles |= FC_PORT_ROLE_NVME_INITIATOR;
+ if (ndlp->nlp_type & NLP_NVME_TARGET)
+ rport_ids.roles |= FC_PORT_ROLE_NVME_TARGET;
+ if (ndlp->nlp_type & NLP_NVME_DISCOVERY)
+ rport_ids.roles |= FC_PORT_ROLE_NVME_DISCOVERY;
if (rport_ids.roles != FC_RPORT_ROLE_UNKNOWN)
fc_remote_port_rolechg(rport, rport_ids.roles);
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 3d46975a5e5c..7342ac77149e 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2258,7 +2258,10 @@ typedef enum {
FCT_BROADCAST,
FCT_INITIATOR,
FCT_TARGET,
- FCT_NVME
+ FCT_NVME_INITIATOR = 0x10,
+ FCT_NVME_TARGET = 0x20,
+ FCT_NVME_DISCOVERY = 0x40,
+ FCT_NVME = 0xf0,
} fc_port_type_t;
enum qla_sess_deletion {
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 0c700b140ce7..8e254dfeed89 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -5194,16 +5194,23 @@ qla2x00_reg_remote_port(scsi_qla_host_t *vha, fc_port_t *fcport)
rport->supported_classes = fcport->supported_classes;
- rport_ids.roles = FC_RPORT_ROLE_UNKNOWN;
+ rport_ids.roles = FC_PORT_ROLE_UNKNOWN;
if (fcport->port_type == FCT_INITIATOR)
- rport_ids.roles |= FC_RPORT_ROLE_FCP_INITIATOR;
+ rport_ids.roles |= FC_PORT_ROLE_FCP_INITIATOR;
if (fcport->port_type == FCT_TARGET)
- rport_ids.roles |= FC_RPORT_ROLE_FCP_TARGET;
+ rport_ids.roles |= FC_PORT_ROLE_FCP_TARGET;
+ if (fcport->port_type & FCT_NVME_INITIATOR)
+ rport_ids.roles |= FC_PORT_ROLE_NVME_INITIATOR;
+ if (fcport->port_type & FCT_NVME_TARGET)
+ rport_ids.roles |= FC_PORT_ROLE_NVME_TARGET;
+ if (fcport->port_type & FCT_NVME_DISCOVERY)
+ rport_ids.roles |= FC_PORT_ROLE_NVME_DISCOVERY;
ql_dbg(ql_dbg_disc, vha, 0x20ee,
"%s %8phN. rport %p is %s mode\n",
__func__, fcport->port_name, rport,
- (fcport->port_type == FCT_TARGET) ? "tgt" : "ini");
+ (fcport->port_type == FCT_TARGET) ? "tgt" :
+ ((fcport->port_type & FCT_NVME) ? "nvme" :"ini"));
fc_remote_port_rolechg(rport, rport_ids.roles);
}
diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
index 5400696e1f6b..f7203a974fb6 100644
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -6318,7 +6318,13 @@ int __qla24xx_parse_gpdb(struct scsi_qla_host *vha, fc_port_t *fcport,
fcport->d_id.b.rsvd_1 = 0;
if (fcport->fc4f_nvme) {
- fcport->port_type = FCT_NVME;
+ fcport->port_type = 0;
+ if ((pd->prli_svc_param_word_3[0] & BIT_5) == 0)
+ fcport->port_type |= FCT_NVME_INITIATOR;
+ if ((pd->prli_svc_param_word_3[0] & BIT_4) == 0)
+ fcport->port_type |= FCT_NVME_TARGET;
+ if ((pd->prli_svc_param_word_3[0] & BIT_3) == 0)
+ fcport->port_type |= FCT_NVME_DISCOVERY;
} else {
/* If not target must be initiator or unknown type. */
if ((pd->prli_svc_param_word_3[0] & BIT_4) == 0)
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index d7035270d274..0ff06d033b87 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -295,6 +295,9 @@ static const struct {
{ FC_PORT_ROLE_FCP_INITIATOR, "FCP Initiator" },
{ FC_PORT_ROLE_IP_PORT, "IP Port" },
{ FC_PORT_ROLE_FCP_DUMMY_INITIATOR, "FCP Dummy Initiator" },
+ { FC_PORT_ROLE_NVME_INITIATOR, "NVMe Initiator" },
+ { FC_PORT_ROLE_NVME_TARGET, "NVMe Target" },
+ { FC_PORT_ROLE_NVME_DISCOVERY, "NVMe Discovery" },
};
fc_bitfield_name_search(port_roles, fc_port_role_names)
diff --git a/include/linux/nvme-fc-driver.h b/include/linux/nvme-fc-driver.h
index 2bb349035431..c48e96436f56 100644
--- a/include/linux/nvme-fc-driver.h
+++ b/include/linux/nvme-fc-driver.h
@@ -17,12 +17,6 @@
-/* FC Port role bitmask - can merge with FC Port Roles in fc transport */
-#define FC_PORT_ROLE_NVME_INITIATOR 0x10
-#define FC_PORT_ROLE_NVME_TARGET 0x20
-#define FC_PORT_ROLE_NVME_DISCOVERY 0x40
-
-
/**
* struct nvme_fc_port_info - port-specific ids and FC connection-specific
* data element used during NVME Host role
diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h
index 15da45dc2a5d..375c4dc641c2 100644
--- a/include/scsi/scsi_transport_fc.h
+++ b/include/scsi/scsi_transport_fc.h
@@ -165,6 +165,9 @@ enum fc_tgtid_binding_type {
#define FC_PORT_ROLE_FCP_INITIATOR 0x02
#define FC_PORT_ROLE_IP_PORT 0x04
#define FC_PORT_ROLE_FCP_DUMMY_INITIATOR 0x08
+#define FC_PORT_ROLE_NVME_INITIATOR 0x10
+#define FC_PORT_ROLE_NVME_TARGET 0x20
+#define FC_PORT_ROLE_NVME_DISCOVERY 0x40
/* The following are for compatibility */
#define FC_RPORT_ROLE_UNKNOWN FC_PORT_ROLE_UNKNOWN
--
2.16.4
^ permalink raw reply related
* [LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build
From: Petr Vorel @ 2019-04-10 14:16 UTC (permalink / raw)
To: ltp
In-Reply-To: <db7687f3-40ca-495e-aa76-efcce204cda7.ruanzw@xiaopeng.com>
Hi Sandeep, Steve,
> Could anyone help me to review this patch? This is useful to cross-compile ltp for Android without specifying '-D__ANDROID__' in configure step.
> Thanks!
> Zhengwang
> ------------------------------------------------------------------
> 发件人：Zhengwang Ruan <ruanzw@xiaopeng.com>
> 发送时间：2019年4月9日(星期二) 12:05
> 收件人：ltp <ltp@lists.linux.it>
> 抄 送：Zhengwang Ruan <ruanzw@xiaopeng.com>
> 主 题：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build
> Enable the __ANDROID__ definition by default for Android build, otherwise we
> should manually enable it by configure command.
> Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
> ---
> include/mk/env_post.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
> index 913bdf5..7953e0a 100644
> --- a/include/mk/env_post.mk
> +++ b/include/mk/env_post.mk
> @@ -44,7 +44,7 @@ endif
> ifeq ($(ANDROID),1)
> # There are many undeclared functions, it's best not to accidentally overlook
> # them.
> -CFLAGS += -Werror-implicit-function-declaration
> +CFLAGS += -Werror-implicit-function-declaration -D__ANDROID__
Would adding __ANDROID__ definition help building LTP with distro
cross-compiler? (i.e. no NDK, no inside AOSP tree)?
I guess so and therefore, I'd be for this change.
I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
BTW: where is defined for AOSP and NDK?
BTW (@cyril): I guess -Werror-implicit-function-declaration is the code which
requires adding <string.h> and <strings.h> (see my fix 4053a2551 ("lib: Add
missing <string.h> and <strings.h> includes")), I'd be for either adding it to
for all or removing it.
> LDFLAGS += -L$(top_builddir)/lib/android_libpthread
> LDFLAGS += -L$(top_builddir)/lib/android_librt
Kind regards,
Petr
[1] https://git.busybox.net/busybox/tree/configs/android_defconfig
[2] https://git.busybox.net/busybox/tree/configs/android_ndk_defconfig
[3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=bld/Android.mk;hb=HEAD
^ permalink raw reply
* Re: [PATCH v3 1/4] perf: Add a 'percore' event qualifier
From: Jin, Yao @ 2019-04-10 14:15 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <20190410125431.GC13888@kernel.org>
On 4/10/2019 8:54 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Apr 10, 2019 at 09:36:41AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Mar 19, 2019 at 04:56:53PM +0800, Jin Yao escreveu:
>>> Add a 'percore' event qualifier, like cpu/event=0,umask=0x3,percore=1/,
>>> that sums up the event counts for both hardware threads in a core.
>>>
>>> We can already do this with --per-core, but it's often useful to do
>>> this together with other metrics that are collected per hardware thread.
>>> So we need to support this per-core counting on a event level.
>>>
>>> This can be implemented in only the user tool, no kernel support needed.
>>>
>>> v3:
>>> ---
>>> Simplify the code according to Jiri's comments.
>>> Before:
>>> "return term->val.percore ? true : false;"
>>> Now:
>>> "return term->val.percore;"
>>>
>>> v2:
>>> ---
>>> Change the qualifier name from 'coresum' to 'percore' according to
>>> comments from Jiri and Andi.
>>
>> I'm applying this, but please, don't forget to, when adding a new
>> qualifier, to update the documentation... I'm doing this for you this
>> time.
>
> The first patch didn't apply with 'git am', I did it manually, and added
> the patch below
>
> But then the second doesn't apply to my perf/core branch as well, please
> refresh and resend a v4, thanks.
>
> - Arnaldo
>
Thanks Arnaldo! I will rebase the patch to latest perf/core branch and
then send v4.
Thanks
Jin Yao
> diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt
> index 138fb6e94b3c..18ed1b0fceb3 100644
> --- a/tools/perf/Documentation/perf-list.txt
> +++ b/tools/perf/Documentation/perf-list.txt
> @@ -199,6 +199,18 @@ also be supplied. For example:
>
> perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ...
>
> +EVENT QUALIFIERS:
> +
> +It is also possible to add extra qualifiers to an event:
> +
> +percore:
> +
> +Sums up the event counts for all hardware threads in a core, e.g.:
> +
> +
> + perf stat -e cpu/event=0,umask=0x3,percore=1/
> +
> +
> EVENT GROUPS
> ------------
>
>
^ permalink raw reply
* Re: (unknown)
From: Jan Kiszka @ 2019-04-10 14:15 UTC (permalink / raw)
To: Norbert Lange, xenomai
In-Reply-To: <20190410111737.19098-1-norbert.lange@andritz.com>
On 10.04.19 13:17, Norbert Lange via Xenomai wrote:
> V2 of the patchset. Fixed checkstyle issues, better identation,
> and aded casts to silence (false) pedantic warnings.
>
Both applied to next, thanks.
You probably want to edit your cover letter subject as well - or use git
format-patch.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: enable cec on stm32mp157a-dk1 board
From: Alexandre Torgue @ 2019-04-10 14:13 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu
In-Reply-To: <1553862545-6066-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 1:29 PM, Yannick Fertré wrote:
> Enable CEC (Consumer Electronics Control) device.
>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157a-dk1.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
> index 1b1886d..61bc23a 100644
> --- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
> +++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
> @@ -46,6 +46,13 @@
> };
> };
>
Applied on stm32-next.
Thanks.
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: How can I change Vendor name LIO-ORG
From: David Disseldorp @ 2019-04-10 14:14 UTC (permalink / raw)
To: target-devel
In-Reply-To: <CAPUHmCreBhAa7Dzr+6pkYXyifXnRQfXt39KLHMVCer9jd+Lh3A@mail.gmail.com>
On Wed, 10 Apr 2019 17:07:10 +0300, Özkan Göksu wrote:
> Thank you for the answer.
>
> Currently I'm using "14.14.71-1-lts #1 SMP Thu Sep 20 20:14:07 CEST
> 2018" and I need to upgrade for this change.
That doesn't look like a kernel version.
> I will upgrade my kernel and re-answer again.
Excluding distributions with backports, you'll need a kernel >= v5.0.
Cheers, David
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 01/13] net/enetc: support physical addressing mode
From: Ferruh Yigit @ 2019-04-10 14:13 UTC (permalink / raw)
To: Gagandeep Singh, dev@dpdk.org
In-Reply-To: <VE1PR04MB6365478B002501846E792094E12E0@VE1PR04MB6365.eurprd04.prod.outlook.com>
On 4/10/2019 12:12 PM, Gagandeep Singh wrote:
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Monday, April 8, 2019 6:47 PM
>> To: Gagandeep Singh <G.Singh@nxp.com>; dev@dpdk.org
>> Subject: [EXT] Re: [PATCH 01/13] net/enetc: support physical addressing mode
>>
>> WARNING: This email was created outside of NXP. DO NOT CLICK links or
>> attachments unless you recognize the sender and know the content is safe.
>>
>>
>>
>> On 4/8/2019 12:22 PM, Gagandeep Singh wrote:
>>> Support added for physical addressing mode and change driver flags to
>>> don't care.
>>>
>>> Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
>>
>> Hi Gagandeep,
>>
>> Since the patchset has been sent after RC1, I assume it is for 19.08. Can you
>> please mark patch title as 19.08 to not confuse with current release?
>>
> Hi Ferruh,
>
> Yes, it was my mistake I was little late while pushing patches. Actually these patches are for 19.05 release.
> If it not bother you, could you please merge these patches to 19.05? otherwise I'll mark title to 19.08.
Got it, only there already patches on the backlog waiting from rc1 which sent
the patch on time, they will be the priority otherwise it will be unfair to
them, and I will work on this with best effort for 19.05.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: phy: tegra-xusb: List PLL power supplies
From: Rob Herring @ 2019-04-10 14:13 UTC (permalink / raw)
To: Thierry Reding; +Cc: Jon Hunter, linux-tegra, devicetree
In-Reply-To: <20190404112511.28118-1-thierry.reding@gmail.com>
On Thu, 4 Apr 2019 13:25:04 +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> These power supplies provide power for various PLLs that are set up and
> driven by the XUSB pad controller. These power supplies were previously
> improperly added to the PCIe and XUSB controllers, but depending on the
> driver probe order, power to the PLLs will not be supplied soon enough
> and cause initialization to fail.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: enable cec on stm32mp157a-dk1 board
From: Alexandre Torgue @ 2019-04-10 14:13 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu
In-Reply-To: <1553862545-6066-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 1:29 PM, Yannick Fertré wrote:
> Enable CEC (Consumer Electronics Control) device.
>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157a-dk1.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
> index 1b1886d..61bc23a 100644
> --- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
> +++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
> @@ -46,6 +46,13 @@
> };
> };
>
Applied on stm32-next.
Thanks.
Alex
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-4.1] q35: acpi: do not create dummy MCFG table
From: Igor Mammedov @ 2019-04-10 14:11 UTC (permalink / raw)
To: Wei Yang; +Cc: ehabkost, qemu-devel, mst
In-Reply-To: <20190410140153.GA2919@richard>
On Wed, 10 Apr 2019 22:01:53 +0800
Wei Yang <richardw.yang@linux.intel.com> wrote:
> On Wed, Apr 10, 2019 at 11:08:33AM +0200, Igor Mammedov wrote:
> >On Wed, 10 Apr 2019 09:12:31 +0800
> >Wei Yang <richardw.yang@linux.intel.com> wrote:
> >
> >> On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
> >> >Dummy table (with signature "QEMU") creation came from original SeaBIOS
> >> >codebase. And QEMU would have to keep it around if there were Q35 machine
> >> >that depended on keeping ACPI tables blob constant size. Luckily there
> >> >were no versioned Q35 machine types before commit:
> >> > (since 2.3) a1666142db acpi-build: make ROMs RAM blocks resizeable
> >> >which obsoleted need to keep ACPI tables blob the same size on source/destination.
> >> >
> >>
> >> I am not sure getting the "versioned Q35" correctly. Seems originally there is
> >> q35-1.4?
> >>
> >> commit bf3caa3dc17552b323cec6831301a22cfc98ecd5
> >> Author: Paolo Bonzini <pbonzini@redhat.com>
> >> Date: Fri Feb 8 14:06:15 2013 +0100
> >>
> >> pc: add compatibility machine types for 1.4
> >>
> >> Adds both pc-i440fx-1.4 and pc-q35-1.4.
> >
> >current upstream has only pc-q35-2.4 as earliest versioned Q35
> >machine type (try to run: qemu-system-x86_64 -M help)
>
> Yes, I see those old type are removed. This means we don't want to support
> those old types, right? Because those old types can't be migrated to latest
> upstream qemu.
Exactly
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-4.1] q35: acpi: do not create dummy MCFG table
From: Igor Mammedov @ 2019-04-10 14:11 UTC (permalink / raw)
To: Wei Yang; +Cc: qemu-devel, mst, marcel.apfelbaum, ehabkost
In-Reply-To: <20190410140153.GA2919@richard>
On Wed, 10 Apr 2019 22:01:53 +0800
Wei Yang <richardw.yang@linux.intel.com> wrote:
> On Wed, Apr 10, 2019 at 11:08:33AM +0200, Igor Mammedov wrote:
> >On Wed, 10 Apr 2019 09:12:31 +0800
> >Wei Yang <richardw.yang@linux.intel.com> wrote:
> >
> >> On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
> >> >Dummy table (with signature "QEMU") creation came from original SeaBIOS
> >> >codebase. And QEMU would have to keep it around if there were Q35 machine
> >> >that depended on keeping ACPI tables blob constant size. Luckily there
> >> >were no versioned Q35 machine types before commit:
> >> > (since 2.3) a1666142db acpi-build: make ROMs RAM blocks resizeable
> >> >which obsoleted need to keep ACPI tables blob the same size on source/destination.
> >> >
> >>
> >> I am not sure getting the "versioned Q35" correctly. Seems originally there is
> >> q35-1.4?
> >>
> >> commit bf3caa3dc17552b323cec6831301a22cfc98ecd5
> >> Author: Paolo Bonzini <pbonzini@redhat.com>
> >> Date: Fri Feb 8 14:06:15 2013 +0100
> >>
> >> pc: add compatibility machine types for 1.4
> >>
> >> Adds both pc-i440fx-1.4 and pc-q35-1.4.
> >
> >current upstream has only pc-q35-2.4 as earliest versioned Q35
> >machine type (try to run: qemu-system-x86_64 -M help)
>
> Yes, I see those old type are removed. This means we don't want to support
> those old types, right? Because those old types can't be migrated to latest
> upstream qemu.
Exactly
^ permalink raw reply
* [igt-dev] ✗ Fi.CI.IGT: failure for Add a new test for driver/device hot reload (rev2)
From: Patchwork @ 2019-04-10 14:11 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev
In-Reply-To: <20190410100226.20618-1-janusz.krzysztofik@linux.intel.com>
== Series Details ==
Series: Add a new test for driver/device hot reload (rev2)
URL : https://patchwork.freedesktop.org/series/59221/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5898_full -> IGTPW_2835_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_2835_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_2835_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://patchwork.freedesktop.org/api/1.0/series/59221/revisions/2/mbox/
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_2835_full:
### IGT changes ###
#### Possible regressions ####
* {igt@core_hot_reload@unbind} (NEW):
- shard-snb: NOTRUN -> DMESG-FAIL +1
- shard-iclb: NOTRUN -> INCOMPLETE +1
* {igt@core_hot_reload@unplug} (NEW):
- shard-hsw: NOTRUN -> DMESG-FAIL +1
* igt@runner@aborted:
- shard-hsw: NOTRUN -> ( 2 FAIL )
- shard-snb: NOTRUN -> ( 2 FAIL )
New tests
---------
New tests have been introduced between CI_DRM_5898_full and IGTPW_2835_full:
### New IGT tests (2) ###
* igt@core_hot_reload@unbind:
- Statuses : 2 dmesg-fail(s) 3 incomplete(s)
- Exec time: [0.0, 1.42] s
* igt@core_hot_reload@unplug:
- Statuses : 2 dmesg-fail(s) 4 incomplete(s)
- Exec time: [0.0, 0.77] s
Known issues
------------
Here are the changes found in IGTPW_2835_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* {igt@core_hot_reload@unbind} (NEW):
- shard-apl: NOTRUN -> INCOMPLETE [fdo#103927] +1
- shard-kbl: NOTRUN -> INCOMPLETE [fdo#103665] +1
* {igt@core_hot_reload@unplug} (NEW):
- shard-glk: NOTRUN -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-glk: NOTRUN -> SKIP [fdo#109271] +12
* igt@gem_pread@stolen-snoop:
- shard-iclb: NOTRUN -> SKIP [fdo#109277] +1
* igt@gem_pwrite@huge-gtt-fbr:
- shard-iclb: NOTRUN -> SKIP [fdo#109290]
* igt@gem_tiled_swapping@non-threaded:
- shard-iclb: PASS -> INCOMPLETE [fdo#108686]
- shard-hsw: PASS -> FAIL [fdo#108686]
* igt@gem_workarounds@suspend-resume:
- shard-apl: PASS -> DMESG-WARN [fdo#108566] +5
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- shard-iclb: NOTRUN -> SKIP [fdo#109308]
* igt@i915_pm_rps@min-max-config-loaded:
- shard-iclb: NOTRUN -> FAIL [fdo#108059] / [fdo#109960]
* igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]
* igt@kms_atomic_transition@3x-modeset-transitions:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3
* igt@kms_atomic_transition@4x-modeset-transitions:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +16
* igt@kms_atomic_transition@plane-toggle-modeset-transition:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@extended-pageflip-hang-oldfb-render-d:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +7
* igt@kms_chamelium@hdmi-cmp-nv61:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +3
* igt@kms_color@pipe-a-ctm-max:
- shard-iclb: NOTRUN -> FAIL [fdo#108147]
* igt@kms_content_protection@legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109300]
- shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336]
* igt@kms_cursor_crc@cursor-512x512-sliding:
- shard-iclb: NOTRUN -> SKIP [fdo#109279]
* igt@kms_cursor_legacy@2x-flip-vs-cursor-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +4
* igt@kms_cursor_legacy@pipe-c-single-bo:
- shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +18
* igt@kms_fbcon_fbt@psr:
- shard-iclb: NOTRUN -> FAIL [fdo#103833]
* igt@kms_flip@dpms-vs-vblank-race:
- shard-apl: PASS -> FAIL [fdo#103060]
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw: PASS -> INCOMPLETE [fdo#103540]
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render:
- shard-iclb: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] / [fdo#109960]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +18
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#109247] +14
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move:
- shard-apl: NOTRUN -> SKIP [fdo#109271] +85
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-indfb-plflip-blt:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] +15
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-render:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] / [fdo#109960] +1
* igt@kms_lease@cursor_implicit_plane:
- shard-apl: NOTRUN -> FAIL [fdo#110278]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-e:
- shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-apl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-glk: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: NOTRUN -> SKIP [fdo#109642]
* igt@kms_psr@no_drrs:
- shard-iclb: PASS -> FAIL [fdo#108341]
* igt@kms_psr@psr2_no_drrs:
- shard-iclb: PASS -> SKIP [fdo#109441] +1
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]
* igt@kms_psr@sprite_blt:
- shard-iclb: NOTRUN -> FAIL [fdo#107383] / [fdo#110215] +1
* igt@kms_rotation_crc@bad-pixel-format:
- shard-iclb: NOTRUN -> SKIP [fdo#109289] +1
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@kms_sysfs_edid_timing:
- shard-apl: NOTRUN -> FAIL [fdo#100047]
* igt@kms_vblank@pipe-a-ts-continuation-modeset:
- shard-apl: PASS -> FAIL [fdo#104894]
* igt@perf_pmu@busy-check-all-vecs0:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +108
* igt@perf_pmu@most-busy-check-all-vcs1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +12
* igt@perf_pmu@rc6:
- shard-kbl: PASS -> SKIP [fdo#109271]
* igt@prime_busy@wait-after-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109960] +3
* igt@prime_nv_api@nv_i915_import_twice_check_flink_name:
- shard-iclb: NOTRUN -> SKIP [fdo#109291] +2
* igt@v3d_mmap@mmap-bad-handle:
- shard-iclb: NOTRUN -> SKIP [fdo#109315] / [fdo#109960]
#### Possible fixes ####
* igt@gem_ctx_isolation@bcs0-s3:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
* igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-kbl: SKIP [fdo#109271] -> PASS
* igt@i915_pm_rpm@system-suspend-execbuf:
- shard-kbl: INCOMPLETE [fdo#103665] / [fdo#107807] -> PASS
* igt@kms_cursor_crc@cursor-64x64-random:
- shard-iclb: INCOMPLETE [fdo#109960] -> PASS
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: FAIL [fdo#104873] -> PASS
* igt@kms_cursor_legacy@cursor-vs-flip-legacy:
- shard-hsw: FAIL [fdo#103355] -> PASS
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: FAIL [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt:
- shard-iclb: FAIL [fdo#103167] / [fdo#109960] -> PASS
* igt@kms_frontbuffer_tracking@fbc-tilingchange:
- shard-iclb: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite:
- shard-iclb: FAIL [fdo#109247] -> PASS +10
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-apl: DMESG-WARN [fdo#108566] -> PASS +1
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: SKIP [fdo#109441] -> PASS +3
* igt@kms_psr@sprite_mmap_cpu:
- shard-iclb: FAIL [fdo#107383] / [fdo#110215] -> PASS +1
* igt@kms_sysfs_edid_timing:
- shard-iclb: FAIL [fdo#100047] -> PASS
#### Warnings ####
* igt@perf_pmu@semaphore-wait-bcs0:
- shard-hsw: SKIP [fdo#109271] -> INCOMPLETE [fdo#103540]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103833]: https://bugs.freedesktop.org/show_bug.cgi?id=103833
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107383]: https://bugs.freedesktop.org/show_bug.cgi?id=107383
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#108059]: https://bugs.freedesktop.org/show_bug.cgi?id=108059
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
[fdo#108954]: https://bugs.freedesktop.org/show_bug.cgi?id=108954
[fdo#109247]: https://bugs.freedesktop.org/show_bug.cgi?id=109247
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109277]: https://bugs.freedesktop.org/show_bug.cgi?id=109277
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109290]: https://bugs.freedesktop.org/show_bug.cgi?id=109290
[fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
[fdo#109300]: https://bugs.freedesktop.org/show_bug.cgi?id=109300
[fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#109960]: https://bugs.freedesktop.org/show_bug.cgi?id=109960
[fdo#110215]: https://bugs.freedesktop.org/show_bug.cgi?id=110215
[fdo#110278]: https://bugs.freedesktop.org/show_bug.cgi?id=110278
[fdo#110321]: https://bugs.freedesktop.org/show_bug.cgi?id=110321
[fdo#110336]: https://bugs.freedesktop.org/show_bug.cgi?id=110336
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (10 -> 6)
------------------------------
Missing (4): pig-skl-6260u shard-skl pig-hsw-4770r pig-glk-j5005
Build changes
-------------
* IGT: IGT_4937 -> IGTPW_2835
* Piglit: piglit_4509 -> None
CI_DRM_5898: b7ec63a9ba82930148c90769d04f957f10b6b6da @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_2835: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2835/
IGT_4937: 256c6107ee127d2ff07d23dfeb3b8d828cb43b37 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2835/
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Potential bug in queue_count_set
From: Minwoo Im @ 2019-04-10 14:11 UTC (permalink / raw)
In-Reply-To: <b62dde65-1abf-1391-9de6-9bcdf6a7fa07@gmail.com>
On 4/10/19 10:33 PM, Maximilian Luz wrote:
> Hi all,
>
> I just stumbled (more or less randomly) over this piece of code
> (/drivers/nvme/host/pci.c, v5.1-rc4):
>
> 147: static int queue_count_set(const char *val, const struct
> kernel_param *kp)
> 148: {
> 149:???? int n = 0, ret;
> 150:
> 151:???? ret = kstrtoint(val, 10, &n);
> 152:???? if (ret)
> 153:???????? return ret;
> 154:???? if (n > num_possible_cpus())
> 155:???????? n = num_possible_cpus();
> 156:
> 157:???? return param_set_int(val, kp);
> 158: }
>
> Link with context:
> https://github.com/torvalds/linux/blob/v5.1-rc4/drivers/nvme/host/pci.c#L154-L155
>
>
> It looks like lines 154, 155 don't achieve anything as `n` is not being
> used afterwards. Sorry if this is already known or a non-issue, just
> wanted to let you guys know.
>
It looks like module parameter "write_queues" is set to the actual given
value (val) without considering reduced number of queues in case given
value is greater than nr_cpus.
I think that might need sprintf() or something like this to make the
actual value reduced in that case.
> Maximilian
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH 2/2] dt-bindings: simple-panel: Set compatible string to "simple-panel".
From: Christoph Muellner @ 2019-04-10 14:10 UTC (permalink / raw)
Cc: heiko, Christoph Muellner, Thierry Reding, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, dri-devel, devicetree,
linux-kernel
In-Reply-To: <20190410141045.58097-1-christoph.muellner@theobroma-systems.com>
The documentation for simple-panel lists "cptt,claa101wb01" as
compatible string. However, the kernel contains no driver, which
recognizes this string. Therefore this patch replaces the compatible
string with "simple-panel".
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
---
Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index b2b872c710f2..2000692ba44f 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -18,7 +18,7 @@ Optional properties:
Example:
panel: panel {
- compatible = "cptt,claa101wb01";
+ compatible = "simple-panel";
ddc-i2c-bus = <&panelddc>;
power-supply = <&vdd_pnl_reg>;
--
2.11.0
^ 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.