Hello:
This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko :
On Thu, 30 Jan 2025 15:33:45 -0700 you wrote:
> Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
> libraries"), only statically linking test_progs is supported. However,
> some d
On Thu, Jan 30, 2025 at 2:34 PM Daniel Xu wrote:
>
> Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
> libraries"), only statically linking test_progs is supported. However,
> some distros only provide a dynamically linkable LLVM.
>
> This commit add
On 2/1/25 12:23 AM, Daniel Xu wrote:
Hi Yonghong,
On Thu, Jan 30, 2025 at 10:28:11PM -0800, Yonghong Song wrote:
On 1/30/25 2:33 PM, Daniel Xu wrote:
Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
libraries"), only statically linking test_progs is supporte
Hi Yonghong,
On Thu, Jan 30, 2025 at 10:28:11PM -0800, Yonghong Song wrote:
>
>
>
> On 1/30/25 2:33 PM, Daniel Xu wrote:
> > Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
> > libraries"), only statically linking test_progs is support
On 1/30/25 2:33 PM, Daniel Xu wrote:
Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
libraries"), only statically linking test_progs is supported. However,
some distros only provide a dynamically linkable LLVM.
This commit adds a fallback for dynamically linki
On 1/30/25 2:33 PM, Daniel Xu wrote:
Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
libraries"), only statically linking test_progs is supported. However,
some distros only provide a dynamically linkable LLVM.
This commit adds a fallback for dynamically linki
On Thu, 2025-01-30 at 15:33 -0700, Daniel Xu wrote:
> Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
> libraries"), only statically linking test_progs is supported. However,
> some distros only provide a dynamically linkable LLVM.
>
> This c
Since 67ab80a01886 ("selftests/bpf: Prefer static linking for LLVM
libraries"), only statically linking test_progs is supported. However,
some distros only provide a dynamically linkable LLVM.
This commit adds a fallback for dynamically linking LLVM if static
linking is not availabl
On Wed, Jan 15, 2025 at 03:54:07PM +0100, Mickaël Salaün wrote:
> Old toolchains require explicit -lpthread (e.g. on Debian 11).
>
> Cc: Günther Noack
> Cc: Nathan Chancellor
> Cc: Tahera Fahimi
> Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads")
> Signed-off-by: Micka
Old toolchains require explicit -lpthread (e.g. on Debian 11).
Cc: Günther Noack
Cc: Nathan Chancellor
Cc: Tahera Fahimi
Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads")
Signed-off-by: Mickaël Salaün
---
tools/testing/selftests/landlock/Makefile | 4 ++--
1 file cha
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
Changes since v2:
- 1st arg to generate_builtin_ranges.awk is now modules.builtin.modinfo
- Use $(real-prereqs) rather than $(filter-out ...)
---
scripts/Makefile.vmlinux | 16
1 file changed, 16 insertions(+)
diff --g
On Sun, May 12, 2024 at 7:44 AM Kris Van Hees wrote:
>
> Signed-off-by: Kris Van Hees
> Reviewed-by: Nick Alcock
> ---
> Changes since v1:
> - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES
> ---
> scripts/Makefile.vmlinux | 17 +
> 1 file changed, 17 insertions(
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
Changes since v1:
- Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES
---
scripts/Makefile.vmlinux | 17 +
1 file changed, 17 insertions(+)
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
ind
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
scripts/Makefile.vmlinux | 17 +
1 file changed, 17 insertions(+)
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index c9f3e03124d7..c23d40b023ff 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makef
Hi,
These are the remaining four patches of the series, now rebased on top
of the latest usb-next. No other changes.
v5 cover letter:
I have to use IS_REACHABLE() instead of IS_ENABLED() also in
include/linux/usb.h. Otherwise compilation will fail if the Type-C
class is build-in while USB is a
Hi,
I have to use IS_REACHABLE() instead of IS_ENABLED() also in
include/linux/usb.h. Otherwise compilation will fail if the Type-C
class is build-in while USB is a module.
I'm sorry for re-sending these so fast, immediately after v4. Normally
I would wait, but I'll be taking a short vacation sta
On Thu, Apr 01, 2021 at 09:53:41AM +0300, Heikki Krogerus wrote:
> Hi,
>
> One more version. I used #ifdef when I should have used #if
> IS_DEFINED(). Thanks Guenter for pointing that out.
>
> I'm sending this version right away because of the holidays. I'm not
> changing anything else except tha
Hi,
One more version. I used #ifdef when I should have used #if
IS_DEFINED(). Thanks Guenter for pointing that out.
I'm sending this version right away because of the holidays. I'm not
changing anything else except that one fix.
v3: cover letter:
Third version: ifdefs now in the header files a
Hi,
Third version: ifdefs now in the header files as they should be.
v2 cover letter:
This is the second version of this series. The "Iterator for ports"
patch is now moved to the end of the series (5/6).
I'm now using usb_for_each_dev() in usb_for_each_port like Alan
suggested, and I'm now us
Hi,
This is the second version of this series. The "Iterator for ports"
patch is now moved to the end of the series (5/6).
I'm now using usb_for_each_dev() in usb_for_each_port like Alan
suggested, and I'm now using usb_port_peer_mutex to lock the ports
while we're dealing with them in __each_hub
Hi,
Adding a simple function typec_link_port() that can be used to create
a symlink "connector" that points to the USB Type-C connector of a
port. It is used with USB ports initially, but hopefully later also
with other things like DisplayPorts.
Being able to see which connector is connected to a
From: Paul Cercueil
Date: Sun, 21 Mar 2021 13:18:05 +
> LLVM's ld.lld chokes on the 64-bit sign-extended load addresses. Use
> 32-bit addresses if the linker is LLVM's ld.lld.
>
> Signed-off-by: Paul Cercueil
> ---
> arch/mips/generic/Platform | 4 ++--
> 1 file changed, 2 insertions(+), 2
LLVM's ld.lld chokes on the 64-bit sign-extended load addresses. Use
32-bit addresses if the linker is LLVM's ld.lld.
Signed-off-by: Paul Cercueil
---
arch/mips/generic/Platform | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/generic/Platform b/arch/mips/generic
Hello!
On Fri, 12 Feb 2021 at 01:44, Rolf Eike Beer wrote:
>
> Am Donnerstag, 11. Februar 2021, 11:29:33 CET schrieb Rolf Eike Beer:
>
> > I'm just guessing, but your build error looks like you are also
> > cross-building the tools, which is wrong. You want them to be host-tools.
> > So don't ex
t approach is.
>
>
>
> Basically, there are two ways to link libraries
> in non-standard paths.
>
>
>
> [1] Give linker flags via HOSTLDFLAGS
>
>This is documented in Documentation/kbuild/kbuild.rst
>
>HOSTLDFLAGS
>---
>Additio
Am Donnerstag, 11. Februar 2021, 11:29:33 CET schrieb Rolf Eike Beer:
> I'm just guessing, but your build error looks like you are also
> cross-building the tools, which is wrong. You want them to be host-tools.
> So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target
> libraries
Am Dienstag, 9. Februar 2021, 09:44:33 CET schrieb Rolf Eike Beer:
> Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz:
> > When compiling under OpenEmbedded, the following error is seen
> >
> > as of recently:
> > /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
Am Dienstag, 9. Februar 2021, 09:44:33 CET schrieb Rolf Eike Beer:
> Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz:
> > When compiling under OpenEmbedded, the following error is seen
> >
> > as of recently:
> > /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
pkg-config to
> locate libcrypto") now calls for `pkg-config --libs libcrypto`
> and inserts that into the Makefile rules as LDLIBS when
> building extract-cert.c.
>
> The problem is that --libs will include both -l and -L, which
> will be out of order when compiling/linking
Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz:
> When compiling under OpenEmbedded, the following error is seen
> as of recently:
>
> /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
> /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a
> i
e rules as LDLIBS when
building extract-cert.c.
The problem is that --libs will include both -l and -L, which
will be out of order when compiling/linking.
This (very ugly) command is what's produced with OpenEmbedded:
gcc -Wp,-MMD,scripts/.extract-cert.d -Wall -Wmissing-prototypes
-Wst
From: Ulf Hansson
commit d7fb9c24209556478e65211d7a1f056f2d43cceb upstream.
The implementation of sdhci_pltfm_suspend() is only available when
CONFIG_PM_SLEEP is set, which triggers a linking error:
"undefined symbol: sdhci_pltfm_suspend" when building sdhci-brcmstb.c.
F
On Sat, Jan 30, 2021 at 02:55:38PM -0800, Florian Fainelli wrote:
> It is currently possible to build CONFIG_HW_RANDOM_PPC4XX=y with
> CONFIG_HW_RANDOM=m which would lead to the inability of linking with
> devm_hwrng_{register,unregister}. We cannot have the framework modular
> and the
It is currently possible to build CONFIG_HW_RANDOM_PPC4XX=y with
CONFIG_HW_RANDOM=m which would lead to the inability of linking with
devm_hwrng_{register,unregister}. We cannot have the framework modular
and the consumer of that framework built-in, so make that dependency
explicit.
Reported-by
drivers.
This patch allows lazy-linking of the required-opps. The OPP tables for
which the required-opp-tables aren't available at the time of their
initialization, are added to a special list of OPP tables:
lazy_opp_tables. Later on, whenever a new OPP table is registered with
the OPP cor
On Thu, Jan 28, 2021 at 12:13 PM Viresh Kumar wrote:
>
> On 27-01-21, 22:40, Hsin-Yi Wang wrote:
> > Hi Viresh,
> >
> > I tested this patch with devfreq passive governor[1] and mt8183
> > cci[2]. It's also working as expected.
>
> I hope I can add your Tested-by for the patch then, right ?
>
Yes,
On 27-01-21, 22:40, Hsin-Yi Wang wrote:
> Hi Viresh,
>
> I tested this patch with devfreq passive governor[1] and mt8183
> cci[2]. It's also working as expected.
I hope I can add your Tested-by for the patch then, right ?
> [1]
> https://patchwork.kernel.org/project/linux-pm/cover/2019072401422
return;
-
mutex_lock(&opp_table_lock);
Thanks.
Hsin-Yi
> -8<-
> Subject: [PATCH] opp: Allow lazy-linking of required-opps
>
> The OPP core currently requires the required opp tables to be available
> before the
H] opp: Allow lazy-linking of required-opps
The OPP core currently requires the required opp tables to be available
before the dependent OPP table is added, as it needs to create links
from the dependent OPP table to the required ones. This may not be
convenient for all the platforms though, as this re
On Sun, Jan 17, 2021 at 11:40 PM Hsin-Yi Wang wrote:
>
> On Mon, Jan 18, 2021 at 3:34 PM Viresh Kumar wrote:
> >
> > On 18-01-21, 15:21, Hsin-Yi Wang wrote:
> > > Do you still have plans to push this? I've tested on mt8183 cci with:
> >
> > I was never able to get Saravana to test this, if you ar
On Mon, Jan 18, 2021 at 3:34 PM Viresh Kumar wrote:
>
> On 18-01-21, 15:21, Hsin-Yi Wang wrote:
> > Do you still have plans to push this? I've tested on mt8183 cci with:
>
> I was never able to get Saravana to test this, if you are interested
> in this stuff then I can rebase this and resend and w
On 18-01-21, 15:21, Hsin-Yi Wang wrote:
> Do you still have plans to push this? I've tested on mt8183 cci with:
I was never able to get Saravana to test this, if you are interested
in this stuff then I can rebase this and resend and we can see if it
works.
--
viresh
you still have plans to push this? I've tested on mt8183 cci with:
1. [v4,0/5] Add required-opps support to devfreq passive gov
(https://patchwork.kernel.org/project/linux-pm/cover/20190724014222.110767-1-sarava...@google.com/):
patch 2, 4, 5
2. opp: Allow lazy-linking of required-opps
(htt
On Mon, 28 Dec 2020 14:46:07 +
Nícolas F. R. A. Prado wrote:
> During the process of converting the documentation to reST, some links
> were converted using the following wrong syntax (and sometimes using %20
> instead of spaces):
>
>`Display text <#section-name-in-html>`__
>
> This syn
Em Mon, 28 Dec 2020 14:46:07 +
Nícolas F. R. A. Prado escreveu:
> During the process of converting the documentation to reST, some links
> were converted using the following wrong syntax (and sometimes using %20
> instead of spaces):
>
>`Display text <#section-name-in-html>`__
>
> This
During the process of converting the documentation to reST, some links
were converted using the following wrong syntax (and sometimes using %20
instead of spaces):
`Display text <#section-name-in-html>`__
This syntax isn't valid according to the docutils' spec [1], but more
importantly, it is
On Sun Dec 27, 2020 at 6:59 AM -03, Mauro Carvalho Chehab wrote:
> Well, docutils define two types of references at:
>
> https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#reference-names
>
> The first one are "simple reference names", defined as:
>
> ``Simple reference names are si
Em Sat, 26 Dec 2020 13:18:58 +
Nícolas F. R. A. Prado escreveu:
> During the process of converting the documentation to reST, some links
> were converted using the following wrong syntax (and sometimes using %20
> instead of spaces):
>
The patch itself looks ok, although the description has
During the process of converting the documentation to reST, some links
were converted using the following wrong syntax (and sometimes using %20
instead of spaces):
`Display text <#section-name-in-html>`__
This syntax can work in html, but isn't the one described in docutils,
and it also doesn'
configuration is triggered from within Linux using
enable_slot().
The PF/VF linking step and setting of pdev->is_virtfn introduced with
commit e5794cf1a270 ("s390/pci: create links between PFs and VFs") was
only triggered for the second case, which is where VFs created through
sriov_n
From: Matteo Croce
commit fd49e03280e596e54edb93a91bc96170f8e97e4a upstream.
When building a kernel with CONFIG_PSTORE=y and CONFIG_CRYPTO not set,
a build error happens:
ld: fs/pstore/platform.o: in function `pstore_dump':
platform.c:(.text+0x3f9): undefined reference to `crypto_comp_c
From: Matteo Croce
commit fd49e03280e596e54edb93a91bc96170f8e97e4a upstream.
When building a kernel with CONFIG_PSTORE=y and CONFIG_CRYPTO not set,
a build error happens:
ld: fs/pstore/platform.o: in function `pstore_dump':
platform.c:(.text+0x3f9): undefined reference to `crypto_comp_c
From: Matteo Croce
commit fd49e03280e596e54edb93a91bc96170f8e97e4a upstream.
When building a kernel with CONFIG_PSTORE=y and CONFIG_CRYPTO not set,
a build error happens:
ld: fs/pstore/platform.o: in function `pstore_dump':
platform.c:(.text+0x3f9): undefined reference to `crypto_comp_c
From: Matteo Croce
commit fd49e03280e596e54edb93a91bc96170f8e97e4a upstream.
When building a kernel with CONFIG_PSTORE=y and CONFIG_CRYPTO not set,
a build error happens:
ld: fs/pstore/platform.o: in function `pstore_dump':
platform.c:(.text+0x3f9): undefined reference to `crypto_comp_c
libc
> > implementations, which do not rely on NSS, such as musl.
> >
> > Allow static linking in this case.
> >
> > Signed-off-by: Ignat Korchagin
> > Reviewed-by: Brendan Higgins
> > Tested-by: Brendan Higgins
> > ---
> > arch/um/Kconfig
It is possible to produce a statically linked UML binary with UML_NET_VECTOR,
UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc
implementations, which do not rely on NSS, such as musl.
Allow static linking in this case.
Signed-off-by: Ignat Korchagin
Reviewed-by: Brendan
oduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS
um: some fixes to build UML with musl
um: allow static linking for non-glibc implementations
arch/um/Kconfig | 6 +++---
arch/um/drivers/Kconfig | 6 +++---
arch/um/drivers/daemon_user.c | 1 +
arch/um/drivers/pcap_user.c
On Wed, 2020-07-15 at 21:11 +0100, Ignat Korchagin wrote:
> It is possible to produce a statically linked UML binary with UML_NET_VECTOR,
> UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc
> implementations, which do not rely on NSS, such as musl.
>
> Allow st
It is possible to produce a statically linked UML binary with UML_NET_VECTOR,
UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc
implementations, which do not rely on NSS, such as musl.
Allow static linking in this case.
Signed-off-by: Ignat Korchagin
Reviewed-by: Brendan
03689-1-ig...@cloudflare.com/
Ignat Korchagin (3):
um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS
um: some fixes to build UML with musl
um: allow static linking for non-glibc implementations
arch/um/Kconfig | 5 +
arch/um/drivers/Kconfig | 3 ---
arch/
ative libc
> > implementations, which do not rely on NSS, such as musl.
> >
> > Allow static linking in this case.
> >
> > Signed-off-by: Ignat Korchagin
>
> One minor issue below. Other than that:
>
> Reviewed-by: Brendan Higgins
>
> > ---
>
On Sat, Jul 4, 2020 at 1:52 AM Ignat Korchagin wrote:
>
> It is possible to produce a statically linked UML binary with UML_NET_VECTOR,
> UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc
> implementations, which do not rely on NSS, such as musl.
>
> Allow stat
on/module being
> included and not related to musl/glibc.
>
> [1]:
> https://patchwork.ozlabs.org/project/linux-um/patch/20200624212319.403689-1-ig...@cloudflare.com/
>
> Ignat Korchagin (3):
> um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS
> um: some fixes to bu
在 2020/7/11 14:37, Zhihao Cheng 写道:
在 2020/7/7 20:47, Richard Weinberger 写道:
- Ursprüngliche Mail -
Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix
O_TMPFILE corner case in ubifs_link()") wanted to fix.
I think orphan area is used to remind filesystem don't forget to
de
在 2020/7/11 14:37, Zhihao Cheng 写道:
在 2020/7/7 20:47, Richard Weinberger 写道:
- Ursprüngliche Mail -
Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix
O_TMPFILE corner case in ubifs_link()") wanted to fix.
I think orphan area is used to remind filesystem don't forget to
de
在 2020/7/7 20:47, Richard Weinberger 写道:
- Ursprüngliche Mail -
Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix
O_TMPFILE corner case in ubifs_link()") wanted to fix.
I think orphan area is used to remind filesystem don't forget to delete
inodes (whose nlink is 0) in next
- Ursprüngliche Mail -
>>> Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix
>>> O_TMPFILE corner case in ubifs_link()") wanted to fix.
>>> I think orphan area is used to remind filesystem don't forget to delete
>>> inodes (whose nlink is 0) in next unclean rebooting. Generall
在 2020/7/7 20:09, Richard Weinberger 写道:
- Ursprüngliche Mail -
Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix
O_TMPFILE corner case in ubifs_link()") wanted to fix.
I think orphan area is used to remind filesystem don't forget to delete
inodes (whose nlink is 0) in next
- Ursprüngliche Mail -
> Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix
> O_TMPFILE corner case in ubifs_link()") wanted to fix.
> I think orphan area is used to remind filesystem don't forget to delete
> inodes (whose nlink is 0) in next unclean rebooting. Generally, the f
在 2020/7/7 19:26, Richard Weinberger 写道:
On Wed, Jul 1, 2020 at 1:28 PM Zhihao Cheng wrote:
There is a potential space leak problem while linking tmpfile, in which
case, inode node (with nlink=0) is valid in tnc (on flash), which leads
to space leak. Meanwhile, the corresponding data nodes
On Wed, Jul 1, 2020 at 1:28 PM Zhihao Cheng wrote:
>
> There is a potential space leak problem while linking tmpfile, in which
> case, inode node (with nlink=0) is valid in tnc (on flash), which leads
> to space leak. Meanwhile, the corresponding data nodes won't be release
It is possible to produce a statically linked UML binary with UML_NET_VECTOR,
UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc
implementations, which do not rely on NSS, such as musl.
Allow static linking in this case.
Signed-off-by: Ignat Korchagin
---
arch/um/Kconfig
/patch/20200624212319.403689-1-ig...@cloudflare.com/
Ignat Korchagin (3):
um/kconfig: introduce CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS
um: some fixes to build UML with musl
um: allow static linking for non-glibc implementations
arch/um/Kconfig | 2 +-
arch/um/drivers/Kconfig
There is a potential space leak problem while linking tmpfile, in which
case, inode node (with nlink=0) is valid in tnc (on flash), which leads
to space leak. Meanwhile, the corresponding data nodes won't be released
from tnc. For example, (A reproducer can be found in Link):
$ mount
There is a potential space leak problem while linking tmpfile, in which
case, inode node (with nlink=0) is valid in tnc (on flash), which leads
to space leak. Meanwhile, the corresponding data nodes won't be released
from tnc. For example, (A reproducer can be found in Link):
$ mount
From: Michał Mirosław
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c32
From: Michał Mirosław
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c32
From: Michał Mirosław
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c32
From: Michał Mirosław
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c32
From: Michał Mirosław
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c32
From: Michał Mirosław
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c32
From: Michał Mirosław
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c32
From: Kees Cook
[ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ]
When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
time collecting and writing the dwarf sections to the temporary output
files. kallsyms does not need this information, and leaving it off
halves
On Mon, 08 Jun 2020 18:50:39 +0200,
Michał Mirosław wrote:
>
> Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
> can't handle it. Fixed commit is not where bug was introduced, but
> changes the context significantly.
>
> Cc: sta...@vger.kernel.or
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
Signed-off-by: Michał M
On Mon, 08 Jun 2020 12:06:32 +0200,
Michał Mirosław wrote:
>
> Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
> can't handle it. Fixed commit is not where bug was introduced, but
> changes the context significantly.
>
> Cc: sta...@vger.kernel.or
Two patches fixing locking issues for SNDRV_PCM_IOCTL_LINK handling:
first adds a check preventing linking a stream to itself, second quiets
lockdep warning about nested locks.
Michał Mirosław (2):
ALSA: pcm: disallow linking stream to itself
ALSA: pcm: fix snd_pcm_link() lockdep splat
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
Signed-off-by:
From: Kees Cook
[ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ]
When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
time collecting and writing the dwarf sections to the temporary output
files. kallsyms does not need this information, and leaving it off
halves
From: Kees Cook
[ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ]
When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
time collecting and writing the dwarf sections to the temporary output
files. kallsyms does not need this information, and leaving it off
halves
Hello Kernel Hackers,
the following series enables PF-VF linking for architectures using the
pdev->no_vf_scan flag (currently just s390). This includes kernel internal
linking with pdev->physfn as well as creation of the relevant sysfs links.
The former are required for example by libv
On 5/6/2020 9:24 AM, Masahiro Yamada wrote:
>> To me this is a regression, as it used to work and now it does not, thus
>> we should be fixing it, any idea about how we go about it without doing
>> a plain revert?
>
>
> In fact, a patch exists.
>
> https://patchwork.kernel.org/patch/11318691/
tems from 4.9 to 5.4, we noticed that one of the
> >> kernel modules that we build, which is done by linking an object that we
> >> pre-compile out of Kbuild stopped working.
> >>
> >> I bisected it down to:
> >>
> >> commit 69ea912fda74a673d
On 5/6/2020 7:37 AM, Masahiro Yamada wrote:
> On Wed, May 6, 2020 at 1:45 PM Florian Fainelli wrote:
>>
>> Hi Masahiro, Michal,
>>
>> While updating our systems from 4.9 to 5.4, we noticed that one of the
>> kernel modules that we build, which is done by
Hello Kernel Hackers,
the following series enables PF-VF linking for architectures using the
pdev->no_vf_scan flag (currently just s390). This includes kernel internal
linking with pdev->physfn as well as creation of the relevant sysfs links.
The former are required for example by libv
On Wed, May 6, 2020 at 1:45 PM Florian Fainelli wrote:
>
> Hi Masahiro, Michal,
>
> While updating our systems from 4.9 to 5.4, we noticed that one of the
> kernel modules that we build, which is done by linking an object that we
> pre-compile out of Kbuild stopped working.
>
Hi Masahiro, Michal,
While updating our systems from 4.9 to 5.4, we noticed that one of the
kernel modules that we build, which is done by linking an object that we
pre-compile out of Kbuild stopped working.
I bisected it down to:
commit 69ea912fda74a673d330d23595385e5b73e3a2b9 (refs/bisect/bad
We currently read how sibling lane adapter ports relate each other from
DROM (Device ROM). If the two lane adapter ports go through the same
physical connector these lanes can then be bonded together. However,
some cases DROM does not provide this information or it is missing
completely (host route
bool "KVM Intel"
>
> Or even just
>
> bool "AMD"
> ...
> bool "Intel"
Ya.
> > endchoice
> >
> > The ends up looking like:
> >
> ><*> Kernel-based Virtual Machine (KVM) support
> &
endchoice
>
> The ends up looking like:
>
><*> Kernel-based Virtual Machine (KVM) support
>KVM built-in support (KVM Intel) --->
>-*- KVM for Intel processors support
On top of this, it's also nice to hide the KVM_INTEL/KVM_AMD prompts if
li
1 - 100 of 578 matches
Mail list logo
