All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 10/11] xfs: improve ondisk dquot flags checking
From: Darrick J. Wong @ 2020-07-17  1:12 UTC (permalink / raw)
  To: linux-xfs, Dave Chinner
In-Reply-To: <159488198306.3813063.16348101518917273554.stgit@magnolia>

From: Darrick J. Wong <darrick.wong@oracle.com>

Create an XFS_DQTYPE_ANY mask for ondisk dquots flags, and use that to
ensure that we never accept any garbage flags when we're loading dquots.
While we're at it, restructure the quota type flag checking to use the
proper masking.

Note that I plan to add y2038 support soon, which will require a new
xfs_dqtype_t flag for extended timestamp support, hence all the work to
make the type masking work correctly.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
v2: amend commit message
---
 fs/xfs/libxfs/xfs_dquot_buf.c |   11 ++++++++---
 fs/xfs/libxfs/xfs_format.h    |    2 ++
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/libxfs/xfs_dquot_buf.c b/fs/xfs/libxfs/xfs_dquot_buf.c
index 75c164ed141c..39d64fbc6b87 100644
--- a/fs/xfs/libxfs/xfs_dquot_buf.c
+++ b/fs/xfs/libxfs/xfs_dquot_buf.c
@@ -39,6 +39,8 @@ xfs_dquot_verify(
 	struct xfs_disk_dquot	*ddq,
 	xfs_dqid_t		id)	/* used only during quotacheck */
 {
+	__u8			ddq_type;
+
 	/*
 	 * We can encounter an uninitialized dquot buffer for 2 reasons:
 	 * 1. If we crash while deleting the quotainode(s), and those blks got
@@ -59,9 +61,12 @@ xfs_dquot_verify(
 	if (ddq->d_version != XFS_DQUOT_VERSION)
 		return __this_address;
 
-	if (ddq->d_flags != XFS_DQTYPE_USER &&
-	    ddq->d_flags != XFS_DQTYPE_PROJ &&
-	    ddq->d_flags != XFS_DQTYPE_GROUP)
+	if (ddq->d_flags & ~XFS_DQTYPE_ANY)
+		return __this_address;
+	ddq_type = ddq->d_flags & XFS_DQTYPE_REC_MASK;
+	if (ddq_type != XFS_DQTYPE_USER &&
+	    ddq_type != XFS_DQTYPE_PROJ &&
+	    ddq_type != XFS_DQTYPE_GROUP)
 		return __this_address;
 
 	if (id != -1 && id != be32_to_cpu(ddq->d_id))
diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
index 0fa969f6202c..29564bd32bef 100644
--- a/fs/xfs/libxfs/xfs_format.h
+++ b/fs/xfs/libxfs/xfs_format.h
@@ -1158,6 +1158,8 @@ static inline void xfs_dinode_put_rdev(struct xfs_dinode *dip, xfs_dev_t rdev)
 				 XFS_DQTYPE_PROJ | \
 				 XFS_DQTYPE_GROUP)
 
+#define XFS_DQTYPE_ANY		(XFS_DQTYPE_REC_MASK)
+
 /*
  * This is the main portion of the on-disk representation of quota information
  * for a user.  We pad this with some more expansion room to construct the on

^ permalink raw reply related

* [PATCH] sandbox: enable FIT cipher support in defconfig
From: patrick.oppenlander at gmail.com @ 2020-07-17  1:12 UTC (permalink / raw)
  To: u-boot

From: Patrick Oppenlander <patrick.oppenlander@gmail.com>

Linux distributions generally use the "make defconfig && make tools-all"
recipe to generate a uboot-tools (or similar) package.

This patch enables FIT cipher support in the default mkimage build.

Signed-off-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
---
 configs/sandbox_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 9b74e404bb..002e4c7d66 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -7,6 +7,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_CIPHER=y
 CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_BOOTSTAGE=y
-- 
2.27.0

^ permalink raw reply related

* Re: [PATCH 10/11] xfs: improve ondisk dquot flags checking
From: Dave Chinner @ 2020-07-17  1:11 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <20200717010528.GK3151642@magnolia>

On Thu, Jul 16, 2020 at 06:05:28PM -0700, Darrick J. Wong wrote:
> On Fri, Jul 17, 2020 at 10:13:59AM +1000, Dave Chinner wrote:
> > On Wed, Jul 15, 2020 at 11:46:23PM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <darrick.wong@oracle.com>
> > > 
> > > Create an XFS_DQTYPE_ANY mask for ondisk dquots flags, and use that to
> > > ensure that we never accept any garbage flags when we're loading dquots.
> > > While we're at it, restructure the quota type flag checking to use the
> > > proper masking.
> > > 
> > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > ---
> > >  fs/xfs/libxfs/xfs_dquot_buf.c |   11 ++++++++---
> > >  fs/xfs/libxfs/xfs_format.h    |    2 ++
> > >  2 files changed, 10 insertions(+), 3 deletions(-)
> > 
> > Ok, I looked at this and questioned why it existed and why the
> > code didn't just use XFS_DQTYPE_REC_MASK directly. I think this
> > change exists because you plan on adding a new on-disk flag for
> > bigtime support and hence XFS_DQTYPE_ANY will grow to include the
> > new flag, right?
> 
> Correct.
> 
> > If so, can you add that to the commit message?
> 
> Ok, will do.

Thanks. With that:

Reviewed-by: Dave Chinner <dchinner@redhat.com>

-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply

* Re: Filesystem Went Read Only During Raid-10 to Raid-6 Data Conversion
From: John Petrini @ 2020-07-17  1:11 UTC (permalink / raw)
  To: Zygo Blaxell; +Cc: John Petrini, linux-btrfs
In-Reply-To: <20200716225731.GI10769@hungrycats.org>

On Thu, Jul 16, 2020 at 6:57 PM Zygo Blaxell
<ce3g8jdj@umail.furryterror.org> wrote:
>
> On Thu, Jul 16, 2020 at 10:20:43AM -0400, John Petrini wrote:
> >    I've cleaned up a bit more space and kicked off a balance. btrfs fi usage
> >    is reporting increased unallocated space so it seems to be helping.
> >    sudo btrfs balance start -dusage=50 /mnt/storage-array/
> >    During one of my attempts to clean up space the filesystem went read only
> >    again with the same out of space error. I'm curious why deleting files
> >    would cause this.
>
> Deleting a file requires writing a new tree with the file not present.
> That requires some extra space...
>
> >    On Thu, Jul 16, 2020 at 9:38 AM John Petrini <[1]john.d.petrini@gmail.com>
> >    wrote:
> >
> >      On Thu, Jul 16, 2020 at 12:27 AM Zygo Blaxell
> >      <[2]ce3g8jdj@umail.furryterror.org> wrote:
> >      >
> >      > On Tue, Jul 14, 2020 at 10:49:08PM -0400, John Petrini wrote:
> >      > > I've done this and the filesystem mounted successfully though when
> >      > > attempting to cancel the balance it just tells me it's not running.
> >      >
> >      > That's fine, as long as it stops one way or another.
> >      >
> >      > > > Aside:  data-raid6 metadata-raid10 isn't a sane configuration.  It
> >      > > > has 2 redundant disks for data and 1 redundant disk for metadata,
> >      so
> >      > > > the second parity disk in raid6 is wasted space.
> >      > > >
> >      > > > The sane configurations for parity raid are:
> >      > > >
> >      > > >         data-raid6 metadata-raid1c3 (2 parity stripes for data, 3
> >      copies
> >      > > >         for metadata, 2 disks can fail, requires 3 or more disks)
> >      > > >
> >      > > >         data-raid5 metadata-raid10 (1 parity stripe for data, 2
> >      copies
> >      > > >         for metadata, 1 disk can fail, requires 4 or more disks)
> >      > > >
> >      > > >         data-raid5 metadata-raid1 (1 parity stripe for data, 2
> >      copies
> >      > > >         for metadata, 1 disk can fail, requires 2 or more disks)
> >      > > >
> >      > >
> >      > > This is very interesting. I had no idea that raid1c3 was an option
> >      > > though it sounds like I may need a really recent kernel version?
> >      >
> >      > 5.5 or later.
> >
> >      Okay I'll look into getting on this version since that's a killer
> >      feature.
> >
> >      >
> >      > > btrfs fi usage /mnt/storage-array/
> >      > > WARNING: RAID56 detected, not implemented
> >      > > Overall:
> >      > >     Device size:          67.31TiB
> >      > >     Device allocated:          65.45TiB
> >      > >     Device unallocated:           1.86TiB
> >      > >     Device missing:             0.00B
> >      > >     Used:              65.14TiB
> >      > >     Free (estimated):           1.12TiB    (min: 1.09TiB)
> >      > >     Data ratio:                  1.94
> >      > >     Metadata ratio:              2.00
> >      > >     Global reserve:         512.00MiB    (used: 0.00B)
> >      > >
> >      > > Data,RAID10: Size:32.68TiB, Used:32.53TiB
> >      > >    /dev/sda       4.34TiB
> >      > >    /dev/sdb       4.34TiB
> >      > >    /dev/sdc       4.34TiB
> >      > >    /dev/sdd       2.21TiB
> >      > >    /dev/sde       2.21TiB
> >      > >    /dev/sdf       4.34TiB
> >      > >    /dev/sdi       1.82TiB
> >      > >    /dev/sdj       1.82TiB
> >      > >    /dev/sdk       1.82TiB
> >      > >    /dev/sdl       1.82TiB
> >      > >    /dev/sdm       1.82TiB
> >      > >    /dev/sdn       1.82TiB
> >      > >
> >      > > Data,RAID6: Size:1.04TiB, Used:1.04TiB
> >      > >    /dev/sda     413.92GiB
> >      > >    /dev/sdb     413.92GiB
> >      > >    /dev/sdc     413.92GiB
> >      > >    /dev/sdd     119.07GiB
> >      > >    /dev/sde     119.07GiB
> >      > >    /dev/sdf     413.92GiB
> >      > >
> >      > > Metadata,RAID10: Size:40.84GiB, Used:39.80GiB
> >      > >    /dev/sda       5.66GiB
> >      > >    /dev/sdb       5.66GiB
> >      > >    /dev/sdc       5.66GiB
> >      > >    /dev/sdd       2.41GiB
> >      > >    /dev/sde       2.41GiB
> >      > >    /dev/sdf       5.66GiB
> >      > >    /dev/sdi       2.23GiB
> >      > >    /dev/sdj       2.23GiB
> >      > >    /dev/sdk       2.23GiB
> >      > >    /dev/sdl       2.23GiB
> >      > >    /dev/sdm       2.23GiB
> >      > >    /dev/sdn       2.23GiB
> >      > >
> >      > > System,RAID10: Size:96.00MiB, Used:3.06MiB
> >      > >    /dev/sda       8.00MiB
> >      > >    /dev/sdb       8.00MiB
> >      > >    /dev/sdc       8.00MiB
> >      > >    /dev/sdd       8.00MiB
> >      > >    /dev/sde       8.00MiB
> >      > >    /dev/sdf       8.00MiB
> >      > >    /dev/sdi       8.00MiB
> >      > >    /dev/sdj       8.00MiB
> >      > >    /dev/sdk       8.00MiB
> >      > >    /dev/sdl       8.00MiB
> >      > >    /dev/sdm       8.00MiB
> >      > >    /dev/sdn       8.00MiB
> >      > >
> >      > > Unallocated:
> >      > >    /dev/sda       4.35TiB
> >      > >    /dev/sdb       4.35TiB
> >      > >    /dev/sdc       4.35TiB
> >      > >    /dev/sdd       2.22TiB
> >      > >    /dev/sde       2.22TiB
> >      > >    /dev/sdf       4.35TiB
> >      > >    /dev/sdi       1.82TiB
> >      > >    /dev/sdj       1.82TiB
> >      > >    /dev/sdk       1.82TiB
> >      > >    /dev/sdl       1.82TiB
> >      > >    /dev/sdm       1.82TiB
> >      > >    /dev/sdn       1.82TiB
> >      >
> >      > Plenty of unallocated space.  It should be able to do the conversion.
> >
> >      After upgrading, the unallocated space tells a different story. Maybe
> >      due to the newer kernel or btrfs-progs?
>
> That is...odd.  Try 'btrfs dev usage', maybe something weird is happening
> with device sizes.

Here it is. I'm not sure what to make of it though.

sudo btrfs dev usage /mnt/storage-array/
/dev/sdd, ID: 1
   Device size:             4.55TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             2.78GiB
   Data,RAID10:           784.31GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            144.07GiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Metadata,RAID10:       352.00MiB
   Unallocated:             1.02MiB

/dev/sde, ID: 2
   Device size:             4.55TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             2.78GiB
   Data,RAID10:           784.31GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            144.07GiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Metadata,RAID10:       352.00MiB
   Unallocated:             1.02MiB

/dev/sdl, ID: 3
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Unallocated:             1.02MiB

/dev/sdn, ID: 4
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Unallocated:             1.02MiB

/dev/sdm, ID: 5
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Unallocated:             1.02MiB

/dev/sdk, ID: 6
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Unallocated:             1.02MiB

/dev/sdj, ID: 7
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Unallocated:             1.02MiB

/dev/sdi, ID: 8
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Unallocated:             1.02MiB

/dev/sdb, ID: 9
   Device size:             9.10TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             4.01TiB
   Data,RAID10:           784.31GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            458.56GiB
   Data,RAID6:            144.07GiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Metadata,RAID10:       352.00MiB
   Metadata,RAID10:         6.00GiB
   Metadata,RAID1C3:        2.00GiB
   System,RAID1C3:         32.00MiB
   Unallocated:            82.89GiB

/dev/sdc, ID: 10
   Device size:             9.10TiB
   Device slack:              0.00B
   Data,RAID10:             3.12GiB
   Data,RAID10:             4.01TiB
   Data,RAID10:           784.31GiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            458.56GiB
   Data,RAID6:            144.07GiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Metadata,RAID10:       352.00MiB
   Metadata,RAID10:         6.00GiB
   Metadata,RAID1C3:        3.00GiB
   Unallocated:            81.92GiB

/dev/sda, ID: 11
   Device size:             9.10TiB
   Device slack:              0.00B
   Data,RAID10:           784.31GiB
   Data,RAID10:             4.01TiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            458.56GiB
   Data,RAID6:            144.07GiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Metadata,RAID10:       352.00MiB
   Metadata,RAID10:         6.00GiB
   Metadata,RAID1C3:        5.00GiB
   System,RAID1C3:         32.00MiB
   Unallocated:            85.79GiB

/dev/sdf, ID: 12
   Device size:             9.10TiB
   Device slack:              0.00B
   Data,RAID10:           784.31GiB
   Data,RAID10:             4.01TiB
   Data,RAID10:             3.34TiB
   Data,RAID6:            458.56GiB
   Data,RAID6:            144.07GiB
   Data,RAID6:            293.03GiB
   Metadata,RAID10:         4.47GiB
   Metadata,RAID10:       352.00MiB
   Metadata,RAID10:         6.00GiB
   Metadata,RAID1C3:        5.00GiB
   System,RAID1C3:         32.00MiB
   Unallocated:            85.79GiB

>
> >      Unallocated:
> >         /dev/sdd        1.02MiB
> >         /dev/sde        1.02MiB
> >         /dev/sdl        1.02MiB
> >         /dev/sdn        1.02MiB
> >         /dev/sdm        1.02MiB
> >         /dev/sdk        1.02MiB
> >         /dev/sdj        1.02MiB
> >         /dev/sdi        1.02MiB
> >         /dev/sdb        1.00MiB
> >         /dev/sdc        1.00MiB
> >         /dev/sda        5.90GiB
> >         /dev/sdg        5.90GiB
>
> ...and here we have only 2 disks with free space, so there's zero available
> space for more metadata (raid10 requires 4 disks).
>
> >      This is after clearing up additional space on the filesytem. When I
> >      started the conversion there was only ~300G available. There's now
> >      close 1TB according to df.
> >
> >      /dev/sdd                      68T   66T  932G  99% /mnt/storage-array
> >
> >      So I'm not sure what to make of this and whether it's safe to start
> >      the conversion again. I don't feel like I can trust the unallocated
> >      space before or after the upgrade.
> >
> >      Here's the versions I'm on now:
> >      sudo dpkg -l | grep btrfs-progs
> >      ii  btrfs-progs                            5.4.1-2
> >              amd64        Checksumming Copy on Write Filesystem utilities
> >
> >      uname -r
> >      5.4.0-40-generic
> >
> >      >
> >      > > > You didn't post the dmesg messages from when the filesystem went
> >      > > > read-only, but metadata 'total' is very close to 'used', you were
> >      doing
> >      > > > a balance, and the filesystem went read-only, so I'm guessing you
> >      hit
> >      > > > ENOSPC for metadata due to lack of unallocated space on at least 4
> >      drives
> >      > > > (minimum for raid10).
> >      > > >
> >      > >
> >      > > Here's a paste of everything in dmesg:
> >      [3]http://paste.openstack.org/show/795929/
> >      >
> >      > Unfortunately the original errors are no longer in the buffer.  Maybe
> >      > try /var/log/kern.log?
> >      >
> >
> >      Found it. So this was a space issue. I knew the filesystem was very
> >      full but figured ~300G would be enough.
> >
> >      kernel: [3755232.352221] BTRFS: error (device sdd) in
> >      __btrfs_free_extent:4860: errno=-28 No space left
> >      kernel: [3755232.352227] BTRFS: Transaction aborted (error -28)
> >      ernel: [3755232.354693] BTRFS info (device sdd): forced readonly
> >      kernel: [3755232.354700] BTRFS: error (device sdd) in
> >      btrfs_run_delayed_refs:2795: errno=-28 No space left
>
> The trick is that the free space has to be unallocated to change profiles.
> 'df' counts both unallocated and allocated-but-unused space.
>
> Also you have disks of different sizes, which adds an additional
> complication: raid6 data on 3 disks takes up more space for the same data
> than raid10 data on 4 disks, because the former is 1 data + 2 parity,
> while the latter is 1 data + 1 mirror.  So for 100 GB of data, it's 200
> GB of raw space in raid10 on 4 disks, or 200GB of raw space in raid6 on
> 4 disks, but 300 GB of raw space in raid6 on 3 disks.
>
> Since your filesystem is nearly full, there are likely to be 3-disk-wide
> raid6 block groups formed when there is space available on only 3 drives.
> If that happens too often, hundreds of GB will be wasted and the filesystem
> fills up.
>
> To convert raid10 to raid6 on a full filesystem with unequal disk sizes
> you'll need to do a few steps:
>
>         1.  balance -dconvert=raid1,stripes=1..3,profiles=raid6
>
> This converts any 3-stripe raid6 to raid1, which will get some wasted
> space back.  Use raid1 here because it's more flexible for allocation
> on small numbers of disks than raid10.  We will get rid of it later.
>
>         2.  balance -dconvert=raid1,devid=1,limit=5
>             balance -dconvert=raid1,devid=2,limit=5
>             balance -dconvert=raid1,devid=3,limit=5
>             balance -dconvert=raid1,devid=6,limit=5
>
> Use btrfs fi show to see the real devids for these, I just put sequential
> numbers in the above.
>
> These balances relocate data on the 4.34TB drives to other disks in
> the array.  The goal is to get some unallocated space on all of the
> largest disks so you can create raid6 block groups that span all of them.
>
> We convert to raid1 to get more flexible redistribution of the
> space--raid10 will keep trying to fill every available drive, and has
> a 4-disk minimum, while raid1 will try to equally distribute space on
> all drives but only 2 at a time.  'soft' is not used here because we
> want to relocate block groups on these devices whether they are already
> raid1 or not.
>
> Note that if there is 5GB free on all the largest disks we can skip
> this entire step.  If there is not 5GB free on all the largest disks
> at the end of the above commands, you may need to repeat this step,
> or try 'balance -dconvert=raid1,limit=50' to try to force free space
> on all disks in the array.
>
>         3.  balance -dconvert=raid6,soft,devid=1
>
> This converts all data block groups that have at least one chunk on devid
> 1 (or any disk of the largest size in the array) from raid10 to raid6.
> This will ensure that every chunk that is added to devid 1 has at least
> one corresponding chunk that is removed from devid 1.  That way, devid
> 1 doesn't fill up; instead, it will stay with a few GB unallocated.
> The other disks will get unallocated space because a raid6 block group
> that is at least 4 disks wide will store more data in the same raw space
> than raid10.
>
> At this stage it doesn't matter where the space is coming from, as long as
> it's coming from a minimum of 4 other disks, and not filling up devid 1.
> Some block groups will not be optimal.  We'll optimize later.
>
> Eventually you'll get to the point where there is unallocated space on
> all disks, and then the balance will finish converting the data to raid6
> without further attention.
>
>         4.  balance -dstripes=1..3,devid=1  # sda, 4.34TB
>             balance -dstripes=1..3,devid=2  # sdb, 4.34TB
>             balance -dstripes=1..3,devid=3  # sdc, 4.34TB
>             balance -dstripes=1..5,devid=4  # sdd, 2.21TB
>             balance -dstripes=1..5,devid=5  # sde, 2.21TB
>             balance -dstripes=1..3,devid=6  # sdf, 4.34TB
>             balance -dstripes=1..9,devid=7  # sdg, 1.82TB
>             balance -dstripes=1..9,devid=8  # sdh, 1.82TB
>             balance -dstripes=1..9,devid=9  # sdi, 1.82TB
>             balance -dstripes=1..9,devid=10 # sdj, 1.82TB
>
> This rebalances any narrow stripes that may have formed during the
> previous balances.  For each device we calculate how many disks are
> the same or equal size, and rebalance any block group that is not
> that number of disks wide:
>
>         There are 4 4.34TB disks, so we balance any block group
>         on a 4.34TB disk that is 1 to (4-1) = 3 stripes wide.
>
>         There are 6 2.21TB-or-larger disks (2x2.21TB + 4x4.34TB), so we
>         balance any block group on a 2.21TB disk that is 1 to (6-1) =
>         5 stripes wide.
>
>         There are 10 1.82TB-or-larger disks (this is the smallest size
>         disk, so all 10 disks are equal or larger), so we balance any
>         block group on a 1.82TB disk that is 1 to (10-1) = 9 stripes wide.
>
> These balances will only relocate non-optimal block groups, so each one
> should not relocate many block groups.  If 'btrfs balance status -v' says
> it's relocating thousands of block groups, check the stripe count and
> devid--if you use the wrong stripe count it will unnecessarily relocate
> all the data on the device.
>
>         5.  balance -mconvert=raid1c3,soft
>
> The final step converts metadata from raid10 to raid1c3.  (requires
> kernel 5.5)

Wow looks like I've got lots of info to mull over here! I kicked off
another convert already after cleaning up quite a bit more space. I
had over 100G unallocated on each device after deleting some data and
running another balance. I'm tempted to let it run and see if it
succeeds but my unallocated space has already dropped off a cliff with
95% of the rebalance remaining.

The command I used was: btrfs fi balance start -dconvert=raid6,soft
-mconvert=raid1c3 /mnt/storage-array/

Here's the current unallocated with only 5% of the conversion complete.
Unallocated:
   /dev/sdd        1.02MiB
   /dev/sde        1.02MiB
   /dev/sdl        1.02MiB
   /dev/sdn        1.02MiB
   /dev/sdm        1.02MiB
   /dev/sdk        1.02MiB
   /dev/sdj        1.02MiB
   /dev/sdi        1.02MiB
   /dev/sdb       82.89GiB
   /dev/sdc       81.92GiB
   /dev/sda       85.79GiB
   /dev/sdf       85.79GiB

>
>
>
> >      > > > > uname -r
> >      > > > > 5.3.0-40-generic
> >      > > >
> >      > > > Please upgrade to 5.4.13 or later.  Kernels 5.1 through 5.4.12
> >      have a
> >      > > > rare but nasty bug that is triggered by writing at exactly the
> >      wrong
> >      > > > moment during balance.  5.3 has some internal defenses against
> >      that bug
> >      > > > (the "write time tree checker"), but if they fail, the result is
> >      metadata
> >      > > > corruption that requires btrfs check to repair.
> >      > > >
> >      > >
> >      > > Thanks for the heads up. I'm getting it updated now and will attempt
> >      > > to remount once I do. Once it's remounted how should I proceed? Can
> >      I
> >      > > just assume the filesystem is healthy at that point? Should I
> >      perform
> >      > > a scrub?
> >      >
> >      > If scrub reports no errors it's probably OK.
> >
> >      I did run a scrub and it came back clean.
> >
> >      >
> >      > A scrub will tell you if any data or metadata is corrupted or any
> >      > parent-child pointers are broken.  That will cover most of the common
> >      > problems.  If the original issue was a spurious ENOSPC then everything
> >      > should be OK.  If the original issue was a write time tree corruption
> >      > then it should be OK.  If the original issue was something else, it
> >      > will present itself again during the scrub or balance.
> >      >
> >      > If there are errors, scrub won't attribute them to the right disks for
> >      > raid6.  It might be worth reading
> >      >
> >      >
> >       [4]https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/
> >      >
> >      > for a list of current raid5/6 issues to be aware of.
> >
> >      Thanks. This is good info.
> >
> >    --
> >    John Petrini
> >
> > References
> >
> >    Visible links
> >    1. mailto:john.d.petrini@gmail.com
> >    2. mailto:ce3g8jdj@umail.furryterror.org
> >    3. http://paste.openstack.org/show/795929/
> >    4. https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/



-- 
---------------------------------------
John Petrini

^ permalink raw reply

* [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap
From: Kunihiko Hayashi @ 2020-07-17  1:10 UTC (permalink / raw)
  To: Sumit Semwal, Andrew F . Davis, Benjamin Gaignard, Liam Mark,
	Laura Abbott, Brian Starkey, John Stultz, Christian Koenig
  Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel,
	Kunihiko Hayashi

Current dma-buf heaps can handle only default CMA. This introduces
dma_heap_add_cma() function to attach CMA heaps that belongs to a device.

At first, the driver calls of_reserved_mem_device_init() to set
memory-region property associated with reserved-memory defined as CMA
to the device. And when the driver calls this dma_heap_add_cma(),
the CMA will be added to dma-buf heaps.

For example, prepare CMA node named "linux,cma@10000000" and
specify the node for memory-region property. After the above calls
in the driver, a device file "/dev/dma_heap/linux,cma@10000000"
associated with the CMA become available as dma-buf heaps.

Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
 drivers/dma-buf/heaps/cma_heap.c | 12 ++++++++++++
 include/linux/dma-heap.h         |  9 +++++++++
 2 files changed, 21 insertions(+)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 626cf7f..5d2442e 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -162,6 +162,18 @@ static int __add_cma_heap(struct cma *cma, void *data)
 	return 0;
 }
 
+/* add device CMA heap to dmabuf heaps */
+int dma_heap_add_cma(struct device *dev)
+{
+	struct cma *cma = dev_get_cma_area(dev);
+
+	if (!cma)
+		return -ENOMEM;
+
+	return __add_cma_heap(cma, NULL);
+}
+EXPORT_SYMBOL_GPL(dma_heap_add_cma);
+
 static int add_default_cma_heap(void)
 {
 	struct cma *default_cma = dev_get_cma_area(NULL);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354..16bec7d 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -56,4 +56,13 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
  */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
+#ifdef CONFIG_DMABUF_HEAPS_CMA
+/**
+ * dma_heap_add_cma - adds a device CMA heap to dmabuf heaps
+ * @dev:	device with a CMA heap to register
+ */
+int dma_heap_add_cma(struct device *dev);
+
+#endif /* CONFIG_DMABUF_HEAPS_CMA */
+
 #endif /* _DMA_HEAPS_H */
-- 
2.7.4


^ permalink raw reply related

* Re: [PATCH v2 bpf-next 1/2] bpf: separate bpf_get_[stack|stackid] for perf events BPF
From: kernel test robot @ 2020-07-17  1:07 UTC (permalink / raw)
  To: Song Liu, linux-kernel, bpf, netdev
  Cc: kbuild-all, clang-built-linux, ast, daniel, kernel-team,
	john.fastabend, kpsingh, brouer, peterz
In-Reply-To: <20200715052601.2404533-2-songliubraving@fb.com>

[-- Attachment #1: Type: text/plain, Size: 5393 bytes --]

Hi Song,

I love your patch! Yet something to improve:

[auto build test ERROR on bpf-next/master]

url:    https://github.com/0day-ci/linux/commits/Song-Liu/bpf-fix-stackmap-on-perf_events-with-PEBS/20200715-133118
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: arm64-randconfig-r004-20200716 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project ed6b578040a85977026c93bf4188f996148f3218)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> kernel/bpf/stackmap.c:698:26: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
                   return __bpf_get_stack(ctx->regs, NULL, NULL, buf, size, flags);
                                          ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   kernel/bpf/stackmap.c:726:26: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
                           ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
                                                 ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   kernel/bpf/stackmap.c:740:26: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
                           ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
                                                 ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   kernel/bpf/stackmap.c:745:25: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
           return __bpf_get_stack(ctx->regs, NULL, trace, buf, size, flags);
                                  ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   4 errors generated.

vim +698 kernel/bpf/stackmap.c

   687	
   688	BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_event_data_kern *, ctx,
   689		   void *, buf, u32, size, u64, flags)
   690	{
   691		struct perf_event *event = ctx->event;
   692		struct perf_callchain_entry *trace;
   693		bool has_kernel, has_user;
   694		bool kernel, user;
   695		int err = -EINVAL;
   696	
   697		if (!(event->attr.sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY))
 > 698			return __bpf_get_stack(ctx->regs, NULL, NULL, buf, size, flags);
   699	
   700		if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
   701				       BPF_F_USER_BUILD_ID)))
   702			goto clear;
   703	
   704		user = flags & BPF_F_USER_STACK;
   705		kernel = !user;
   706	
   707		has_kernel = !event->attr.exclude_callchain_kernel;
   708		has_user = !event->attr.exclude_callchain_user;
   709	
   710		if ((kernel && !has_kernel) || (user && !has_user))
   711			goto clear;
   712	
   713		err = -EFAULT;
   714		trace = ctx->data->callchain;
   715		if (!trace || (!has_kernel && !has_user))
   716			goto clear;
   717	
   718		if (has_kernel && has_user) {
   719			__u64 nr_kernel = count_kernel_ip(trace);
   720			int ret;
   721	
   722			if (kernel) {
   723				__u64 nr = trace->nr;
   724	
   725				trace->nr = nr_kernel;
   726				ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
   727						      size, flags);
   728	
   729				/* restore nr */
   730				trace->nr = nr;
   731			} else { /* user */
   732				u64 skip = flags & BPF_F_SKIP_FIELD_MASK;
   733	
   734				skip += nr_kernel;
   735				if (skip > ~BPF_F_SKIP_FIELD_MASK)
   736					goto clear;
   737	
   738				flags = (flags & ~BPF_F_SKIP_FIELD_MASK) |
   739					(skip  & BPF_F_SKIP_FIELD_MASK);
   740				ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
   741						      size, flags);
   742			}
   743			return ret;
   744		}
   745		return __bpf_get_stack(ctx->regs, NULL, trace, buf, size, flags);
   746	clear:
   747		memset(buf, 0, size);
   748		return err;
   749	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38706 bytes --]

