* Re: [PATCH 4/6] vfs: don't allow most setxattr to immutable files
From: Jan Kara @ 2019-06-20 14:03 UTC (permalink / raw)
To: Darrick J. Wong
Cc: linux-efi, linux-btrfs, yuchao0, linux-mm, clm, adilger.kernel,
matthew.garrett, linux-nilfs, linux-ext4, devel, josef,
reiserfs-devel, viro, dsterba, jaegeuk, tytso, ard.biesheuvel,
linux-kernel, linux-f2fs-devel, linux-xfs, jk, jack,
linux-fsdevel, linux-mtd, ocfs2-devel
In-Reply-To: <156022840560.3227213.4776913678782966728.stgit@magnolia>
On Mon 10-06-19 21:46:45, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metadata can not be modified, and the file can not be opened in write
> mode."
>
> However, we don't actually check the immutable flag in the setattr code,
> which means that we can update inode flags and project ids and extent
> size hints on supposedly immutable files. Therefore, reject setflags
> and fssetxattr calls on an immutable file if the file is immutable and
> will remain that way.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/inode.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
>
> diff --git a/fs/inode.c b/fs/inode.c
> index a3757051fd55..adfb458bf533 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -2184,6 +2184,17 @@ int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags)
> !capable(CAP_LINUX_IMMUTABLE))
> return -EPERM;
>
> + /*
> + * We aren't allowed to change any other flags if the immutable flag is
> + * already set and is not being unset.
> + */
> + if ((oldflags & FS_IMMUTABLE_FL) &&
> + (flags & FS_IMMUTABLE_FL)) {
> + if ((oldflags & ~FS_IMMUTABLE_FL) !=
> + (flags & ~FS_IMMUTABLE_FL))
This check looks a bit strange when you've just check FS_IMMUTABLE_FL isn't
changing... Why not just oldflags != flags?
> + if ((old_fa->fsx_xflags & FS_XFLAG_IMMUTABLE) &&
> + (fa->fsx_xflags & FS_XFLAG_IMMUTABLE)) {
> + if ((old_fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE) !=
> + (fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE))
Ditto here...
> + return -EPERM;
> + if (old_fa->fsx_projid != fa->fsx_projid)
> + return -EPERM;
> + if ((fa->fsx_xflags & (FS_XFLAG_EXTSIZE |
> + FS_XFLAG_EXTSZINHERIT)) &&
> + old_fa->fsx_extsize != fa->fsx_extsize)
> + return -EPERM;
> + if ((old_fa->fsx_xflags & FS_XFLAG_COWEXTSIZE) &&
> + old_fa->fsx_cowextsize != fa->fsx_cowextsize)
> + return -EPERM;
> + }
> +
> /* Extent size hints of zero turn off the flags. */
> if (fa->fsx_extsize == 0)
> fa->fsx_xflags &= ~(FS_XFLAG_EXTSIZE | FS_XFLAG_EXTSZINHERIT);
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [f2fs-dev] [PATCH 4/6] vfs: don't allow most setxattr to immutable files
From: Jan Kara @ 2019-06-20 14:03 UTC (permalink / raw)
To: Darrick J. Wong
Cc: linux-efi, linux-btrfs, linux-mm, clm, adilger.kernel,
matthew.garrett, linux-nilfs, linux-ext4, devel, josef,
reiserfs-devel, viro, dsterba, jaegeuk, tytso, ard.biesheuvel,
linux-kernel, linux-f2fs-devel, linux-xfs, jk, jack,
linux-fsdevel, linux-mtd, ocfs2-devel
In-Reply-To: <156022840560.3227213.4776913678782966728.stgit@magnolia>
On Mon 10-06-19 21:46:45, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metadata can not be modified, and the file can not be opened in write
> mode."
>
> However, we don't actually check the immutable flag in the setattr code,
> which means that we can update inode flags and project ids and extent
> size hints on supposedly immutable files. Therefore, reject setflags
> and fssetxattr calls on an immutable file if the file is immutable and
> will remain that way.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/inode.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
>
> diff --git a/fs/inode.c b/fs/inode.c
> index a3757051fd55..adfb458bf533 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -2184,6 +2184,17 @@ int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags)
> !capable(CAP_LINUX_IMMUTABLE))
> return -EPERM;
>
> + /*
> + * We aren't allowed to change any other flags if the immutable flag is
> + * already set and is not being unset.
> + */
> + if ((oldflags & FS_IMMUTABLE_FL) &&
> + (flags & FS_IMMUTABLE_FL)) {
> + if ((oldflags & ~FS_IMMUTABLE_FL) !=
> + (flags & ~FS_IMMUTABLE_FL))
This check looks a bit strange when you've just check FS_IMMUTABLE_FL isn't
changing... Why not just oldflags != flags?
> + if ((old_fa->fsx_xflags & FS_XFLAG_IMMUTABLE) &&
> + (fa->fsx_xflags & FS_XFLAG_IMMUTABLE)) {
> + if ((old_fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE) !=
> + (fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE))
Ditto here...
> + return -EPERM;
> + if (old_fa->fsx_projid != fa->fsx_projid)
> + return -EPERM;
> + if ((fa->fsx_xflags & (FS_XFLAG_EXTSIZE |
> + FS_XFLAG_EXTSZINHERIT)) &&
> + old_fa->fsx_extsize != fa->fsx_extsize)
> + return -EPERM;
> + if ((old_fa->fsx_xflags & FS_XFLAG_COWEXTSIZE) &&
> + old_fa->fsx_cowextsize != fa->fsx_cowextsize)
> + return -EPERM;
> + }
> +
> /* Extent size hints of zero turn off the flags. */
> if (fa->fsx_extsize == 0)
> fa->fsx_xflags &= ~(FS_XFLAG_EXTSIZE | FS_XFLAG_EXTSZINHERIT);
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [PATCH 4/6] vfs: don't allow most setxattr to immutable files
From: Jan Kara @ 2019-06-20 14:03 UTC (permalink / raw)
To: Darrick J. Wong
Cc: matthew.garrett, yuchao0, tytso, ard.biesheuvel, josef, clm,
adilger.kernel, viro, jack, dsterba, jaegeuk, jk, reiserfs-devel,
linux-efi, devel, linux-kernel, linux-f2fs-devel, linux-xfs,
linux-mm, linux-nilfs, linux-mtd, ocfs2-devel, linux-fsdevel,
linux-ext4, linux-btrfs
In-Reply-To: <156022840560.3227213.4776913678782966728.stgit@magnolia>
On Mon 10-06-19 21:46:45, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metadata can not be modified, and the file can not be opened in write
> mode."
>
> However, we don't actually check the immutable flag in the setattr code,
> which means that we can update inode flags and project ids and extent
> size hints on supposedly immutable files. Therefore, reject setflags
> and fssetxattr calls on an immutable file if the file is immutable and
> will remain that way.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/inode.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
>
> diff --git a/fs/inode.c b/fs/inode.c
> index a3757051fd55..adfb458bf533 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -2184,6 +2184,17 @@ int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags)
> !capable(CAP_LINUX_IMMUTABLE))
> return -EPERM;
>
> + /*
> + * We aren't allowed to change any other flags if the immutable flag is
> + * already set and is not being unset.
> + */
> + if ((oldflags & FS_IMMUTABLE_FL) &&
> + (flags & FS_IMMUTABLE_FL)) {
> + if ((oldflags & ~FS_IMMUTABLE_FL) !=
> + (flags & ~FS_IMMUTABLE_FL))
This check looks a bit strange when you've just check FS_IMMUTABLE_FL isn't
changing... Why not just oldflags != flags?
> + if ((old_fa->fsx_xflags & FS_XFLAG_IMMUTABLE) &&
> + (fa->fsx_xflags & FS_XFLAG_IMMUTABLE)) {
> + if ((old_fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE) !=
> + (fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE))
Ditto here...
> + return -EPERM;
> + if (old_fa->fsx_projid != fa->fsx_projid)
> + return -EPERM;
> + if ((fa->fsx_xflags & (FS_XFLAG_EXTSIZE |
> + FS_XFLAG_EXTSZINHERIT)) &&
> + old_fa->fsx_extsize != fa->fsx_extsize)
> + return -EPERM;
> + if ((old_fa->fsx_xflags & FS_XFLAG_COWEXTSIZE) &&
> + old_fa->fsx_cowextsize != fa->fsx_cowextsize)
> + return -EPERM;
> + }
> +
> /* Extent size hints of zero turn off the flags. */
> if (fa->fsx_extsize == 0)
> fa->fsx_xflags &= ~(FS_XFLAG_EXTSIZE | FS_XFLAG_EXTSZINHERIT);
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [Qemu-devel] [PATCH v2 1/4] target/mips: Fix emulation of ILVEV.<B|H|W> on big endian host
From: Aleksandar Markovic @ 2019-06-20 13:45 UTC (permalink / raw)
To: qemu-devel; +Cc: arikalo, amarkovic
In-Reply-To: <1561038349-17105-1-git-send-email-aleksandar.markovic@rt-rk.com>
From: Aleksandar Markovic <amarkovic@wavecomp.com>
Fix emulation of ILVEV.<B|H|W> on big endian host by applying
mapping of data element indexes from one endian to another.
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com>
---
target/mips/msa_helper.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/target/mips/msa_helper.c b/target/mips/msa_helper.c
index be059a3..215d8af 100644
--- a/target/mips/msa_helper.c
+++ b/target/mips/msa_helper.c
@@ -1737,6 +1737,24 @@ void helper_msa_ilvev_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
switch (df) {
case DF_BYTE:
+#if defined(TARGET_WORDS_BIGENDIAN)
+ pwd->b[8] = pws->b[9];
+ pwd->b[9] = pwt->b[9];
+ pwd->b[10] = pws->b[11];
+ pwd->b[11] = pwt->b[11];
+ pwd->b[12] = pws->b[13];
+ pwd->b[13] = pwt->b[13];
+ pwd->b[14] = pws->b[15];
+ pwd->b[15] = pwt->b[15];
+ pwd->b[0] = pws->b[1];
+ pwd->b[1] = pwt->b[1];
+ pwd->b[2] = pws->b[3];
+ pwd->b[3] = pwt->b[3];
+ pwd->b[4] = pws->b[5];
+ pwd->b[5] = pwt->b[5];
+ pwd->b[6] = pws->b[7];
+ pwd->b[7] = pwt->b[7];
+#else
pwd->b[15] = pws->b[14];
pwd->b[14] = pwt->b[14];
pwd->b[13] = pws->b[12];
@@ -1753,8 +1771,19 @@ void helper_msa_ilvev_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
pwd->b[2] = pwt->b[2];
pwd->b[1] = pws->b[0];
pwd->b[0] = pwt->b[0];
+#endif
break;
case DF_HALF:
+#if defined(TARGET_WORDS_BIGENDIAN)
+ pwd->h[4] = pws->h[5];
+ pwd->h[5] = pwt->h[5];
+ pwd->h[6] = pws->h[7];
+ pwd->h[7] = pwt->h[7];
+ pwd->h[0] = pws->h[1];
+ pwd->h[1] = pwt->h[1];
+ pwd->h[2] = pws->h[3];
+ pwd->h[3] = pwt->h[3];
+#else
pwd->h[7] = pws->h[6];
pwd->h[6] = pwt->h[6];
pwd->h[5] = pws->h[4];
@@ -1763,12 +1792,20 @@ void helper_msa_ilvev_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
pwd->h[2] = pwt->h[2];
pwd->h[1] = pws->h[0];
pwd->h[0] = pwt->h[0];
+#endif
break;
case DF_WORD:
+#if defined(TARGET_WORDS_BIGENDIAN)
+ pwd->w[2] = pws->w[3];
+ pwd->w[3] = pwt->w[3];
+ pwd->w[0] = pws->w[1];
+ pwd->w[1] = pwt->w[1];
+#else
pwd->w[3] = pws->w[2];
pwd->w[2] = pwt->w[2];
pwd->w[1] = pws->w[0];
pwd->w[0] = pwt->w[0];
+#endif
break;
case DF_DOUBLE:
pwd->d[1] = pws->d[0];
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [PATCH v2 0/4] target/mips: Fix some issues of MSA emulation on big endian hosts
From: Aleksandar Markovic @ 2019-06-20 13:45 UTC (permalink / raw)
To: qemu-devel; +Cc: arikalo, amarkovic
From: Aleksandar Markovic <amarkovic@wavecomp.com>
Fix some issues of MSA emulation on big endian hosts.
v1->v2:
- updated commit messages
Aleksandar Markovic (4):
target/mips: Fix emulation of ILVEV.<B|H|W> on big endian host
target/mips: Fix emulation of ILVOD.<B|H|W> on big endian host
target/mips: Fix emulation of ILVL.<B|H|W> on big endian host
target/mips: Fix emulation of ILVR.<B|H|W> on big endian host
target/mips/msa_helper.c | 148 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 148 insertions(+)
--
2.7.4
^ permalink raw reply
* [Ocfs2-devel] [PATCH 4/6] vfs: don't allow most setxattr to immutable files
From: Jan Kara @ 2019-06-20 14:03 UTC (permalink / raw)
To: Darrick J. Wong
Cc: matthew.garrett, yuchao0, tytso, ard.biesheuvel, josef, clm,
adilger.kernel, viro, jack, dsterba, jaegeuk, jk, reiserfs-devel,
linux-efi, devel, linux-kernel, linux-f2fs-devel, linux-xfs,
linux-mm, linux-nilfs, linux-mtd, ocfs2-devel, linux-fsdevel,
linux-ext4, linux-btrfs
In-Reply-To: <156022840560.3227213.4776913678782966728.stgit@magnolia>
On Mon 10-06-19 21:46:45, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metadata can not be modified, and the file can not be opened in write
> mode."
>
> However, we don't actually check the immutable flag in the setattr code,
> which means that we can update inode flags and project ids and extent
> size hints on supposedly immutable files. Therefore, reject setflags
> and fssetxattr calls on an immutable file if the file is immutable and
> will remain that way.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/inode.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
>
> diff --git a/fs/inode.c b/fs/inode.c
> index a3757051fd55..adfb458bf533 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -2184,6 +2184,17 @@ int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags)
> !capable(CAP_LINUX_IMMUTABLE))
> return -EPERM;
>
> + /*
> + * We aren't allowed to change any other flags if the immutable flag is
> + * already set and is not being unset.
> + */
> + if ((oldflags & FS_IMMUTABLE_FL) &&
> + (flags & FS_IMMUTABLE_FL)) {
> + if ((oldflags & ~FS_IMMUTABLE_FL) !=
> + (flags & ~FS_IMMUTABLE_FL))
This check looks a bit strange when you've just check FS_IMMUTABLE_FL isn't
changing... Why not just oldflags != flags?
> + if ((old_fa->fsx_xflags & FS_XFLAG_IMMUTABLE) &&
> + (fa->fsx_xflags & FS_XFLAG_IMMUTABLE)) {
> + if ((old_fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE) !=
> + (fa->fsx_xflags & ~FS_XFLAG_IMMUTABLE))
Ditto here...
> + return -EPERM;
> + if (old_fa->fsx_projid != fa->fsx_projid)
> + return -EPERM;
> + if ((fa->fsx_xflags & (FS_XFLAG_EXTSIZE |
> + FS_XFLAG_EXTSZINHERIT)) &&
> + old_fa->fsx_extsize != fa->fsx_extsize)
> + return -EPERM;
> + if ((old_fa->fsx_xflags & FS_XFLAG_COWEXTSIZE) &&
> + old_fa->fsx_cowextsize != fa->fsx_cowextsize)
> + return -EPERM;
> + }
> +
> /* Extent size hints of zero turn off the flags. */
> if (fa->fsx_extsize == 0)
> fa->fsx_xflags &= ~(FS_XFLAG_EXTSIZE | FS_XFLAG_EXTSZINHERIT);
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH 2/4] switch: allow to switch in the middle of bisect
From: Derrick Stolee @ 2019-06-20 14:02 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20190620095523.10003-3-pclouds@gmail.com>
On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> In c45f0f525d (switch: reject if some operation is in progress,
> 2019-03-29), a check is added to prevent switching when some operation
> is in progress. The reason is it's often not safe to do so.
>
> This is true for merge, am, rebase, cherry-pick and revert, but not so
> much for bisect because bisecting is basically jumping/switching between
> a bunch of commits to pin point the first bad one. git-bisect suggests
> the next commit to test, but it's not wrong for the user to test a
> different commit because git-bisect cannot have the knowledge to know
> better.
When a user switches commits during a bisect, it can just create new
known-good or known-bad commits, right? It won't mess up the next
selection of a test commit? I'm imagining someone jumping to a commit
between two known-bad commits or something, when it is more likely that
they are jumping to a parallel history.
> For this reason, allow to switch when bisecting (*). I considered if we
> should still prevent switching by default and allow it with
> --ignore-in-progress. But I don't think the prevention really adds
> anything much.
>
> If the user switches away by mistake, since we print the previous HEAD
> value, even if they don't know about the "-" shortcut, switching back is
> still possible.
I tell everyone I know about the "-" shortcut, and I'm always surprised
they didn't already know about "cd -".
> The warning will be printed on every switch while bisect is still
> ongoing, not the first time you switch away from bisect's suggested
> commit, so it could become a bit annoying.
I think a one-line warning is fine, as a power user doing this a lot
will develop blinders that ignore the message as they switch during
a bisect.
-Stolee
^ permalink raw reply
* [Buildroot] [git commit] package/psplash: add license file details
From: Thomas Petazzoni @ 2019-06-20 14:01 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=32a0d3a8e2cf78f0f36b948ba5ea5aa85c2ceeb1
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/psplash/psplash.hash | 1 +
package/psplash/psplash.mk | 1 +
2 files changed, 2 insertions(+)
diff --git a/package/psplash/psplash.hash b/package/psplash/psplash.hash
index 68c6ffa8a9..c8865697c4 100644
--- a/package/psplash/psplash.hash
+++ b/package/psplash/psplash.hash
@@ -1,2 +1,3 @@
# Locally computed
sha256 aaddb20ef892dfb03d4e046cc634159bbcdfe555f7291652dde2b7d4cf491289 psplash-5b3c1cc28f5abdc2c33830150b48b278cc4f7bca.tar.gz
+sha256 f9c375a1be4a41f7b70301dd83c91cb89e41567478859b77eef375a52d782505 COPYING
diff --git a/package/psplash/psplash.mk b/package/psplash/psplash.mk
index fe009785b9..4a2e0de5ce 100644
--- a/package/psplash/psplash.mk
+++ b/package/psplash/psplash.mk
@@ -7,6 +7,7 @@
PSPLASH_VERSION = 5b3c1cc28f5abdc2c33830150b48b278cc4f7bca
PSPLASH_SITE = git://git.yoctoproject.org/psplash
PSPLASH_LICENSE = GPL-2.0+
+PSPLASH_LICENSE_FILES = COPYING
PSPLASH_AUTORECONF = YES
define PSPLASH_INSTALL_INIT_SYSTEMD
^ permalink raw reply related
* Re: [PATCH net] af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
From: Matteo Croce @ 2019-06-20 14:01 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Neil Horman, Network Development, David S. Miller
In-Reply-To: <CA+FuTSe=kJSSvcYwCE9-omRF5Snd9AyesZac61PYyAHDStPt=A@mail.gmail.com>
On Thu, Jun 20, 2019 at 3:42 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Wed, Jun 19, 2019 at 4:26 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > When an application is run that:
> > a) Sets its scheduler to be SCHED_FIFO
> > and
> > b) Opens a memory mapped AF_PACKET socket, and sends frames with the
> > MSG_DONTWAIT flag cleared, its possible for the application to hang
> > forever in the kernel. This occurs because when waiting, the code in
> > tpacket_snd calls schedule, which under normal circumstances allows
> > other tasks to run, including ksoftirqd, which in some cases is
> > responsible for freeing the transmitted skb (which in AF_PACKET calls a
> > destructor that flips the status bit of the transmitted frame back to
> > available, allowing the transmitting task to complete).
> >
> > However, when the calling application is SCHED_FIFO, its priority is
> > such that the schedule call immediately places the task back on the cpu,
> > preventing ksoftirqd from freeing the skb, which in turn prevents the
> > transmitting task from detecting that the transmission is complete.
> >
> > We can fix this by converting the schedule call to a completion
> > mechanism. By using a completion queue, we force the calling task, when
> > it detects there are no more frames to send, to schedule itself off the
> > cpu until such time as the last transmitted skb is freed, allowing
> > forward progress to be made.
> >
> > Tested by myself and the reporter, with good results
> >
> > Appies to the net tree
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > Reported-by: Matteo Croce <mcroce@redhat.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > ---
>
> This is a complex change for a narrow configuration. Isn't a
> SCHED_FIFO process preempting ksoftirqd a potential problem for other
> networking workloads as well? And the right configuration to always
> increase ksoftirqd priority when increasing another process's
> priority? Also, even when ksoftirqd kicks in, isn't some progress
> still made on the local_bh_enable reached from schedule()?
Hi Willem,
from my tests, it seems that when the application hangs, raising the
ksoftirqd priority doesn't help.
If the application priority is the same as ksoftirqd, it will loop
forever, the only workaround is to lower the application priority or
set it to SCHED_NORMAL
Regards,
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* [Buildroot] [PATCH v2, 1/1] package/libidn2: bump to version 2.2.0
From: Thomas Petazzoni @ 2019-06-20 14:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190619182422.6237-1-fontaine.fabrice@gmail.com>
On Wed, 19 Jun 2019 20:24:22 +0200
Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
> Changes v1 -> v2:
> - Fix package's name
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v7 20/21] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
From: Yong Wu @ 2019-06-20 14:00 UTC (permalink / raw)
To: Matthias Brugger
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Joerg Roedel, Will Deacon, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, yingjoe.chen, anan.sun,
Robin Murphy, Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <db9b3b2f-3206-01bf-f0f9-67251e5ff756@gmail.com>
On Tue, 2019-06-18 at 18:35 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > In the 4GB mode, the physical address is remapped,
> >
> > Here is the detailed remap relationship.
> > CPU PA -> HW PA
> > 0x4000_0000 0x1_4000_0000 (Add bit32)
> > 0x8000_0000 0x1_8000_0000 ...
> > 0xc000_0000 0x1_c000_0000 ...
> > 0x1_0000_0000 0x1_0000_0000 (No change)
> >
> > Thus, we always add bit32 for PA when entering mtk_iommu_map.
> > But in the iova_to_phys, the CPU don't need this bit32 if the
> > PA is from 0x1_4000_0000 to 0x1_ffff_ffff.
> > This patch discards the bit32 in this iova_to_phys in the 4GB mode.
> >
> > Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> > for 4GB mode")
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 67cab2d..34f2e40 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -119,6 +119,19 @@ struct mtk_iommu_domain {
> >
> > static const struct iommu_ops mtk_iommu_ops;
> >
> > +/*
> > + * In M4U 4GB mode, the physical address is remapped as below:
> > + * CPU PA -> M4U HW PA
> > + * 0x4000_0000 0x1_4000_0000 (Add bit32)
> > + * 0x8000_0000 0x1_8000_0000 ...
> > + * 0xc000_0000 0x1_c000_0000 ...
> > + * 0x1_0000_0000 0x1_0000_0000 (No change)
> > + *
> > + * Thus, We always add BIT32 in the iommu_map and disable BIT32 if PA is >=
> > + * 0x1_4000_0000 in the iova_to_phys.
> > + */
> > +#define MTK_IOMMU_4GB_MODE_PA_140000000 0x140000000UL
> > +
> > static LIST_HEAD(m4ulist); /* List all the M4U HWs */
> >
> > #define for_each_m4u(data) list_for_each_entry(data, &m4ulist, list)
> > @@ -415,6 +428,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > dma_addr_t iova)
> > {
> > struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> > + struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
> > unsigned long flags;
> > phys_addr_t pa;
> >
> > @@ -422,6 +436,10 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > pa = dom->iop->iova_to_phys(dom->iop, iova);
> > spin_unlock_irqrestore(&dom->pgtlock, flags);
> >
> > + if (data->plat_data->has_4gb_mode && data->dram_is_4gb &&
> > + pa >= MTK_IOMMU_4GB_MODE_PA_140000000)
> > + pa &= ~BIT_ULL(32);
> > +
>
> Hm, I wonder if we could fix this as first patch in the series, especially before:
> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
OK.
>
> This would make it easier for the stable maintainer to cherry-pick the fix.
> Without 100% understanding the code, it seems suspicious to me, that you first
> move the setting of the bit32 and bit33 into v7s and later explicitly clean the
> bits here.
>
> So my take on this is, that patch 6/21 introduced the regression you are trying
> to fix here. As said that is speculation as I don't understand the code in its
> whole.
>
> Any clarification would be useful.
I guess the commit message in [06/21] will be helpful.
In the previous mt8173 and mt2712, the M4U HW support "4GB mode" in
which the range of dram is from 0x4000_0000 to 0x1_3fff_ffff and it was
remapped to 0x1_0000_0000 ~0x1_ffff_ffff(For readable, I have wrote the
re-map relationship into the code in this patch.). but mt8183 don't need
remap the dram address(0x4000_0000 ~ 0x3_ffff_ffff).
In order to unify the code, we add bit32 for "4GB mode". But actually
the PA doesn't always have bit32, thus, I have to remove bit32 when PA >
0x1_4000_0000.
So sorry that the "4GB mode" is a little unreadable and special, And the
4GB patch(30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode") has introduced several fix patches.
>
> Regards,
> Matthias
>
> > return pa;
> > }
> >
> >
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Buildroot] [git commit] package/libidn2: bump to version 2.2.0
From: Thomas Petazzoni @ 2019-06-20 14:01 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=4455af3f7fe154b9928efa1ff8601ffec92c5b1a
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/libidn2/libidn2.hash | 2 +-
package/libidn2/libidn2.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/libidn2/libidn2.hash b/package/libidn2/libidn2.hash
index 300cedb479..3dae7f7590 100644
--- a/package/libidn2/libidn2.hash
+++ b/package/libidn2/libidn2.hash
@@ -1,5 +1,5 @@
# Calculated locally after checking signature
-sha256 032398dbaa9537af43f51a8d94e967e3718848547b1b2a4eb3138b20cad11d32 libidn2-2.1.0.tar.gz
+sha256 fc734732b506d878753ec6606982bf7b936e868c25c30ddb0d83f7d7056381fe libidn2-2.2.0.tar.gz
# Hash for license files:
sha256 73483f797a83373fca1b968c11785b98c4fc4803cdc7d3210811ca8b075d6d76 COPYING
diff --git a/package/libidn2/libidn2.mk b/package/libidn2/libidn2.mk
index 7112553fea..10f179ebcc 100644
--- a/package/libidn2/libidn2.mk
+++ b/package/libidn2/libidn2.mk
@@ -4,7 +4,7 @@
#
################################################################################
-LIBIDN2_VERSION = 2.1.0
+LIBIDN2_VERSION = 2.2.0
LIBIDN2_SITE = $(BR2_GNU_MIRROR)/libidn
LIBIDN2_LICENSE := GPL-2.0+ or LGPL-3.0+ (library)
LIBIDN2_LICENSE_FILES = COPYING COPYINGv2 COPYING.LESSERv3 COPYING.unicode
^ permalink raw reply related
* Re: [PATCH v7 20/21] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
From: Yong Wu @ 2019-06-20 14:00 UTC (permalink / raw)
To: Matthias Brugger
Cc: Joerg Roedel, Robin Murphy, Rob Herring, youlin.pei, devicetree,
Nicolas Boichat, srv_heupstream, Will Deacon, linux-kernel,
Evan Green, Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek,
yingjoe.chen, anan.sun, linux-arm-kernel
In-Reply-To: <db9b3b2f-3206-01bf-f0f9-67251e5ff756@gmail.com>
On Tue, 2019-06-18 at 18:35 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > In the 4GB mode, the physical address is remapped,
> >
> > Here is the detailed remap relationship.
> > CPU PA -> HW PA
> > 0x4000_0000 0x1_4000_0000 (Add bit32)
> > 0x8000_0000 0x1_8000_0000 ...
> > 0xc000_0000 0x1_c000_0000 ...
> > 0x1_0000_0000 0x1_0000_0000 (No change)
> >
> > Thus, we always add bit32 for PA when entering mtk_iommu_map.
> > But in the iova_to_phys, the CPU don't need this bit32 if the
> > PA is from 0x1_4000_0000 to 0x1_ffff_ffff.
> > This patch discards the bit32 in this iova_to_phys in the 4GB mode.
> >
> > Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> > for 4GB mode")
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 67cab2d..34f2e40 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -119,6 +119,19 @@ struct mtk_iommu_domain {
> >
> > static const struct iommu_ops mtk_iommu_ops;
> >
> > +/*
> > + * In M4U 4GB mode, the physical address is remapped as below:
> > + * CPU PA -> M4U HW PA
> > + * 0x4000_0000 0x1_4000_0000 (Add bit32)
> > + * 0x8000_0000 0x1_8000_0000 ...
> > + * 0xc000_0000 0x1_c000_0000 ...
> > + * 0x1_0000_0000 0x1_0000_0000 (No change)
> > + *
> > + * Thus, We always add BIT32 in the iommu_map and disable BIT32 if PA is >=
> > + * 0x1_4000_0000 in the iova_to_phys.
> > + */
> > +#define MTK_IOMMU_4GB_MODE_PA_140000000 0x140000000UL
> > +
> > static LIST_HEAD(m4ulist); /* List all the M4U HWs */
> >
> > #define for_each_m4u(data) list_for_each_entry(data, &m4ulist, list)
> > @@ -415,6 +428,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > dma_addr_t iova)
> > {
> > struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> > + struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
> > unsigned long flags;
> > phys_addr_t pa;
> >
> > @@ -422,6 +436,10 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > pa = dom->iop->iova_to_phys(dom->iop, iova);
> > spin_unlock_irqrestore(&dom->pgtlock, flags);
> >
> > + if (data->plat_data->has_4gb_mode && data->dram_is_4gb &&
> > + pa >= MTK_IOMMU_4GB_MODE_PA_140000000)
> > + pa &= ~BIT_ULL(32);
> > +
>
> Hm, I wonder if we could fix this as first patch in the series, especially before:
> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
OK.
>
> This would make it easier for the stable maintainer to cherry-pick the fix.
> Without 100% understanding the code, it seems suspicious to me, that you first
> move the setting of the bit32 and bit33 into v7s and later explicitly clean the
> bits here.
>
> So my take on this is, that patch 6/21 introduced the regression you are trying
> to fix here. As said that is speculation as I don't understand the code in its
> whole.
>
> Any clarification would be useful.
I guess the commit message in [06/21] will be helpful.
In the previous mt8173 and mt2712, the M4U HW support "4GB mode" in
which the range of dram is from 0x4000_0000 to 0x1_3fff_ffff and it was
remapped to 0x1_0000_0000 ~0x1_ffff_ffff(For readable, I have wrote the
re-map relationship into the code in this patch.). but mt8183 don't need
remap the dram address(0x4000_0000 ~ 0x3_ffff_ffff).
In order to unify the code, we add bit32 for "4GB mode". But actually
the PA doesn't always have bit32, thus, I have to remove bit32 when PA >
0x1_4000_0000.
So sorry that the "4GB mode" is a little unreadable and special, And the
4GB patch(30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode") has introduced several fix patches.
>
> Regards,
> Matthias
>
> > return pa;
> > }
> >
> >
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v7 20/21] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
From: Yong Wu @ 2019-06-20 14:00 UTC (permalink / raw)
To: Matthias Brugger
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, linux-kernel, Evan Green, Tomasz Figa, iommu,
Rob Herring, linux-mediatek, yingjoe.chen, anan.sun, Robin Murphy,
Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <db9b3b2f-3206-01bf-f0f9-67251e5ff756@gmail.com>
On Tue, 2019-06-18 at 18:35 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > In the 4GB mode, the physical address is remapped,
> >
> > Here is the detailed remap relationship.
> > CPU PA -> HW PA
> > 0x4000_0000 0x1_4000_0000 (Add bit32)
> > 0x8000_0000 0x1_8000_0000 ...
> > 0xc000_0000 0x1_c000_0000 ...
> > 0x1_0000_0000 0x1_0000_0000 (No change)
> >
> > Thus, we always add bit32 for PA when entering mtk_iommu_map.
> > But in the iova_to_phys, the CPU don't need this bit32 if the
> > PA is from 0x1_4000_0000 to 0x1_ffff_ffff.
> > This patch discards the bit32 in this iova_to_phys in the 4GB mode.
> >
> > Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> > for 4GB mode")
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 67cab2d..34f2e40 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -119,6 +119,19 @@ struct mtk_iommu_domain {
> >
> > static const struct iommu_ops mtk_iommu_ops;
> >
> > +/*
> > + * In M4U 4GB mode, the physical address is remapped as below:
> > + * CPU PA -> M4U HW PA
> > + * 0x4000_0000 0x1_4000_0000 (Add bit32)
> > + * 0x8000_0000 0x1_8000_0000 ...
> > + * 0xc000_0000 0x1_c000_0000 ...
> > + * 0x1_0000_0000 0x1_0000_0000 (No change)
> > + *
> > + * Thus, We always add BIT32 in the iommu_map and disable BIT32 if PA is >=
> > + * 0x1_4000_0000 in the iova_to_phys.
> > + */
> > +#define MTK_IOMMU_4GB_MODE_PA_140000000 0x140000000UL
> > +
> > static LIST_HEAD(m4ulist); /* List all the M4U HWs */
> >
> > #define for_each_m4u(data) list_for_each_entry(data, &m4ulist, list)
> > @@ -415,6 +428,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > dma_addr_t iova)
> > {
> > struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> > + struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
> > unsigned long flags;
> > phys_addr_t pa;
> >
> > @@ -422,6 +436,10 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > pa = dom->iop->iova_to_phys(dom->iop, iova);
> > spin_unlock_irqrestore(&dom->pgtlock, flags);
> >
> > + if (data->plat_data->has_4gb_mode && data->dram_is_4gb &&
> > + pa >= MTK_IOMMU_4GB_MODE_PA_140000000)
> > + pa &= ~BIT_ULL(32);
> > +
>
> Hm, I wonder if we could fix this as first patch in the series, especially before:
> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
OK.
>
> This would make it easier for the stable maintainer to cherry-pick the fix.
> Without 100% understanding the code, it seems suspicious to me, that you first
> move the setting of the bit32 and bit33 into v7s and later explicitly clean the
> bits here.
>
> So my take on this is, that patch 6/21 introduced the regression you are trying
> to fix here. As said that is speculation as I don't understand the code in its
> whole.
>
> Any clarification would be useful.
I guess the commit message in [06/21] will be helpful.
In the previous mt8173 and mt2712, the M4U HW support "4GB mode" in
which the range of dram is from 0x4000_0000 to 0x1_3fff_ffff and it was
remapped to 0x1_0000_0000 ~0x1_ffff_ffff(For readable, I have wrote the
re-map relationship into the code in this patch.). but mt8183 don't need
remap the dram address(0x4000_0000 ~ 0x3_ffff_ffff).
In order to unify the code, we add bit32 for "4GB mode". But actually
the PA doesn't always have bit32, thus, I have to remove bit32 when PA >
0x1_4000_0000.
So sorry that the "4GB mode" is a little unreadable and special, And the
4GB patch(30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode") has introduced several fix patches.
>
> Regards,
> Matthias
>
> > return pa;
> > }
> >
> >
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH 3/3] drm/i915/execlists: Force preemption
From: Mika Kuoppala @ 2019-06-20 14:00 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
In-Reply-To: <20190620070559.30076-3-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> If the preempted context takes too long to relinquish control, e.g. it
> is stuck inside a shader with arbitration disabled, evict that context
> with an engine reset. This ensures that preemptions are reasonably
> responsive, providing a tighter QoS for the more important context at
> the cost of flagging unresponsive contexts more frequently (i.e. instead
> of using an ~10s hangcheck, we now evict at ~10ms). The challenge of
> lies in picking a timeout that can be reasonably serviced by HW for
> typical workloads, balancing the existing clients against the needs for
> responsiveness.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> drivers/gpu/drm/i915/Kconfig.profile | 12 ++++++
> drivers/gpu/drm/i915/gt/intel_lrc.c | 56 ++++++++++++++++++++++++++--
> 2 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile
> index 48df8889a88a..8273d3baafe4 100644
> --- a/drivers/gpu/drm/i915/Kconfig.profile
> +++ b/drivers/gpu/drm/i915/Kconfig.profile
> @@ -25,3 +25,15 @@ config DRM_I915_SPIN_REQUEST
> May be 0 to disable the initial spin. In practice, we estimate
> the cost of enabling the interrupt (if currently disabled) to be
> a few microseconds.
> +
> +config DRM_I915_PREEMPT_TIMEOUT
> + int "Preempt timeout (ms)"
> + default 10 # milliseconds
> + help
> + How long to wait (in milliseconds) for a preemption event to occur
> + when submitting a new context via execlists. If the current context
> + does not hit an arbitration point and yield to HW before the timer
> + expires, the HW will be reset to allow the more important context
> + to execute.
> +
> + May be 0 to disable the timeout.
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index fca79adb4aa3..e8d7deba3e49 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -889,6 +889,15 @@ enable_timeslice(struct intel_engine_cs *engine)
> return last && need_timeslice(engine, last);
> }
>
> +static unsigned long preempt_expires(void)
> +{
> + unsigned long timeout =
could be const
> + msecs_to_jiffies_timeout(CONFIG_DRM_I915_PREEMPT_TIMEOUT);
> +
> + barrier();
This needs a comment. I fail to connect the dots as jiffies
is volatile by nature.
> + return jiffies + timeout;
> +}
> +
> static void execlists_dequeue(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlists * const execlists = &engine->execlists;
> @@ -1220,6 +1229,9 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
> *port = execlists_schedule_in(last, port - execlists->pending);
> memset(port + 1, 0, (last_port - port) * sizeof(*port));
> execlists_submit_ports(engine);
> +
> + if (CONFIG_DRM_I915_PREEMPT_TIMEOUT)
> + mod_timer(&execlists->timer, preempt_expires());
> }
> }
>
> @@ -1376,13 +1388,48 @@ static void process_csb(struct intel_engine_cs *engine)
> invalidate_csb_entries(&buf[0], &buf[num_entries - 1]);
> }
>
> -static void __execlists_submission_tasklet(struct intel_engine_cs *const engine)
> +static bool __execlists_submission_tasklet(struct intel_engine_cs *const engine)
> {
> lockdep_assert_held(&engine->active.lock);
>
> process_csb(engine);
> - if (!engine->execlists.pending[0])
> + if (!engine->execlists.pending[0]) {
> execlists_dequeue(engine);
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void preempt_reset(struct intel_engine_cs *engine)
> +{
> + const unsigned int bit = I915_RESET_ENGINE + engine->id;
> + unsigned long *lock = &engine->i915->gpu_error.flags;
> +
> + if (test_and_set_bit(bit, lock))
> + return;
> +
> + tasklet_disable_nosync(&engine->execlists.tasklet);
> + spin_unlock(&engine->active.lock);
> +
Why do we need to drop the lock?
-Mika
> + i915_reset_engine(engine, "preemption time out");
> +
> + spin_lock(&engine->active.lock);
> + tasklet_enable(&engine->execlists.tasklet);
> +
> + clear_bit(bit, lock);
> + wake_up_bit(lock, bit);
> +}
> +
> +static bool preempt_timeout(struct intel_engine_cs *const engine)
> +{
> + if (!CONFIG_DRM_I915_PREEMPT_TIMEOUT)
> + return false;
> +
> + if (!intel_engine_has_preemption(engine))
> + return false;
> +
> + return !timer_pending(&engine->execlists.timer);
> }
>
> /*
> @@ -1395,7 +1442,10 @@ static void execlists_submission_tasklet(unsigned long data)
> unsigned long flags;
>
> spin_lock_irqsave(&engine->active.lock, flags);
> - __execlists_submission_tasklet(engine);
> +
> + if (!__execlists_submission_tasklet(engine) && preempt_timeout(engine))
> + preempt_reset(engine);
> +
> spin_unlock_irqrestore(&engine->active.lock, flags);
> }
>
> --
> 2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/6] vfs: flush and wait for io when setting the immutable flag via SETFLAGS
From: Jan Kara @ 2019-06-20 14:00 UTC (permalink / raw)
To: Darrick J. Wong
Cc: linux-efi, linux-btrfs, yuchao0, linux-mm, clm, adilger.kernel,
matthew.garrett, linux-nilfs, linux-ext4, devel, josef,
reiserfs-devel, viro, dsterba, jaegeuk, tytso, ard.biesheuvel,
linux-kernel, linux-f2fs-devel, linux-xfs, jk, jack,
linux-fsdevel, linux-mtd, ocfs2-devel
In-Reply-To: <156022838496.3227213.3771632042609589318.stgit@magnolia>
On Mon 10-06-19 21:46:25, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> need to ensure that userspace can't continue to write the file after the
> file becomes immutable. To make that happen, we have to flush all the
> dirty pagecache pages to disk to ensure that we can fail a page fault on
> a mmap'd region, wait for pending directio to complete, and hope the
> caller locked out any new writes by holding the inode lock.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
...
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 6aa1df1918f7..a05341b94d98 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -290,6 +290,9 @@ static int ext4_ioctl_setflags(struct inode *inode,
> jflag = flags & EXT4_JOURNAL_DATA_FL;
>
> err = vfs_ioc_setflags_check(inode, oldflags, flags);
> + if (err)
> + goto flags_out;
> + err = vfs_ioc_setflags_flush_data(inode, flags);
> if (err)
> goto flags_out;
>
...
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8dad3c80b611..9c899c63957e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3548,7 +3548,41 @@ static inline struct sock *io_uring_get_socket(struct file *file)
>
> int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags);
>
> +/*
> + * Do we need to flush the file data before changing attributes? When we're
> + * setting the immutable flag we must stop all directio writes and flush the
> + * dirty pages so that we can fail the page fault on the next write attempt.
> + */
> +static inline bool vfs_ioc_setflags_need_flush(struct inode *inode, int flags)
> +{
> + if (S_ISREG(inode->i_mode) && !IS_IMMUTABLE(inode) &&
> + (flags & FS_IMMUTABLE_FL))
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * Flush file data before changing attributes. Caller must hold any locks
> + * required to prevent further writes to this file until we're done setting
> + * flags.
> + */
> +static inline int inode_flush_data(struct inode *inode)
> +{
> + inode_dio_wait(inode);
> + return filemap_write_and_wait(inode->i_mapping);
> +}
> +
> +/* Flush file data before changing attributes, if necessary. */
> +static inline int vfs_ioc_setflags_flush_data(struct inode *inode, int flags)
> +{
> + if (vfs_ioc_setflags_need_flush(inode, flags))
> + return inode_flush_data(inode);
> + return 0;
> +}
> +
But this is racy at least for page faults, isn't it? What protects you
against write faults just after filemap_write_and_wait() has finished?
So either you need to set FS_IMMUTABLE_FL before flushing data or you need
to get more protection from the fs than just i_rwsem. In the case of ext4
that would be i_mmap_rwsem but other filesystems don't have equivalent
protection...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v7 20/21] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
From: Yong Wu @ 2019-06-20 14:00 UTC (permalink / raw)
To: Matthias Brugger
Cc: youlin.pei-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nicolas Boichat,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Evan Green, Tomasz Figa,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
anan.sun-NuS5LvNUpcJWk0Htik3J/w, Robin Murphy, Matthias Kaehlcke,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <db9b3b2f-3206-01bf-f0f9-67251e5ff756-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, 2019-06-18 at 18:35 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > In the 4GB mode, the physical address is remapped,
> >
> > Here is the detailed remap relationship.
> > CPU PA -> HW PA
> > 0x4000_0000 0x1_4000_0000 (Add bit32)
> > 0x8000_0000 0x1_8000_0000 ...
> > 0xc000_0000 0x1_c000_0000 ...
> > 0x1_0000_0000 0x1_0000_0000 (No change)
> >
> > Thus, we always add bit32 for PA when entering mtk_iommu_map.
> > But in the iova_to_phys, the CPU don't need this bit32 if the
> > PA is from 0x1_4000_0000 to 0x1_ffff_ffff.
> > This patch discards the bit32 in this iova_to_phys in the 4GB mode.
> >
> > Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> > for 4GB mode")
> > Signed-off-by: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/iommu/mtk_iommu.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 67cab2d..34f2e40 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -119,6 +119,19 @@ struct mtk_iommu_domain {
> >
> > static const struct iommu_ops mtk_iommu_ops;
> >
> > +/*
> > + * In M4U 4GB mode, the physical address is remapped as below:
> > + * CPU PA -> M4U HW PA
> > + * 0x4000_0000 0x1_4000_0000 (Add bit32)
> > + * 0x8000_0000 0x1_8000_0000 ...
> > + * 0xc000_0000 0x1_c000_0000 ...
> > + * 0x1_0000_0000 0x1_0000_0000 (No change)
> > + *
> > + * Thus, We always add BIT32 in the iommu_map and disable BIT32 if PA is >=
> > + * 0x1_4000_0000 in the iova_to_phys.
> > + */
> > +#define MTK_IOMMU_4GB_MODE_PA_140000000 0x140000000UL
> > +
> > static LIST_HEAD(m4ulist); /* List all the M4U HWs */
> >
> > #define for_each_m4u(data) list_for_each_entry(data, &m4ulist, list)
> > @@ -415,6 +428,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > dma_addr_t iova)
> > {
> > struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> > + struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
> > unsigned long flags;
> > phys_addr_t pa;
> >
> > @@ -422,6 +436,10 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
> > pa = dom->iop->iova_to_phys(dom->iop, iova);
> > spin_unlock_irqrestore(&dom->pgtlock, flags);
> >
> > + if (data->plat_data->has_4gb_mode && data->dram_is_4gb &&
> > + pa >= MTK_IOMMU_4GB_MODE_PA_140000000)
> > + pa &= ~BIT_ULL(32);
> > +
>
> Hm, I wonder if we could fix this as first patch in the series, especially before:
> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
OK.
>
> This would make it easier for the stable maintainer to cherry-pick the fix.
> Without 100% understanding the code, it seems suspicious to me, that you first
> move the setting of the bit32 and bit33 into v7s and later explicitly clean the
> bits here.
>
> So my take on this is, that patch 6/21 introduced the regression you are trying
> to fix here. As said that is speculation as I don't understand the code in its
> whole.
>
> Any clarification would be useful.
I guess the commit message in [06/21] will be helpful.
In the previous mt8173 and mt2712, the M4U HW support "4GB mode" in
which the range of dram is from 0x4000_0000 to 0x1_3fff_ffff and it was
remapped to 0x1_0000_0000 ~0x1_ffff_ffff(For readable, I have wrote the
re-map relationship into the code in this patch.). but mt8183 don't need
remap the dram address(0x4000_0000 ~ 0x3_ffff_ffff).
In order to unify the code, we add bit32 for "4GB mode". But actually
the PA doesn't always have bit32, thus, I have to remove bit32 when PA >
0x1_4000_0000.
So sorry that the "4GB mode" is a little unreadable and special, And the
4GB patch(30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode") has introduced several fix patches.
>
> Regards,
> Matthias
>
> > return pa;
> > }
> >
> >
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v7 19/21] iommu/mediatek: Rename enable_4GB to dram_is_4gb
From: Yong Wu @ 2019-06-20 13:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Joerg Roedel, Will Deacon, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, yingjoe.chen, anan.sun,
Robin Murphy, Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <9bf13c22-0c73-2950-2204-23d577976b03@gmail.com>
On Tue, 2019-06-18 at 18:06 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > This patch only rename the variable name from enable_4GB to
> > dram_is_4gb for readable.
>
> From my understanding this is true when available RAM > 4GB so I think the name
> should be something like dram_bigger_4gb otherwise it may create confusion again.
Strictly, It is not "dram_bigger_4gb". actually if the dram size is over
3GB (the first 1GB is the register space), the "4GB mode" will be
enabled. then how about the name "dram_enable_32bit"?(the PA 32bit will
be enabled in the 4GB mode.)
There is another option, please see the last part in [1] suggested by
Evan, something like below:
----
data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
if (!data->plat_data->has_4gb_mode)
data->enable_4GB = false;
Then mtk_iommu_map would only have:
if (data->enable_4GB)
paddr |= BIT_ULL(32);
----
Which one do you prefer?
[1] https://lore.kernel.org/patchwork/patch/1028421/
>
> Also from my point of view this patch should be done before
> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
OK.
>
> Regards,
> Matthias
>
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > Reviewed-by: Evan Green <evgreen@chromium.org>
> > ---
> > drivers/iommu/mtk_iommu.c | 10 +++++-----
> > drivers/iommu/mtk_iommu.h | 2 +-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 86158d8..67cab2d 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -382,7 +382,7 @@ static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
> > int ret;
> >
> > /* The "4GB mode" M4U physically can not use the lower remap of Dram. */
> > - if (data->plat_data->has_4gb_mode && data->enable_4GB)
> > + if (data->plat_data->has_4gb_mode && data->dram_is_4gb)
> > paddr |= BIT_ULL(32);
> >
> > spin_lock_irqsave(&dom->pgtlock, flags);
> > @@ -554,13 +554,13 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
> >
> > if (data->plat_data->m4u_plat == M4U_MT8173)
> > - regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> > + regval = (data->protect_base >> 1) | (data->dram_is_4gb << 31);
> > else
> > regval = lower_32_bits(data->protect_base) |
> > upper_32_bits(data->protect_base);
> > writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
> >
> > - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> > + if (data->dram_is_4gb && data->plat_data->has_vld_pa_rng) {
> > /*
> > * If 4GB mode is enabled, the validate PA range is from
> > * 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
> > @@ -611,8 +611,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> > return -ENOMEM;
> > data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
> >
> > - /* Whether the current dram is over 4GB */
> > - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> > + /* Whether the current dram is 4GB. */
> > + data->dram_is_4gb = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > data->base = devm_ioremap_resource(dev, res);
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 753266b..e8114b2 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -65,7 +65,7 @@ struct mtk_iommu_data {
> > struct mtk_iommu_domain *m4u_dom;
> > struct iommu_group *m4u_group;
> > struct mtk_smi_iommu smi_imu; /* SMI larb iommu info */
> > - bool enable_4GB;
> > + bool dram_is_4gb;
> > bool tlb_flush_active;
> >
> > struct iommu_device iommu;
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH 2/6] vfs: flush and wait for io when setting the immutable flag via SETFLAGS
From: Jan Kara @ 2019-06-20 14:00 UTC (permalink / raw)
To: Darrick J. Wong
Cc: linux-efi, linux-btrfs, linux-mm, clm, adilger.kernel,
matthew.garrett, linux-nilfs, linux-ext4, devel, josef,
reiserfs-devel, viro, dsterba, jaegeuk, tytso, ard.biesheuvel,
linux-kernel, linux-f2fs-devel, linux-xfs, jk, jack,
linux-fsdevel, linux-mtd, ocfs2-devel
In-Reply-To: <156022838496.3227213.3771632042609589318.stgit@magnolia>
On Mon 10-06-19 21:46:25, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> need to ensure that userspace can't continue to write the file after the
> file becomes immutable. To make that happen, we have to flush all the
> dirty pagecache pages to disk to ensure that we can fail a page fault on
> a mmap'd region, wait for pending directio to complete, and hope the
> caller locked out any new writes by holding the inode lock.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
...
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 6aa1df1918f7..a05341b94d98 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -290,6 +290,9 @@ static int ext4_ioctl_setflags(struct inode *inode,
> jflag = flags & EXT4_JOURNAL_DATA_FL;
>
> err = vfs_ioc_setflags_check(inode, oldflags, flags);
> + if (err)
> + goto flags_out;
> + err = vfs_ioc_setflags_flush_data(inode, flags);
> if (err)
> goto flags_out;
>
...
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8dad3c80b611..9c899c63957e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3548,7 +3548,41 @@ static inline struct sock *io_uring_get_socket(struct file *file)
>
> int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags);
>
> +/*
> + * Do we need to flush the file data before changing attributes? When we're
> + * setting the immutable flag we must stop all directio writes and flush the
> + * dirty pages so that we can fail the page fault on the next write attempt.
> + */
> +static inline bool vfs_ioc_setflags_need_flush(struct inode *inode, int flags)
> +{
> + if (S_ISREG(inode->i_mode) && !IS_IMMUTABLE(inode) &&
> + (flags & FS_IMMUTABLE_FL))
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * Flush file data before changing attributes. Caller must hold any locks
> + * required to prevent further writes to this file until we're done setting
> + * flags.
> + */
> +static inline int inode_flush_data(struct inode *inode)
> +{
> + inode_dio_wait(inode);
> + return filemap_write_and_wait(inode->i_mapping);
> +}
> +
> +/* Flush file data before changing attributes, if necessary. */
> +static inline int vfs_ioc_setflags_flush_data(struct inode *inode, int flags)
> +{
> + if (vfs_ioc_setflags_need_flush(inode, flags))
> + return inode_flush_data(inode);
> + return 0;
> +}
> +
But this is racy at least for page faults, isn't it? What protects you
against write faults just after filemap_write_and_wait() has finished?
So either you need to set FS_IMMUTABLE_FL before flushing data or you need
to get more protection from the fs than just i_rwsem. In the case of ext4
that would be i_mmap_rwsem but other filesystems don't have equivalent
protection...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [PATCH 2/6] vfs: flush and wait for io when setting the immutable flag via SETFLAGS
From: Jan Kara @ 2019-06-20 14:00 UTC (permalink / raw)
To: Darrick J. Wong
Cc: matthew.garrett, yuchao0, tytso, ard.biesheuvel, josef, clm,
adilger.kernel, viro, jack, dsterba, jaegeuk, jk, reiserfs-devel,
linux-efi, devel, linux-kernel, linux-f2fs-devel, linux-xfs,
linux-mm, linux-nilfs, linux-mtd, ocfs2-devel, linux-fsdevel,
linux-ext4, linux-btrfs
In-Reply-To: <156022838496.3227213.3771632042609589318.stgit@magnolia>
On Mon 10-06-19 21:46:25, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> need to ensure that userspace can't continue to write the file after the
> file becomes immutable. To make that happen, we have to flush all the
> dirty pagecache pages to disk to ensure that we can fail a page fault on
> a mmap'd region, wait for pending directio to complete, and hope the
> caller locked out any new writes by holding the inode lock.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
...
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 6aa1df1918f7..a05341b94d98 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -290,6 +290,9 @@ static int ext4_ioctl_setflags(struct inode *inode,
> jflag = flags & EXT4_JOURNAL_DATA_FL;
>
> err = vfs_ioc_setflags_check(inode, oldflags, flags);
> + if (err)
> + goto flags_out;
> + err = vfs_ioc_setflags_flush_data(inode, flags);
> if (err)
> goto flags_out;
>
...
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8dad3c80b611..9c899c63957e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3548,7 +3548,41 @@ static inline struct sock *io_uring_get_socket(struct file *file)
>
> int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags);
>
> +/*
> + * Do we need to flush the file data before changing attributes? When we're
> + * setting the immutable flag we must stop all directio writes and flush the
> + * dirty pages so that we can fail the page fault on the next write attempt.
> + */
> +static inline bool vfs_ioc_setflags_need_flush(struct inode *inode, int flags)
> +{
> + if (S_ISREG(inode->i_mode) && !IS_IMMUTABLE(inode) &&
> + (flags & FS_IMMUTABLE_FL))
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * Flush file data before changing attributes. Caller must hold any locks
> + * required to prevent further writes to this file until we're done setting
> + * flags.
> + */
> +static inline int inode_flush_data(struct inode *inode)
> +{
> + inode_dio_wait(inode);
> + return filemap_write_and_wait(inode->i_mapping);
> +}
> +
> +/* Flush file data before changing attributes, if necessary. */
> +static inline int vfs_ioc_setflags_flush_data(struct inode *inode, int flags)
> +{
> + if (vfs_ioc_setflags_need_flush(inode, flags))
> + return inode_flush_data(inode);
> + return 0;
> +}
> +
But this is racy at least for page faults, isn't it? What protects you
against write faults just after filemap_write_and_wait() has finished?
So either you need to set FS_IMMUTABLE_FL before flushing data or you need
to get more protection from the fs than just i_rwsem. In the case of ext4
that would be i_mmap_rwsem but other filesystems don't have equivalent
protection...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [Ocfs2-devel] [PATCH 2/6] vfs: flush and wait for io when setting the immutable flag via SETFLAGS
From: Jan Kara @ 2019-06-20 14:00 UTC (permalink / raw)
To: Darrick J. Wong
Cc: matthew.garrett, yuchao0, tytso, ard.biesheuvel, josef, clm,
adilger.kernel, viro, jack, dsterba, jaegeuk, jk, reiserfs-devel,
linux-efi, devel, linux-kernel, linux-f2fs-devel, linux-xfs,
linux-mm, linux-nilfs, linux-mtd, ocfs2-devel, linux-fsdevel,
linux-ext4, linux-btrfs
In-Reply-To: <156022838496.3227213.3771632042609589318.stgit@magnolia>
On Mon 10-06-19 21:46:25, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> need to ensure that userspace can't continue to write the file after the
> file becomes immutable. To make that happen, we have to flush all the
> dirty pagecache pages to disk to ensure that we can fail a page fault on
> a mmap'd region, wait for pending directio to complete, and hope the
> caller locked out any new writes by holding the inode lock.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
...
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 6aa1df1918f7..a05341b94d98 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -290,6 +290,9 @@ static int ext4_ioctl_setflags(struct inode *inode,
> jflag = flags & EXT4_JOURNAL_DATA_FL;
>
> err = vfs_ioc_setflags_check(inode, oldflags, flags);
> + if (err)
> + goto flags_out;
> + err = vfs_ioc_setflags_flush_data(inode, flags);
> if (err)
> goto flags_out;
>
...
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8dad3c80b611..9c899c63957e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3548,7 +3548,41 @@ static inline struct sock *io_uring_get_socket(struct file *file)
>
> int vfs_ioc_setflags_check(struct inode *inode, int oldflags, int flags);
>
> +/*
> + * Do we need to flush the file data before changing attributes? When we're
> + * setting the immutable flag we must stop all directio writes and flush the
> + * dirty pages so that we can fail the page fault on the next write attempt.
> + */
> +static inline bool vfs_ioc_setflags_need_flush(struct inode *inode, int flags)
> +{
> + if (S_ISREG(inode->i_mode) && !IS_IMMUTABLE(inode) &&
> + (flags & FS_IMMUTABLE_FL))
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * Flush file data before changing attributes. Caller must hold any locks
> + * required to prevent further writes to this file until we're done setting
> + * flags.
> + */
> +static inline int inode_flush_data(struct inode *inode)
> +{
> + inode_dio_wait(inode);
> + return filemap_write_and_wait(inode->i_mapping);
> +}
> +
> +/* Flush file data before changing attributes, if necessary. */
> +static inline int vfs_ioc_setflags_flush_data(struct inode *inode, int flags)
> +{
> + if (vfs_ioc_setflags_need_flush(inode, flags))
> + return inode_flush_data(inode);
> + return 0;
> +}
> +
But this is racy at least for page faults, isn't it? What protects you
against write faults just after filemap_write_and_wait() has finished?
So either you need to set FS_IMMUTABLE_FL before flushing data or you need
to get more protection from the fs than just i_rwsem. In the case of ext4
that would be i_mmap_rwsem but other filesystems don't have equivalent
protection...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [Xen-devel] [freebsd-master test] 138015: all pass - PUSHED
From: osstest service owner @ 2019-06-20 13:59 UTC (permalink / raw)
To: xen-devel, osstest-admin, royger
flight 138015 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138015/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 4cc7ca905d882bd40d71348235decd5c1ce32626
baseline version:
freebsd d946d8f14c81df5c94524f0c759db84880bbcae8
Last test of basis 137901 2019-06-17 09:19:34 Z 3 days
Testing same since 138015 2019-06-19 09:22:06 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
alc <alc@FreeBSD.org>
bdrewery <bdrewery@FreeBSD.org>
cem <cem@FreeBSD.org>
cy <cy@FreeBSD.org>
delphij <delphij@FreeBSD.org>
emaste <emaste@FreeBSD.org>
gjb <gjb@FreeBSD.org>
ian <ian@FreeBSD.org>
markj <markj@FreeBSD.org>
mav <mav@FreeBSD.org>
mm <mm@FreeBSD.org>
scottl <scottl@FreeBSD.org>
sevan <sevan@FreeBSD.org>
takawata <takawata@FreeBSD.org>
vmaffione <vmaffione@FreeBSD.org>
zec <zec@FreeBSD.org>
zeising <zeising@FreeBSD.org>
jobs:
build-amd64-freebsd-again pass
build-amd64-freebsd pass
build-amd64-xen-freebsd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
To xenbits.xen.org:/home/xen/git/freebsd.git
d946d8f14c8..4cc7ca905d8 4cc7ca905d882bd40d71348235decd5c1ce32626 -> tested/master
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qmp: make qmp-shell work with python3
From: Eduardo Habkost @ 2019-06-20 13:45 UTC (permalink / raw)
To: Igor Mammedov; +Cc: qemu-devel, armbru, Cleber Rosa
In-Reply-To: <20190620111103.297277bc@redhat.com>
On Thu, Jun 20, 2019 at 11:11:03AM +0200, Igor Mammedov wrote:
> On Wed, 19 Jun 2019 09:29:24 -0400
> Cleber Rosa <crosa@redhat.com> wrote:
>
> > On Tue, Jun 18, 2019 at 10:29:31AM -0400, Igor Mammedov wrote:
> > > python3 doesn't have raw_input(), so qmp-shell breaks.
> > > Use input() instead and override it with raw_input()
> > > if running on python2.
> > >
> > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > ---
> > > scripts/qmp/qmp-shell | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
> > > index 7776c7b141..8c49b39afa 100755
> > > --- a/scripts/qmp/qmp-shell
> > > +++ b/scripts/qmp/qmp-shell
> > > @@ -308,7 +308,11 @@ class QMPShell(qmp.QEMUMonitorProtocol):
> > > @return True if execution was ok, return False if disconnected.
> > > """
> > > try:
> > > - cmdline = raw_input(prompt)
> > > + try: # attempt to set Python2 override
> > > + import __builtin__;
> > > + getattr(__builtin__, 'raw_input', input)
> > > + except ModuleNotFoundError: pass
> >
> > Something like:
> >
> > if sys.version_info[0] == 2:
> > input = raw_input
> >
> > Also does the job, and may be considered simpler and easier to read.
>
> that causes scope issues on python3
Which issues? It should work if you set it at the module top
level. We had done this before in other scripts. e.g.:
$ git grep -1 'range = xrange'
tests/qemu-iotests/044-if sys.version_info.major == 2:
tests/qemu-iotests/044: range = xrange
tests/qemu-iotests/044-
--
tests/qemu-iotests/163-if sys.version_info.major == 2:
tests/qemu-iotests/163: range = xrange
tests/qemu-iotests/163-
--
Eduardo
^ permalink raw reply
* Re: [PATCH v7 19/21] iommu/mediatek: Rename enable_4GB to dram_is_4gb
From: Yong Wu @ 2019-06-20 13:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: Joerg Roedel, Robin Murphy, Rob Herring, Evan Green, Tomasz Figa,
Will Deacon, linux-mediatek, srv_heupstream, devicetree,
linux-kernel, linux-arm-kernel, iommu, yingjoe.chen, youlin.pei,
Nicolas Boichat, anan.sun, Matthias Kaehlcke
In-Reply-To: <9bf13c22-0c73-2950-2204-23d577976b03@gmail.com>
On Tue, 2019-06-18 at 18:06 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > This patch only rename the variable name from enable_4GB to
> > dram_is_4gb for readable.
>
> From my understanding this is true when available RAM > 4GB so I think the name
> should be something like dram_bigger_4gb otherwise it may create confusion again.
Strictly, It is not "dram_bigger_4gb". actually if the dram size is over
3GB (the first 1GB is the register space), the "4GB mode" will be
enabled. then how about the name "dram_enable_32bit"?(the PA 32bit will
be enabled in the 4GB mode.)
There is another option, please see the last part in [1] suggested by
Evan, something like below:
----
data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
if (!data->plat_data->has_4gb_mode)
data->enable_4GB = false;
Then mtk_iommu_map would only have:
if (data->enable_4GB)
paddr |= BIT_ULL(32);
----
Which one do you prefer?
[1] https://lore.kernel.org/patchwork/patch/1028421/
>
> Also from my point of view this patch should be done before
> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
OK.
>
> Regards,
> Matthias
>
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > Reviewed-by: Evan Green <evgreen@chromium.org>
> > ---
> > drivers/iommu/mtk_iommu.c | 10 +++++-----
> > drivers/iommu/mtk_iommu.h | 2 +-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 86158d8..67cab2d 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -382,7 +382,7 @@ static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
> > int ret;
> >
> > /* The "4GB mode" M4U physically can not use the lower remap of Dram. */
> > - if (data->plat_data->has_4gb_mode && data->enable_4GB)
> > + if (data->plat_data->has_4gb_mode && data->dram_is_4gb)
> > paddr |= BIT_ULL(32);
> >
> > spin_lock_irqsave(&dom->pgtlock, flags);
> > @@ -554,13 +554,13 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
> >
> > if (data->plat_data->m4u_plat == M4U_MT8173)
> > - regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> > + regval = (data->protect_base >> 1) | (data->dram_is_4gb << 31);
> > else
> > regval = lower_32_bits(data->protect_base) |
> > upper_32_bits(data->protect_base);
> > writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
> >
> > - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> > + if (data->dram_is_4gb && data->plat_data->has_vld_pa_rng) {
> > /*
> > * If 4GB mode is enabled, the validate PA range is from
> > * 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
> > @@ -611,8 +611,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> > return -ENOMEM;
> > data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
> >
> > - /* Whether the current dram is over 4GB */
> > - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> > + /* Whether the current dram is 4GB. */
> > + data->dram_is_4gb = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > data->base = devm_ioremap_resource(dev, res);
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 753266b..e8114b2 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -65,7 +65,7 @@ struct mtk_iommu_data {
> > struct mtk_iommu_domain *m4u_dom;
> > struct iommu_group *m4u_group;
> > struct mtk_smi_iommu smi_imu; /* SMI larb iommu info */
> > - bool enable_4GB;
> > + bool dram_is_4gb;
> > bool tlb_flush_active;
> >
> > struct iommu_device iommu;
> >
^ permalink raw reply
* Re: [PATCH v7 19/21] iommu/mediatek: Rename enable_4GB to dram_is_4gb
From: Yong Wu @ 2019-06-20 13:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, linux-kernel, Evan Green, Tomasz Figa, iommu,
Rob Herring, linux-mediatek, yingjoe.chen, anan.sun, Robin Murphy,
Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <9bf13c22-0c73-2950-2204-23d577976b03@gmail.com>
On Tue, 2019-06-18 at 18:06 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > This patch only rename the variable name from enable_4GB to
> > dram_is_4gb for readable.
>
> From my understanding this is true when available RAM > 4GB so I think the name
> should be something like dram_bigger_4gb otherwise it may create confusion again.
Strictly, It is not "dram_bigger_4gb". actually if the dram size is over
3GB (the first 1GB is the register space), the "4GB mode" will be
enabled. then how about the name "dram_enable_32bit"?(the PA 32bit will
be enabled in the 4GB mode.)
There is another option, please see the last part in [1] suggested by
Evan, something like below:
----
data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
if (!data->plat_data->has_4gb_mode)
data->enable_4GB = false;
Then mtk_iommu_map would only have:
if (data->enable_4GB)
paddr |= BIT_ULL(32);
----
Which one do you prefer?
[1] https://lore.kernel.org/patchwork/patch/1028421/
>
> Also from my point of view this patch should be done before
> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
OK.
>
> Regards,
> Matthias
>
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > Reviewed-by: Evan Green <evgreen@chromium.org>
> > ---
> > drivers/iommu/mtk_iommu.c | 10 +++++-----
> > drivers/iommu/mtk_iommu.h | 2 +-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 86158d8..67cab2d 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -382,7 +382,7 @@ static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
> > int ret;
> >
> > /* The "4GB mode" M4U physically can not use the lower remap of Dram. */
> > - if (data->plat_data->has_4gb_mode && data->enable_4GB)
> > + if (data->plat_data->has_4gb_mode && data->dram_is_4gb)
> > paddr |= BIT_ULL(32);
> >
> > spin_lock_irqsave(&dom->pgtlock, flags);
> > @@ -554,13 +554,13 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
> >
> > if (data->plat_data->m4u_plat == M4U_MT8173)
> > - regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> > + regval = (data->protect_base >> 1) | (data->dram_is_4gb << 31);
> > else
> > regval = lower_32_bits(data->protect_base) |
> > upper_32_bits(data->protect_base);
> > writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
> >
> > - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> > + if (data->dram_is_4gb && data->plat_data->has_vld_pa_rng) {
> > /*
> > * If 4GB mode is enabled, the validate PA range is from
> > * 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
> > @@ -611,8 +611,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> > return -ENOMEM;
> > data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
> >
> > - /* Whether the current dram is over 4GB */
> > - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> > + /* Whether the current dram is 4GB. */
> > + data->dram_is_4gb = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > data->base = devm_ioremap_resource(dev, res);
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 753266b..e8114b2 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -65,7 +65,7 @@ struct mtk_iommu_data {
> > struct mtk_iommu_domain *m4u_dom;
> > struct iommu_group *m4u_group;
> > struct mtk_smi_iommu smi_imu; /* SMI larb iommu info */
> > - bool enable_4GB;
> > + bool dram_is_4gb;
> > bool tlb_flush_active;
> >
> > struct iommu_device iommu;
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.