On Tue, Sep 24, 2019 at 10:01:41PM +0200, Jann Horn wrote:
> On Tue, Sep 24, 2019 at 9:35 PM Omar Sandoval wrote:
> > On Tue, Sep 24, 2019 at 10:15:13AM -0700, Omar Sandoval wrote:
> > > On Thu, Sep 19, 2019 at 05:44:12PM +0200, Jann Horn wrote:
> > > > On Thu, Sep 19, 2019 at 8:54 AM Omar Sandova
On Tue, Mar 16, 2021 at 12:42:57PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This is essentially copy_struct_from_user() but for an iov_iter.
>
> Suggested-by: Aleksa Sarai
> Reviewed-by: Josef Bacik
> Signed-off-by: Omar Sandoval
> ---
> include/linux/uio.h | 2 ++
> lib/iov_it
On Fri, Mar 19, 2021 at 01:27:25PM -0700, Omar Sandoval wrote:
> On Fri, Mar 19, 2021 at 01:08:05PM -0700, Linus Torvalds wrote:
> > On Fri, Mar 19, 2021 at 11:21 AM Josef Bacik wrote:
> > >
> > > Can we get some movement on this? Omar is sort of spinning his wheels
> > > here
> > > trying to ge
On Wed, Mar 17, 2021 at 11:45:02AM -0700, Omar Sandoval wrote:
> On Wed, Mar 17, 2021 at 06:56:11PM +0100, Christian Brauner wrote:
> > On Tue, Mar 16, 2021 at 12:42:57PM -0700, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > This is essentiall
On Fri, Apr 02, 2021 at 12:33:20AM -0700, Omar Sandoval wrote:
> On Thu, Apr 01, 2021 at 09:05:22AM -0700, Linus Torvalds wrote:
> > On Wed, Mar 31, 2021 at 11:51 PM Omar Sandoval wrote:
> > >
> > > + *
> > > + * The recommended usage is something like the following:
> > > + *
> > > + * if (us
> if the
> kernel silently tries to accept and fixup the breakage, it is nice in the
> short term (no complaining users) but it tends to get ugly in the long term
> (where tend people come up with nasty cases where it was wrong to fix it
> up).
Yeah, very much agree. It works for simple APIs somet
On Tue, Jul 02, 2024 at 08:21:42AM GMT, Jeff Layton wrote:
> On Tue, 2024-07-02 at 05:15 -0700, Christoph Hellwig wrote:
> > On Tue, Jul 02, 2024 at 08:09:46AM -0400, Jeff Layton wrote:
> > > > > corrupt timestamps like this?
> > > >
> > > > inode_set_ctime_to_ts should return an error if things a
On Mon, Jul 15, 2024 at 08:48:51AM GMT, Jeff Layton wrote:
> I think this is pretty much ready for linux-next now. Since the latest
> changes are pretty minimal, I've left the Reviewed-by's intact. It would
> be nice to have acks or reviews from maintainers for ext4 and tmpfs too.
>
> I did try to
On Tue, Jul 16, 2024 at 08:45:16AM GMT, Jeff Layton wrote:
> On Tue, 2024-07-16 at 09:37 +0200, Christian Brauner wrote:
> > On Mon, Jul 15, 2024 at 08:48:51AM GMT, Jeff Layton wrote:
> > > I think this is pretty much ready for linux-next now. Since the latest
> > >
they will lack is a nice error message.
Signed-off-by: Christian Brauner
---
cmds-receive.c | 13 +
send-stream.c | 2 +-
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/cmds-receive.c b/cmds-receive.c
index 6cf22637..b59f00e4 100644
--- a/cmds-receive.c
+++ b/cmds
Hi guys,
Friendly ping. Just checking in on this patch since I haven't heard back so far
and this is a blocker in some scenarios where we're using btrfs.
Thanks!
Christian
On Fri, Mar 24, 2017 at 04:00:57PM +0100, Christian Brauner wrote:
> The old check here tried to ensure that
thing that they will lack is a nice error message.
Christian Brauner (2):
btrfs-progs: fix btrfs send & receive with -e flag
tests: use receive -e to terminate on end marker
cmds-receive.c | 13 +
send-stream.c
Signed-off-by: Christian Brauner
---
tests/misc-tests/018-recv-end-of-stream/test.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/misc-tests/018-recv-end-of-stream/test.sh
b/tests/misc-tests/018-recv-end-of-stream/test.sh
index d39683e9..90655929 100755
they will lack is a nice error message.
Signed-off-by: Christian Brauner
---
Changelog: 2017-04-03
- no changes
---
cmds-receive.c | 13 +
send-stream.c | 2 +-
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/cmds-receive.c b/cmds-receive.c
index 6cf22637
Hi guys,
If a qgroup is created for a btrfs subvolume /some/path and limits are set and
a new btrfs subvolume /some/path/bla is created it does not inherit the parent
subvolume's /some/path qgroup and limits. The only way to achieve something
similar is to create a common "parent" qgroup and assig
-ENODATA is returned with this patch it should mean that there
was no header data. So is the user sure that this doesn't indicate a valid
error?
Christian
>
>
> Cheers,
> Lakshmipathi.G
>
>
> On Tue, Apr 4, 2017 at 1:51 AM, Christian Brauner <
> christian.brau..
Christian Brauner (1):
btrfs-progs: send: fail on first -ENODATA only
cmds-receive.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
Returning -ENODATA is only considered invalid on the first run of the loop.
Signed-off-by: Christian Brauner
---
cmds-receive.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/cmds-receive.c b/cmds-receive.c
index b59f00e4..72e9c8f3 100644
--- a/cmds
Hi,
The original bug-reporter verified that my patch fixes the bug. See
https://bugzilla.kernel.org/show_bug.cgi?id=195597
Christian
On Sat, Apr 29, 2017 at 11:54:05PM +0200, Christian Brauner wrote:
> Returning -ENODATA is only considered invalid on the first run of the loop.
>
> S
Hi guys,
It seems that btrfs v4.12.1 allows:
(1) btrfs send -p
but disallows
(2) btrfs send -p
Code-wise it assumes that is always found at optind == 1. I was
about to patch this but I'm not sure which way we'd like to go with this:
Actually only allow (1) and block (2) p
20 matches
Mail list logo