^ permalink raw reply

* Re: [PATCH v2] selftests: net: ip_defrag: modprobe missing nf_defrag_ipv6 support
From: Jakub Kicinski @ 2020-07-17  1:09 UTC (permalink / raw)
  To: Paolo Pisati
  Cc: David S . Miller, Shuah Khan, netdev, linux-kselftest,
	linux-kernel
In-Reply-To: <20200716155114.72625-1-paolo.pisati@canonical.com>

On Thu, 16 Jul 2020 17:51:14 +0200 Paolo Pisati wrote:
> Fix ip_defrag.sh when CONFIG_NF_DEFRAG_IPV6=m:
> 
> $ sudo ./ip_defrag.sh
> + set -e
> + mktemp -u XXXXXX
> + readonly NETNS=ns-rGlXcw
> + trap cleanup EXIT
> + setup
> + ip netns add ns-rGlXcw
> + ip -netns ns-rGlXcw link set lo up
> + ip netns exec ns-rGlXcw sysctl -w net.ipv4.ipfrag_high_thresh=9000000
> + ip netns exec ns-rGlXcw sysctl -w net.ipv4.ipfrag_low_thresh=7000000
> + ip netns exec ns-rGlXcw sysctl -w net.ipv4.ipfrag_time=1
> + ip netns exec ns-rGlXcw sysctl -w net.ipv6.ip6frag_high_thresh=9000000
> + ip netns exec ns-rGlXcw sysctl -w net.ipv6.ip6frag_low_thresh=7000000
> + ip netns exec ns-rGlXcw sysctl -w net.ipv6.ip6frag_time=1
> + ip netns exec ns-rGlXcw sysctl -w net.netfilter.nf_conntrack_frag6_high_thresh=9000000
> + cleanup
> + ip netns del ns-rGlXcw
> 
> $ ls -la /proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh
> ls: cannot access '/proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh': No such file or directory
> 
> $ sudo modprobe nf_defrag_ipv6
> $ ls -la /proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh
> -rw-r--r-- 1 root root 0 Jul 14 12:34 /proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh
> 
> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>

