Hi all,
Today's linux-next merge of the block tree got a conflict in:
fs/open.c
between commit:
0a51692d49ec ("open: introduce openat2(2) syscall")
from the vfs tree and commit:
252270311374 ("fs: make build_open_flags() available internally")
from the block tree.
I fixed it up (see at end, plus the merge fix patch below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
From: Stephen Rothwell <[email protected]>
Date: Fri, 20 Dec 2019 11:50:51 +1100
Subject: [PATCH] io_uring: fix up for "open: introduce openat2(2) syscall"
Signed-off-by: Stephen Rothwell <[email protected]>
---
fs/internal.h | 3 ++-
fs/io_uring.c | 6 ++++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/internal.h b/fs/internal.h
index 166134be439f..dabf747c14fd 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -124,7 +124,8 @@ extern struct file *do_filp_open(int dfd, struct filename *pathname,
const struct open_flags *op);
extern struct file *do_file_open_root(struct dentry *, struct vfsmount *,
const char *, const struct open_flags *);
-extern int build_open_flags(int flags, umode_t mode, struct open_flags *op);
+extern struct open_how build_open_how(int flags, umode_t mode);
+extern int build_open_flags(const struct open_how *how, struct open_flags *op);
long do_sys_ftruncate(unsigned int fd, loff_t length, int small);
long do_faccessat(int dfd, const char __user *filename, int mode);
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 26edb980df02..c756b8fc44c6 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2337,19 +2337,21 @@ static int io_openat(struct io_kiocb *req, struct io_kiocb **nxt,
bool force_nonblock)
{
struct open_flags op;
+ struct open_how how;
struct file *file;
int ret;
ret = io_openat_prep(req);
if (ret)
goto err;
- ret = build_open_flags(req->open.flags, req->open.mode, &op);
+ how = build_open_how(req->open.flags, req->open.mode);
+ ret = build_open_flags(&how, &op);
if (ret)
goto err;
if (force_nonblock)
op.lookup_flags |= LOOKUP_NONBLOCK;
- ret = get_unused_fd_flags(req->open.flags);
+ ret = get_unused_fd_flags(how.flags);
if (ret < 0)
goto err;
--
2.24.0
--
Cheers,
Stephen Rothwell
diff --cc fs/open.c
index 50a46501bcc9,24cb5d58bbda..000000000000
--- a/fs/open.c
+++ b/fs/open.c
@@@ -955,29 -955,8 +955,29 @@@ struct file *open_with_fake_path(const
}
EXPORT_SYMBOL(open_with_fake_path);
-inline int build_open_flags(int flags, umode_t mode, struct open_flags *op)
+#define WILL_CREATE(flags) (flags & (O_CREAT | __O_TMPFILE))
+#define O_PATH_FLAGS (O_DIRECTORY | O_NOFOLLOW | O_PATH | O_CLOEXEC)
+
- static inline struct open_how build_open_how(int flags, umode_t mode)
++inline struct open_how build_open_how(int flags, umode_t mode)
+{
+ struct open_how how = {
+ .flags = flags & VALID_OPEN_FLAGS,
+ .mode = mode & S_IALLUGO,
+ };
+
+ /* O_PATH beats everything else. */
+ if (how.flags & O_PATH)
+ how.flags &= O_PATH_FLAGS;
+ /* Modes should only be set for create-like flags. */
+ if (!WILL_CREATE(how.flags))
+ how.mode = 0;
+ return how;
+}
+
- static inline int build_open_flags(const struct open_how *how,
++inline int build_open_flags(const struct open_how *how,
+ struct open_flags *op)
{
+ int flags = how->flags;
int lookup_flags = 0;
int acc_mode = ACC_MODE(flags);
On 12/19/19 6:36 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the block tree got a conflict in:
>
> fs/open.c
>
> between commit:
>
> 0a51692d49ec ("open: introduce openat2(2) syscall")
>
> from the vfs tree and commit:
>
> 252270311374 ("fs: make build_open_flags() available internally")
>
> from the block tree.
>
> I fixed it up (see at end, plus the merge fix patch below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.
--
Jens Axboe
Hi Jens,
On Thu, 19 Dec 2019 22:34:59 -0700 Jens Axboe <[email protected]> wrote:
>
> On 12/19/19 6:36 PM, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the block tree got a conflict in:
> >
> > fs/open.c
> >
> > between commit:
> >
> > 0a51692d49ec ("open: introduce openat2(2) syscall")
> >
> > from the vfs tree and commit:
> >
> > 252270311374 ("fs: make build_open_flags() available internally")
> >
> > from the block tree.
> >
> > I fixed it up (see at end, plus the merge fix patch below) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the
> > conflicting tree to minimise any particularly complex conflicts.
>
> Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.
I looks like Al has rewritten the branch you merged from his tree and
caused various conflicts in my merge of the block tree today. I used
Al's new versions of the conflicting files.
--
Cheers,
Stephen Rothwell
On 1/19/20 6:40 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> On Thu, 19 Dec 2019 22:34:59 -0700 Jens Axboe <[email protected]> wrote:
>>
>> On 12/19/19 6:36 PM, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the block tree got a conflict in:
>>>
>>> fs/open.c
>>>
>>> between commit:
>>>
>>> 0a51692d49ec ("open: introduce openat2(2) syscall")
>>>
>>> from the vfs tree and commit:
>>>
>>> 252270311374 ("fs: make build_open_flags() available internally")
>>>
>>> from the block tree.
>>>
>>> I fixed it up (see at end, plus the merge fix patch below) and can
>>> carry the fix as necessary. This is now fixed as far as linux-next is
>>> concerned, but any non trivial conflicts should be mentioned to your
>>> upstream maintainer when your tree is submitted for merging. You may
>>> also want to consider cooperating with the maintainer of the
>>> conflicting tree to minimise any particularly complex conflicts.
>>
>> Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.
>
> I looks like Al has rewritten the branch you merged from his tree and
> caused various conflicts in my merge of the block tree today. I used
> Al's new versions of the conflicting files.
That's a bummer. I guess I'll have to rebase on top of the new one. Al,
is the new one going to be persistent?
--
Jens Axboe
On 1/19/20 7:45 PM, Jens Axboe wrote:
> On 1/19/20 6:40 PM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> On Thu, 19 Dec 2019 22:34:59 -0700 Jens Axboe <[email protected]> wrote:
>>>
>>> On 12/19/19 6:36 PM, Stephen Rothwell wrote:
>>>>
>>>> Today's linux-next merge of the block tree got a conflict in:
>>>>
>>>> fs/open.c
>>>>
>>>> between commit:
>>>>
>>>> 0a51692d49ec ("open: introduce openat2(2) syscall")
>>>>
>>>> from the vfs tree and commit:
>>>>
>>>> 252270311374 ("fs: make build_open_flags() available internally")
>>>>
>>>> from the block tree.
>>>>
>>>> I fixed it up (see at end, plus the merge fix patch below) and can
>>>> carry the fix as necessary. This is now fixed as far as linux-next is
>>>> concerned, but any non trivial conflicts should be mentioned to your
>>>> upstream maintainer when your tree is submitted for merging. You may
>>>> also want to consider cooperating with the maintainer of the
>>>> conflicting tree to minimise any particularly complex conflicts.
>>>
>>> Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.
>>
>> I looks like Al has rewritten the branch you merged from his tree and
>> caused various conflicts in my merge of the block tree today. I used
>> Al's new versions of the conflicting files.
>
> That's a bummer. I guess I'll have to rebase on top of the new one. Al,
> is the new one going to be persistent?
Stephen, I rebased and pushed it out, verified that the io_uring bits
are identical to before. So at least this should be painless for you on
next pull.
--
Jens Axboe