* [Cluster-devel] [PATCH v5 01/13] mm: Fix the return type of __do_page_cache_readahead
From: Matthew Wilcox @ 2020-02-14 19:50 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200211010348.6872-2-willy@infradead.org>
On Mon, Feb 10, 2020 at 05:03:36PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> ra_submit() which is a wrapper around __do_page_cache_readahead() already
> returns an unsigned long, and the 'nr_to_read' parameter is an unsigned
> long, so fix __do_page_cache_readahead() to return an unsigned long,
> even though I'm pretty sure we're not going to readahead more than 2^32
> pages ever.
I was going through this and realised it's completely pointless -- the
returned value from ra_submit() and __do_page_cache_readahead() is
eventually ignored through all paths. So I'm replacing this patch with
one that makes everything return void.
^ permalink raw reply
* [Ocfs2-devel] [PATCH v5 01/13] mm: Fix the return type of __do_page_cache_readahead
From: Matthew Wilcox @ 2020-02-14 19:50 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <20200211010348.6872-2-willy@infradead.org>
On Mon, Feb 10, 2020 at 05:03:36PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> ra_submit() which is a wrapper around __do_page_cache_readahead() already
> returns an unsigned long, and the 'nr_to_read' parameter is an unsigned
> long, so fix __do_page_cache_readahead() to return an unsigned long,
> even though I'm pretty sure we're not going to readahead more than 2^32
> pages ever.
I was going through this and realised it's completely pointless -- the
returned value from ra_submit() and __do_page_cache_readahead() is
eventually ignored through all paths. So I'm replacing this patch with
one that makes everything return void.
^ permalink raw reply
* Re: [PATCH v5 01/13] mm: Fix the return type of __do_page_cache_readahead
From: Matthew Wilcox @ 2020-02-14 19:50 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-mm, linux-kernel, linux-btrfs, linux-erofs, linux-ext4,
linux-f2fs-devel, cluster-devel, ocfs2-devel, linux-xfs
In-Reply-To: <20200211010348.6872-2-willy@infradead.org>
On Mon, Feb 10, 2020 at 05:03:36PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> ra_submit() which is a wrapper around __do_page_cache_readahead() already
> returns an unsigned long, and the 'nr_to_read' parameter is an unsigned
> long, so fix __do_page_cache_readahead() to return an unsigned long,
> even though I'm pretty sure we're not going to readahead more than 2^32
> pages ever.
I was going through this and realised it's completely pointless -- the
returned value from ra_submit() and __do_page_cache_readahead() is
eventually ignored through all paths. So I'm replacing this patch with
one that makes everything return void.
^ permalink raw reply
* Re: [PATCH v4] arm64: dts: meson-a1: add I2C nodes
From: Kevin Hilman @ 2020-02-14 19:50 UTC (permalink / raw)
To: Jerome Brunet, Neil Armstrong
Cc: Jian Hu, Rob Herring, Martin Blumenstingl, Michael Turquette,
Wolfram Sang, Mark Rutland, Jianxin Pan,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200109031756.176547-1-jian.hu-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
Jian Hu <jian.hu-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org> writes:
> There are four I2C controllers in A1 series,
> Share the same comptible with AXG. Compared to AXG,
> Drive strength feature is newly added in A1.
>
> Signed-off-by: Jian Hu <jian.hu-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> ---
> This patch depends on A1 clock patchset at [0][3]
Just FYI, due the dependency, I'm waiting on the clock series to merge
before queuing this. When the clock series is ready, please repost this
since it no longer applies to current mainline.
Thanks,
Kevin
^ permalink raw reply
* Re: [PATCH v4] arm64: dts: meson-a1: add I2C nodes
From: Kevin Hilman @ 2020-02-14 19:50 UTC (permalink / raw)
To: Jian Hu, Jerome Brunet, Neil Armstrong
Cc: Jian Hu, Rob Herring, Martin Blumenstingl, Michael Turquette,
Wolfram Sang, Mark Rutland, Jianxin Pan, linux-amlogic, linux-i2c,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20200109031756.176547-1-jian.hu@amlogic.com>
Jian Hu <jian.hu@amlogic.com> writes:
> There are four I2C controllers in A1 series,
> Share the same comptible with AXG. Compared to AXG,
> Drive strength feature is newly added in A1.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>
> ---
> This patch depends on A1 clock patchset at [0][3]
Just FYI, due the dependency, I'm waiting on the clock series to merge
before queuing this. When the clock series is ready, please repost this
since it no longer applies to current mainline.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 4/4] target/arm: Flush high bits of sve register after AdvSIMD INS
From: Richard Henderson @ 2020-02-14 19:46 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, qemu-arm
In-Reply-To: <20200214194643.23317-1-richard.henderson@linaro.org>
Writes to AdvSIMD registers flush the bits above 128.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
target/arm/translate-a64.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index b83d09dbcd..bd68588a71 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -7412,6 +7412,9 @@ static void handle_simd_inse(DisasContext *s, int rd, int rn,
write_vec_element(s, tmp, rd, dst_index, size);
tcg_temp_free_i64(tmp);
+
+ /* INS is considered a 128-bit write for SVE. */
+ clear_vec_high(s, true, rd);
}
@@ -7441,6 +7444,9 @@ static void handle_simd_insg(DisasContext *s, int rd, int rn, int imm5)
idx = extract32(imm5, 1 + size, 4 - size);
write_vec_element(s, cpu_reg(s, rn), rd, idx, size);
+
+ /* INS is considered a 128-bit write for SVE. */
+ clear_vec_high(s, true, rd);
}
/*
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v4] arm64: dts: meson-a1: add I2C nodes
From: Kevin Hilman @ 2020-02-14 19:50 UTC (permalink / raw)
To: Jian Hu, Jerome Brunet, Neil Armstrong
Cc: Mark Rutland, Rob Herring, Jianxin Pan, Wolfram Sang,
Martin Blumenstingl, Michael Turquette, linux-kernel, devicetree,
Jian Hu, linux-i2c, linux-amlogic, linux-arm-kernel
In-Reply-To: <20200109031756.176547-1-jian.hu@amlogic.com>
Jian Hu <jian.hu@amlogic.com> writes:
> There are four I2C controllers in A1 series,
> Share the same comptible with AXG. Compared to AXG,
> Drive strength feature is newly added in A1.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>
> ---
> This patch depends on A1 clock patchset at [0][3]
Just FYI, due the dependency, I'm waiting on the clock series to merge
before queuing this. When the clock series is ready, please repost this
since it no longer applies to current mainline.
Thanks,
Kevin
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH v4] arm64: dts: meson-a1: add I2C nodes
From: Kevin Hilman @ 2020-02-14 19:50 UTC (permalink / raw)
To: Jian Hu, Jerome Brunet, Neil Armstrong
Cc: Mark Rutland, Rob Herring, Jianxin Pan, Wolfram Sang,
Martin Blumenstingl, Michael Turquette, linux-kernel, devicetree,
Jian Hu, linux-i2c, linux-amlogic, linux-arm-kernel
In-Reply-To: <20200109031756.176547-1-jian.hu@amlogic.com>
Jian Hu <jian.hu@amlogic.com> writes:
> There are four I2C controllers in A1 series,
> Share the same comptible with AXG. Compared to AXG,
> Drive strength feature is newly added in A1.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>
> ---
> This patch depends on A1 clock patchset at [0][3]
Just FYI, due the dependency, I'm waiting on the clock series to merge
before queuing this. When the clock series is ready, please repost this
since it no longer applies to current mainline.
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v5 01/13] mm: Fix the return type of __do_page_cache_readahead
From: Matthew Wilcox @ 2020-02-14 19:50 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-ext4, linux-erofs, linux-btrfs
In-Reply-To: <20200211010348.6872-2-willy@infradead.org>
On Mon, Feb 10, 2020 at 05:03:36PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> ra_submit() which is a wrapper around __do_page_cache_readahead() already
> returns an unsigned long, and the 'nr_to_read' parameter is an unsigned
> long, so fix __do_page_cache_readahead() to return an unsigned long,
> even though I'm pretty sure we're not going to readahead more than 2^32
> pages ever.
I was going through this and realised it's completely pointless -- the
returned value from ra_submit() and __do_page_cache_readahead() is
eventually ignored through all paths. So I'm replacing this patch with
one that makes everything return void.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [PATCH userspace v2] libsepol: cache ebitmap cardinality value
From: Ondrej Mosnacek @ 2020-02-14 19:51 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SElinux list, James Carter
In-Reply-To: <1a11d058-eee1-41c5-9686-da01ecf6ea33@tycho.nsa.gov>
On Fri, Feb 14, 2020 at 6:37 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 2/13/20 8:39 AM, Ondrej Mosnacek wrote:
> > According to profiling of semodule -BN, ebitmap_cardinality() is called
> > quite often and contributes a lot to the total runtime. Cache its result
> > in the ebitmap struct to reduce this overhead. The cached value is
> > invalidated on most modifying operations, but ebitmap_cardinality() is
> > usually called once the ebitmap doesn't change any more.
> >
> > After this patch, the time to do 'semodule -BN' on Fedora Rawhide has
> > decreased from ~14.6s to ~12.4s (2.2s saved).
> >
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
>
> This seems fine but I was wondering how many of the callers of
> ebitmap_cardinality() actually need anything more than ebitmap_length()?
The caller that calls it the most (>99%) during a 'semodule -B' is
__cil_should_expand_attribute(), which logically needs the actual
cardinality. It might be possible to cache the decision directly in
'struct cil_typeattribute', but I don't know the CIL code well enough
to attempt that...
--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.
^ permalink raw reply
* Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
From: Sean Christopherson @ 2020-02-14 19:52 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Chia-I Wu, kvm, vkuznets, wanpengli, jmattson, joro,
Gurchetan Singh, Gerd Hoffmann, ML dri-devel
In-Reply-To: <b82cd76c-0690-c13b-cf2c-75d7911c5c61@redhat.com>
On Fri, Feb 14, 2020 at 11:26:06AM +0100, Paolo Bonzini wrote:
> On 13/02/20 23:18, Chia-I Wu wrote:
> >
> > The bug you mentioned was probably this one
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=104091
>
> Yes, indeed.
>
> > From what I can tell, the commit allowed the guests to create cached
> > mappings to MMIO regions and caused MCEs. That is different than what
> > I need, which is to allow guests to create uncached mappings to system
> > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has uncached
> > mappings. But it is true that this still allows the userspace & guest
> > kernel to create conflicting memory types.
This is ok.
> Right, the question is whether the MCEs were tied to MMIO regions
> specifically and if so why.
99.99999% likelihood the answer is "yes". Cacheable accesses to non-existent
memory and most (all?) MMIO regions will cause a #MC. This includes
speculative accesses.
Commit fd717f11015f ("KVM: x86: apply guest MTRR virtualization on host
reserved pages") explicitly had a comment "1. MMIO: trust guest MTRR",
which is basically a direct avenue to generating #MCs.
IIRC, WC accesses to non-existent memory will also cause #MC, but KVM has
bigger problems if it has PRESENT EPTEs pointing at garbage.
> An interesting remark is in the footnote of table 11-7 in the SDM.
> There, for the MTRR (EPT for us) memory type UC you can read:
>
> The UC attribute comes from the MTRRs and the processors are not
> required to snoop their caches since the data could never have
> been cached. This attribute is preferred for performance reasons.
>
> There are two possibilities:
>
> 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> That would make your change safe.
>
> 2) the footnote also applies when the UC attribute comes from the EPT
> page tables rather than the MTRRs. In that case, the host should use
> UC as the EPT page attribute if and only if it's consistent with the host
> MTRRs; it would be more or less impossible to honor UC in the guest MTRRs.
> In that case, something like the patch below would be needed.
(2), the EPTs effectively replace the MTRRs. The expectation being that
the VMM will use always use EPT memtypes consistent with the MTRRs.
> It is not clear from the manual why the footnote would not apply to WC; that
> is, the manual doesn't say explicitly that the processor does not do snooping
> for accesses to WC memory. But I guess that must be the case, which is why I
> used MTRR_TYPE_WRCOMB in the patch below.
A few paragraphs below table 11-12 states:
In particular, a WC page must never be aliased to a cacheable page because
WC writes may not check the processor caches.
> Either way, we would have an explanation of why creating cached mapping to
> MMIO regions would, and why in practice we're not seeing MCEs for guest RAM
> (the guest would have set WB for that memory in its MTRRs, not UC).
Aliasing (physical) RAM with different memtypes won't cause #MC, just
memory corruption.
> One thing you didn't say: how would userspace use KVM_MEM_DMA? On which
> regions would it be set?
>
> Thanks,
>
> Paolo
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dc331fb06495..2be6f7effa1d 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6920,8 +6920,16 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> }
>
> cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
> -
> exit:
> + if (cache == MTRR_TYPE_UNCACHABLE && !is_mmio) {
> + /*
> + * We cannot set UC in the EPT page tables as it can cause
> + * machine check exceptions (??). Hopefully the guest is
> + * using PAT.
> + */
> + cache = MTRR_TYPE_WRCOMB;
This is unnecessary. Setting UC in the EPT tables will never directly lead
to #MC. Forcing WC is likely more dangerous.
> + }
> +
> return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
> }
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
From: Sean Christopherson @ 2020-02-14 19:52 UTC (permalink / raw)
To: Paolo Bonzini
Cc: wanpengli, kvm, joro, ML dri-devel, Gurchetan Singh,
Gerd Hoffmann, vkuznets, jmattson
In-Reply-To: <b82cd76c-0690-c13b-cf2c-75d7911c5c61@redhat.com>
On Fri, Feb 14, 2020 at 11:26:06AM +0100, Paolo Bonzini wrote:
> On 13/02/20 23:18, Chia-I Wu wrote:
> >
> > The bug you mentioned was probably this one
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=104091
>
> Yes, indeed.
>
> > From what I can tell, the commit allowed the guests to create cached
> > mappings to MMIO regions and caused MCEs. That is different than what
> > I need, which is to allow guests to create uncached mappings to system
> > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has uncached
> > mappings. But it is true that this still allows the userspace & guest
> > kernel to create conflicting memory types.
This is ok.
> Right, the question is whether the MCEs were tied to MMIO regions
> specifically and if so why.
99.99999% likelihood the answer is "yes". Cacheable accesses to non-existent
memory and most (all?) MMIO regions will cause a #MC. This includes
speculative accesses.
Commit fd717f11015f ("KVM: x86: apply guest MTRR virtualization on host
reserved pages") explicitly had a comment "1. MMIO: trust guest MTRR",
which is basically a direct avenue to generating #MCs.
IIRC, WC accesses to non-existent memory will also cause #MC, but KVM has
bigger problems if it has PRESENT EPTEs pointing at garbage.
> An interesting remark is in the footnote of table 11-7 in the SDM.
> There, for the MTRR (EPT for us) memory type UC you can read:
>
> The UC attribute comes from the MTRRs and the processors are not
> required to snoop their caches since the data could never have
> been cached. This attribute is preferred for performance reasons.
>
> There are two possibilities:
>
> 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> That would make your change safe.
>
> 2) the footnote also applies when the UC attribute comes from the EPT
> page tables rather than the MTRRs. In that case, the host should use
> UC as the EPT page attribute if and only if it's consistent with the host
> MTRRs; it would be more or less impossible to honor UC in the guest MTRRs.
> In that case, something like the patch below would be needed.
(2), the EPTs effectively replace the MTRRs. The expectation being that
the VMM will use always use EPT memtypes consistent with the MTRRs.
> It is not clear from the manual why the footnote would not apply to WC; that
> is, the manual doesn't say explicitly that the processor does not do snooping
> for accesses to WC memory. But I guess that must be the case, which is why I
> used MTRR_TYPE_WRCOMB in the patch below.
A few paragraphs below table 11-12 states:
In particular, a WC page must never be aliased to a cacheable page because
WC writes may not check the processor caches.
> Either way, we would have an explanation of why creating cached mapping to
> MMIO regions would, and why in practice we're not seeing MCEs for guest RAM
> (the guest would have set WB for that memory in its MTRRs, not UC).
Aliasing (physical) RAM with different memtypes won't cause #MC, just
memory corruption.
> One thing you didn't say: how would userspace use KVM_MEM_DMA? On which
> regions would it be set?
>
> Thanks,
>
> Paolo
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dc331fb06495..2be6f7effa1d 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6920,8 +6920,16 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> }
>
> cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
> -
> exit:
> + if (cache == MTRR_TYPE_UNCACHABLE && !is_mmio) {
> + /*
> + * We cannot set UC in the EPT page tables as it can cause
> + * machine check exceptions (??). Hopefully the guest is
> + * using PAT.
> + */
> + cache = MTRR_TYPE_WRCOMB;
This is unnecessary. Setting UC in the EPT tables will never directly lead
to #MC. Forcing WC is likely more dangerous.
> + }
> +
> return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
> }
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [MPTCP] Re: [PATCH net v2 2/3] mptcp: Protect subflow socket options before connection completes
From: Mat Martineau @ 2020-02-14 19:52 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 5412 bytes --]
On Fri, 14 Feb 2020, Paolo Abeni wrote:
> On Thu, 2020-02-13 at 12:38 -0800, Mat Martineau wrote:
>> Userspace should not be able to directly manipulate subflow socket
>> options before a connection is established since it is not yet known if
>> it will be an MPTCP subflow or a TCP fallback subflow. TCP fallback
>> subflows can be more directly controlled by userspace because they are
>> regular TCP connections, while MPTCP subflow sockets need to be
>> configured for the specific needs of MPTCP. Use the same logic as
>> sendmsg/recvmsg to ensure that socket option calls are only passed
>> through to known TCP fallback subflows.
>>
>> Signed-off-by: Mat Martineau <mathew.j.martineau(a)linux.intel.com>
>> ---
>> net/mptcp/protocol.c | 50 ++++++++++++++++++++++++--------------------
>> 1 file changed, 27 insertions(+), 23 deletions(-)
>>
>> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
>> index a8faf66c38d8..0169e7dfc2d1 100644
>> --- a/net/mptcp/protocol.c
>> +++ b/net/mptcp/protocol.c
>> @@ -756,60 +756,64 @@ static int mptcp_setsockopt(struct sock *sk, int level, int optname,
>> char __user *optval, unsigned int optlen)
>> {
>> struct mptcp_sock *msk = mptcp_sk(sk);
>> - int ret = -EOPNOTSUPP;
>> struct socket *ssock;
>> - struct sock *ssk;
>>
>> pr_debug("msk=%p", msk);
>>
>> /* @@ the meaning of setsockopt() when the socket is connected and
>> - * there are multiple subflows is not defined.
>> + * there are multiple subflows is not yet defined. It is up to the
>> + * MPTCP-level socket to configure the subflows until the subflow
>> + * is in TCP fallback, when TCP socket options are passed through
>> + * to the one remaining subflow.
>> */
>> lock_sock(sk);
>> - ssock = __mptcp_socket_create(msk, MPTCP_SAME_STATE);
>> - if (IS_ERR(ssock)) {
>> + ssock = __mptcp_tcp_fallback(msk);
>> + if (ssock) {
>> + struct sock *ssk = ssock->sk;
>> + int ret;
>> +
>> + sock_hold(ssk);
>> release_sock(sk);
>> + ret = tcp_setsockopt(ssk, level, optname, optval, optlen);
>> + sock_put(ssk);
>> return ret;
>> }
>>
>> - ssk = ssock->sk;
>> - sock_hold(ssk);
>> release_sock(sk);
>>
>> - ret = tcp_setsockopt(ssk, level, optname, optval, optlen);
>> - sock_put(ssk);
>> -
>> - return ret;
>> + return -EOPNOTSUPP;
>> }
>>
>> static int mptcp_getsockopt(struct sock *sk, int level, int optname,
>> char __user *optval, int __user *option)
>> {
>> struct mptcp_sock *msk = mptcp_sk(sk);
>> - int ret = -EOPNOTSUPP;
>> struct socket *ssock;
>> - struct sock *ssk;
>>
>> pr_debug("msk=%p", msk);
>>
>> - /* @@ the meaning of getsockopt() when the socket is connected and
>> - * there are multiple subflows is not defined.
>> + /* @@ the meaning of setsockopt() when the socket is connected and
>> + * there are multiple subflows is not yet defined. It is up to the
>> + * MPTCP-level socket to configure the subflows until the subflow
>> + * is in TCP fallback, when socket options are passed through
>> + * to the one remaining subflow.
>> */
>> lock_sock(sk);
>> - ssock = __mptcp_socket_create(msk, MPTCP_SAME_STATE);
>> - if (IS_ERR(ssock)) {
>> + ssock = __mptcp_tcp_fallback(msk);
>> + if (ssock) {
>> + struct sock *ssk = ssock->sk;
>> + int ret;
>> +
>> + sock_hold(ssk);
>> release_sock(sk);
>
> Since I can't wrap my head on it, I'm going to do ask dumb question:
>
I think it's a good question!
> do we need this refcont at all? (here, in poll and in {recv,send}msg) ?
>
> AFAICS:
> - subflows can be freed only by mptcp_close()
This is true now, but Florian's patch that removed __mptcp_close() is
fairly recent. I think the branch I was working from when I got concerned
about the subflow lifetimes didn't have the change yet, so I the idea in
my head that there were other paths to the subflow-freeing code that
relied only on the MPTCP socket lock.
> - mptcp_close() is called by vfs->release() when the last reference to
> the file descriptor associated to the msk socket is dropped.
> - every syscall wraps vfs ops with fdget()/fdput() pairs so the file
> descriptor can't go away during the syscall execution.
While I saw that the MPTCP socket lifetime was managed with fdget/fdput, I
couldn't track down such protections for the subflow socket structures
because (as I now see) we're depending on the MPTCP-level socket reference
count for that.
>
> Overall I think the race between mptcp_close() and sock_sendmsg() is
> not possible, WDYT ?!?
For single subflow, it does seem safe to me now that it's clear when
mptcp_close is called. I'll drop the fallback changes outside of the
sockopt functions and send the one sockopt patch to netdev.
>
> mptcp_close should need to care of possible cuncurrent BH/receive path
> processing.
>
Seems like the struct sock reference counts should handle that?
>
> Note: the I this doubt since I was wondering why socket-releated inet_*
> operations that do not acquire the sock lock still do not have any
> issue racing with close().
I'm glad you looked in to it. I was wondering the same thing when I saw
the lack of fdget/fdput on the "struct socket" for subflows but didn't see
that those were only freed when the entire MPTCP socket was being torn
down.
--
Mat Martineau
Intel
^ permalink raw reply
* [igt-dev] ✗ GitLab.Pipeline: failure for i915/gem_ctx_engines: Exercise 0 engines[]
From: Patchwork @ 2020-02-14 19:52 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200214192327.4002875-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: i915/gem_ctx_engines: Exercise 0 engines[]
URL : https://patchwork.freedesktop.org/series/73484/
State : failure
== Summary ==
ERROR! This series introduces new undocumented tests:
gem_ctx_engines@none
Can you document them as per the requirement in the [CONTRIBUTING.md]?
[Documentation] has more details on how to do this.
Here are few examples:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/0316695d03aa46108296b27f3982ec93200c7a6e
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/443cc658e1e6b492ee17bf4f4d891029eb7a205d
Thanks in advance!
[CONTRIBUTING.md]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/CONTRIBUTING.md#L19
[Documentation]: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-gpu-tools-Core.html#igt-describe
Other than that, pipeline status: SUCCESS.
see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/108859 for the overview.
== Logs ==
For more details see: https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/108859
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: get-lore-mbox: quickly grab full threads from lore
From: Konstantin Ryabitsev @ 2020-02-14 19:53 UTC (permalink / raw)
To: Kevin Hilman; +Cc: workflows
In-Reply-To: <7hwo8p9db1.fsf@baylibre.com>
On Fri, Feb 14, 2020 at 11:30:42AM -0800, Kevin Hilman wrote:
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
>
> > I'd like your opinion on this quick helper script I wrote that uses any
> > message-id to grab a full thread from lore.kernel.org and save it as a
> > mbox file.
>
> This is very useful, thank you!
>
> One question/request: Is there a way for it to only grab a subset of a
> series? e.g. Some series contain patches that might end up going
> through a couple different trees (e.g. DT patches typically take a
> separate path than drivers) so as a maintainer for one of the
> subsystems, I might want to only get a subset of the series into an
> mbox, not the whole thing.
>
> IOW, Right now even if I pass a msgid from the middle of the series, it
> finds the whole series (which is cool!), but what if I want to apply
> just that single patch? Or even better, I might want to only apply
> patches 3-5 and 9 from a 10-patch series.
>
> Is this something do-able?
I think for such cases it's easy enough to just edit the .mbx file to
remove the patches you're not interested in. When you use the '-a' flag,
the content is de-mimefied to remove various mta-transmission cruft like
quoted-printable/base64 encodings, etc -- making it easy to identify and
remove content that is not relevant.
-K
^ permalink raw reply
* Re: get-lore-mbox: quickly grab full threads from lore
From: Mark Brown @ 2020-02-14 19:53 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Kevin Hilman, Konstantin Ryabitsev, workflows
In-Reply-To: <87zhdlares.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Fri, Feb 14, 2020 at 08:40:43PM +0100, Toke Høiland-Jørgensen wrote:
> Kevin Hilman <khilman@baylibre.com> writes:
> > IOW, Right now even if I pass a msgid from the middle of the series, it
> > finds the whole series (which is cool!), but what if I want to apply
> > just that single patch? Or even better, I might want to only apply
> > patches 3-5 and 9 from a 10-patch series.
> > Is this something do-able?
> git am --interactive ?
That's not so great if your patch application is done as part of a
script (eg, with something like aiaiai) rather than interactively. You
can always download the full mailbox, open it and delete unwanted
messages but it'd be handy to be able to do that as part of the download
stage.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH AUTOSEL 4.4 074/100] ide: remove set but not used variable 'hwif'
From: Sasha Levin @ 2020-02-14 16:23 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Wang Hai, linux-ide, Hulk Robot, linuxppc-dev,
David S . Miller
In-Reply-To: <20200214162425.21071-1-sashal@kernel.org>
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 98949a1946d70771789def0c9dbc239497f9f138 ]
Fix the following gcc warning:
drivers/ide/pmac.c: In function pmac_ide_setup_device:
drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used
[-Wunused-but-set-variable]
Fixes: d58b0c39e32f ("powerpc/macio: Rework hotplug media bay support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/pmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index 0add5bb3cee85..fbfe5761328fc 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -1024,7 +1024,6 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
struct device_node *np = pmif->node;
const int *bidp;
struct ide_host *host;
- ide_hwif_t *hwif;
struct ide_hw *hws[] = { hw };
struct ide_port_info d = pmac_port_info;
int rc;
@@ -1080,7 +1079,7 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
rc = -ENOMEM;
goto bail;
}
- hwif = pmif->hwif = host->ports[0];
+ pmif->hwif = host->ports[0];
if (on_media_bay(pmif)) {
/* Fixup bus ID for media bay */
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] kvm/emulate: fix a -Werror=cast-function-type
From: Sean Christopherson @ 2020-02-14 19:54 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Qian Cai, Jim Mattson, Vitaly Kuznetsov, Wanpeng Li, Joerg Roedel,
kvm list, LKML
In-Reply-To: <28680b99-d043-ee02-dab3-b5ce8c2e625b@redhat.com>
On Fri, Feb 14, 2020 at 08:33:50PM +0100, Paolo Bonzini wrote:
> On 14/02/20 20:14, Qian Cai wrote:
> >> It seems misguided to define a local variable just to get an implicit
> >> cast from (void *) to (fastop_t). Sean's first suggestion gives you
> >> the same implicit cast without the local variable. The second
> >> suggestion makes both casts explicit.
> >
> > OK, I'll do a v2 using the first suggestion which looks simpler once it passed
> > compilations.
> >
>
> Another interesting possibility is to use an unnamed union of a
> (*execute) function pointer and a (*fastop) function pointer.
I considered that when introducing fastop_t. I don't remember why I
didn't go that route. It's entirely possible I completely forgot that
anonymous unions are allowed and thought it would mean changing a bunch
of use sites.
^ permalink raw reply
* RE: [PATCH v1] usb:gadget: Fix issue with config_ep_by_speed function.
From: Pawel Laszczak @ 2020-02-14 19:55 UTC (permalink / raw)
To: Thinh Nguyen, Jayshri Dajiram Pawar, linux-usb@vger.kernel.org,
balbi@kernel.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org,
heikki.krogerus@linux.intel.com, rogerq@ti.com,
linux-kernel@vger.kernel.org, jbergsagel@ti.com, nsekhar@ti.com,
nm@ti.com, peter.chen@nxp.com, Rahul Kumar, Sanket Parmar
In-Reply-To: <7ef4b9c5-8694-4d8e-2866-95ec11546bec@synopsys.com>
>
>Pawel Laszczak wrote:
>> Hi,
>>
>>> Hi,
>>>
>>> Jayshri Pawar wrote:
>>>> This patch adds additional parameter alt to config_ep_by_speed function.
>>>> This additional parameter allows to improve this function and
>>>> find proper usb_ss_ep_comp_descriptor.
>>>>
>>>> Problem has appeared during testing f_tcm (BOT/UAS) driver function.
>>>>
>>>> f_tcm function for SS use array of headers for both BOT/UAS alternate
>>>> setting:
>>>>
>>>> static struct usb_descriptor_header *uasp_ss_function_desc[] = {
>>>> (struct usb_descriptor_header *) &bot_intf_desc,
>>>> (struct usb_descriptor_header *) &bot_uasp_ss_bi_desc,
>>>> (struct usb_descriptor_header *) &bot_bi_ep_comp_desc,
>>>> (struct usb_descriptor_header *) &bot_uasp_ss_bo_desc,
>>>> (struct usb_descriptor_header *) &bot_bo_ep_comp_desc,
>>>>
>>>> (struct usb_descriptor_header *) &uasp_intf_desc,
>>>> (struct usb_descriptor_header *) &bot_uasp_ss_bi_desc,
>>>> (struct usb_descriptor_header *) &uasp_bi_ep_comp_desc,
>>>> (struct usb_descriptor_header *) &uasp_bi_pipe_desc,
>>>> (struct usb_descriptor_header *) &bot_uasp_ss_bo_desc,
>>>> (struct usb_descriptor_header *) &uasp_bo_ep_comp_desc,
>>>> (struct usb_descriptor_header *) &uasp_bo_pipe_desc,
>>>> (struct usb_descriptor_header *) &uasp_ss_status_desc,
>>>> (struct usb_descriptor_header *) &uasp_status_in_ep_comp_desc,
>>>> (struct usb_descriptor_header *) &uasp_status_pipe_desc,
>>>> (struct usb_descriptor_header *) &uasp_ss_cmd_desc,
>>>> (struct usb_descriptor_header *) &uasp_cmd_comp_desc,
>>>> (struct usb_descriptor_header *) &uasp_cmd_pipe_desc,
>>>> NULL,
>>>> };
>>>>
>>>> The first 5 descriptors are associated with BOT alternate setting,
>>>> and others are associated with UAS.
>>>>
>>>> During handling UAS alternate setting f_tcm drivr invokes
>>>> config_ep_by_speed and this function sets incorrect companion endpoint
>>>> descriptor in usb_ep object.
>>>>
>>>> Instead setting ep->comp_desc to uasp_bi_ep_comp_desc function in this
>>>> case set ep->comp_desc to bot_uasp_ss_bi_desc.
>>>>
>>>> This is due to the fact that it search endpoint based on endpoint
>>>> address:
>>>>
>>>> for_each_ep_desc(speed_desc, d_spd) {
>>>> chosen_desc = (struct usb_endpoint_descriptor *)*d_spd;
>>>> if (chosen_desc->bEndpoitAddress == _ep->address)
>>>> goto ep_found;
>>>> }
>>>>
>>>> And in result it uses the descriptor from BOT alternate setting
>>>> instead UAS.
>>>>
>>>> Finally, it causes that controller driver during enabling endpoints
>>>> detect that just enabled endpoint for bot.
>>>>
>>>> Signed-off-by: Jayshri Pawar <jpawar@cadence.com>
>>>> Signed-off-by: Pawel Laszczak <pawell@cadence.com>
>>>> ---
>>>> drivers/usb/gadget/composite.c | 46 ++++++++++++++------
>>>> drivers/usb/gadget/function/f_acm.c | 7 +--
>>>> drivers/usb/gadget/function/f_ecm.c | 7 +--
>>>> drivers/usb/gadget/function/f_eem.c | 4 +-
>>>> drivers/usb/gadget/function/f_fs.c | 3 +-
>>>> drivers/usb/gadget/function/f_hid.c | 4 +-
>>>> drivers/usb/gadget/function/f_loopback.c | 2 +-
>>>> drivers/usb/gadget/function/f_mass_storage.c | 5 ++-
>>>> drivers/usb/gadget/function/f_midi.c | 2 +-
>>>> drivers/usb/gadget/function/f_ncm.c | 7 +--
>>>> drivers/usb/gadget/function/f_obex.c | 4 +-
>>>> drivers/usb/gadget/function/f_phonet.c | 4 +-
>>>> drivers/usb/gadget/function/f_rndis.c | 7 +--
>>>> drivers/usb/gadget/function/f_serial.c | 4 +-
>>>> drivers/usb/gadget/function/f_sourcesink.c | 11 +++--
>>>> drivers/usb/gadget/function/f_subset.c | 4 +-
>>>> drivers/usb/gadget/function/f_tcm.c | 36 +++++++--------
>>>> drivers/usb/gadget/function/f_uac1_legacy.c | 2 +-
>>>> drivers/usb/gadget/function/f_uvc.c | 5 ++-
>>>> drivers/usb/gadget/function/u_audio.c | 4 +-
>>>> include/linux/usb/composite.h | 2 +-
>>>> 21 files changed, 99 insertions(+), 71 deletions(-)
>>>>
>>> I think we should create a new function and keep the old
>>> config_ep_by_speed() for default alt-setting (e.i. have
>>> config_ep_by_speed calls the new function with default alt-setting 0).
>>> This way, we can keep compatibility with old function drivers and
>>> minimize changes. At least that's what we did.
>>>
>> I don't think we need the separate function.
>> If we set last parameter alt=0 then this function will work in the same way as old one.
>>
>
>I wasn't talking about that. This patch modifies the
>config_ep_by_speed() parameters, which requires to make a change to
>every function driver of the kernel, and all in a single patch. This
>makes it difficult to backport this fix. The only function driver that
>you really need this fix for is f_tcm because of the stream eps right?
>
>You could just add a function like
>
> int config_ep_by_speed_and_alt(struct usb_gadget *g, struct
> usb_function *f, unsigned int alt, struct usb_ep *_ep);
>
>
>Then redefine config_ep_by_speed() to use it
>
> int config_ep_by_speed(struct usb_gadget *g,
> struct usb_function *f,
> struct usb_ep *_ep)
> {
> return config_ep_by_speed_and_alt(g, f, 0, _ep);
> }
>
>This way, 1) you can split this patch, 2) you only need to make a fix to
>f_tcm, 3) this fix can be backported much easier.
>
>Anyways, this is just a suggestion. It's up to the maintainers to decide.
Thanks for clarification, now I got it. In my opinion, both solution has pros and cons
1. Original patch.
cons: introduce many change in many files
pros: we have only single API function - simpler Gadget Subsystem API
2. using config_ep_by_speed_and_alt
cons: minimal impact to other files.
pros: introduce the new API function which in fact could be omitted.
It's only my personal opinion :) .
Felipe and Greg what is you opinion ?
Best Regards,
Pawel
>
>BR,
>Thinh
^ permalink raw reply
* [Xen-devel] [PATCH] x86/msr: Virtualise MSR_PLATFORM_ID properly
From: Andrew Cooper @ 2020-02-14 19:55 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich, Roger Pau Monné
This is an Intel-only, read-only MSR related to microcode loading. Expose it
in similar circumstances as the PATCHLEVEL MSR.
This should have been alongside c/s 013896cb8b2 "x86/msr: Fix handling of
MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV"
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
Turns out I wrote this nearly a year ago and didn't send it. It obviously got
dropped in the leadup to MDS.
---
xen/arch/x86/msr.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 785574de67..1cea777680 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -143,6 +143,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
/* Not offered to guests. */
goto gp_fault;
+ case MSR_IA32_PLATFORM_ID:
+ if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
+ !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
+ goto gp_fault;
+ rdmsrl(MSR_IA32_PLATFORM_ID, *val);
+ break;
+
case MSR_AMD_PATCHLEVEL:
BUILD_BUG_ON(MSR_IA32_UCODE_REV != MSR_AMD_PATCHLEVEL);
/*
@@ -275,6 +282,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
{
uint64_t rsvd;
+ case MSR_IA32_PLATFORM_ID:
case MSR_INTEL_CORE_THREAD_COUNT:
case MSR_INTEL_PLATFORM_INFO:
case MSR_ARCH_CAPABILITIES:
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH userspace v2] libsepol: cache ebitmap cardinality value
From: Stephen Smalley @ 2020-02-14 19:57 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: SElinux list, James Carter
In-Reply-To: <CAFqZXNtpqOszQ5a2s86TTHtQGK_c+vqmtaRPBv04+vFAqExEmg@mail.gmail.com>
On 2/14/20 2:51 PM, Ondrej Mosnacek wrote:
> On Fri, Feb 14, 2020 at 6:37 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 2/13/20 8:39 AM, Ondrej Mosnacek wrote:
>>> According to profiling of semodule -BN, ebitmap_cardinality() is called
>>> quite often and contributes a lot to the total runtime. Cache its result
>>> in the ebitmap struct to reduce this overhead. The cached value is
>>> invalidated on most modifying operations, but ebitmap_cardinality() is
>>> usually called once the ebitmap doesn't change any more.
>>>
>>> After this patch, the time to do 'semodule -BN' on Fedora Rawhide has
>>> decreased from ~14.6s to ~12.4s (2.2s saved).
>>>
>>> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
>>
>> This seems fine but I was wondering how many of the callers of
>> ebitmap_cardinality() actually need anything more than ebitmap_length()?
>
> The caller that calls it the most (>99%) during a 'semodule -B' is
> __cil_should_expand_attribute(), which logically needs the actual
> cardinality. It might be possible to cache the decision directly in
> 'struct cil_typeattribute', but I don't know the CIL code well enough
> to attempt that...
That's fine - I'm ok with the patch itself. I just happened to notice
that there appear to be quite a few callers elsewhere in libsepol that
only seem to care whether the result is zero or non-zero, which
seemingly would be just as happy using ebitmap_length().
^ permalink raw reply
* [meta-python][PATCH] python3-can: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 19:56 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../recipes-devtools/python/python-can.inc | 18 ------------------
.../python/python3-can_3.3.2.bb | 17 ++++++++++++++++-
2 files changed, 16 insertions(+), 19 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-can.inc
diff --git a/meta-python/recipes-devtools/python/python-can.inc b/meta-python/recipes-devtools/python/python-can.inc
deleted file mode 100644
index 7d0100d7d7..0000000000
--- a/meta-python/recipes-devtools/python/python-can.inc
+++ /dev/null
@@ -1,18 +0,0 @@
-SUMMARY = "Controller Area Network (CAN) interface module for Python"
-SECTION = "devel/python"
-LICENSE = "LGPLv3"
-LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=e6a600fd5e1d9cbde2d983680233ad02"
-
-SRC_URI[md5sum] = "b724553a330478270267380b4888a18e"
-SRC_URI[sha256sum] = "5fefb5c1e7e7f07faefc02c6eac79f9b58376f007048a04d8e7f325d48ec6b2e"
-
-PYPI_PACKAGE="python-can"
-
-RDEPENDS_${PN}_class-target += "\
- ${PYTHON_PN}-ctypes \
- ${PYTHON_PN}-logging \
- ${PYTHON_PN}-misc \
- ${PYTHON_PN}-netserver \
- ${PYTHON_PN}-sqlite3 \
- ${PYTHON_PN}-wrapt \
-"
diff --git a/meta-python/recipes-devtools/python/python3-can_3.3.2.bb b/meta-python/recipes-devtools/python/python3-can_3.3.2.bb
index aaa9e811ce..4597795d50 100644
--- a/meta-python/recipes-devtools/python/python3-can_3.3.2.bb
+++ b/meta-python/recipes-devtools/python/python3-can_3.3.2.bb
@@ -1,7 +1,22 @@
-require python-can.inc
+SUMMARY = "Controller Area Network (CAN) interface module for Python"
+SECTION = "devel/python"
+LICENSE = "LGPLv3"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=e6a600fd5e1d9cbde2d983680233ad02"
+
+SRC_URI[md5sum] = "b724553a330478270267380b4888a18e"
+SRC_URI[sha256sum] = "5fefb5c1e7e7f07faefc02c6eac79f9b58376f007048a04d8e7f325d48ec6b2e"
+
+PYPI_PACKAGE="python-can"
+
inherit pypi setuptools3
RDEPENDS_${PN}_class-target += "\
+ ${PYTHON_PN}-ctypes \
${PYTHON_PN}-codecs \
${PYTHON_PN}-compression \
+ ${PYTHON_PN}-logging \
+ ${PYTHON_PN}-misc \
+ ${PYTHON_PN}-netserver \
+ ${PYTHON_PN}-sqlite3 \
+ ${PYTHON_PN}-wrapt \
"
--
2.17.1
^ permalink raw reply related
* Re: [RFC patch 14/19] bpf: Use migrate_disable() in hashtab code
From: Thomas Gleixner @ 2020-02-14 19:56 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: LKML, David Miller, bpf, netdev, Alexei Starovoitov,
Daniel Borkmann, Sebastian Sewior, Peter Zijlstra, Clark Williams,
Steven Rostedt, Juri Lelli, Ingo Molnar
In-Reply-To: <20200214191126.lbiusetaxecdl3of@localhost>
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
> On 14-Feb-2020 02:39:31 PM, Thomas Gleixner wrote:
>> Replace the preempt_disable/enable() pairs with migrate_disable/enable()
>> pairs to prepare BPF to work on PREEMPT_RT enabled kernels. On a non-RT
>> kernel this maps to preempt_disable/enable(), i.e. no functional change.
...
> Having all those events randomly and silently discarded might be quite
> unexpected from a user standpoint. This turns the deadlock prevention
> mechanism into a random tracepoint-dropping facility, which is
> unsettling.
Well, it randomly drops events which might be unrelated to the syscall
target today already, this will just drop some more. Shrug.
> One alternative approach we could consider to solve this is to make
> this deadlock prevention nesting counter per-thread rather than
> per-cpu.
That should work both on !RT and RT.
> Also, I don't think using __this_cpu_inc() without preempt-disable or
> irq off is safe. You'll probably want to move to this_cpu_inc/dec
> instead, which can be heavier on some architectures.
Good catch.
Thanks,
tglx
^ permalink raw reply
* [Buildroot] [PATCH] core: fix packages-file-list.txt after an incremental build
From: Thomas De Schampheleire @ 2020-02-14 19:57 UTC (permalink / raw)
To: buildroot
From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
The package instrumentation step 'step_pkg_size' is populating the files:
output/build/packages-file-list.txt
output/build/packages-file-list-staging.txt
output/build/packages-file-list-host.txt
by comparing the list of files before and after installation of a package,
with some clever tricks to detect changes to existing files etc.
As an optimization, instead of gathering this list before and after each
package, where the 'after-state' of one package is the same as the
'before-state' of the next package, only the 'after-state' is used and
is shared between packages.
This works fine, except at the end of the build, as explained next.
In the target-finalize step, many files will be touched. For example, files
like /etc/hosts, /etc/os-release, but also all object files that are
stripped, and all files touched by post-build scripts or created by rootfs
overlays. This means that the 'after-state' of the last package does not
reflect the actual situation after target-finalize is run.
For a single complete build this poses no problem. But, if one incrementally
rebuilds a package after the initial build, e.g. with 'make foo-rebuild',
then all changes that happened in target-finalize at the end of the initial
build (the 'after-state' of the last package built) will be detected as
changes caused by the rebuild of package foo. As a result, all these files
will incorrectly be treated as 'owned' by package foo.
Correct this situation by capturing a new state at the end of
target-finalize, so that the 'before-state' of an incremental build will be
correct.
Note: the reasoning above talks about packages-file-list.txt and
target-finalize, but also applies to
packages-file-list-staging.txt/staging-finalize and
packages-file-list-host.txt/host-finalize.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
---
Makefile | 10 ++++++++++
package/pkg-generic.mk | 23 ++++++++++++++++++-----
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index a52f1c75fd..af24630d2f 100644
--- a/Makefile
+++ b/Makefile
@@ -801,6 +801,16 @@ endif # merged /usr
touch $(TARGET_DIR)/usr
+# AFTER ALL FILE-CHANGING ACTIONS:
+# Update timestamps in internal file list to fix attribution of files
+# to packages on subsequent builds
+ $(call step_pkg_size_file_list,$(TARGET_DIR))
+ $(call step_pkg_size_finalize)
+ $(call step_pkg_size_file_list,$(STAGING_DIR),-staging)
+ $(call step_pkg_size_finalize,-staging)
+ $(call step_pkg_size_file_list,$(HOST_DIR),-host)
+ $(call step_pkg_size_finalize,-host)
+
.PHONY: target-post-image
target-post-image: $(TARGETS_ROOTFS) target-finalize staging-finalize
@rm -f $(ROOTFS_COMMON_TAR)
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 268d999efb..2f11e3903f 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -57,6 +57,22 @@ GLOBAL_INSTRUMENTATION_HOOKS += step_time
# Hooks to collect statistics about installed files
+# Helper function to create the file list -- also used from target-finalize
+# $(1): base directory to search in
+# $(2): suffix of file (optional)
+define step_pkg_size_file_list
+ cd $(1); \
+ LC_ALL=C find . \( -type f -o -type l \) -printf '%T@:%i:%#m:%y:%s,%p\n' \
+ | LC_ALL=C sort > $(BUILD_DIR)/.files-list$(2).new
+endef
+# Helper function to mark the latest file list as the reference for next
+# iteration -- also used from target-finalize
+# $(1): suffix of file (optional)
+define step_pkg_size_finalize
+ mv $(BUILD_DIR)/.files-list$(1).new \
+ $(BUILD_DIR)/.files-list$(1).stat
+endef
+
# The suffix is typically empty for the target variant, for legacy backward
# compatibility.
# $(1): package name
@@ -66,9 +82,7 @@ define step_pkg_size_inner
@touch $(BUILD_DIR)/.files-list$(3).stat
@touch $(BUILD_DIR)/packages-file-list$(3).txt
$(SED) '/^$(1),/d' $(BUILD_DIR)/packages-file-list$(3).txt
- cd $(2); \
- LC_ALL=C find . \( -type f -o -type l \) -printf '%T@:%i:%#m:%y:%s,%p\n' \
- | LC_ALL=C sort > $(BUILD_DIR)/.files-list$(3).new
+ $(call step_pkg_size_file_list,$(2),$(3))
LC_ALL=C comm -13 \
$(BUILD_DIR)/.files-list$(3).stat \
$(BUILD_DIR)/.files-list$(3).new \
@@ -76,8 +90,7 @@ define step_pkg_size_inner
sed -r -e 's/^[^,]+/$(1)/' \
$($(PKG)_BUILDDIR)/.files-list$(3).txt \
>> $(BUILD_DIR)/packages-file-list$(3).txt
- mv $(BUILD_DIR)/.files-list$(3).new \
- $(BUILD_DIR)/.files-list$(3).stat
+ $(call step_pkg_size_finalize,$(3))
endef
define step_pkg_size
--
2.24.1
^ permalink raw reply related
* Redfish message registries, plus translation
From: Matt Spinler @ 2020-02-14 19:57 UTC (permalink / raw)
To: James Feist, openbmc
Hi James,
It's looking like in our future we will have to provide:
1) Redfish logs using multiple message registries that probably can't be
hardcoded into hpp files and checked in.
- For example, a registry for our host firmware and hypervisor errors,
as our BMC handles displaying logs for them, that we would pick up
during our build process.
and
2) Message registry text in multiple languages
Those being my goals, I have a few questions:
In general, is the multi-language strategy to just provide a standalone
registry array for each language which the code then selects based on the
Language property?
To support both of the above, would you be open to having functionality
added
to read in registries from data files, including based on language? Or,
would you
have any other ideas for how to support these items?
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.