Reviewed-by: Jakub Kicinski <kuba@kernel.org>

^ permalink raw reply

* Re: [PATCH 08/11] xfs: replace a few open-coded XFS_DQTYPE_REC_MASK uses
From: Darrick J. Wong @ 2020-07-17  1:07 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-xfs
In-Reply-To: <20200717000242.GU2005@dread.disaster.area>

On Fri, Jul 17, 2020 at 10:02:42AM +1000, Dave Chinner wrote:
> On Wed, Jul 15, 2020 at 11:46:10PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Fix a few places where we open-coded this mask constant.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  fs/xfs/xfs_dquot_item_recover.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > 
> > diff --git a/fs/xfs/xfs_dquot_item_recover.c b/fs/xfs/xfs_dquot_item_recover.c
> > index d7eb85c7d394..93178341569a 100644
> > --- a/fs/xfs/xfs_dquot_item_recover.c
> > +++ b/fs/xfs/xfs_dquot_item_recover.c
> > @@ -39,7 +39,7 @@ xlog_recover_dquot_ra_pass2(
> >  	if (item->ri_buf[1].i_len < sizeof(struct xfs_disk_dquot))
> >  		return;
> >  
> > -	type = recddq->d_flags & (XFS_DQTYPE_USER | XFS_DQTYPE_PROJ | XFS_DQTYPE_GROUP);
> > +	type = recddq->d_flags & XFS_DQTYPE_REC_MASK;
> >  	ASSERT(type);
> >  	if (log->l_quotaoffs_flag & type)
> >  		return;
> > @@ -91,7 +91,7 @@ xlog_recover_dquot_commit_pass2(
> >  	/*
> >  	 * This type of quotas was turned off, so ignore this record.
> >  	 */
> > -	type = recddq->d_flags & (XFS_DQTYPE_USER | XFS_DQTYPE_PROJ | XFS_DQTYPE_GROUP);
> > +	type = recddq->d_flags & XFS_DQTYPE_REC_MASK;
> 
> Couldn't these both be converted to xfs_dquot_type(recddq)?

xfs_dquot_type takes a pointer to a incore dquot, not a struct
xfs_disk_dquot, so no.

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

^ permalink raw reply

* Re: [PATCH v2 bpf-next 1/2] bpf: separate bpf_get_[stack|stackid] for perf events BPF
From: kernel test robot @ 2020-07-17  1:07 UTC (permalink / raw)
  To: kbuild-all
In-Reply-To: <20200715052601.2404533-2-songliubraving@fb.com>

[-- Attachment #1: Type: text/plain, Size: 5513 bytes --]

Hi Song,

I love your patch! Yet something to improve:

[auto build test ERROR on bpf-next/master]

url:    https://github.com/0day-ci/linux/commits/Song-Liu/bpf-fix-stackmap-on-perf_events-with-PEBS/20200715-133118
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: arm64-randconfig-r004-20200716 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project ed6b578040a85977026c93bf4188f996148f3218)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> kernel/bpf/stackmap.c:698:26: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
                   return __bpf_get_stack(ctx->regs, NULL, NULL, buf, size, flags);
                                          ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   kernel/bpf/stackmap.c:726:26: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
                           ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
                                                 ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   kernel/bpf/stackmap.c:740:26: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
                           ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
                                                 ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   kernel/bpf/stackmap.c:745:25: error: incompatible pointer types passing 'bpf_user_pt_regs_t *' (aka 'struct user_pt_regs *') to parameter of type 'struct pt_regs *' [-Werror,-Wincompatible-pointer-types]
           return __bpf_get_stack(ctx->regs, NULL, trace, buf, size, flags);
                                  ^~~~~~~~~
   kernel/bpf/stackmap.c:581:45: note: passing argument to parameter 'regs' here
   static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                                               ^
   4 errors generated.

vim +698 kernel/bpf/stackmap.c

   687	
   688	BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_event_data_kern *, ctx,
   689		   void *, buf, u32, size, u64, flags)
   690	{
   691		struct perf_event *event = ctx->event;
   692		struct perf_callchain_entry *trace;
   693		bool has_kernel, has_user;
   694		bool kernel, user;
   695		int err = -EINVAL;
   696	
   697		if (!(event->attr.sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY))
 > 698			return __bpf_get_stack(ctx->regs, NULL, NULL, buf, size, flags);
   699	
   700		if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
   701				       BPF_F_USER_BUILD_ID)))
   702			goto clear;
   703	
   704		user = flags & BPF_F_USER_STACK;
   705		kernel = !user;
   706	
   707		has_kernel = !event->attr.exclude_callchain_kernel;
   708		has_user = !event->attr.exclude_callchain_user;
   709	
   710		if ((kernel && !has_kernel) || (user && !has_user))
   711			goto clear;
   712	
   713		err = -EFAULT;
   714		trace = ctx->data->callchain;
   715		if (!trace || (!has_kernel && !has_user))
   716			goto clear;
   717	
   718		if (has_kernel && has_user) {
   719			__u64 nr_kernel = count_kernel_ip(trace);
   720			int ret;
   721	
   722			if (kernel) {
   723				__u64 nr = trace->nr;
   724	
   725				trace->nr = nr_kernel;
   726				ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
   727						      size, flags);
   728	
   729				/* restore nr */
   730				trace->nr = nr;
   731			} else { /* user */
   732				u64 skip = flags & BPF_F_SKIP_FIELD_MASK;
   733	
   734				skip += nr_kernel;
   735				if (skip > ~BPF_F_SKIP_FIELD_MASK)
   736					goto clear;
   737	
   738				flags = (flags & ~BPF_F_SKIP_FIELD_MASK) |
   739					(skip  & BPF_F_SKIP_FIELD_MASK);
   740				ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
   741						      size, flags);
   742			}
   743			return ret;
   744		}
   745		return __bpf_get_stack(ctx->regs, NULL, trace, buf, size, flags);
   746	clear:
   747		memset(buf, 0, size);
   748		return err;
   749	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 38706 bytes --]

