* Re: [PATCH v2 1/5] common/overlay,rc,config: introduce OVL_FSTYP variable and aufs
From: Amir Goldstein @ 2020-02-14 22:06 UTC (permalink / raw)
To: Mauricio Faria de Oliveira; +Cc: fstests, overlayfs
In-Reply-To: <20200214151848.8328-2-mfo@canonical.com>
On Fri, Feb 14, 2020 at 5:18 PM Mauricio Faria de Oliveira
<mfo@canonical.com> wrote:
>
> Recently I was looking for an aufs test suite, and reached out to
> Okajima, but 'There is no public test suite specific to aufs.' [1],
> and it looks like 'xfstests/tests/generic' should be enough [1, 2].
>
> Thus, building on top existing xfstests support for overlay just
> introduce the OVL_FSTYP variable, and the default value "overlay"
> can be changed to "aufs" (uses overlay's upperdir as a rw-branch
> and lowerdir as a ro-branch; workdir is not used.)
>
> This is indeed a workaround^W simple change that does the job vs.
> creating a new FSTYP "aufs" and mechanically changing the number
> of places that check for "overlay" to just handle "aufs" as well.
> (so the effort is still small as aufs has no specific tests now.)
>
> This also allows testing fuse-overlayfs with the next patches.
>
> The changes are minimal -- just translate overlay mount options
> and use $OVL_FSTYP as filesystem type for checking/mount/umount;
> then report it in log headers and document it in README.overlay.
>
> Currently, running './check -overlay' tests (excluding a few [3]
> which either hang or keep looping) the numbers for aufs on loop
> devices on v5.4-based Ubuntu kernel are:
>
> - Ran: 645 tests
> - Not run: 483 tests
> - Failures: 22 tests
>
> So, hopefully this may help with a starting point for an public
> test suite for aufs.
>
> Thanks to Amir Goldstein for feedback/improvements and pointers
> to support fuse-overlayfs as well [v2].
>
> [1] https://sourceforge.net/p/aufs/mailman/message/36918721/
> [2] https://sourceforge.net/p/aufs/mailman/message/36918932/
> [3] Steps:
>
> $ export OVL_FSTYP=aufs
> $ export FSTYP=ext4
> $ export TEST_DEV=/dev/loop0
> $ export TEST_DIR=/mnt/test
> $ export SCRATCH_DEV=/dev/loop1
> $ export SCRATCH_MNT=/mnt/scratch
>
> $ sudo mkfs.$FSTYP -F $TEST_DEV
> $ sudo mkfs.$FSTYP -F $SCRATCH_DEV
> $ sudo mkdir $TEST_DIR $SCRATCH_MNT
>
> $ cat <<EOF >/tmp/exclude-tests
> generic/013
> generic/070
> generic/075
> generic/112
> generic/127
> generic/461
> generic/476
> generic/522
> generic/530
> overlay/019
> EOF
>
> $ sudo -E ./check -overlay -E /tmp/exclude-tests
>
> Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
> ---
> README.overlay | 4 ++++
> common/config | 2 ++
> common/overlay | 11 ++++++++---
> common/rc | 6 ++++++
> 4 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/README.overlay b/README.overlay
> index 30b5ddb2d1c3..08a39b8830c9 100644
> --- a/README.overlay
> +++ b/README.overlay
> @@ -50,3 +50,7 @@ In the example above, MOUNT_OPTIONS will be used to mount the base scratch fs,
> TEST_FS_MOUNT_OPTS will be used to mount the base test fs,
> OVERLAY_MOUNT_OPTIONS will be used to mount both test and scratch overlay and
> OVERLAY_FSCK_OPTIONS will be used to check both test and scratch overlay.
> +
> +To test other filesystem types (experimental) configure the OVL_FSTYP variable:
> +
> + OVL_FSTYP=aufs
> diff --git a/common/config b/common/config
> index 9a9c77602b54..d92a78003295 100644
> --- a/common/config
> +++ b/common/config
> @@ -71,6 +71,8 @@ export OVL_LOWER="ovl-lower"
> export OVL_WORK="ovl-work"
> # overlay mount point parent must be the base fs root
> export OVL_MNT="ovl-mnt"
> +# overlay mount filesystem type (for testing other fs)
> +export OVL_FSTYP=${OVL_FSTYP:-overlay}
>
> # From e2fsprogs/e2fsck/e2fsck.h:
> # Exit code used by fsck-type programs
> diff --git a/common/overlay b/common/overlay
> index 65c639e9c6d8..a1076926c23f 100644
> --- a/common/overlay
> +++ b/common/overlay
> @@ -18,10 +18,15 @@ _overlay_mount_dirs()
> local lowerdir=$1
> local upperdir=$2
> local workdir=$3
> + local options
> shift 3
>
> - $MOUNT_PROG -t overlay -o lowerdir=$lowerdir -o upperdir=$upperdir \
> - -o workdir=$workdir `_common_dev_mount_options $*`
> + options="-o lowerdir=$lowerdir -o upperdir=$upperdir -o workdir=$workdir"
> + if [ "$OVL_FSTYP" = "aufs" ]; then
> + options="-o br=$upperdir=rw -o br=$lowerdir=ro"
> + fi
> +
> + $MOUNT_PROG -t $OVL_FSTYP $options `_common_dev_mount_options $*`
> }
>
> # Mount with same options/mnt/dev of scratch mount, but optionally
> @@ -302,7 +307,7 @@ _overlay_check_fs()
> _overlay_base_mount $*
> else
> # Check and umount overlay for dir check
> - ovl_mounted=`_is_dir_mountpoint $ovl_mnt`
> + ovl_mounted=`_is_dir_mountpoint $ovl_mnt $OVL_FSTYP`
> [ -z "$ovl_mounted" ] || $UMOUNT_PROG $ovl_mnt
> fi
>
> diff --git a/common/rc b/common/rc
> index b4a77a2187f4..1feae1a94f9e 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -1471,6 +1471,10 @@ _check_mounted_on()
> return 2 # 2 = mounted on wrong mnt
> fi
>
> + if [ -n "$type" -a "$type" = "overlay" ]; then
> + type="$OVL_FSTYP"
> + fi
> +
Hmm. I found 2 other instances of _fs_type in common/rc.
I think it would be safer to let _fs_type return "overlay" in
case the mounted fs is of type $OVL_FSTYP.
This will be simple to do by extending the sed expression -
no need for special cases and conditions.
Other than that, patch looks good.
Thanks,
Amir.
> if [ -n "$type" -a "`_fs_type $dev`" != "$type" ]; then
> echo "$devname=$dev is mounted but not a type $type filesystem"
> # raw $DF_PROG cannot handle NFS/CIFS/overlay correctly
> @@ -2841,6 +2845,8 @@ _full_fstyp_details()
> FSTYP="$FSTYP (non-debug)"
> fi
> fi
> + elif [ $FSTYP = "overlay" -a "$OVL_FSTYP" != "overlay" ]; then
> + FSTYP="$FSTYP ($OVL_FSTYP)"
> fi
> echo $FSTYP
> }
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v3 00/12] Enable per-file/directory DAX operations V3
From: Jeff Moyer @ 2020-02-14 22:06 UTC (permalink / raw)
To: Ira Weiny
Cc: Dan Williams, Darrick J. Wong, Linux Kernel Mailing List,
Alexander Viro, Dave Chinner, Christoph Hellwig,
Theodore Y. Ts'o, Jan Kara, linux-ext4, linux-xfs,
linux-fsdevel
In-Reply-To: <20200214215759.GA20548@iweiny-DESK2.sc.intel.com>
Ira Weiny <ira.weiny@intel.com> writes:
> On Fri, Feb 14, 2020 at 04:23:19PM -0500, Jeff Moyer wrote:
>> Ira Weiny <ira.weiny@intel.com> writes:
>>
>> > [disclaimer: the following assumes the underlying 'device' (superblock)
>> > supports DAX]
>> >
>> > ... which results in S_DAX == false when the file is opened without the mount
>> > option. The key would be that all directories/files created under a root with
>> > XFS_DIFLAG2_DAX == true would inherit their flag and be XFS_DIFLAG2_DAX == true
>> > all the way down the tree. Any file not wanting DAX would need to set
>> > XFS_DIFLAG2_DAX == false. And setting false could be used on a directory to
>> > allow a user or group to not use dax on files in that sub-tree.
>> >
>> > Then without '-o dax' (XFS_MOUNT_DAX == false) all files when opened set S_DAX
>> > equal to XFS_DIFLAG2_DAX value. (Directories, as of V4, never get S_DAX set.)
>> >
>> > If '-o dax' (XFS_MOUNT_DAX == true) then S_DAX is set on all files.
>>
>> One more clarifying question. Let's say I set XFS_DIFLAG2_DAX on an
>> inode. I then open the file, and perform mmap/load/store/etc. I close
>> the file, and I unset XFS_DIFLAG2_DAX. Will the next open treat the
>> file as S_DAX or not? My guess is the inode won't be evicted, and so
>> S_DAX will remain set.
>
> The inode will not be evicted, or even it happens to be xfs_io will reload it
> to unset the XFS_DIFLAG2_DAX flag. And the S_DAX flag changes _with_ the
> XFS_DIFLAG2_DAX change when it can (when the underlying storage supports
> S_DAX).
OK, so it will be possible to change the effective mode.
I'll try to get some testing in on this series, now.
Thanks!
Jeff
^ permalink raw reply
* Linux kernel 5.5.4 released
From: Linux Kernel Distribution System @ 2020-02-14 22:05 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 5.5.4 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.5.4.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-5.5.4.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.5.4.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v5.5.4/v5.5.3
^ permalink raw reply
* Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
From: Sean Christopherson @ 2020-02-14 22:03 UTC (permalink / raw)
To: Jim Mattson
Cc: Chia-I Wu, Paolo Bonzini, kvm list, Vitaly Kuznetsov, Wanpeng Li,
Joerg Roedel, Gurchetan Singh, Gerd Hoffmann, ML dri-devel
In-Reply-To: <CALMp9eRwTxdqxAcobZ7sYbD=F8Kga=jR3kaz-OEYdA9fV0AoKQ@mail.gmail.com>
On Fri, Feb 14, 2020 at 01:56:48PM -0800, Jim Mattson wrote:
> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu <olvaffe@gmail.com> wrote:
> > AFAICT, it is currently allowed on ARM (verified) and AMD (not
> > verified, but svm_get_mt_mask returns 0 which supposedly means the NPT
> > does not restrict what the guest PAT can do). This diff would do the
> > trick for Intel without needing any uapi change:
>
> I would be concerned about Intel CPU errata such as SKX40 and SKX59.
The part KVM cares about, #MC, is already addressed by forcing UC for MMIO.
The data corruption issue is on the guest kernel to correctly use WC
and/or non-temporal writes.
^ permalink raw reply
* Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
From: Sean Christopherson @ 2020-02-14 22:03 UTC (permalink / raw)
To: Jim Mattson
Cc: Wanpeng Li, kvm list, Joerg Roedel, ML dri-devel, Gurchetan Singh,
Gerd Hoffmann, Paolo Bonzini, Vitaly Kuznetsov
In-Reply-To: <CALMp9eRwTxdqxAcobZ7sYbD=F8Kga=jR3kaz-OEYdA9fV0AoKQ@mail.gmail.com>
On Fri, Feb 14, 2020 at 01:56:48PM -0800, Jim Mattson wrote:
> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu <olvaffe@gmail.com> wrote:
> > AFAICT, it is currently allowed on ARM (verified) and AMD (not
> > verified, but svm_get_mt_mask returns 0 which supposedly means the NPT
> > does not restrict what the guest PAT can do). This diff would do the
> > trick for Intel without needing any uapi change:
>
> I would be concerned about Intel CPU errata such as SKX40 and SKX59.
The part KVM cares about, #MC, is already addressed by forcing UC for MMIO.
The data corruption issue is on the guest kernel to correctly use WC
and/or non-temporal writes.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] net: phy: restore mdio regs in the iproc mdio driver
From: Florian Fainelli @ 2020-02-14 22:02 UTC (permalink / raw)
To: Scott Branden, Andrew Lunn, Heiner Kallweit
Cc: Russell King, David S . Miller, Ray Jui, bcm-kernel-feedback-list,
netdev, linux-arm-kernel, linux-kernel, Arun Parameswaran
In-Reply-To: <20200214214746.10153-1-scott.branden@broadcom.com>
On 2/14/20 1:47 PM, Scott Branden wrote:
> From: Arun Parameswaran <arun.parameswaran@broadcom.com>
>
> The mii management register in iproc mdio block
> does not have a retention register so it is lost on suspend.
> Save and restore value of register while resuming from suspend.
>
> Fixes: bb1a619735b4 ("net: phy: Initialize mdio clock at probe function")
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v2] net: phy: restore mdio regs in the iproc mdio driver
From: Florian Fainelli @ 2020-02-14 22:02 UTC (permalink / raw)
To: Scott Branden, Andrew Lunn, Heiner Kallweit
Cc: Ray Jui, Arun Parameswaran, Russell King, linux-kernel,
bcm-kernel-feedback-list, netdev, David S . Miller,
linux-arm-kernel
In-Reply-To: <20200214214746.10153-1-scott.branden@broadcom.com>
On 2/14/20 1:47 PM, Scott Branden wrote:
> From: Arun Parameswaran <arun.parameswaran@broadcom.com>
>
> The mii management register in iproc mdio block
> does not have a retention register so it is lost on suspend.
> Save and restore value of register while resuming from suspend.
>
> Fixes: bb1a619735b4 ("net: phy: Initialize mdio clock at probe function")
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Add PMU event filtering infrastructure
From: Robin Murphy @ 2020-02-14 22:01 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: James Morse, Julien Thierry, Suzuki K Poulose
In-Reply-To: <20200214183615.25498-2-maz@kernel.org>
Hi Marc,
On 2020-02-14 6:36 pm, Marc Zyngier wrote:
[...]
> @@ -585,6 +585,14 @@ static void kvm_pmu_create_perf_event(struct kvm_vcpu *vcpu, u64 select_idx)
> pmc->idx != ARMV8_PMU_CYCLE_IDX)
> return;
>
> + /*
> + * If we have a filter in place and that the event isn't allowed, do
> + * not install a perf event either.
> + */
> + if (vcpu->kvm->arch.pmu_filter &&
> + !test_bit(eventsel, vcpu->kvm->arch.pmu_filter))
> + return;
If I'm reading the derivation of eventsel right, this will end up
treating cycle counter events (aliased to SW_INCR) differently from
CPU_CYCLES, which doesn't seem desirable.
Also, if the user did try to blacklist SW_INCR for ridiculous reasons,
we'd need to special-case kvm_pmu_software_increment() to make it (not)
work as expected, right?
Robin.
> +
> memset(&attr, 0, sizeof(struct perf_event_attr));
> attr.type = PERF_TYPE_RAW;
> attr.size = sizeof(attr);
^ permalink raw reply
* Re: [PATCH] usb-storage: Use const to reduce object data size
From: Alan Stern @ 2020-02-14 22:01 UTC (permalink / raw)
To: Joe Perches; +Cc: Greg Kroah-Hartman, linux-usb, usb-storage, linux-kernel
In-Reply-To: <60559197a1af9e0af7f329cc3427989e5756846f.camel@perches.com>
On Fri, 14 Feb 2020, Joe Perches wrote:
> Make structs const to reduce data size ~20KB.
>
> Change function arguments and prototypes as necessary to compile.
>
> $ size (x86-64 defconfig pre)
> text data bss dec hex filename
> 12281 10948 480 23709 5c9d ./drivers/usb/storage/usb.o
> 111 10528 8 10647 2997 ./drivers/usb/storage/usual-tables.o
>
> $ size (x86-64 defconfig post)
> text data bss dec hex filename
> 22809 420 480 23709 5c9d drivers/usb/storage/usb.o
> 10551 0 0 10551 2937 drivers/usb/storage/usual-tables.o
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>
> compile tested only
>
> drivers/usb/storage/usb.c | 10 +++++-----
> drivers/usb/storage/usb.h | 5 +++--
> drivers/usb/storage/usual-tables.c | 6 +++---
> include/linux/usb_usual.h | 2 +-
> 4 files changed, 12 insertions(+), 11 deletions(-)
It all looks quite reasonable.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Alan Stern
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Add PMU event filtering infrastructure
From: Robin Murphy @ 2020-02-14 22:01 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: James Morse, Julien Thierry, Suzuki K Poulose
In-Reply-To: <20200214183615.25498-2-maz@kernel.org>
Hi Marc,
On 2020-02-14 6:36 pm, Marc Zyngier wrote:
[...]
> @@ -585,6 +585,14 @@ static void kvm_pmu_create_perf_event(struct kvm_vcpu *vcpu, u64 select_idx)
> pmc->idx != ARMV8_PMU_CYCLE_IDX)
> return;
>
> + /*
> + * If we have a filter in place and that the event isn't allowed, do
> + * not install a perf event either.
> + */
> + if (vcpu->kvm->arch.pmu_filter &&
> + !test_bit(eventsel, vcpu->kvm->arch.pmu_filter))
> + return;
If I'm reading the derivation of eventsel right, this will end up
treating cycle counter events (aliased to SW_INCR) differently from
CPU_CYCLES, which doesn't seem desirable.
Also, if the user did try to blacklist SW_INCR for ridiculous reasons,
we'd need to special-case kvm_pmu_software_increment() to make it (not)
work as expected, right?
Robin.
> +
> memset(&attr, 0, sizeof(struct perf_event_attr));
> attr.type = PERF_TYPE_RAW;
> attr.size = sizeof(attr);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Add PMU event filtering infrastructure
From: Robin Murphy @ 2020-02-14 22:01 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
In-Reply-To: <20200214183615.25498-2-maz@kernel.org>
Hi Marc,
On 2020-02-14 6:36 pm, Marc Zyngier wrote:
[...]
> @@ -585,6 +585,14 @@ static void kvm_pmu_create_perf_event(struct kvm_vcpu *vcpu, u64 select_idx)
> pmc->idx != ARMV8_PMU_CYCLE_IDX)
> return;
>
> + /*
> + * If we have a filter in place and that the event isn't allowed, do
> + * not install a perf event either.
> + */
> + if (vcpu->kvm->arch.pmu_filter &&
> + !test_bit(eventsel, vcpu->kvm->arch.pmu_filter))
> + return;
If I'm reading the derivation of eventsel right, this will end up
treating cycle counter events (aliased to SW_INCR) differently from
CPU_CYCLES, which doesn't seem desirable.
Also, if the user did try to blacklist SW_INCR for ridiculous reasons,
we'd need to special-case kvm_pmu_software_increment() to make it (not)
work as expected, right?
Robin.
> +
> memset(&attr, 0, sizeof(struct perf_event_attr));
> attr.type = PERF_TYPE_RAW;
> attr.size = sizeof(attr);
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Linux kernel 5.4.20 released
From: Linux Kernel Distribution System @ 2020-02-14 22:00 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 5.4.20 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.20.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-5.4.20.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.20.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v5.4.20/v5.4.19
^ permalink raw reply
* Re: [PATCH v7 00/15] add git-bugreport tool
From: Emily Shaffer @ 2020-02-14 22:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Derrick Stolee, Johannes Schindelin, Martin Ågren,
Aaron Schrab, Danh Doan, Eric Sunshine, SZEDER Gábor,
Andreas Schwab
In-Reply-To: <xmqqv9o9nkh3.fsf@gitster-ct.c.googlers.com>
On Fri, Feb 14, 2020 at 09:32:08AM -0800, Junio C Hamano wrote:
> Emily Shaffer <emilyshaffer@google.com> writes:
>
> > present(patch 9/15). This now uses POSIX character classes and {}
> > notation instead of + and has been tested on OSX; I'd love to hear if
>
> I'd rather not to see unnecessary uses of POSIX character classes.
>
> The interdiff of this step between the previous and this round looks
> to me more like "I used it, just because POSIX says I *can* use it",
> not "I did so because I needed to do, and it should be OK on POSIX
> platforms."
>
> Instead of overly long
>
> 's/^\([^[:blank:]]*\)[[:blank:]]\{1,\}annotate:bugreport\[include\].* ::$/ "\1",/p'
>
> just limiting ourselves to SP and saying
>
> 's/^\([^ ]*\) *annotate:bugreport\[include\].* ::$/ "\1",/p'
>
> would keep the result much easier to read, I would think.
That's fine by me. I find the [[:syntax:]] extremely ugly, but I was
worried about whether that was more portable somehow. Your proposal
seems fine to me.
- Emily
^ permalink raw reply
* Re: [PATCH] kcsan, trace: Make KCSAN compatible with tracing
From: Marco Elver @ 2020-02-14 21:59 UTC (permalink / raw)
To: Qian Cai
Cc: Paul E. McKenney, Andrey Konovalov, Alexander Potapenko,
Dmitry Vyukov, kasan-dev, LKML, Steven Rostedt, Ingo Molnar
In-Reply-To: <1581708956.7365.75.camel@lca.pw>
On Fri, 14 Feb 2020 at 20:35, Qian Cai <cai@lca.pw> wrote:
>
> On Fri, 2020-02-14 at 20:05 +0100, Marco Elver wrote:
> > Previously the system would lock up if ftrace was enabled together with
> > KCSAN. This is due to recursion on reporting if the tracer code is
> > instrumented with KCSAN.
> >
> > To avoid this for all types of tracing, disable KCSAN instrumentation
> > for all of kernel/trace.
>
> I remembered that KCSAN + ftrace was working last week, but I probably had a bad
> memory. Anyway, this patch works fine. Feel free to add,
>
> Tested-by: Qian Cai <cai@lca.pw>
Based your further feedback I've sent v2:
http://lkml.kernel.org/r/20200214211035.209972-1-elver@google.com
Thanks,
-- Marco
> >
> > Signed-off-by: Marco Elver <elver@google.com>
> > Reported-by: Qian Cai <cai@lca.pw>
> > Cc: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Steven Rostedt <rostedt@goodmis.org>
> > ---
> > kernel/kcsan/Makefile | 2 ++
> > kernel/trace/Makefile | 3 +++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/kernel/kcsan/Makefile b/kernel/kcsan/Makefile
> > index df6b7799e4927..d4999b38d1be5 100644
> > --- a/kernel/kcsan/Makefile
> > +++ b/kernel/kcsan/Makefile
> > @@ -4,6 +4,8 @@ KCOV_INSTRUMENT := n
> > UBSAN_SANITIZE := n
> >
> > CFLAGS_REMOVE_core.o = $(CC_FLAGS_FTRACE)
> > +CFLAGS_REMOVE_debugfs.o = $(CC_FLAGS_FTRACE)
> > +CFLAGS_REMOVE_report.o = $(CC_FLAGS_FTRACE)
> >
> > CFLAGS_core.o := $(call cc-option,-fno-conserve-stack,) \
> > $(call cc-option,-fno-stack-protector,)
> > diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> > index f9dcd19165fa2..6b601d88bf71e 100644
> > --- a/kernel/trace/Makefile
> > +++ b/kernel/trace/Makefile
> > @@ -6,6 +6,9 @@ ifdef CONFIG_FUNCTION_TRACER
> > ORIG_CFLAGS := $(KBUILD_CFLAGS)
> > KBUILD_CFLAGS = $(subst $(CC_FLAGS_FTRACE),,$(ORIG_CFLAGS))
> >
> > +# Avoid recursion due to instrumentation.
> > +KCSAN_SANITIZE := n
> > +
> > ifdef CONFIG_FTRACE_SELFTEST
> > # selftest needs instrumentation
> > CFLAGS_trace_selftest_dynamic.o = $(CC_FLAGS_FTRACE)
^ permalink raw reply
* Re: [PATCH v3 00/12] Enable per-file/directory DAX operations V3
From: Ira Weiny @ 2020-02-14 21:58 UTC (permalink / raw)
To: Jeff Moyer
Cc: Dan Williams, Darrick J. Wong, Linux Kernel Mailing List,
Alexander Viro, Dave Chinner, Christoph Hellwig,
Theodore Y. Ts'o, Jan Kara, linux-ext4, linux-xfs,
linux-fsdevel
In-Reply-To: <x4936bcdfso.fsf@segfault.boston.devel.redhat.com>
On Fri, Feb 14, 2020 at 04:23:19PM -0500, Jeff Moyer wrote:
> Ira Weiny <ira.weiny@intel.com> writes:
>
> > [disclaimer: the following assumes the underlying 'device' (superblock)
> > supports DAX]
> >
> > ... which results in S_DAX == false when the file is opened without the mount
> > option. The key would be that all directories/files created under a root with
> > XFS_DIFLAG2_DAX == true would inherit their flag and be XFS_DIFLAG2_DAX == true
> > all the way down the tree. Any file not wanting DAX would need to set
> > XFS_DIFLAG2_DAX == false. And setting false could be used on a directory to
> > allow a user or group to not use dax on files in that sub-tree.
> >
> > Then without '-o dax' (XFS_MOUNT_DAX == false) all files when opened set S_DAX
> > equal to XFS_DIFLAG2_DAX value. (Directories, as of V4, never get S_DAX set.)
> >
> > If '-o dax' (XFS_MOUNT_DAX == true) then S_DAX is set on all files.
>
> One more clarifying question. Let's say I set XFS_DIFLAG2_DAX on an
> inode. I then open the file, and perform mmap/load/store/etc. I close
> the file, and I unset XFS_DIFLAG2_DAX. Will the next open treat the
> file as S_DAX or not? My guess is the inode won't be evicted, and so
> S_DAX will remain set.
The inode will not be evicted, or even it happens to be xfs_io will reload it
to unset the XFS_DIFLAG2_DAX flag. And the S_DAX flag changes _with_ the
XFS_DIFLAG2_DAX change when it can (when the underlying storage supports
S_DAX).
Trying to change XFS_DIFLAG2_DAX while the file is mmap'ed returns -EBUSY.
Ira
>
> The reason I ask is I've had requests from application developers to do
> just this. They want to be able to switch back and forth between dax
> modes.
>
> Thanks,
> Jeff
>
> > [1] I'm beginning to think that if I type dax one more time I'm going to go
> > crazy... :-P
>
> dax dax dax!
>
^ permalink raw reply
* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] i915/gem_ctx_engine: Exercise for_each_context_engine() with custom engine[]
From: Chris Wilson @ 2020-02-14 21:57 UTC (permalink / raw)
To: Antonio Argenziano, intel-gfx; +Cc: igt-dev
In-Reply-To: <224cefba-4b48-c085-b0b5-952b62af29b3@intel.com>
Quoting Antonio Argenziano (2020-02-14 21:49:16)
>
>
> On 14/02/20 11:40, Chris Wilson wrote:
> > Set up a custom engine map with no engines, and check that the
> > for_each_context_engine() correctly iterates over nothing.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> > tests/i915/gem_ctx_engines.c | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
> > index 063140e0f..6a2edd1e0 100644
> > --- a/tests/i915/gem_ctx_engines.c
> > +++ b/tests/i915/gem_ctx_engines.c
> > @@ -549,6 +549,31 @@ static void independent(int i915)
> > gem_context_destroy(i915, param.ctx_id);
> > }
> >
> > +static void libapi(int i915)
> > +{
> > + struct i915_context_param_engines engines = {};
>
> Is there a case for invalid engines as well?
One would have to think what the behaviour should be :)
for_each_context_engine() should iterate over every engine defined,
providing you with (e->class, e->instance, e->pretty_name).
Invalid will still have an entry, maybe with "unknown".
for_each_physical_engine would skip invalid entries that are rejected by
the kernel. It's really just
for_each_context_engine()
for_each_if(gem_has_ring())
and I think I should drop the second loop here and focus on testing that
for_each_context_engine() simply reports back the class:inst we put
into the context.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t 2/4] i915/gem_ctx_engine: Exercise for_each_context_engine() with custom engine[]
From: Chris Wilson @ 2020-02-14 21:57 UTC (permalink / raw)
To: Antonio Argenziano, intel-gfx; +Cc: igt-dev
In-Reply-To: <224cefba-4b48-c085-b0b5-952b62af29b3@intel.com>
Quoting Antonio Argenziano (2020-02-14 21:49:16)
>
>
> On 14/02/20 11:40, Chris Wilson wrote:
> > Set up a custom engine map with no engines, and check that the
> > for_each_context_engine() correctly iterates over nothing.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> > tests/i915/gem_ctx_engines.c | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
> > index 063140e0f..6a2edd1e0 100644
> > --- a/tests/i915/gem_ctx_engines.c
> > +++ b/tests/i915/gem_ctx_engines.c
> > @@ -549,6 +549,31 @@ static void independent(int i915)
> > gem_context_destroy(i915, param.ctx_id);
> > }
> >
> > +static void libapi(int i915)
> > +{
> > + struct i915_context_param_engines engines = {};
>
> Is there a case for invalid engines as well?
One would have to think what the behaviour should be :)
for_each_context_engine() should iterate over every engine defined,
providing you with (e->class, e->instance, e->pretty_name).
Invalid will still have an entry, maybe with "unknown".
for_each_physical_engine would skip invalid entries that are rejected by
the kernel. It's really just
for_each_context_engine()
for_each_if(gem_has_ring())
and I think I should drop the second loop here and focus on testing that
for_each_context_engine() simply reports back the class:inst we put
into the context.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices
From: Jason A. Donenfeld @ 2020-02-14 21:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Netdev
In-Reply-To: <ec52e8cb-5649-9167-bb14-7e9775c6a8be@gmail.com>
Hey Eric,
On Fri, Feb 14, 2020 at 7:53 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > The before passings off to the udp tunnel api, we indicate that we
> > support ip segmentation, and then it gets handled and fragmented
> > deeper down. Check out socket.c.
>
> Okay. Speaking of socket.c, I found this wg_socket_reinit() snippet :
>
> synchronize_rcu();
> synchronize_net();
>
> Which makes little sense. Please add a comment explaining why these two
> calls are needed.
Thanks, I appreciate your scrutiny here. Right again, you are. It
looks like that was added in 2017 after observing the pattern in other
drivers and seeing the documentation comment, "Wait for packets
currently being received to be done." That sounds like an important
thing to do before tearing down a socket. But here it makes no sense
at all, since synchronize_net() is just a wrapper around
synchronize_rcu() (and sometimes _expedited). And here, the
synchronize_rcu() usage makes sense to have, since this is as boring
of an rcu pattern as can be:
mutex_lock()
old = rcu_dereference_protected(x->y)
rcu_assign(x->y, new)
mutex_unlock()
synchronize_rcu()
free_it(old)
Straight out of the documentation. Having the extra synchronize_net()
in there adds nothing at all. I'll send a v3 of this 5.6-rc2 cleanup
series containing that removal.
Jason
^ permalink raw reply
* Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
From: Jim Mattson @ 2020-02-14 21:56 UTC (permalink / raw)
To: Chia-I Wu
Cc: Sean Christopherson, Paolo Bonzini, kvm list, Vitaly Kuznetsov,
Wanpeng Li, Joerg Roedel, Gurchetan Singh, Gerd Hoffmann,
ML dri-devel
In-Reply-To: <CAPaKu7Q4gehyhEgG_Nw=tiZiTh+7A8-uuXq1w4he6knp6NWErQ@mail.gmail.com>
On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu <olvaffe@gmail.com> wrote:
>
> On Fri, Feb 14, 2020 at 11:52 AM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> >
> > 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.
> This is my understanding as well.
>
> > > 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.
>
> What we need potentially gives the userspace (the guest kernel, to be
> exact) the ability to create conflicting memory types. If we can be
> sure that the worst scenario is for a guest to corrupt its own memory,
> by only allowing aliases on physical ram, that seems alright.
>
> AFAICT, it is currently allowed on ARM (verified) and AMD (not
> verified, but svm_get_mt_mask returns 0 which supposedly means the NPT
> does not restrict what the guest PAT can do). This diff would do the
> trick for Intel without needing any uapi change:
I would be concerned about Intel CPU errata such as SKX40 and SKX59.
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 253/542] PCI/ATS: Restore EXPORT_SYMBOL_GPL() for pci_{enable,disable}_ats()
From: Greg Kroah-Hartman @ 2020-02-14 21:47 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Greg Kroah-Hartman, Bjorn Helgaas,
Joerg Roedel, Will Deacon, John Garry, linux-pci
In-Reply-To: <20200214154854.6746-253-sashal@kernel.org>
On Fri, Feb 14, 2020 at 10:44:05AM -0500, Sasha Levin wrote:
> From: Greg Kroah-Hartman <gregkh@google.com>
>
> [ Upstream commit bb950bca5d522119f8b9ce3f6cbac4841c6d6517 ]
>
> Commit d355bb209783 ("PCI/ATS: Remove unnecessary EXPORT_SYMBOL_GPL()")
> unexported a bunch of symbols from the PCI core since the only external
> users were non-modular IOMMU drivers. Although most of those symbols
> can remain private for now, 'pci_{enable,disable_ats()' is required for
> the ARM SMMUv3 driver to build as a module, otherwise we get a build
> failure as follows:
>
> | ERROR: "pci_enable_ats" [drivers/iommu/arm-smmu-v3.ko] undefined!
> | ERROR: "pci_disable_ats" [drivers/iommu/arm-smmu-v3.ko] undefined!
>
> Re-export these two functions so that the ARM SMMUv3 driver can be build
> as a module.
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Joerg Roedel <jroedel@suse.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
> [will: rewrote commit message]
> Signed-off-by: Will Deacon <will@kernel.org>
> Tested-by: John Garry <john.garry@huawei.com> # smmu v3
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/pci/ats.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index b6f064c885c37..3ef0bb281e7cc 100644
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
> @@ -69,6 +69,7 @@ int pci_enable_ats(struct pci_dev *dev, int ps)
> dev->ats_enabled = 1;
> return 0;
> }
> +EXPORT_SYMBOL_GPL(pci_enable_ats);
>
> /**
> * pci_disable_ats - disable the ATS capability
> @@ -87,6 +88,7 @@ void pci_disable_ats(struct pci_dev *dev)
>
> dev->ats_enabled = 0;
> }
> +EXPORT_SYMBOL_GPL(pci_disable_ats);
>
> void pci_restore_ats_state(struct pci_dev *dev)
> {
> --
> 2.20.1
>
This isn't needed to be backported as the problem it solves is not in
the 5.5 or older kernels, it only showed up in 5.6-rc1, and this was
part of a larger patchset.
So please drop from everywhere, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 496/542] char: hpet: Fix out-of-bounds read bug
From: Greg Kroah-Hartman @ 2020-02-14 21:48 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Gustavo A. R. Silva, Tetsuo Handa,
Eric Biggers
In-Reply-To: <20200214154854.6746-496-sashal@kernel.org>
On Fri, Feb 14, 2020 at 10:48:08AM -0500, Sasha Levin wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
>
> [ Upstream commit 98c49f1746ac44ccc164e914b9a44183fad09f51 ]
>
> Currently, there is an out-of-bounds read on array hpetp->hp_dev
> in the following for loop:
>
> 870 for (i = 0; i < hdp->hd_nirqs; i++)
> 871 hpetp->hp_dev[i].hd_hdwirq = hdp->hd_irq[i];
>
> This is due to the recent change from one-element array to
> flexible-array member in struct hpets:
>
> 104 struct hpets {
> ...
> 113 struct hpet_dev hp_dev[];
> 114 };
>
> This change affected the total size of the dynamic memory
> allocation, decreasing it by one time the size of struct hpet_dev.
>
> Fix this by adjusting the allocation size when calling
> struct_size().
>
> Fixes: 987f028b8637c ("char: hpet: Use flexible-array member")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Acked-by: Eric Biggers <ebiggers@kernel.org>
> Link: https://lore.kernel.org/r/20200129022613.GA24281@embeddedor.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/char/hpet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index aed2c45f7968c..ed3b7dab678db 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -855,7 +855,7 @@ int hpet_alloc(struct hpet_data *hdp)
> return 0;
> }
>
> - hpetp = kzalloc(struct_size(hpetp, hp_dev, hdp->hd_nirqs - 1),
> + hpetp = kzalloc(struct_size(hpetp, hp_dev, hdp->hd_nirqs),
> GFP_KERNEL);
>
> if (!hpetp)
> --
> 2.20.1
>
Not needed unless you have the other patch that I asked you to drop
added :)
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 456/542] char: hpet: Use flexible-array member
From: Greg Kroah-Hartman @ 2020-02-14 21:48 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, stable, Gustavo A. R. Silva
In-Reply-To: <20200214154854.6746-456-sashal@kernel.org>
On Fri, Feb 14, 2020 at 10:47:28AM -0500, Sasha Levin wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
>
> [ Upstream commit 987f028b8637cfa7658aa456ae73f8f21a7a7f6f ]
>
> Old code in the kernel uses 1-byte and 0-byte arrays to indicate the
> presence of a "variable length array":
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> instance->length = size;
> memcpy(instance->data, source, size);
>
> There is also 0-byte arrays. Both cases pose confusion for things like
> sizeof(), CONFIG_FORTIFY_SOURCE, etc.[1] Instead, the preferred mechanism
> to declare variable-length types such as the one above is a flexible array
> member[2] which need to be the last member of a structure and empty-sized:
>
> struct something {
> int stuff;
> u8 data[];
> };
>
> Also, by making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> unadvertenly introduced[3] to the codebase from now on.
>
> [1] https://github.com/KSPP/linux/issues/21
> [2] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Link: https://lore.kernel.org/r/20200120235326.GA29231@embeddedor.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/char/hpet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 9ac6671bb5141..aed2c45f7968c 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -110,7 +110,7 @@ struct hpets {
> unsigned long hp_delta;
> unsigned int hp_ntimer;
> unsigned int hp_which;
> - struct hpet_dev hp_dev[1];
> + struct hpet_dev hp_dev[];
> };
>
> static struct hpets *hpets;
> --
> 2.20.1
>
Not needed, please drop from all trees. Along with the other hpet patch
that fixes the bug this one introduced :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 188/542] tty: omap-serial: remove set but unused variable
From: Greg Kroah-Hartman @ 2020-02-14 21:50 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Xiongfeng Wang, Hulk Robot, linux-serial
In-Reply-To: <20200214154854.6746-188-sashal@kernel.org>
On Fri, Feb 14, 2020 at 10:43:00AM -0500, Sasha Levin wrote:
> From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>
> [ Upstream commit e83c6587c47caa2278aa3bd603b5a85eddc4cec9 ]
>
> Fix the following warning:
> drivers/tty/serial/omap-serial.c: In function serial_omap_rlsi:
> drivers/tty/serial/omap-serial.c:496:16: warning: variable ch set but not used [-Wunused-but-set-variable]
>
> The character read is useless according to the table 23-246 of the omap4
> TRM. So we can drop it.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Link: https://lore.kernel.org/r/1575617863-32484-1-git-send-email-wangxiongfeng2@huawei.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/tty/serial/omap-serial.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 6420ae581a802..5f808d8dfcd5c 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -493,10 +493,13 @@ static unsigned int check_modem_status(struct uart_omap_port *up)
> static void serial_omap_rlsi(struct uart_omap_port *up, unsigned int lsr)
> {
> unsigned int flag;
> - unsigned char ch = 0;
>
> + /*
> + * Read one data character out to avoid stalling the receiver according
> + * to the table 23-246 of the omap4 TRM.
> + */
> if (likely(lsr & UART_LSR_DR))
> - ch = serial_in(up, UART_RX);
> + serial_in(up, UART_RX);
>
> up->port.icount.rx++;
> flag = TTY_NORMAL;
> --
> 2.20.1
>
Please drop.
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 200/542] tty: serial: amba-pl011: remove set but unused variable
From: Greg Kroah-Hartman @ 2020-02-14 21:50 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Xiongfeng Wang, Hulk Robot, linux-serial
In-Reply-To: <20200214154854.6746-200-sashal@kernel.org>
On Fri, Feb 14, 2020 at 10:43:12AM -0500, Sasha Levin wrote:
> From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>
> [ Upstream commit 94345aee285334e9e12fc70572e3d9380791a64e ]
>
> Fix the following warning:
> drivers/tty/serial/amba-pl011.c: In function check_apply_cts_event_workaround:
> drivers/tty/serial/amba-pl011.c:1461:15: warning: variable dummy_read set but not used [-Wunused-but-set-variable]
>
> The data read is useless and can be dropped.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Link: https://lore.kernel.org/r/1575619526-34482-1-git-send-email-wangxiongfeng2@huawei.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/tty/serial/amba-pl011.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 4b28134d596a9..c5e9475feb47a 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -1452,8 +1452,6 @@ static void pl011_modem_status(struct uart_amba_port *uap)
>
> static void check_apply_cts_event_workaround(struct uart_amba_port *uap)
> {
> - unsigned int dummy_read;
> -
> if (!uap->vendor->cts_event_workaround)
> return;
>
> @@ -1465,8 +1463,8 @@ static void check_apply_cts_event_workaround(struct uart_amba_port *uap)
> * single apb access will incur 2 pclk(133.12Mhz) delay,
> * so add 2 dummy reads
> */
> - dummy_read = pl011_read(uap, REG_ICR);
> - dummy_read = pl011_read(uap, REG_ICR);
> + pl011_read(uap, REG_ICR);
> + pl011_read(uap, REG_ICR);
> }
>
> static irqreturn_t pl011_int(int irq, void *dev_id)
> --
> 2.20.1
>
Please drop.
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 222/542] Revert "tty/serial: atmel: fix out of range clock divider handling"
From: Greg Kroah-Hartman @ 2020-02-14 21:51 UTC (permalink / raw)
To: Sasha Levin
Cc: Stephen Rothwell, linux-kernel, stable, linux-serial,
David Engraf, linux-arm-kernel
In-Reply-To: <20200214154854.6746-222-sashal@kernel.org>
On Fri, Feb 14, 2020 at 10:43:34AM -0500, Sasha Levin wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> [ Upstream commit 6dbd54e4154dfe386b3333687de15be239576617 ]
>
> This reverts commit 751d0017334db9c4d68a8909c59f662a6ecbcec6.
>
> The wrong commit got added to the tty-next tree, the correct one is in
> the tty-linus branch.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: David Engraf <david.engraf@sysgo.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/tty/serial/atmel_serial.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 1ba9bc667e136..ab4d4a0b36497 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2270,6 +2270,9 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> mode |= ATMEL_US_USMODE_NORMAL;
> }
>
> + /* set the mode, clock divisor, parity, stop bits and data size */
> + atmel_uart_writel(port, ATMEL_US_MR, mode);
> +
> /*
> * Set the baud rate:
> * Fractional baudrate allows to setup output frequency more
> --
> 2.20.1
>
Are you sure this is correct to be added? This was the result of some
fun merge problems, I don't think it's needed anywhere else...
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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.