* [PATCH/RFT 0/7] rsnd: add support for r8a77965
From: Simon Horman @ 2018-07-23 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1531856883-19645-1-git-send-email-ykaneko0929@gmail.com>
On Wed, Jul 18, 2018 at 04:47:56AM +0900, Yoshihiro Kaneko wrote:
> This series adds sound support for r8a77965 (R-Car M3-N).
> This series is based on the devel branch of Simon Horman's renesas tree.
>
> Hiroyuki Yokoyama (1):
> ASoC: rsnd: Document R-Car M3-N support
>
> Takeshi Kihara (6):
> arm64: dts: renesas: r8a77965: Add Audio-DMAC device nodes
> arm64: dts: renesas: r8a77965: Add Sound device node and SSI support
> arm64: dts: renesas: r8a77965: Add Sound SRC support
> arm64: dts: renesas: r8a77965: Add Sound DVC device nodes
> arm64: dts: renesas: r8a77965: Add Sound CTU support
> arm64: dts: renesas: r8a77965: Add Sound MIX support
>
> .../devicetree/bindings/sound/renesas,rsnd.txt | 1 +
> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 245 ++++++++++++++++++++-
Thanks Kaneko-san,
in general this series looks good, however, I would like to ask you to
squash all the dts patches (the patches by Kihara-san) into a single patch.
For many years now we have split patches up as this series does.
And no doubt that is why BPS team chose to split up the patches
that you have based this patchset on. However, we were recently
asked by the Olof Johansson to squash patches together to make
the high-level intent of patches clearer to him in his position
of ARM-SoC co-maintainer.
So while what you have done is correct, it is now the "old way".
Please squash the patches together as this is the "new way".
Thanks!
^ permalink raw reply
* RE: [PATCH] IB/mlx5: avoid binding a new mpi unit to the same devices repeatedly
From: Parav Pandit @ 2018-07-23 16:21 UTC (permalink / raw)
To: Qing Huang, Daniel Jurgens, Or Gerlitz
Cc: Linux Kernel, RDMA mailing list, Jason Gunthorpe, Doug Ledford,
Leon Romanovsky, gerald.gibson@oracle.com
In-Reply-To: <556984ea-c35f-197d-0e45-16272da3f604@oracle.com>
Hi Qing,
> -----Original Message-----
> From: Qing Huang [mailto:qing.huang@oracle.com]
> Sent: Monday, July 23, 2018 10:36 AM
> To: Daniel Jurgens <danielj@mellanox.com>; Or Gerlitz
> <gerlitz.or@gmail.com>; Parav Pandit <parav@mellanox.com>
> Cc: Linux Kernel <linux-kernel@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Jason Gunthorpe <jgg@ziepe.ca>; Doug Ledford
> <dledford@redhat.com>; Leon Romanovsky <leon@kernel.org>;
> gerald.gibson@oracle.com
> Subject: Re: [PATCH] IB/mlx5: avoid binding a new mpi unit to the same
> devices repeatedly
>
>
>
> On 7/15/2018 12:48 PM, Daniel Jurgens wrote:
> > On 7/14/2018 10:57 AM, Or Gerlitz wrote:
> >> On Sat, Jul 14, 2018 at 2:50 AM, Qing Huang <qing.huang@oracle.com>
> wrote:
> >>> When a CX5 device is configured in dual-port RoCE mode, after
> >>> creating many VFs against port 1, creating the same number of VFs
> >>> against port 2 will flood kernel/syslog with something like
> >>> "mlx5_*:mlx5_ib_bind_slave_port:4266:(pid 5269): port 2 already
> >>> affiliated."
> >>>
> >>> So basically, when traversing mlx5_ib_dev_list,
> >>> mlx5_ib_add_slave_port() shouldn't repeatedly attempt to bind the
> >>> new mpi data unit to every device on the list until it finds an unbound
> device.
> >> Daniel,
> >>
> >> What is mpi data unit?
> > It's a structure to keep track affiliated port info in dual port RoCE mode,
> mpi meaning multi-port info. Parav can review this it my absence, otherwise I
> can take a closer look when I return to the office.
> Hi Daniel/Parav,
>
> Have you got a chance to review this patch? Thanks!
Didn't have chance yet.
Will do this week.
^ permalink raw reply
* Re: [PATCH 1/2] ata: sata_rcar: Provide a short-hand for &pdev->dev
From: Tejun Heo @ 2018-07-23 15:19 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Wolfram Sang, linux-ide, linux-renesas-soc
In-Reply-To: <20180720122739.30056-2-geert+renesas@glider.be>
On Fri, Jul 20, 2018 at 02:27:38PM +0200, Geert Uytterhoeven wrote:
> No functional changes.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied 1-2 to libata/for-4.19.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 3/4] perf/x86/intel/ds: Handle PEBS overflow for fixed counters
From: Peter Zijlstra @ 2018-07-23 16:21 UTC (permalink / raw)
To: kan.liang
Cc: tglx, mingo, linux-kernel, acme, alexander.shishkin,
vincent.weaver, jolsa, ak
In-Reply-To: <20180723145944.GB2458@hirez.programming.kicks-ass.net>
On Mon, Jul 23, 2018 at 04:59:44PM +0200, Peter Zijlstra wrote:
> On Thu, Mar 08, 2018 at 06:15:41PM -0800, kan.liang@linux.intel.com wrote:
> > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > index ef47a418d819..86149b87cce8 100644
> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -2280,7 +2280,10 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
> > * counters from the GLOBAL_STATUS mask and we always process PEBS
> > * events via drain_pebs().
> > */
> > - status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
> > + if (x86_pmu.flags & PMU_FL_PEBS_ALL)
> > + status &= ~(cpuc->pebs_enabled & EXTENDED_PEBS_COUNTER_MASK);
> > + else
> > + status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
> >
> > /*
> > * PEBS overflow sets bit 62 in the global status register
>
> Doesn't this re-introduce the problem fixed in commit fd583ad1563be,
> where pebs_enabled:32-34 are PEBS Load Latency, instead of fixed
> counters?
Also, since they 'fixed' that conflict, the PEBS_ALL version could be:
state &= cpuc->pebs_enabled;
Right?
^ permalink raw reply
* Re: INFO: task hung in fuse_reverse_inval_entry
From: Dmitry Vyukov @ 2018-07-23 15:19 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: linux-fsdevel, LKML, syzkaller-bugs, syzbot
In-Reply-To: <CAJfpeguni8JReXKXU_yUFqBfHav1-JFHfHzhxc=kaXu3ME6Qsw@mail.gmail.com>
On Mon, Jul 23, 2018 at 5:09 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Mon, Jul 23, 2018 at 3:37 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Mon, Jul 23, 2018 at 3:05 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>>> Biggest conceptual problem: your definition of fuse-server is weak.
>>> Take the following example: process A is holding the fuse device fd
>>> and is forwarding requests and replies to/from process B via a pipe.
>>> So basically A is just a proxy that does nothing interesting, the
>>> "real" server is B. But according to your definition B is not a
>>> server, only A is.
>>
>> I proposed to abort fuse conn when all fuse device fd's are "killed"
>> (all processes having the fd opened are killed). So if _only_ process
>> B is killed, then, yes, it will still hang. However if A is killed or
>> both A and B (say, process group, everything inside of pid namespace,
>> etc) then the deadlock will be autoresolved without human
>> intervention.
>
> Okay, so you're saying:
>
> 1) when process gets SIGKILL and is uninterruptible sleep mark process as doomed
> 2) for a particular fuse instance find set of fuse device fd
> references that are in non-doomed tasks; if there are none then abort
> fuse instance
>
> Right?
Yes, something like this.
Perhaps checking for "uninterruptible sleep" is excessive. If it has
SIGKILL pending it's pretty much doomed already. This info should be
already available for tasks.
Not saying that it's better, but what I described was the other way
around: when a task killed it drops a reference to all opened fuse
fds, when the last fd is dropped, the connection can be aborted.
> The above is not an implementation proposal, just to get us on the
> same page regarding the concept.
>
>>> And this is just a simple example, parts of the server might be on
>>> different machines, etc... It's impossible to automatically detect if
>>> a process is acting as a fuse server or not.
>>
>> It does not seem we need the precise definition. If no one ever can
>> write anything into the fd, we can safely abort the connection (?).
>
> Seems to me so.
>
>> If
>> we don't, we can either get that the process exits normally and the
>> connection is doomed anyway, so no difference in behavior, or we can
>> get a deadlock.
>>
>>> We could let the fuse server itself notify the kernel that it's a fuse
>>> server. That might help in the cases where the deadlock is
>>> accidental, but obviously not in the case when done by a malicious
>>> agent. I'm not sure it's worth the effort. Also I have no idea how
>>> the respective maintainers would take the idea of "kill hooks"... It
>>> would probably be a lot of work for little gain.
>>
>> What looks wrong to me here is that fuse is only (?) subsystem in
>> kernel that stops SIGKILL from working and requires complex custom
>> dance performed by a human operator (which is not necessary there at
>> all). Say, if a process has opened a socket, whatever, I don't need to
>> locate and abort something in socketctl fs, just SIGKILL. If a
>> processes has opened a file, I don't need to locate the fd in /proc
>> and abort it, just SIGKILL. If a process has created an ipc object, I
>> don't need to do any special dance, just SIGKILL. fuse is somehow very
>> special, if we have more such cases, it definitely won't scale.
>> I understand that there can be implementation difficulties, but
>> fundamentally that's how things should work -- choose target
>> processes, kill, done, right?
>
> Yes, it would be nice.
>
> But I'm not sure it will fly due to implementation difficulties. It's
> definitely not a high prio feature currently for me, but I'll happily
> accept patches.
I see. Thanks for bearing with me.
^ permalink raw reply
* [PATCH] net: ethernet: fs-enet: Use generic CRC32 implementation
From: Krzysztof Kozlowski @ 2018-07-23 16:20 UTC (permalink / raw)
To: Pantelis Antoniou, David S. Miller, linuxppc-dev, netdev,
linux-kernel
Cc: Eric Biggers, Krzysztof Kozlowski
Use generic kernel CRC32 implementation because it:
1. Should be faster (uses lookup tables),
2. Removes duplicated CRC generation code,
3. Uses well-proven algorithm instead of coding it one more time.
Suggested-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on hardware.
---
drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c
index 1fc27c97e3b2..99fe2c210d0f 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c
@@ -18,6 +18,7 @@
#include <linux/string.h>
#include <linux/ptrace.h>
#include <linux/errno.h>
+#include <linux/crc32.h>
#include <linux/ioport.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
@@ -176,21 +177,10 @@ static void set_multicast_start(struct net_device *dev)
static void set_multicast_one(struct net_device *dev, const u8 *mac)
{
struct fs_enet_private *fep = netdev_priv(dev);
- int temp, hash_index, i, j;
+ int temp, hash_index;
u32 crc, csrVal;
- u8 byte, msb;
-
- crc = 0xffffffff;
- for (i = 0; i < 6; i++) {
- byte = mac[i];
- for (j = 0; j < 8; j++) {
- msb = crc >> 31;
- crc <<= 1;
- if (msb ^ (byte & 0x1))
- crc ^= FEC_CRC_POLY;
- byte >>= 1;
- }
- }
+
+ crc = ether_crc(6, mac);
temp = (crc & 0x3f) >> 1;
hash_index = ((temp & 0x01) << 4) |
--
2.14.1
^ permalink raw reply related
* [PATCH v3] net: ethernet: freescale: Use generic CRC32 implementation
From: Krzysztof Kozlowski @ 2018-07-23 16:19 UTC (permalink / raw)
To: Fugang Duan, David S. Miller, netdev, linux-kernel
Cc: Eric Biggers, Krzysztof Kozlowski
Use generic kernel CRC32 implementation because it:
1. Should be faster (uses lookup tables),
2. Removes duplicated CRC generation code,
3. Uses well-proven algorithm instead of coding it one more time.
Suggested-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v2:
1. Use ether_crc_le (suggested by David)
Changes since v1:
1. Fix missing header inclusion.
---
drivers/net/ethernet/freescale/fec_main.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index c729665107f5..98ad34192255 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -48,6 +48,7 @@
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/clk.h>
+#include <linux/crc32.h>
#include <linux/platform_device.h>
#include <linux/mdio.h>
#include <linux/phy.h>
@@ -2955,7 +2956,7 @@ static void set_multicast_list(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
struct netdev_hw_addr *ha;
- unsigned int i, bit, data, crc, tmp;
+ unsigned int crc, tmp;
unsigned char hash;
unsigned int hash_high = 0, hash_low = 0;
@@ -2983,15 +2984,7 @@ static void set_multicast_list(struct net_device *ndev)
/* Add the addresses in hash register */
netdev_for_each_mc_addr(ha, ndev) {
/* calculate crc32 value of mac address */
- crc = 0xffffffff;
-
- for (i = 0; i < ndev->addr_len; i++) {
- data = ha->addr[i];
- for (bit = 0; bit < 8; bit++, data >>= 1) {
- crc = (crc >> 1) ^
- (((crc ^ data) & 1) ? CRC32_POLY : 0);
- }
- }
+ crc = ether_crc_le(ndev->addr_len, ha->addr);
/* only upper 6 bits (FEC_HASH_BITS) are used
* which point to specific bit in the hash registers
--
2.14.1
^ permalink raw reply related
* Re: [PATCHv3 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
From: David Ahern @ 2018-07-23 15:17 UTC (permalink / raw)
To: Xin Long, network dev; +Cc: davem, Davide Caratti, idosch
In-Reply-To: <a3c46ade85539e450f037e62984f750c7d56084d.1532346504.git.lucien.xin@gmail.com>
On 7/23/18 5:51 AM, Xin Long wrote:
> +ping_ipv4()
> +{
> + sysctl_set net.ipv4.icmp_echo_ignore_broadcasts 0
> +
> + bc_forwarding_disable
> + ping_test_from $h1 198.51.100.255 192.0.2.1
> + ping_test_from $h1 198.51.200.255 192.0.2.1
> + ping_test_from $h1 192.0.2.255 192.0.2.1
> + ping_test_from $h1 255.255.255.255 192.0.2.1
> +
> + ping_test_from $h2 192.0.2.255 198.51.100.1
> + ping_test_from $h2 198.51.200.255 198.51.100.1
> + ping_test_from $h2 198.51.100.255 198.51.100.1
> + ping_test_from $h2 255.255.255.255 198.51.100.1
> + bc_forwarding_restore
> +
> + bc_forwarding_enable
> + ping_test_from $h1 198.51.100.255 198.51.100.2
> + ping_test_from $h1 198.51.200.255 198.51.200.2
> + ping_test_from $h1 192.0.2.255 192.0.2.1 1
> + ping_test_from $h1 255.255.255.255 192.0.2.1
> +
> + ping_test_from $h2 192.0.2.255 192.0.2.2
> + ping_test_from $h2 198.51.200.255 198.51.200.2
> + ping_test_from $h2 198.51.100.255 198.51.100.1 1
> + ping_test_from $h2 255.255.255.255 198.51.100.1
> + bc_forwarding_restore
> +
> + sysctl_restore net.ipv4.icmp_echo_ignore_broadcasts
You need a better description for each test. This output:
TEST: ping_test_from [PASS]
TEST: ping_test_from [PASS]
TEST: ping_test_from [PASS]
TEST: ping_test_from [PASS]
...
does not help in understanding which cases are working and which are not.
^ permalink raw reply
* Re: [PATCH] mtd: nand: fix spelling in driver api documentation
From: Boris Brezillon @ 2018-07-23 16:19 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Marcel Ziswiler, linux-mtd, Marcel Ziswiler, Gregory CLEMENT,
H Hartley Sweeten, linux-doc, linux-kernel, Krzysztof Kozlowski,
Vladimir Zapolskiy, Miquel Raynal
In-Reply-To: <20180723093924.04af0e2f@lwn.net>
Hi Jonathan,
On Mon, 23 Jul 2018 09:39:24 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> On Fri, 20 Jul 2018 09:53:33 +0200
> Marcel Ziswiler <marcel@ziswiler.com> wrote:
>
> > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > This fixes some spelling mistakes.
>
> So I hate to complain about a documentation improvement, but...
>
> >
> > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Documentation/driver-api/mtdnand.rst | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/driver-api/mtdnand.rst b/Documentation/driver-api/mtdnand.rst
> > index dcd63599f700..c55a6034c397 100644
> > --- a/Documentation/driver-api/mtdnand.rst
> > +++ b/Documentation/driver-api/mtdnand.rst
> > @@ -374,7 +374,7 @@ The nand driver supports three different types of hardware ECC.
> >
> > - NAND_ECC_HW8_512
> >
> > - Hardware ECC generator providing 6 bytes ECC per 512 byte.
> > + Hardware ECC generator providing 8 bytes ECC per 512 byte.
>
> That's not a spelling mistake, that's a factual change. I'll apply the
> patch since it appears to be correct, but will be tweaking the changelog.
I think Miquel had planned to apply this patch to the NAND tree, but we
don't seem to have conflicting changes on this file, so feel free to
take it in the doc tree.
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Regards,
Boris
^ permalink raw reply
* Re: [PATCH] mtd: nand: fix spelling in driver api documentation
From: Boris Brezillon @ 2018-07-23 16:19 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Marcel Ziswiler, linux-mtd, Marcel Ziswiler, Gregory CLEMENT,
H Hartley Sweeten, linux-doc, linux-kernel, Krzysztof Kozlowski,
Vladimir Zapolskiy, Miquel Raynal
In-Reply-To: <20180723093924.04af0e2f@lwn.net>
Hi Jonathan,
On Mon, 23 Jul 2018 09:39:24 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> On Fri, 20 Jul 2018 09:53:33 +0200
> Marcel Ziswiler <marcel@ziswiler.com> wrote:
>
> > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > This fixes some spelling mistakes.
>
> So I hate to complain about a documentation improvement, but...
>
> >
> > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Documentation/driver-api/mtdnand.rst | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/driver-api/mtdnand.rst b/Documentation/driver-api/mtdnand.rst
> > index dcd63599f700..c55a6034c397 100644
> > --- a/Documentation/driver-api/mtdnand.rst
> > +++ b/Documentation/driver-api/mtdnand.rst
> > @@ -374,7 +374,7 @@ The nand driver supports three different types of hardware ECC.
> >
> > - NAND_ECC_HW8_512
> >
> > - Hardware ECC generator providing 6 bytes ECC per 512 byte.
> > + Hardware ECC generator providing 8 bytes ECC per 512 byte.
>
> That's not a spelling mistake, that's a factual change. I'll apply the
> patch since it appears to be correct, but will be tweaking the changelog.
I think Miquel had planned to apply this patch to the NAND tree, but we
don't seem to have conflicting changes on this file, so feel free to
take it in the doc tree.
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Regards,
Boris
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] am654 changes for v4.19 merge window
From: Olof Johansson @ 2018-07-23 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723130620.qe5xbjcsl3yaawt6@kahuna>
On Mon, Jul 23, 2018 at 6:06 AM, Nishanth Menon <nm@ti.com> wrote:
> On 06:40-20180722, Tony Lindgren wrote:
>> * Olof Johansson <olof@lixom.net> [180721 22:28]:
>> > On Fri, Jul 20, 2018 at 11:05:16PM -0700, Tony Lindgren wrote:
>> > > From: "Tony Lindgren" <tony@atomide.com>
>> > >
>> > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>> > >
>> > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>> > >
>> > > are available in the Git repository at:
>> > >
>> > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/am654-for-v4.19-signed
>> > >
>> > > for you to fetch changes up to d0a064bec75e20a526c7bc0d626912f2660b6e81:
>> > >
>> > > arm64: dts: ti: Add support for AM654 EVM base board (2018-07-18 11:48:36 -0700)
>> > >
>> > > ----------------------------------------------------------------
>> > > TI AM654 support for v4.19 merge window
>> > >
>> > > This branch adds initial support for new Texas Instruments AM654
>> > > quad core A53 ARMv8 SoC. It's the first device for TI K3 multicore SoC
>> > > architecture.
>> > >
>> > > Initially only basic devices are configured, support for more devices
>> > > will follow later on. And many of the internal devices familiar from
>> > > earlier TI SoCs should work with existing kernel device drivers.
>> >
>> > I squinted a bit and merged this into next/dt. Might have been a bit cleaner to
>> > split it in a SoC and a DT branch, but either way it's pretty small changes.
>>
>> OK yeah I could have done a separate branch for Kconfig changes.
>
> Thanks a bunch.
>
>>
>> > Should the support be enabled in arm64's defconfig?
>>
>> Yes it should, Nishanth, care to check Linux next once your
>> patches are merged and send a patch for that?
>
> Just checked next-20180723 - Seems to work for me[1]. I was holding off
> the defconfig update to get the driver changes for base to get in. I
> will send a ping on those and if i dont see any response, will send a
> defconfig update by tomorrow.
Feel free to send a patch right after -rc1 to turn on new
options/drivers that have landed in the merge window. If it's just a
few lines we can apply and merge it at that time.
-Olof
^ permalink raw reply
* Re: Very slow SYS_io_destroy()
From: Alex Richman @ 2018-07-23 15:16 UTC (permalink / raw)
To: Jeff Moyer; +Cc: linux-kernel, linux-fsdevel
In-Reply-To: <x49fu0a3rz1.fsf@segfault.boston.devel.redhat.com>
Thanks for the response. I'm running 4.4.123-1 from Gentoo. It also
happens on 4.4.87-r1.
Cheers,
- Alex.
On 23/07/18 16:13, Jeff Moyer wrote:
> Alex Richman <alex.r@gblabs.co.uk> writes:
>
>> Hi,
>>
>> I'm seeing some weirdness with AIO, specifically SYS_io_destroy() is
>> taking upwards of ~100000 microseconds (~100 miliseconds) per call.
>> How long is that call expected to take? I can see from the source
> Well, it waits for an RCU grace period. I would not expect that to take
> 100ms, though. What kernel version is this?
>
> -Jeff
--
Alex Richman
alex.r@gblabs.co.uk
Engineering
Tel:+44 (0)118 455 5000
www.gblabs.com
^ permalink raw reply
* [PATCH 4/9] tests/data: extract LogRecord into own file
From: Urs Fässler @ 2018-07-23 15:42 UTC (permalink / raw)
To: bitbake-devel
In-Reply-To: <20180723154259.9076-1-urs.fassler@bbv.ch>
LogRecord is a mechanism to capture the log output. It is used in the
data tests. It is moved into its own file to be used by other tests.
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
---
lib/bb/tests/data.py | 25 +------------------
lib/bb/tests/logrecord.py | 51 +++++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 24 deletions(-)
create mode 100644 lib/bb/tests/logrecord.py
diff --git a/lib/bb/tests/data.py b/lib/bb/tests/data.py
index a4a9dd30..e8121a21 100644
--- a/lib/bb/tests/data.py
+++ b/lib/bb/tests/data.py
@@ -24,30 +24,7 @@ import unittest
import bb
import bb.data
import bb.parse
-import logging
-
-class LogRecord():
- def __enter__(self):
- logs = []
- class LogHandler(logging.Handler):
- def emit(self, record):
- logs.append(record)
- logger = logging.getLogger("BitBake")
- handler = LogHandler()
- self.handler = handler
- logger.addHandler(handler)
- return logs
- def __exit__(self, type, value, traceback):
- logger = logging.getLogger("BitBake")
- logger.removeHandler(self.handler)
- return
-
-def logContains(item, logs):
- for l in logs:
- m = l.getMessage()
- if item in m:
- return True
- return False
+from bb.tests.logrecord import LogRecord, logContains
class DataExpansions(unittest.TestCase):
def setUp(self):
diff --git a/lib/bb/tests/logrecord.py b/lib/bb/tests/logrecord.py
new file mode 100644
index 00000000..2693e4ff
--- /dev/null
+++ b/lib/bb/tests/logrecord.py
@@ -0,0 +1,51 @@
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# BitBake Tests for the Data Store (data.py/data_smart.py)
+#
+# Copyright (C) 2010 Chris Larson
+# Copyright (C) 2012 Richard Purdie
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+
+import logging
+
+
+class LogRecord():
+ def __enter__(self):
+ logs = []
+
+ class LogHandler(logging.Handler):
+ def emit(self, record):
+ logs.append(record)
+
+ logger = logging.getLogger("BitBake")
+ handler = LogHandler()
+ self.handler = handler
+ logger.addHandler(handler)
+ return logs
+
+ def __exit__(self, type, value, traceback):
+ logger = logging.getLogger("BitBake")
+ logger.removeHandler(self.handler)
+ return
+
+
+def logContains(item, logs):
+ for l in logs:
+ m = l.getMessage()
+ if item in m:
+ return True
+ return False
--
2.18.0
^ permalink raw reply related
* [xen-unstable-smoke test] 125521: tolerable all pass - PUSHED
From: osstest service owner @ 2018-07-23 16:17 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125521 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125521/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
xen 61bdddb82151fbf51c58f6ebc1b4a687942c45a8
baseline version:
xen 890b9b8075121c8c2f99ff6135cd1581bc5cb383
Last test of basis 125516 2018-07-23 11:00:26 Z 0 days
Testing same since 125521 2018-07-23 14:01:00 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Julien Grall <julien.grall@arm.com>
Razvan Cojocaru <rcojocaru@bitdefender.com>
Tamas K Lengyel <tamas@tklengyel.com>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
To xenbits.xen.org:/home/xen/git/xen.git
890b9b8075..61bdddb821 61bdddb82151fbf51c58f6ebc1b4a687942c45a8 -> smoke
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.19, round 2
From: Olof Johansson @ 2018-07-23 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hk1pm3ym6.fsf@baylibre.com>
On Mon, Jul 23, 2018 at 5:50 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> Olof Johansson <olof@lixom.net> writes:
>
>> On Fri, Jul 20, 2018 at 11:30:15AM -0500, Kevin Hilman wrote:
>>> Olof, Arnd,
>>>
>>> A second round of DT updates for Amlogic, directly on top of the redo of
>>> the first one.
>>>
>>> This includes a merge of a branch already queued in the clk tree because
>>> of the dependency on clock headers used in the DT changes here..
>>>
>>> Kevin
>>>
>>>
>>> The following changes since commit 89803e8b26569bdf5798f8745a4c708bf9360ee6:
>>>
>>> ARM64: dts: meson-axg: add pdm pins (2018-07-20 08:18:37 -0700)
>>>
>>> are available in the git repository at:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2
>>>
>>> for you to fetch changes up to fcf775a1e6717b7157b1ea626028b7e039b3c989:
>>>
>>> Merge branch 'v4.19/dt64' into tmp/aml-rebuild (2018-07-20 09:05:11 -0700)
>>>
>>> ----------------------------------------------------------------
>>> Amlogic 64-bit DT changes for v4.19, round 2
>>> - new SoC: S905W
>>> - new boards: based on S905W: Amlogic P281, Oranth Tanix TX3 Mini
>>> - AXG: add DT for new audio clock controller
>>>
>>> ----------------------------------------------------------------
>>
>> Something happened to your diffstat here. It's also based on -rc5?
>
> My branch is/was based on -rc1 but the dependency branch from the clock
> tree is based on -rc5. That made the diffstat include -rc5, which was
> too noisy, so I removed it but then forgot to add the simplified
> version.
Ah, thanks. It's unfortunate that this brings in a new -rc but not the
end of the world. Will merge later today or tomorrow depending on
travel progress.
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.19, round 2
From: Olof Johansson @ 2018-07-23 16:17 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <7hk1pm3ym6.fsf@baylibre.com>
On Mon, Jul 23, 2018 at 5:50 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> Olof Johansson <olof@lixom.net> writes:
>
>> On Fri, Jul 20, 2018 at 11:30:15AM -0500, Kevin Hilman wrote:
>>> Olof, Arnd,
>>>
>>> A second round of DT updates for Amlogic, directly on top of the redo of
>>> the first one.
>>>
>>> This includes a merge of a branch already queued in the clk tree because
>>> of the dependency on clock headers used in the DT changes here..
>>>
>>> Kevin
>>>
>>>
>>> The following changes since commit 89803e8b26569bdf5798f8745a4c708bf9360ee6:
>>>
>>> ARM64: dts: meson-axg: add pdm pins (2018-07-20 08:18:37 -0700)
>>>
>>> are available in the git repository at:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2
>>>
>>> for you to fetch changes up to fcf775a1e6717b7157b1ea626028b7e039b3c989:
>>>
>>> Merge branch 'v4.19/dt64' into tmp/aml-rebuild (2018-07-20 09:05:11 -0700)
>>>
>>> ----------------------------------------------------------------
>>> Amlogic 64-bit DT changes for v4.19, round 2
>>> - new SoC: S905W
>>> - new boards: based on S905W: Amlogic P281, Oranth Tanix TX3 Mini
>>> - AXG: add DT for new audio clock controller
>>>
>>> ----------------------------------------------------------------
>>
>> Something happened to your diffstat here. It's also based on -rc5?
>
> My branch is/was based on -rc1 but the dependency branch from the clock
> tree is based on -rc5. That made the diffstat include -rc5, which was
> too noisy, so I removed it but then forgot to add the simplified
> version.
Ah, thanks. It's unfortunate that this brings in a new -rc but not the
end of the world. Will merge later today or tomorrow depending on
travel progress.
-Olof
^ permalink raw reply
* Re: [PATCH] mm: memcg: fix use after free in mem_cgroup_iter()
From: Shakeel Butt @ 2018-07-23 16:17 UTC (permalink / raw)
To: Michal Hocko
Cc: jing.xia.mail, Johannes Weiner, Vladimir Davydov, chunyan.zhang,
Cgroups, Linux MM, LKML, Andrew Morton
In-Reply-To: <20180723064441.GA17905@dhcp22.suse.cz>
On Sun, Jul 22, 2018 at 11:44 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Thu 19-07-18 09:23:10, Shakeel Butt wrote:
> > On Thu, Jul 19, 2018 at 3:43 AM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > [CC Andrew]
> > >
> > > On Thu 19-07-18 18:06:47, Jing Xia wrote:
> > > > It was reported that a kernel crash happened in mem_cgroup_iter(),
> > > > which can be triggered if the legacy cgroup-v1 non-hierarchical
> > > > mode is used.
> > > >
> > > > Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b8f
> > > > ......
> > > > Call trace:
> > > > mem_cgroup_iter+0x2e0/0x6d4
> > > > shrink_zone+0x8c/0x324
> > > > balance_pgdat+0x450/0x640
> > > > kswapd+0x130/0x4b8
> > > > kthread+0xe8/0xfc
> > > > ret_from_fork+0x10/0x20
> > > >
> > > > mem_cgroup_iter():
> > > > ......
> > > > if (css_tryget(css)) <-- crash here
> > > > break;
> > > > ......
> > > >
> > > > The crashing reason is that mem_cgroup_iter() uses the memcg object
> > > > whose pointer is stored in iter->position, which has been freed before
> > > > and filled with POISON_FREE(0x6b).
> > > >
> > > > And the root cause of the use-after-free issue is that
> > > > invalidate_reclaim_iterators() fails to reset the value of
> > > > iter->position to NULL when the css of the memcg is released in non-
> > > > hierarchical mode.
> > >
> > > Well, spotted!
> > >
> > > I suspect
> > > Fixes: 6df38689e0e9 ("mm: memcontrol: fix possible memcg leak due to interrupted reclaim")
> > >
> > > but maybe it goes further into past. I also suggest
> > > Cc: stable
> > >
> > > even though the non-hierarchical mode is strongly discouraged.
> >
> > Why not set root_mem_cgroup's use_hierarchy to true by default on
> > init? If someone wants non-hierarchical mode, they can explicitly set
> > it to false.
>
> We do not change defaults under users feet usually.
Then how non-hierarchical mode is being discouraged currently? I don't
see any comments in the docs.
Shakeel
^ permalink raw reply
* [PATCH v3 0/7] mmc: sunxi: Add runtime PM support
From: Ondřej Jirman @ 2018-07-23 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720145143.qgvlk2gbegxwwcfs@flea>
Hi Maxime,
On Fri, Jul 20, 2018 at 04:51:43PM +0200, Maxime Ripard wrote:
> Hi Ondrej,
>
> On Mon, Jul 16, 2018 at 07:14:28PM +0200, Ond?ej Jirman wrote:
> > On Mon, Apr 16, 2018 at 04:22:58PM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > Since it's introduction, our MMC controller has had its external clocks
> > > running all the time.
> > >
> > > While that was working great, the power usage and most importantly the EMI
> > > that it generated was pretty bad.
> > >
> > > Let's implement some runtime_pm hooks with an autosuspend to shut down the
> > > whole block when the MMC is not active.
> > >
> > > However, some SDIO devices will not probe properly if we keep shutting down
> > > the controller, so the autosuspend is disabled for the SDIO devices.
> >
> > I've tested your patches on TBS A711 tablet (A83T). I get this in the log:
> >
> > sunxi-mmc 1c10000.mmc: fatal err update clk timeout
> >
> > Interestingly, this only happens after the first boot. If I hard power cycle the
> > tablet (removing/reinserting the battery) the first boot after that, there's no
> > timeout, and WiFi chip connected to the mmc controller works.
> >
> > Any other reboot (even power cycling via PMIC), it fails with the above error.
> > Maybe there's some unforeseen interaction of runtime PM with mmc-powerseq used
> > for the wifi chip power seuencing? Do you know what's the above error about?
> > I don't know anything about mmc subsystem.
>
> It's kind of weird. Do you have an oscilloscope available to look at
> the clock signal (and the reset gpio) and see if there's any
> difference of behaviour?
No, I don't. I can try some printks on the kernel side if it toggles the WiFi
reset/power enable gpios differntly.
It looks like something's different on initialization when booting the kernel.
WiFi works fine for extended periods of time after the hard power cycle. But
when rebooting, it fails.
Adding to the weirdness factor may be the fact that WiFi is not connected via
PMIC, so it gets power almost directly from the battery. So kernel may not be
doing the WiFi reset properly on boot (which is fine right after the hard power
cycle, but leaves the WiFi in unknown state on subsequent reboots).
Thank you and regards,
o.
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 0/7] mmc: sunxi: Add runtime PM support
From: Ondřej Jirman @ 2018-07-23 16:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: ulf.hansson, Quentin Schulz, linux-mmc, Chen-Yu Tsai,
Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20180720145143.qgvlk2gbegxwwcfs@flea>
Hi Maxime,
On Fri, Jul 20, 2018 at 04:51:43PM +0200, Maxime Ripard wrote:
> Hi Ondrej,
>
> On Mon, Jul 16, 2018 at 07:14:28PM +0200, Ondřej Jirman wrote:
> > On Mon, Apr 16, 2018 at 04:22:58PM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > Since it's introduction, our MMC controller has had its external clocks
> > > running all the time.
> > >
> > > While that was working great, the power usage and most importantly the EMI
> > > that it generated was pretty bad.
> > >
> > > Let's implement some runtime_pm hooks with an autosuspend to shut down the
> > > whole block when the MMC is not active.
> > >
> > > However, some SDIO devices will not probe properly if we keep shutting down
> > > the controller, so the autosuspend is disabled for the SDIO devices.
> >
> > I've tested your patches on TBS A711 tablet (A83T). I get this in the log:
> >
> > sunxi-mmc 1c10000.mmc: fatal err update clk timeout
> >
> > Interestingly, this only happens after the first boot. If I hard power cycle the
> > tablet (removing/reinserting the battery) the first boot after that, there's no
> > timeout, and WiFi chip connected to the mmc controller works.
> >
> > Any other reboot (even power cycling via PMIC), it fails with the above error.
> > Maybe there's some unforeseen interaction of runtime PM with mmc-powerseq used
> > for the wifi chip power seuencing? Do you know what's the above error about?
> > I don't know anything about mmc subsystem.
>
> It's kind of weird. Do you have an oscilloscope available to look at
> the clock signal (and the reset gpio) and see if there's any
> difference of behaviour?
No, I don't. I can try some printks on the kernel side if it toggles the WiFi
reset/power enable gpios differntly.
It looks like something's different on initialization when booting the kernel.
WiFi works fine for extended periods of time after the hard power cycle. But
when rebooting, it fails.
Adding to the weirdness factor may be the fact that WiFi is not connected via
PMIC, so it gets power almost directly from the battery. So kernel may not be
doing the WiFi reset properly on boot (which is fine right after the hard power
cycle, but leaves the WiFi in unknown state on subsequent reboots).
Thank you and regards,
o.
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> 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: Incorrect name of PCM
From: Takashi Iwai @ 2018-07-23 16:15 UTC (permalink / raw)
To: Christopher Head; +Cc: alsa-devel
In-Reply-To: <3E9578B3-156B-40D9-BC11-F8D11B73E722@chead.ca>
On Mon, 23 Jul 2018 18:11:38 +0200,
Christopher Head wrote:
>
> On July 23, 2018 12:34:34 AM PDT, Takashi Iwai <tiwai@suse.de> wrote:
> >
> >For playing via HDMI on your machine, you'd need to pass as "aplay -L"
> >shows, one of the following:
> >
> >> hdmi:CARD=NVidia,DEV=0
> >> HDA NVidia, HDMI 0
> >> HDMI Audio Output
> >> hdmi:CARD=NVidia,DEV=1
> >> HDA NVidia, HDMI 1
> >> HDMI Audio Output
> >> hdmi:CARD=NVidia,DEV=2
> >> HDA NVidia, HDMI 2
> >> HDMI Audio Output
> >> hdmi:CARD=NVidia,DEV=3
> >> HDA NVidia, HDMI 3
> >> HDMI Audio Output
> >
> >The device number depends on the HDMI port you plugged in.
> >The above can be in a shorter form like "hdmi:1,0", too.
>
> Hi,
> Thanks for responding. Did you miss this part of the aplay -L output?
No.
> hdmi:CARD=PCH,DEV=0
> HDA Intel PCH, VT1708S Digital
> HDMI Audio Output
>
> This is the part I think is wrong, not the parts mentioning the NVidia HDMI outputs.
Just ignore this entry. alsa-lib tries to parse the all possible
outputs that are provided from the kernel interface. Due to
historical reasons, this digital output might be either SPDIF or HDMI,
and alsa-lib has no knowledge to distinguish easily, hence both spdif
and hdmi device names are provided equally for such a case.
Again, on your machine, the HDMI output is the card#1, not card#0.
The hdmi alsa-lib definition for card#0 is nothing but an alias of the
general digital I/O.
HTH,
Takashi
^ permalink raw reply
* Re: [PATCH v2 00/14] mm: Asynchronous + multithreaded memmap init for ZONE_DEVICE
From: Dave Hansen @ 2018-07-23 16:15 UTC (permalink / raw)
To: Michal Hocko
Cc: Dan Williams, pasha.tatashin, dalias, Jan Kara,
Benjamin Herrenschmidt, Heiko Carstens, linux-mm, Paul Mackerras,
H. Peter Anvin, Yoshinori Sato, linux-nvdimm@lists.01.org,
the arch/x86 maintainers, Matthew Wilcox, daniel.m.jordan,
Ingo Molnar, fenghua.yu, Jerome Glisse, Thomas Gleixner,
Luck, Tony, Linux Kernel Mailing List, Michael Ellerman,
Martin Schwidefsky, Andrew Morton, Christoph Hellwig
In-Reply-To: <20180723110928.GC31229@dhcp22.suse.cz>
On 07/23/2018 04:09 AM, Michal Hocko wrote:
> On Thu 19-07-18 11:41:10, Dave Hansen wrote:
>> Are you looking for the actual end-user reports? This was more of a
>> case of the customer plugging in some persistent memory DIMMs, noticing
>> the boot delta and calling the folks who sold them the DIMMs (Intel).
> But this doesn't sound like something to rush a solution for in the
> upcoming merge windown, does it?
No, we should not rush it. We'll try to rework it properly.
^ permalink raw reply
* Re: [PATCH v2 00/14] mm: Asynchronous + multithreaded memmap init for ZONE_DEVICE
From: Dave Hansen @ 2018-07-23 16:15 UTC (permalink / raw)
To: Michal Hocko
Cc: dalias, Jan Kara, Benjamin Herrenschmidt, Heiko Carstens,
linux-mm, Paul Mackerras, H. Peter Anvin, Thomas Gleixner,
Yoshinori Sato, linux-nvdimm@lists.01.org, Michael Ellerman,
the arch/x86 maintainers, pasha.tatashin, Matthew Wilcox,
daniel.m.jordan, Ingo Molnar, fenghua.yu, Jerome Glisse,
Luck, Tony, Linux Kernel Mailing List, Martin Schwidefsky,
Andrew Morton, Christoph Hellwig
In-Reply-To: <20180723110928.GC31229@dhcp22.suse.cz>
On 07/23/2018 04:09 AM, Michal Hocko wrote:
> On Thu 19-07-18 11:41:10, Dave Hansen wrote:
>> Are you looking for the actual end-user reports? This was more of a
>> case of the customer plugging in some persistent memory DIMMs, noticing
>> the boot delta and calling the folks who sold them the DIMMs (Intel).
> But this doesn't sound like something to rush a solution for in the
> upcoming merge windown, does it?
No, we should not rush it. We'll try to rework it properly.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH 1/1] getxattr: use correct xattr length
From: Serge E. Hallyn @ 2018-07-23 15:14 UTC (permalink / raw)
To: Christian Brauner
Cc: Serge E. Hallyn, linux-fsdevel, linux-kernel, cjwatson, ebiederm,
viro
In-Reply-To: <20180723150021.GA16606@gmail.com>
Quoting Christian Brauner (christian.brauner@canonical.com):
> On Wed, Jun 13, 2018 at 10:45:37AM -0500, Serge Hallyn wrote:
> > On Thu, Jun 07, 2018 at 01:43:48PM +0200, Christian Brauner wrote:
> > > When running in a container with a user namespace, if you call getxattr
> > > with name = "system.posix_acl_access" and size % 8 != 4, then getxattr
> > > silently skips the user namespace fixup that it normally does resulting in
> > > un-fixed-up data being returned.
> > > This is caused by posix_acl_fix_xattr_to_user() being passed the total
> > > buffer size and not the actual size of the xattr as returned by
> > > vfs_getxattr().
> > > This commit passes the actual length of the xattr as returned by
> > > vfs_getxattr() down.
> > >
> > > A reproducer for the issue is:
> > >
> > > touch acl_posix
> > >
> > > setfacl -m user:0:rwx acl_posix
> > >
> > > and the compile:
> > >
> > > #define _GNU_SOURCE
> > > #include <errno.h>
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <string.h>
> > > #include <sys/types.h>
> > > #include <unistd.h>
> > > #include <attr/xattr.h>
> > >
> > > /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */
> > > int main(int argc, void **argv)
> > > {
> > > ssize_t ret1, ret2;
> > > char buf1[128], buf2[132];
> > > int fret = EXIT_SUCCESS;
> > > char *file;
> > >
> > > if (argc < 2) {
> > > fprintf(stderr,
> > > "Please specify a file with "
> > > "\"system.posix_acl_access\" permissions set\n");
> > > _exit(EXIT_FAILURE);
> > > }
> > > file = argv[1];
> > >
> > > ret1 = getxattr(file, "system.posix_acl_access",
> > > buf1, sizeof(buf1));
> > > if (ret1 < 0) {
> > > fprintf(stderr, "%s - Failed to retrieve "
> > > "\"system.posix_acl_access\" "
> > > "from \"%s\"\n", strerror(errno), file);
> > > _exit(EXIT_FAILURE);
> > > }
> > >
> > > ret2 = getxattr(file, "system.posix_acl_access",
> > > buf2, sizeof(buf2));
> > > if (ret2 < 0) {
> > > fprintf(stderr, "%s - Failed to retrieve "
> > > "\"system.posix_acl_access\" "
> > > "from \"%s\"\n", strerror(errno), file);
> > > _exit(EXIT_FAILURE);
> > > }
> > >
> > > if (ret1 != ret2) {
> > > fprintf(stderr, "The value of \"system.posix_acl_"
> > > "access\" for file \"%s\" changed "
> > > "between two successive calls\n", file);
> > > _exit(EXIT_FAILURE);
> > > }
> > >
> > > for (ssize_t i = 0; i < ret2; i++) {
> > > if (buf1[i] == buf2[i])
> > > continue;
> > >
> > > fprintf(stderr,
> > > "Unexpected different in byte %zd: "
> > > "%02x != %02x\n", i, buf1[i], buf2[i]);
> > > fret = EXIT_FAILURE;
> > > }
> > >
> > > if (fret == EXIT_SUCCESS)
> > > fprintf(stderr, "Test passed\n");
> > > else
> > > fprintf(stderr, "Test failed\n");
> > >
> > > _exit(fret);
> > > }
> > > and run:
> > >
> > > ./tester acl_posix
> > >
> > > On a non-fixed up kernel this should return something like:
> > >
> > > root@c1:/# ./t
> > > Unexpected different in byte 16: ffffffa0 != 00
> > > Unexpected different in byte 17: ffffff86 != 00
> > > Unexpected different in byte 18: 01 != 00
> > >
> > > and on a fixed kernel:
> > >
> > > root@c1:~# ./t
> > > Test passed
> > >
> > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=199945
> > > Reported-by: Colin Watson <cjwatson@ubuntu.com>
> > > Signed-off-by: Christian Brauner <christian@brauner.io>
> >
> > D'oh, sorry, I thought I had replied to this!
> >
> > Acked-by: Serge Hallyn <serge@hallyn.com>
>
> Should this still land as a bugfix in 4.18?
Eric, do you mind picking this up?
> Christian
>
> >
> > thanks,
> > Serge
> >
> > > ---
> > > fs/xattr.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/fs/xattr.c b/fs/xattr.c
> > > index f9cb1db187b7..1bee74682513 100644
> > > --- a/fs/xattr.c
> > > +++ b/fs/xattr.c
> > > @@ -539,7 +539,7 @@ getxattr(struct dentry *d, const char __user *name, void __user *value,
> > > if (error > 0) {
> > > if ((strcmp(kname, XATTR_NAME_POSIX_ACL_ACCESS) == 0) ||
> > > (strcmp(kname, XATTR_NAME_POSIX_ACL_DEFAULT) == 0))
> > > - posix_acl_fix_xattr_to_user(kvalue, size);
> > > + posix_acl_fix_xattr_to_user(kvalue, error);
> > > if (size && copy_to_user(value, kvalue, error))
> > > error = -EFAULT;
> > > } else if (error == -ERANGE && size >= XATTR_SIZE_MAX) {
> > > --
> > > 2.17.0
^ permalink raw reply
* Re: Very slow SYS_io_destroy()
From: Jeff Moyer @ 2018-07-23 15:13 UTC (permalink / raw)
To: Alex Richman; +Cc: linux-kernel, linux-fsdevel
In-Reply-To: <27245a6a-a827-2662-215c-05ccdff65768@gblabs.co.uk>
Alex Richman <alex.r@gblabs.co.uk> writes:
> Hi,
>
> I'm seeing some weirdness with AIO, specifically SYS_io_destroy() is
> taking upwards of ~100000 microseconds (~100 miliseconds) per call.
> How long is that call expected to take? I can see from the source
Well, it waits for an RCU grace period. I would not expect that to take
100ms, though. What kernel version is this?
-Jeff
^ permalink raw reply
* Re: Incorrect name of PCM
From: Christopher Head @ 2018-07-23 16:14 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <s5h7elm1k39.wl-tiwai@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 921 bytes --]
On July 23, 2018 12:34:34 AM PDT, Takashi Iwai <tiwai@suse.de> wrote:
>
>For playing via HDMI on your machine, you'd need to pass as "aplay -L"
>shows, one of the following:
>
>> hdmi:CARD=NVidia,DEV=0
>> HDA NVidia, HDMI 0
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=1
>> HDA NVidia, HDMI 1
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=2
>> HDA NVidia, HDMI 2
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=3
>> HDA NVidia, HDMI 3
>> HDMI Audio Output
>
>The device number depends on the HDMI port you plugged in.
>The above can be in a shorter form like "hdmi:1,0", too.
Hi,
Thanks for responding. Did you miss this part of the aplay -L output?
hdmi:CARD=PCH,DEV=0
HDA Intel PCH, VT1708S Digital
HDMI Audio Output
This is the part I think is wrong, not the parts mentioning the NVidia HDMI outputs.
Thanks,
--
Christopher Head
--
Christopher Head
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 244 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ 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.