^ permalink raw reply

* Re: [pull request][net-next V2 00/15] mlx5 updates 2020-07-16
From: Jakub Kicinski @ 2020-07-17  1:07 UTC (permalink / raw)
  To: Saeed Mahameed; +Cc: David S. Miller, netdev
In-Reply-To: <20200717000410.55600-1-saeedm@mellanox.com>

On Thu, 16 Jul 2020 17:03:55 -0700 Saeed Mahameed wrote:
> Hi Dave, Jakub,
> 
> This patchset includes mlx5 RX XFRM ipsec offloads for ConnectX devices
> and some other misc updates and fixes to net-next.
> v1->v2:
>  - Fix "was not declared" build warning when RETPOLINE=y, reported by Jakub.
> 
> For more information please see tag log below.
> 
> Please pull and let me know if there is any problem.

Patch 5 a little skimpy on the why, but:

Acked-by: Jakub Kicinski <kuba@kernel.org>

^ permalink raw reply

* [PATCH] usb: only build hcd-dwc2 host controller for RASPI target
From: Paul Zimmerman @ 2020-07-17  1:05 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: Peter Maydell, QEMU Developers, Paul Zimmerman

The hcd-dwc2 host controller is currently built for all targets.
Since for now hcd-dwc2 is only implemented on RASPI, restrict its
build to that target only.

Signed-off-by: Paul Zimmerman <pauldzim@gmail.com>
---

Hi Gerd,

Do we want to apply this before the 5.1.0 release? It seems a waste
to build this code for every target when it's only used on one.
Sorry I didn't realize this earlier.

Thanks,
Paul

 hw/arm/Kconfig | 1 +
 hw/usb/Kconfig | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 4a224a6351..bc3a423940 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -315,6 +315,7 @@ config RASPI
     select FRAMEBUFFER
     select PL011 # UART
     select SDHCI
+    select USB_DWC2
 
 config STM32F205_SOC
     bool
diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig
index d4d8c37c28..5e63dc75f8 100644
--- a/hw/usb/Kconfig
+++ b/hw/usb/Kconfig
@@ -48,7 +48,6 @@ config USB_MUSB
 
 config USB_DWC2
     bool
-    default y
     select USB
 
 config TUSB6010
-- 
2.17.1



^ permalink raw reply related

* Re: [PATCH 00/39] multipath-tools series part II: dev_loss_tmo fixes
From: Benjamin Marzinski @ 2020-07-17  1:05 UTC (permalink / raw)
  To: mwilck; +Cc: dm-devel
In-Reply-To: <20200709101952.7285-1-mwilck@suse.com>

On Thu, Jul 09, 2020 at 12:19:48PM +0200, mwilck@suse.com wrote:
> From: Martin Wilck <mwilck@suse.com>
> 
> Hi Christophe, hi Ben,
> 
> This is part II of a larger patch series for multpath-tools I've been preparing.
> It contains some minor fixes for dev_loss_tmo handling, mostly logging.
> It's based on the previously submitted part I.
> 
> The full series will also be available here:
> https://github.com/mwilck/multipath-tools/tree/ups/submit-2007
> 
> There are tags in that repo for each part of the series.
> This part is tagged "submit-200709-2".
> 
> Regards,
> Martin
> 

Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
for the part.

> 
> Martin Wilck (4):
>   libmultipath: add macro DEV_LOSS_TMO_UNSET
>   libmultipath: improve logging for dev_loss_tmo override
>   libmultipath: print message if setting dev_loss_tmo is unsupported
>   libmultipath: increase log level of limiting dev_loss_tmo
> 
>  libmultipath/defaults.h  |  1 +
>  libmultipath/dict.c      |  4 +--
>  libmultipath/discovery.c | 56 ++++++++++++++++++++++++++++++----------
>  libmultipath/propsel.c   |  2 +-
>  4 files changed, 46 insertions(+), 17 deletions(-)
> 
> -- 
> 2.26.2

^ permalink raw reply

* Re: [PATCH 10/11] xfs: improve ondisk dquot flags checking
From: Darrick J. Wong @ 2020-07-17  1:05 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-xfs
In-Reply-To: <20200717001359.GW2005@dread.disaster.area>

On Fri, Jul 17, 2020 at 10:13:59AM +1000, Dave Chinner wrote:
> On Wed, Jul 15, 2020 at 11:46:23PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Create an XFS_DQTYPE_ANY mask for ondisk dquots flags, and use that to
> > ensure that we never accept any garbage flags when we're loading dquots.
> > While we're at it, restructure the quota type flag checking to use the
> > proper masking.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  fs/xfs/libxfs/xfs_dquot_buf.c |   11 ++++++++---
> >  fs/xfs/libxfs/xfs_format.h    |    2 ++
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> Ok, I looked at this and questioned why it existed and why the
> code didn't just use XFS_DQTYPE_REC_MASK directly. I think this
> change exists because you plan on adding a new on-disk flag for
> bigtime support and hence XFS_DQTYPE_ANY will grow to include the
> new flag, right?

Correct.

> If so, can you add that to the commit message?

Ok, will do.

--D

> Code looks fine assuming I've understood this correctly...
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

^ permalink raw reply

* Re: [PATCH] mm: mmap: Merge vma after call_mmap() if possible
From: linmiaohe @ 2020-07-17  1:04 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org

Andrew Morton <akpm@linux-foundation.org> wrote:
>On Tue, 14 Jul 2020 11:07:44 +0800 linmiaohe <linmiaohe@huawei.com> wrote:
>
>> From: Miaohe Lin <linmiaohe@huawei.com>
>> 
>> The vm_flags may be changed after call_mmap() because drivers may set 
>> some flags for their own purpose. As a result, we failed to merge the 
>> adjacent vma due to the different vm_flags as userspace can't pass in the same one.
>> Try to merge vma after call_mmap() to fix this issue.
>> 
>> Signed-off-by: Hongxiang Lou <louhongxiang@huawei.com>
>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>> ---
>> +		/* If vm_flags changed after call_mmap(), we should try merge vma again
>> +		 * as we may succeed this time.
>> +		 */
>> +		if (unlikely(vm_flags != vma->vm_flags && prev)) {
>> +			merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
>> +				NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
>> +			if (merge) {
>> +				fput(file);
>> +				vm_area_free(vma);
>> +				vma = merge;
>> +				goto unmap_writable;
>
>Shouldn't we update local variable `vm_flags' here, to pick up the change?  And possibly `addr'?

Yes, we should. `vm_flags` and `addr` should be updated to continue the work. Many thanks for your
great review. I will fix it and test again. I will send a patch v2 soon.


^ permalink raw reply

* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev2)
From: Patchwork @ 2020-07-17  1:04 UTC (permalink / raw)
  To: Manasi Navare; +Cc: intel-gfx
In-Reply-To: <20200715224222.7557-1-manasi.d.navare@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 14091 bytes --]

== Series Details ==

Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev2)
URL   : https://patchwork.freedesktop.org/series/79534/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8758_full -> Patchwork_18196_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_18196_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18196_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_18196_full:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-tglb:         [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb5/igt@kms_dp_dsc@basic-dsc-enable-edp.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-tglb1/igt@kms_dp_dsc@basic-dsc-enable-edp.html

  
Known issues
------------

  Here are the changes found in Patchwork_18196_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_balancer@bonded-early:
    - shard-kbl:          [PASS][3] -> [FAIL][4] ([i915#2079])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl4/igt@gem_exec_balancer@bonded-early.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-kbl3/igt@gem_exec_balancer@bonded-early.html

  * igt@i915_selftest@live@execlists:
    - shard-iclb:         [PASS][5] -> [INCOMPLETE][6] ([i915#1580] / [i915#1684])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb1/igt@i915_selftest@live@execlists.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-iclb5/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@mock@requests:
    - shard-skl:          [PASS][7] -> [INCOMPLETE][8] ([i915#198] / [i915#2110])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-skl5/igt@i915_selftest@mock@requests.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-skl4/igt@i915_selftest@mock@requests.html

  * igt@kms_big_fb@x-tiled-8bpp-rotate-180:
    - shard-glk:          [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk8/igt@kms_big_fb@x-tiled-8bpp-rotate-180.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-glk5/igt@kms_big_fb@x-tiled-8bpp-rotate-180.html

  * igt@kms_big_fb@yf-tiled-32bpp-rotate-270:
    - shard-apl:          [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#1982])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl4/igt@kms_big_fb@yf-tiled-32bpp-rotate-270.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-apl2/igt@kms_big_fb@yf-tiled-32bpp-rotate-270.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-rapid-movement:
    - shard-snb:          [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-snb4/igt@kms_cursor_crc@pipe-b-cursor-256x256-rapid-movement.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-snb2/igt@kms_cursor_crc@pipe-b-cursor-256x256-rapid-movement.html

  * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions:
    - shard-tglb:         [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 similar issue
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb1/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-tglb2/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html

  * igt@kms_flip@flip-vs-expired-vblank@b-dp1:
    - shard-apl:          [PASS][17] -> [FAIL][18] ([i915#1635] / [i915#79]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl1/igt@kms_flip@flip-vs-expired-vblank@b-dp1.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-apl3/igt@kms_flip@flip-vs-expired-vblank@b-dp1.html

  * igt@kms_flip@flip-vs-suspend@c-dp1:
    - shard-kbl:          [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +3 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl3/igt@kms_flip@flip-vs-suspend@c-dp1.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-kbl4/igt@kms_flip@flip-vs-suspend@c-dp1.html

  * igt@kms_flip_tiling@flip-changes-tiling-yf:
    - shard-kbl:          [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +2 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl6/igt@kms_flip_tiling@flip-changes-tiling-yf.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-kbl1/igt@kms_flip_tiling@flip-changes-tiling-yf.html

  * igt@kms_psr@psr2_dpms:
    - shard-iclb:         [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb2/igt@kms_psr@psr2_dpms.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-iclb7/igt@kms_psr@psr2_dpms.html

  * igt@kms_vblank@crtc-id:
    - shard-skl:          [PASS][25] -> [DMESG-WARN][26] ([i915#1982]) +6 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-skl8/igt@kms_vblank@crtc-id.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-skl8/igt@kms_vblank@crtc-id.html

  
#### Possible fixes ####

  * igt@gem_exec_reloc@basic-concurrent0:
    - shard-glk:          [FAIL][27] ([i915#1930]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk2/igt@gem_exec_reloc@basic-concurrent0.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-glk5/igt@gem_exec_reloc@basic-concurrent0.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-0:
    - shard-glk:          [DMESG-FAIL][29] ([i915#118] / [i915#95]) -> [PASS][30] +1 similar issue
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk8/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-glk6/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html

  * igt@kms_color@pipe-c-ctm-0-25:
    - shard-skl:          [DMESG-WARN][31] ([i915#1982]) -> [PASS][32] +9 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-skl5/igt@kms_color@pipe-c-ctm-0-25.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-skl2/igt@kms_color@pipe-c-ctm-0-25.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-skl:          [INCOMPLETE][33] ([i915#300]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-skl9/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-skl6/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions:
    - shard-kbl:          [DMESG-WARN][35] ([i915#1982]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl4/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-kbl2/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled:
    - shard-apl:          [DMESG-WARN][37] ([i915#1635] / [i915#1982]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl8/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-apl6/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled.html

  * igt@kms_flip@flip-vs-suspend@b-dp1:
    - shard-kbl:          [DMESG-WARN][39] ([i915#180]) -> [PASS][40] +5 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl3/igt@kms_flip@flip-vs-suspend@b-dp1.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-kbl4/igt@kms_flip@flip-vs-suspend@b-dp1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt:
    - shard-tglb:         [DMESG-WARN][41] ([i915#1982]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-tglb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [FAIL][43] ([fdo#108145] / [i915#265]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-skl1/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-skl5/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [SKIP][45] ([fdo#109441]) -> [PASS][46] +1 similar issue
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@perf@blocking-parameterized:
    - shard-tglb:         [FAIL][47] ([i915#1542]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb3/igt@perf@blocking-parameterized.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-tglb5/igt@perf@blocking-parameterized.html

  * igt@perf@polling-small-buf:
    - shard-skl:          [FAIL][49] ([i915#1722]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-skl1/igt@perf@polling-small-buf.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-skl5/igt@perf@polling-small-buf.html

  
#### Warnings ####

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [DMESG-WARN][51] ([i915#1226]) -> [SKIP][52] ([fdo#109349])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-iclb1/igt@kms_dp_dsc@basic-dsc-enable-edp.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
    - shard-apl:          [FAIL][53] ([fdo#108145] / [i915#1635] / [i915#265]) -> [DMESG-FAIL][54] ([fdo#108145] / [i915#1635] / [i915#1982])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl3/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-apl3/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html

  * igt@runner@aborted:
    - shard-apl:          ([FAIL][55], [FAIL][56], [FAIL][57]) ([i915#1610] / [i915#1635] / [i915#2110] / [i915#637]) -> [FAIL][58] ([i915#1635] / [i915#2110])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl8/igt@runner@aborted.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl1/igt@runner@aborted.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl8/igt@runner@aborted.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/shard-apl1/igt@runner@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580
  [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1684]: https://gitlab.freedesktop.org/drm/intel/issues/1684
  [i915#1722]: https://gitlab.freedesktop.org/drm/intel/issues/1722
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1930]: https://gitlab.freedesktop.org/drm/intel/issues/1930
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2079]: https://gitlab.freedesktop.org/drm/intel/issues/2079
  [i915#2110]: https://gitlab.freedesktop.org/drm/intel/issues/2110
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#300]: https://gitlab.freedesktop.org/drm/intel/issues/300
  [i915#637]: https://gitlab.freedesktop.org/drm/intel/issues/637
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * Linux: CI_DRM_8758 -> Patchwork_18196

  CI-20190529: 20190529
  CI_DRM_8758: b6738761bde03de00a1c84c6a85f9379f53f585c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5738: bc8b56fe177af34fbde7b96f1f66614a0014c6ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18196: f4de44a552c14b647651ed909c64dfdde6eaa525 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/index.html

[-- Attachment #1.2: Type: text/html, Size: 16775 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: nfs4_show_superblock considered harmful :-)
From: J. Bruce Fields @ 2020-07-17  1:03 UTC (permalink / raw)
  To: NeilBrown; +Cc: Jeff Layton, linux-nfs
In-Reply-To: <87tuy7vxeb.fsf@notabene.neil.brown.name>

On Fri, Jul 17, 2020 at 09:43:40AM +1000, NeilBrown wrote:
> On Thu, Jul 16 2020, J. Bruce Fields wrote:
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -507,6 +507,16 @@ find_any_file(struct nfs4_file *f)
> >  	return ret;
> >  }
> >  
> > +static struct nfsd_file *find_deleg_file(struct nfs4_file *f)
> > +{
> > +	struct nfsd_file *ret;
> > +
> > +	spin_lock(&f->fi_lock);
> > +	ret = nfsd_file_get(f->fi_deleg_file);
> 
> A test on f->fi_deleg_file being non-NULL would make this look safer.
> It would  also make the subsequent test on the return value appear sane.

Yes, thanks!-b.

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index c2a2e56c896d..6e8811e7c134 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -509,10 +509,11 @@ find_any_file(struct nfs4_file *f)
 
 static struct nfsd_file *find_deleg_file(struct nfs4_file *f)
 {
-	struct nfsd_file *ret;
+	struct nfsd_file *ret = NULL;
 
 	spin_lock(&f->fi_lock);
-	ret = nfsd_file_get(f->fi_deleg_file);
+	if (f->fi_deleg_file)
+		ret = nfsd_file_get(f->fi_deleg_file);
 	spin_unlock(&f->fi_lock);
 	return ret;
 }

^ permalink raw reply related

* [PATCH] musl: Update to latest tip
From: Khem Raj @ 2020-07-17  1:01 UTC (permalink / raw)
  To: openembedded-core; +Cc: Khem Raj

License-Update: Added copyright for AArch64 memcpy and memset code [1]

Details changelog is here [2]

[1] https://git.musl-libc.org/cgit/musl/commit/?id=fdf8b2ad9c5ae6adf3a91c0043eb898badee46d1
[2] https://git.musl-libc.org/cgit/musl/log/?qt=range&q=fca7428c096066482d8c3f52450810288e27515c..0a005f499cf39822166dd4db3d2d31f0639f1b1b

Signed-off-by: Khem Raj <raj.khem@gmail.com>

s
---
 meta/recipes-core/musl/musl.inc    | 2 +-
 meta/recipes-core/musl/musl_git.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/musl/musl.inc b/meta/recipes-core/musl/musl.inc
index bdce412162..54edfc88e5 100644
--- a/meta/recipes-core/musl/musl.inc
+++ b/meta/recipes-core/musl/musl.inc
@@ -9,7 +9,7 @@ standards-conformance and safety."
 HOMEPAGE = "http://www.musl-libc.org/"
 LICENSE = "MIT"
 SECTION = "libs"
-LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=f95ee848a08ad253c04723da00cedb01"
+LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=b03f1cc25363d094011f8f4fd8bcfb68"
 
 INHIBIT_DEFAULT_DEPS = "1"
 
diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb
index 0913b09aaf..ed2178b5a4 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -4,7 +4,7 @@
 require musl.inc
 inherit linuxloader
 
-SRCREV = "fca7428c096066482d8c3f52450810288e27515c"
+SRCREV = "0a005f499cf39822166dd4db3d2d31f0639f1b1b"
 
 BASEVER = "1.2.0"
 
-- 
2.27.0


^ permalink raw reply related

* Re: [PATCH] leds: add NCT6795D driver
From: Alexandre Courbot @ 2020-07-17  1:00 UTC (permalink / raw)
  To: Jacek Anaszewski
  Cc: Pavel Machek, Dan Murphy, Linux Kernel Mailing List, linux-leds
In-Reply-To: <17fe52a2-73ff-b547-8a59-5df009c929c8@gmail.com>

Hi Jacek,

On Thu, Jul 16, 2020 at 4:32 AM Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
>
> Hi Alexandre,
>
> On 7/15/20 3:54 AM, Alexandre Courbot wrote:
> > Hi Pavel,
> >
> > On Wed, Jul 15, 2020 at 7:33 AM Pavel Machek <pavel@ucw.cz> wrote:
> >>
> >> Hi!
> >>
> >>> Add support for the LED feature of the NCT6795D chip found on some
> >>> motherboards, notably MSI ones. The LEDs are typically used using a
> >>> RGB connector so this driver creates one LED device for each color
> >>> component.
> >>
> >> Ok, let me take a look. What entries does it present in /sys?
> >
> > Right now these 3 directories in /sys/class/leds:
> >
> > nct6795d:blue:
> > nct6795d:green:
> > nct6795d:red:
> >
> > with the usual suspects `brightness` and `max_brightness` in each. I
> > am not 100% sure I got the names right so please let me know if that
> > is not correct.
>
> You miss LED function, that should be in the second section.

The reason for not having a function at the moment is that I took a
look at include/dt-bindings/leds/common.h and could not find any
function that could reasonably apply. This basically controls a RGB
connector on the motherboard which serves no particular function - you
can plug a RGB fan or anything else you want and control it in any
fashion. Is there a function that applies to this use-case?

^ permalink raw reply

* Re: [PATCH] arm64: Make TSK_STACK_CANARY more accurate defined
From: Guo Ren @ 2020-07-17  0:56 UTC (permalink / raw)
  To: Will Deacon
  Cc: Guo Ren, Catalin Marinas, linux-csky, Linux Kernel Mailing List,
	linux-arm-kernel
In-Reply-To: <20200714083715.GE4516@willie-the-truck>

BTW, Jim found a GCC security leak in arm64, and would you want to
have a look at it?
-------
I notice in the epilogue I get
    ld a4, 8(sp)
    ld a5, 100(t6)
    xor a5, a4, a5
    bne a5,zero,.L4
This looks like a security leak that the canary value is left in a4.
The i386 implementation operates directly on memory without loading
into registers.  The rs6000 implementation is careful to load 0 into
the other register in the stack_protector_test code after the xor.  I
think this is a bug in the aarch64 code that it isn't clearing the
other register.  And I think it is a bug in your code too.  If we
don't need to clear the canary from the two registers, then you should
eliminate the xor and just use "bne a5,a4,.L4".  But I think the way
you have it is right, you just need to clear the a4 register after the
xor.
--------
[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549910.html

On Tue, Jul 14, 2020 at 4:37 PM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Jul 13, 2020 at 04:03:33AM +0000, guoren@kernel.org wrote:
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > TSK_STACK_CANARY only used in arm64/Makefile with
> > CONFIG_STACKPROTECTOR_PER_TASK wrap. So use the same policy in
> > asm-offset.c.
> >
> > Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
> > Co-developed-by: Kees Cook <keescook@chromium.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> >  arch/arm64/kernel/asm-offsets.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> > index 0577e21..37d5d3d 100644
> > --- a/arch/arm64/kernel/asm-offsets.c
> > +++ b/arch/arm64/kernel/asm-offsets.c
> > @@ -39,7 +39,7 @@ int main(void)
> >    DEFINE(TSK_TI_SCS_SP,              offsetof(struct task_struct, thread_info.scs_sp));
> >  #endif
> >    DEFINE(TSK_STACK,          offsetof(struct task_struct, stack));
> > -#ifdef CONFIG_STACKPROTECTOR
> > +#ifdef CONFIG_STACKPROTECTOR_PER_TASK
> >    DEFINE(TSK_STACK_CANARY,   offsetof(struct task_struct, stack_canary));
> >  #endif
>
> I don't think this really makese much sense. The 'stack_canary' field in
> 'struct task_struct' is defined as:
>
> #ifdef CONFIG_STACKPROTECTOR
>         /* Canary value for the -fstack-protector GCC feature: */
>         unsigned long                   stack_canary;
> #endif
>
> so I think it makes sense to follow that in asm-offsets.c
>
> Does the current code actually cause a problem?
>
> Will



--
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

_______________________________________________
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 net-next v4] net: dccp: Add SIOCOUTQ IOCTL support (send buffer fill)
From: Richard Sailer @ 2020-07-17  0:56 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: gerrit, davem, dccp, netdev
In-Reply-To: <20200716125608.33a0589b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>


[-- Attachment #1.1: Type: text/plain, Size: 2766 bytes --]



On 16/07/2020 21:56, Jakub Kicinski wrote:
> On Mon, 13 Jul 2020 00:55:20 +0200 Richard Sailer wrote:
>> This adds support for the SIOCOUTQ IOCTL to get the send buffer fill
>> of a DCCP socket, like UDP and TCP sockets already have.
>>
>> Regarding the used data field: DCCP uses per packet sequence numbers,
>> not per byte, so sequence numbers can't be used like in TCP. sk_wmem_queued
>> is not used by DCCP and always 0, even in test on highly congested paths.
>> Therefore this uses sk_wmem_alloc like in UDP.
>>
>> Signed-off-by: Richard Sailer <richard_siegfried@systemli.org>
> 
> Sorry for the late review
No problem, nothing compared to the information delays at university^^

> 
>> diff --git a/Documentation/networking/dccp.rst b/Documentation/networking/dccp.rst
>> index dde16be044562..74659da107f6b 100644
>> --- a/Documentation/networking/dccp.rst
>> +++ b/Documentation/networking/dccp.rst
>> @@ -192,6 +192,8 @@ FIONREAD
>>  	Works as in udp(7): returns in the ``int`` argument pointer the size of
>>  	the next pending datagram in bytes, or 0 when no datagram is pending.
>>  
>> +SIOCOUTQ
>> +  Returns the number of data bytes in the local send queue.
> 
> FIONREAD uses tabs for indentation, it seems like a good idea to
> document the size of the argument (i.e. "returns in the ``int`` ...").

Agreed
> 
>>  Other tunables
>>  ==============
>> diff --git a/net/dccp/proto.c b/net/dccp/proto.c
>> index c13b6609474b6..dab74e8a8a69b 100644
>> --- a/net/dccp/proto.c
>> +++ b/net/dccp/proto.c
>> @@ -375,6 +375,14 @@ int dccp_ioctl(struct sock *sk, int cmd, unsigned long arg)
>>  		goto out;
>>  
>>  	switch (cmd) {
>> +	case SIOCOUTQ: {
>> +		/* Using sk_wmem_alloc here because sk_wmem_queued is not used by DCCP and
>> +		 * always 0, comparably to UDP.
>> +		 */
>> +		int amount = sk_wmem_alloc_get(sk);
>> +		rc = put_user(amount, (int __user *)arg);
> 
> checkpatch warns:
> 
> WARNING: Missing a blank line after declarations
> #48: FILE: net/dccp/proto.c:383:
> +		int amount = sk_wmem_alloc_get(sk);
> +		rc = put_user(amount, (int __user *)arg);
> 
> Could you please address that, and better still move the declaration of
> "int amount" up to the function level and avoid the funky bracket around
> the case statement altogether?

I found the funky braces disturbing too, but thought they were
convention, so happy to delete them.

Regarding "putting int amount at function level": well the problem is in
the other case statement is a unsigned long (and the pointer in
put_user() is (int __user *) ). I don't yet know if I can make that all
a simple int without losing correctness/security. I will send a v5 when
I figured that out.

Thanks,
-- Richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* Re: [PATCH net-next v4] net: dccp: Add SIOCOUTQ IOCTL support (send buffer fill)
From: Richard Sailer @ 2020-07-17  0:56 UTC (permalink / raw)
  To: dccp
In-Reply-To: <20200712225520.269542-1-richard_siegfried@systemli.org>


[-- Attachment #1.1: Type: text/plain, Size: 2766 bytes --]



On 16/07/2020 21:56, Jakub Kicinski wrote:
> On Mon, 13 Jul 2020 00:55:20 +0200 Richard Sailer wrote:
>> This adds support for the SIOCOUTQ IOCTL to get the send buffer fill
>> of a DCCP socket, like UDP and TCP sockets already have.
>>
>> Regarding the used data field: DCCP uses per packet sequence numbers,
>> not per byte, so sequence numbers can't be used like in TCP. sk_wmem_queued
>> is not used by DCCP and always 0, even in test on highly congested paths.
>> Therefore this uses sk_wmem_alloc like in UDP.
>>
>> Signed-off-by: Richard Sailer <richard_siegfried@systemli.org>
> 
> Sorry for the late review
No problem, nothing compared to the information delays at university^^

> 
>> diff --git a/Documentation/networking/dccp.rst b/Documentation/networking/dccp.rst
>> index dde16be044562..74659da107f6b 100644
>> --- a/Documentation/networking/dccp.rst
>> +++ b/Documentation/networking/dccp.rst
>> @@ -192,6 +192,8 @@ FIONREAD
>>  	Works as in udp(7): returns in the ``int`` argument pointer the size of
>>  	the next pending datagram in bytes, or 0 when no datagram is pending.
>>  
>> +SIOCOUTQ
>> +  Returns the number of data bytes in the local send queue.
> 
> FIONREAD uses tabs for indentation, it seems like a good idea to
> document the size of the argument (i.e. "returns in the ``int`` ...").

Agreed
> 
>>  Other tunables
>>  ==============
>> diff --git a/net/dccp/proto.c b/net/dccp/proto.c
>> index c13b6609474b6..dab74e8a8a69b 100644
>> --- a/net/dccp/proto.c
>> +++ b/net/dccp/proto.c
>> @@ -375,6 +375,14 @@ int dccp_ioctl(struct sock *sk, int cmd, unsigned long arg)
>>  		goto out;
>>  
>>  	switch (cmd) {
>> +	case SIOCOUTQ: {
>> +		/* Using sk_wmem_alloc here because sk_wmem_queued is not used by DCCP and
>> +		 * always 0, comparably to UDP.
>> +		 */
>> +		int amount = sk_wmem_alloc_get(sk);
>> +		rc = put_user(amount, (int __user *)arg);
> 
> checkpatch warns:
> 
> WARNING: Missing a blank line after declarations
> #48: FILE: net/dccp/proto.c:383:
> +		int amount = sk_wmem_alloc_get(sk);
> +		rc = put_user(amount, (int __user *)arg);
> 
> Could you please address that, and better still move the declaration of
> "int amount" up to the function level and avoid the funky bracket around
> the case statement altogether?

I found the funky braces disturbing too, but thought they were
convention, so happy to delete them.

Regarding "putting int amount at function level": well the problem is in
the other case statement is a unsigned long (and the pointer in
put_user() is (int __user *) ). I don't yet know if I can make that all
a simple int without losing correctness/security. I will send a v5 when
I figured that out.

Thanks,
-- Richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* [igt-dev] ✓ Fi.CI.IGT: success for i915/gem_exec_balancer: Race breadcrumb signaling against timeslicing
From: Patchwork @ 2020-07-17  0:56 UTC (permalink / raw)
  To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200716204448.737869-1-chris@chris-wilson.co.uk>


[-- Attachment #1.1: Type: text/plain, Size: 18146 bytes --]

== Series Details ==

Series: i915/gem_exec_balancer: Race breadcrumb signaling against timeslicing
URL   : https://patchwork.freedesktop.org/series/79566/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8758_full -> IGTPW_4772_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/index.html

New tests
---------

  New tests have been introduced between CI_DRM_8758_full and IGTPW_4772_full:

### New IGT tests (1) ###

  * igt@gem_exec_balancer@waits:
    - Statuses : 5 pass(s) 2 skip(s)
    - Exec time: [0.0, 6.56] s

  

Known issues
------------

  Here are the changes found in IGTPW_4772_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@core_setmaster@master-drop-set-root:
    - shard-iclb:         [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb5/igt@core_setmaster@master-drop-set-root.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-iclb2/igt@core_setmaster@master-drop-set-root.html

  * igt@gem_exec_create@madvise:
    - shard-glk:          [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk9/igt@gem_exec_create@madvise.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-glk5/igt@gem_exec_create@madvise.html

  * igt@i915_module_load@reload-with-fault-injection:
    - shard-tglb:         [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +2 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb6/igt@i915_module_load@reload-with-fault-injection.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-tglb7/igt@i915_module_load@reload-with-fault-injection.html

  * igt@i915_selftest@live@execlists:
    - shard-iclb:         [PASS][7] -> [INCOMPLETE][8] ([i915#2089])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb1/igt@i915_selftest@live@execlists.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-iclb1/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@mock@requests:
    - shard-hsw:          [PASS][9] -> [INCOMPLETE][10] ([i915#2110])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw7/igt@i915_selftest@mock@requests.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw1/igt@i915_selftest@mock@requests.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-0:
    - shard-glk:          [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / [i915#95])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk1/igt@kms_big_fb@y-tiled-64bpp-rotate-0.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-glk8/igt@kms_big_fb@y-tiled-64bpp-rotate-0.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x128-random:
    - shard-kbl:          [PASS][13] -> [FAIL][14] ([i915#54])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-128x128-random.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-kbl3/igt@kms_cursor_crc@pipe-a-cursor-128x128-random.html
    - shard-apl:          [PASS][15] -> [FAIL][16] ([i915#1635] / [i915#54])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl6/igt@kms_cursor_crc@pipe-a-cursor-128x128-random.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-apl1/igt@kms_cursor_crc@pipe-a-cursor-128x128-random.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-kbl:          [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +6 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl7/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_flip@2x-modeset-vs-vblank-race@ab-vga1-hdmi-a1:
    - shard-hsw:          [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw1/igt@kms_flip@2x-modeset-vs-vblank-race@ab-vga1-hdmi-a1.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw6/igt@kms_flip@2x-modeset-vs-vblank-race@ab-vga1-hdmi-a1.html

  * igt@kms_flip@modeset-vs-vblank-race-interruptible@b-hdmi-a1:
    - shard-glk:          [PASS][21] -> [FAIL][22] ([i915#407])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk1/igt@kms_flip@modeset-vs-vblank-race-interruptible@b-hdmi-a1.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-glk5/igt@kms_flip@modeset-vs-vblank-race-interruptible@b-hdmi-a1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt:
    - shard-tglb:         [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-tglb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt.html

  * igt@kms_psr@psr2_sprite_render:
    - shard-iclb:         [PASS][25] -> [SKIP][26] ([fdo#109441])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb2/igt@kms_psr@psr2_sprite_render.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-iclb8/igt@kms_psr@psr2_sprite_render.html

  * igt@perf@create-destroy-userspace-config:
    - shard-glk:          [PASS][27] -> [SKIP][28] ([fdo#109271])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk3/igt@perf@create-destroy-userspace-config.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-glk2/igt@perf@create-destroy-userspace-config.html

  
#### Possible fixes ####

  * igt@dumb_buffer@map-invalid-size:
    - shard-snb:          [TIMEOUT][29] ([i915#1958] / [i915#2119]) -> [PASS][30] +1 similar issue
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-snb5/igt@dumb_buffer@map-invalid-size.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-snb2/igt@dumb_buffer@map-invalid-size.html
    - shard-hsw:          [TIMEOUT][31] ([i915#1958] / [i915#2119]) -> [PASS][32] +2 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw6/igt@dumb_buffer@map-invalid-size.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw2/igt@dumb_buffer@map-invalid-size.html

  * igt@gem_exec_params@invalid-bsd1-flag-on-blt:
    - shard-tglb:         [DMESG-WARN][33] ([i915#402]) -> [PASS][34] +1 similar issue
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb8/igt@gem_exec_params@invalid-bsd1-flag-on-blt.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-tglb7/igt@gem_exec_params@invalid-bsd1-flag-on-blt.html

  * igt@gem_exec_reloc@basic-concurrent0:
    - shard-glk:          [FAIL][35] ([i915#1930]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk2/igt@gem_exec_reloc@basic-concurrent0.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-glk2/igt@gem_exec_reloc@basic-concurrent0.html

  * igt@gem_exec_whisper@basic-queues-all:
    - shard-glk:          [DMESG-WARN][37] ([i915#118] / [i915#95]) -> [PASS][38] +1 similar issue
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk7/igt@gem_exec_whisper@basic-queues-all.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-glk3/igt@gem_exec_whisper@basic-queues-all.html

  * igt@gem_userptr_blits@invalid-mmap-offset-unsync@gtt:
    - shard-tglb:         [INCOMPLETE][39] ([i915#2119] / [i915#2149]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb7/igt@gem_userptr_blits@invalid-mmap-offset-unsync@gtt.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-tglb7/igt@gem_userptr_blits@invalid-mmap-offset-unsync@gtt.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-0:
    - shard-glk:          [DMESG-FAIL][41] ([i915#118] / [i915#95]) -> [PASS][42] +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-glk8/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-glk1/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html

  * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions:
    - shard-kbl:          [DMESG-WARN][43] ([i915#1982]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl4/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-kbl1/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled:
    - shard-apl:          [DMESG-WARN][45] ([i915#1635] / [i915#1982]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl8/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-apl8/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled.html

  * igt@kms_frontbuffer_tracking@psr-slowdraw:
    - shard-tglb:         [DMESG-WARN][47] ([i915#1982]) -> [PASS][48] +1 similar issue
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb5/igt@kms_frontbuffer_tracking@psr-slowdraw.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-tglb3/igt@kms_frontbuffer_tracking@psr-slowdraw.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [SKIP][49] ([fdo#109441]) -> [PASS][50] +4 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb4/igt@kms_psr@psr2_sprite_plane_move.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
    - shard-kbl:          [DMESG-WARN][51] ([i915#180]) -> [PASS][52] +5 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-kbl1/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-kbl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html

  * igt@perf_pmu@busy-idle@rcs0:
    - shard-snb:          [FAIL][53] ([i915#1958]) -> [PASS][54] +1 similar issue
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-snb5/igt@perf_pmu@busy-idle@rcs0.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-snb6/igt@perf_pmu@busy-idle@rcs0.html

  * igt@perf_pmu@busy-idle@vcs0:
    - shard-hsw:          [FAIL][55] ([i915#1958]) -> [PASS][56] +2 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw6/igt@perf_pmu@busy-idle@vcs0.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw6/igt@perf_pmu@busy-idle@vcs0.html
    - shard-snb:          [INCOMPLETE][57] ([i915#2119] / [i915#82]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-snb5/igt@perf_pmu@busy-idle@vcs0.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-snb6/igt@perf_pmu@busy-idle@vcs0.html

  * igt@perf_pmu@busy-idle@vecs0:
    - shard-hsw:          [DMESG-FAIL][59] ([i915#2119]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw6/igt@perf_pmu@busy-idle@vecs0.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw6/igt@perf_pmu@busy-idle@vecs0.html

  
#### Warnings ####

  * igt@kms_big_fb@linear-32bpp-rotate-270:
    - shard-snb:          [SKIP][61] ([fdo#109271]) -> [TIMEOUT][62] ([i915#1958] / [i915#2119]) +1 similar issue
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-snb6/igt@kms_big_fb@linear-32bpp-rotate-270.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-snb6/igt@kms_big_fb@linear-32bpp-rotate-270.html

  * igt@kms_ccs@pipe-c-ccs-on-another-bo:
    - shard-hsw:          [TIMEOUT][63] ([i915#1958] / [i915#2119]) -> [SKIP][64] ([fdo#109271])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw6/igt@kms_ccs@pipe-c-ccs-on-another-bo.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw1/igt@kms_ccs@pipe-c-ccs-on-another-bo.html
    - shard-snb:          [TIMEOUT][65] ([i915#1958] / [i915#2119]) -> [SKIP][66] ([fdo#109271]) +1 similar issue
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-snb5/igt@kms_ccs@pipe-c-ccs-on-another-bo.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-snb2/igt@kms_ccs@pipe-c-ccs-on-another-bo.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [DMESG-WARN][67] ([i915#1226]) -> [SKIP][68] ([fdo#109349])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-iclb8/igt@kms_dp_dsc@basic-dsc-enable-edp.html

  * igt@kms_psr@psr2_dpms:
    - shard-snb:          [SKIP][69] ([fdo#109271]) -> [INCOMPLETE][70] ([i915#82])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-snb1/igt@kms_psr@psr2_dpms.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-snb6/igt@kms_psr@psr2_dpms.html

  * igt@perf@polling-parameterized:
    - shard-hsw:          [FAIL][71] ([i915#1542]) -> [INCOMPLETE][72] ([i915#1958])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw2/igt@perf@polling-parameterized.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw6/igt@perf@polling-parameterized.html

  * igt@runner@aborted:
    - shard-hsw:          [FAIL][73] ([i915#2110]) -> [FAIL][74] ([i915#1436] / [i915#2110])
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-hsw1/igt@runner@aborted.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-hsw1/igt@runner@aborted.html
    - shard-iclb:         ([FAIL][75], [FAIL][76]) ([i915#2110]) -> ([FAIL][77], [FAIL][78]) ([i915#1580] / [i915#2110])
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb4/igt@runner@aborted.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-iclb2/igt@runner@aborted.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-iclb1/igt@runner@aborted.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-iclb5/igt@runner@aborted.html
    - shard-apl:          ([FAIL][79], [FAIL][80], [FAIL][81]) ([i915#1610] / [i915#1635] / [i915#2110] / [i915#637]) -> [FAIL][82] ([i915#1635] / [i915#2110])
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl1/igt@runner@aborted.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl8/igt@runner@aborted.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-apl8/igt@runner@aborted.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-apl2/igt@runner@aborted.html
    - shard-tglb:         ([FAIL][83], [FAIL][84], [FAIL][85]) ([i915#2110]) -> [FAIL][86] ([i915#1764] / [i915#2110])
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb5/igt@runner@aborted.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb7/igt@runner@aborted.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/shard-tglb1/igt@runner@aborted.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/shard-tglb3/igt@runner@aborted.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580
  [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1764]: https://gitlab.freedesktop.org/drm/intel/issues/1764
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1930]: https://gitlab.freedesktop.org/drm/intel/issues/1930
  [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089
  [i915#2110]: https://gitlab.freedesktop.org/drm/intel/issues/2110
  [i915#2119]: https://gitlab.freedesktop.org/drm/intel/issues/2119
  [i915#2149]: https://gitlab.freedesktop.org/drm/intel/issues/2149
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#407]: https://gitlab.freedesktop.org/drm/intel/issues/407
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#637]: https://gitlab.freedesktop.org/drm/intel/issues/637
  [i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (10 -> 8)
------------------------------

  Missing    (2): pig-skl-6260u pig-glk-j5005 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5738 -> IGTPW_4772
  * Piglit: piglit_4509 -> None

  CI-20190529: 20190529
  CI_DRM_8758: b6738761bde03de00a1c84c6a85f9379f53f585c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4772: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/index.html
  IGT_5738: bc8b56fe177af34fbde7b96f1f66614a0014c6ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4772/index.html

[-- Attachment #1.2: Type: text/html, Size: 22676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* Re: [PATCH] arm64: Make TSK_STACK_CANARY more accurate defined
From: Guo Ren @ 2020-07-17  0:56 UTC (permalink / raw)
  To: Will Deacon
  Cc: Catalin Marinas, Linux Kernel Mailing List, linux-arm-kernel,
	linux-csky, Guo Ren
In-Reply-To: <20200714083715.GE4516@willie-the-truck>

BTW, Jim found a GCC security leak in arm64, and would you want to
have a look at it?
-------
I notice in the epilogue I get
    ld a4, 8(sp)
    ld a5, 100(t6)
    xor a5, a4, a5
    bne a5,zero,.L4
This looks like a security leak that the canary value is left in a4.
The i386 implementation operates directly on memory without loading
into registers.  The rs6000 implementation is careful to load 0 into
the other register in the stack_protector_test code after the xor.  I
think this is a bug in the aarch64 code that it isn't clearing the
other register.  And I think it is a bug in your code too.  If we
don't need to clear the canary from the two registers, then you should
eliminate the xor and just use "bne a5,a4,.L4".  But I think the way
you have it is right, you just need to clear the a4 register after the
xor.
--------
[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549910.html

On Tue, Jul 14, 2020 at 4:37 PM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Jul 13, 2020 at 04:03:33AM +0000, guoren@kernel.org wrote:
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > TSK_STACK_CANARY only used in arm64/Makefile with
> > CONFIG_STACKPROTECTOR_PER_TASK wrap. So use the same policy in
> > asm-offset.c.
> >
> > Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
> > Co-developed-by: Kees Cook <keescook@chromium.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> >  arch/arm64/kernel/asm-offsets.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> > index 0577e21..37d5d3d 100644
> > --- a/arch/arm64/kernel/asm-offsets.c
> > +++ b/arch/arm64/kernel/asm-offsets.c
> > @@ -39,7 +39,7 @@ int main(void)
> >    DEFINE(TSK_TI_SCS_SP,              offsetof(struct task_struct, thread_info.scs_sp));
> >  #endif
> >    DEFINE(TSK_STACK,          offsetof(struct task_struct, stack));
> > -#ifdef CONFIG_STACKPROTECTOR
> > +#ifdef CONFIG_STACKPROTECTOR_PER_TASK
> >    DEFINE(TSK_STACK_CANARY,   offsetof(struct task_struct, stack_canary));
> >  #endif
>
> I don't think this really makese much sense. The 'stack_canary' field in
> 'struct task_struct' is defined as:
>
> #ifdef CONFIG_STACKPROTECTOR
>         /* Canary value for the -fstack-protector GCC feature: */
>         unsigned long                   stack_canary;
> #endif
>
> so I think it makes sense to follow that in asm-offsets.c
>
> Does the current code actually cause a problem?
>
> Will



--
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

^ permalink raw reply

* RE: Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?
From: Meng, Fino @ 2020-07-17  0:55 UTC (permalink / raw)
  To: 孙世龙 sunshilong; +Cc: Xenomai (xenomai@xenomai.org)
In-Reply-To: <CAAvDm6bKV3jueSVTj9c5yfrxTKVd-oMj1ETX4Z2xtiV+-nGKxQ@mail.gmail.com>

In my understanding cgroup's design is exclusionary with real-time/deterministic/time coordinate design,
The latency/jitter is already down to 20us level,  how it can endure cgroup's volatility, 
Do u really have strong requirement for this scenario? maybe it will work on a highly fine-tuned environment. 

BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling

>Sent: Thursday, July 16, 2020 8:01 PM
>
>Hi, list
>
>Are there some methods that could limit how much CPU resources could be maximally used by a single Xenomai process or
>thread?
>Does the Linux kernel's cgroup interface work for the Xenomai?
>
>The description about cgroup quoted from the Linux program manual:
>The kernel's cgroup interface is provided through a pseudo-filesystem called cgroupfs.
>Grouping is implemented in the core cgroup kernel code, while resource tracking and limits are implemented in a set of per-
>resource-type subsystems (memory, CPU, and so on).
>
>Thank you for your attention to this matter.
>Looking forward to hearing from you.
>Best Regards.


^ permalink raw reply

* Re: [PATCH] net: check payload length limit for all frames
From: Li Qiang @ 2020-07-17  0:53 UTC (permalink / raw)
  To: P J P
  Cc: Alexander Bulekov, Jason Wang, Dmitry Fleytman, QEMU Developers,
	Prasad J Pandit
In-Reply-To: <20200716192335.1212638-1-ppandit@redhat.com>

P J P <ppandit@redhat.com> 于2020年7月17日周五 上午3:26写道:
>
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> While sending packets, the check that packet 'payload_len'
> is within 64kB limit, seems to happen only for GSO frames.
> It may lead to use-after-free or out-of-bounds access like
> issues when sending non-GSO frames. Check the 'payload_len'
> limit for all packets, irrespective of the gso type.
>

Hello Prasad,
Which issue are you trying to solve, any reference linking?

I also send a patch related this part and also a UAF.

Thanks,
Li Qiang

> Reported-by: Alexander Bulekov <alxndr@bu.edu>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
>  hw/net/net_tx_pkt.c | 10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
> index 162f802dd7..e66998a8f9 100644
> --- a/hw/net/net_tx_pkt.c
> +++ b/hw/net/net_tx_pkt.c
> @@ -607,12 +607,10 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt, NetClientState *nc)
>       * Since underlying infrastructure does not support IP datagrams longer
>       * than 64K we should drop such packets and don't even try to send
>       */
> -    if (VIRTIO_NET_HDR_GSO_NONE != pkt->virt_hdr.gso_type) {
> -        if (pkt->payload_len >
> -            ETH_MAX_IP_DGRAM_LEN -
> -            pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> -            return false;
> -        }
> +    if (pkt->payload_len >
> +        ETH_MAX_IP_DGRAM_LEN -
> +        pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> +        return false;
>      }
>
>      if (pkt->has_virt_hdr ||
> --
> 2.26.2
>
>


^ permalink raw reply


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.