On Wed, 2021-03-03 at 08:45 +, ruansy.f...@fujitsu.com wrote:
> I have re-sent two new patches to fix this(PATCH 08/10)
> and the previous(PATCH 07/10) which are in-reply-to these two patch, please
> take a look on those two. Maybe I should resend all of the patchset as a
> new one...
That's
On Fri, 2021-02-26 at 08:20 +0800, Shiyang Ruan wrote:
> With dax we cannot deal with readpage() etc. So, we create a dax
> comparison funciton which is similar with
> vfs_dedupe_file_range_compare().
> And introduce dax_remap_file_range_prep() for filesystem use.
[]
> diff --git a/fs/dax.c b/fs/da
On Fri, 2019-05-31 at 23:31 +0300, Andrey Abramov wrote:
> 31.05.2019, 23:05, "Joe Perches" :
> > On Fri, 2019-05-31 at 22:53 +0300, Andrey Abramov wrote:
> > > Fix -Wunused-but-set-variable warnings in raid56.c and sysfs.c files
> > These uses seem boolean, so p
On Fri, 2019-05-31 at 22:53 +0300, Andrey Abramov wrote:
> Fix -Wunused-but-set-variable warnings in raid56.c and sysfs.c files
trivia:
> diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
> index f3d0576dd327..4ab29eacfdf3 100644
> --- a/fs/btrfs/raid56.c
> +++ b/fs/btrfs/raid56.c
> @@ -1182,22
On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote:
> - There's no warning for the first paragraph of section 6:
>
> 6) Functions
>
>
> Functions should be short and sweet, and do just one thing. They should
> fit on one or two screenfuls of text (the ISO/ANSI screen size is 8
On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote:
> On Mon, Dec 11, 2017 at 02:12:28PM -0800, Joe Perches wrote:
> > Completely reasonable. Thanks.
>
> If we're doing "completely reasonable" complaints, then ...
>
> - I don't understand why pl
On Tue, 2017-12-12 at 08:43 +1100, Dave Chinner wrote:
> On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> > On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > > 1. Using lockdep_set_novalidate_class() for anything other
> > > than device-&
On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> 1. Using lockdep_set_novalidate_class() for anything other
> than device->mutex will throw checkpatch warnings. Nice. (*)
[]
> (*) checkpatch.pl is considered mostly harmful round here, too,
> but that's another rant
How so?
On Wed, 2017-09-13 at 13:02 +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais
I think the changelog for this series of conversions
should show that you've validated the change by
inspecting the return call chain at each modified line.
Also, it seems you've cc'd the same mailing lists for
all
On Mon, 2016-02-22 at 01:31 +0100, Philippe Loctaux wrote:
> Hi,
> I'm really sorry, but I don't understand what you're trying to mean.
> Could you simplify your sentence please (since I'm not english
> native)?
> I'd really apreciate that, thanks :)
Please do not put your reply at the top of the
On Mon, 2016-02-22 at 00:26 +0100, Philippe Loctaux wrote:
> Added line after variable declaration, fixing checkpatch warning.
[]
> diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
[]
> @@ -522,6 +522,7 @@ static noinline int add_ra_bio_pages(struct inode *inode,
>
>
On Mon, 2016-02-22 at 01:01 +0100, Philippe Loctaux wrote:
> Is there no need of additional blank line here particulary
> or in all lines that I changed?
Please don't top post and just here.
> On Sun, Feb 21, 2016 at 03:53:04PM -0800, Joe Perches wrote:
> > On Mon, 2016-
On Mon, 2016-02-22 at 00:46 +0100, Philippe Loctaux wrote:
> Added lines after variable declarations, fixing 22 checkpatch warnings.
[]
> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
[]
> @@ -4592,6 +4610,7 @@ void btrfs_truncate_item(struct btrfs_root *root,
> struct btrfs_path *path,
>
On Sat, 2016-02-20 at 18:57 -0600, Simon Quigley wrote:
> Better?
No, not really.
The alignment should be to the open parenthesis
as I wrote in the first reply.
> On 02/20/2016 06:56 PM, Simon Quigley wrote:
> > checkpatch.pl reported a warning of over 80 characters on line 1833
> >
> > Adjuste
On Sat, 2016-02-20 at 12:17 -0600, Simon Quigley wrote:
> checkpatch.pl reported a warning of over 80 characters on line 1833
[]
> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
[]
> @@ -1830,7 +1830,11 @@ static int iterate_inode_extrefs(u64 inum, struct
> btrfs_root *fs_root,
> unsig
On Sat, 2014-11-08 at 00:46 -0800, Omar Sandoval wrote:
> The RCU-friendly string API used internally by BTRFS is generic enough for
> common use. This doesn't add any new functionality, but instead just moves the
> code and documents the existing API.
Some more trivia, can be updated later if des
On Fri, 2014-11-07 at 15:21 -0500, Chris Mason wrote:
>
> On Fri, Nov 7, 2014 at 3:17 PM, Omar Sandoval
> wrote:
> > The RCU-friendly string API used internally by BTRFS is generic
> > enough for
> > common use. This doesn't add any new functionality, but instead just
> > moves the
> > code an
On Fri, 2014-09-26 at 22:36 -0700, Omar Sandoval wrote:
> printk returns an integer; there's no reason for printk_ratelimited to swallow
> it.
>
> Signed-off-by: Omar Sandoval
> Acked-by: Paul E. McKenney
> ---
I'd prefer to keep it the way it is actually.
I've submitted several patches to con
On Sun, 2014-09-21 at 06:25 -0700, Paul E. McKenney wrote:
> On Fri, Sep 19, 2014 at 11:15:53AM -0700, Joe Perches wrote:
> > On Fri, 2014-09-19 at 13:21 -0400, Steven Rostedt wrote:
> > > On Fri, 19 Sep 2014 02:01:29 -0700
> > > Omar Sandoval wrote:
> > >
On Fri, 2014-09-19 at 13:21 -0400, Steven Rostedt wrote:
> On Fri, 19 Sep 2014 02:01:29 -0700
> Omar Sandoval wrote:
>
> > printk returns an integer; there's no reason for printk_ratelimited to
> > swallow
> > it.
Except for the lack of usefulness of the return value itself.
See: https://lkml.o
On Wed, 2013-08-14 at 10:56 +0200, Geert Uytterhoeven wrote:
> These bring in the 64-bit divisor from somewhere else, so they're less
> trivial to fix.
Using div64_u64 or div64_s64 could fix it.
Maybe that could be added to do_div too.
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, 2013-07-30 at 16:40 -0400, Josef Bacik wrote:
> So stripe_len shouldn't be 0, if it is you have bigger problems :). Is this a
> corrupt fs or something? If there was some sort of corruption that occured
> then
> I suppose stripe_len could be 0 and we'd need to catch that somewhere higher
On Tue, 2013-07-30 at 13:13 -0400, Josef Bacik wrote:
> I've looked at all the places we do divides in this function and it
> doesn't look like we're doing this anywhere but I could be blind,
do_div seems a likely suspect...
/*
* stripe_nr counts the total number of stripes we ha
On Wed, 2013-06-19 at 12:15 -0700, Joe Perches wrote:
> Don't emit OOM warnings when k.alloc calls fail when
> there there is a v.alloc immediately afterwards.
>
> Converted a kmalloc/vmalloc with memset to kzalloc/vzalloc.
Hey Jiri.
What's your schedule for accepting or
Don't emit OOM warnings when k.alloc calls fail when
there there is a v.alloc immediately afterwards.
Converted a kmalloc/vmalloc with memset to kzalloc/vzalloc.
Signed-off-by: Joe Perches
---
drivers/block/drbd/drbd_bitmap.c | 2 +-
drivers/infiniband/hw/ehca/ipz_pt
vprintk_emit prefix parsing should only be done for internal
kernel messages. This allows existing behavior to be kept
in all cases.
Signed-off-by: Joe Perches
---
kernel/printk.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/kernel
On Wed, 2012-06-06 at 03:10 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 2:46 AM, Andrew Morton
> wrote:
> > On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches wrote:
> >
> >> On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote:
> >> > On Tue, 05 Jun
On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote:
> On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches wrote:
>
> > On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
> > > echo "\0014Hello Joe" > /dev/kmsg
> >
> > # echo -e "\x014Hel
On Wed, 2012-06-06 at 02:28 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 2:19 AM, Joe Perches wrote:
> > On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote:
> >> The question is what happens if you inject your new binary two-byte
> >> prefix, like:
> >&
On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote:
> The question is what happens if you inject your new binary two-byte
> prefix, like:
> echo -e "\x01\x02Hello" > /dev/kmsg
It's not a 2 byte binary.
It's a leading ascii SOH and a standard ascii char
'0' ... '7' or 'd'.
#define KERN_EMERG
On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
> echo "\0014Hello Joe" > /dev/kmsg
# echo -e "\x014Hello Me" > /dev/kmsg
gives:
12,778,4057982669;Hello Me
#echo -e "\x011Hello Me_2" > /dev/kmsg
gives:
12,779,4140452093;Hello Me_2
I didn't change devkmsg_writev so the
original parsing s
On Wed, 2012-06-06 at 01:48 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 1:43 AM, Joe Perches wrote:
> > On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
>
> >> > # echo "\001Hello Andrew" > /dev/kmsg
> >> > /dev/kmsg has
> >>
On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
> Try "echo -e"? The stuff is copied verbatim otherwise.
btw: I didn't change the devkmsg_writev function
which does the decoding of any "" prefix for
printk_emit.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
t
On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 1:35 AM, Joe Perches wrote:
> > On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote:
> >> What about writes starting with \001n? AFACIT, that will be stripped
> >> away and the printk l
On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote:
> What about writes starting with \001n? AFACIT, that will be stripped
> away and the printk level will be altered. This is new behavior.
Nope.
# echo "\001Hello Andrew" > /dev/kmsg
/dev/kmsg has
12,774,2462339252;\001Hello Andrew
12 is 8
On Tue, 2012-06-05 at 15:17 -0700, Andrew Morton wrote:
> On Tue, 05 Jun 2012 15:11:43 -0700
> Joe Perches wrote:
>
> > On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
> > > Unfortunately the thing is part of the kernel ABI:
> > >
> > > echo
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
> Unfortunately the thing is part of the kernel ABI:
>
> echo "<4>foo" > /dev/kmsg
Which works the same way it did before.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord.
Use the generic printk_get_level function to search a message
for a kern_level. Add __printf to verify format and arguments.
Fix a few messages that had mismatches in format and arguments.
Add #ifdef CONFIG_PRINTK blocks to shrink the object size a bit
when not using printk.
Signed-off-by: Joe
KERN_ currently takes up 3 bytes.
Shrink the kernel size by using an ASCII SOH and then the level byte.
Remove the need for KERN_CONT.
Convert directly embedded uses of <.> to KERN_
Joe Perches (8):
printk: Add generic functions to find KERN_ headers
printk: Add kern_levels.h to make
On Fri, 2011-09-23 at 11:07 -0700, H Hartley Sweeten wrote:
> Quiet the following sparse warnings:
[]
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
[]
> @@ -2705,7 +2705,7 @@ long btrfs_ioctl_space_info(struct btrfs_root *root,
> void __user *arg)
> up_read(&info->groups_sem);
>
Signed-off-by: Joe Perches
---
fs/btrfs/tree-log.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c139222..ab326dd 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2605,7 +2605,7 @@ static noinline int
Now that btrfs is in mainline, perhaps
a maintainers entry is appropriate?
Perhaps:
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f65a26..138a54c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1021,6 +1021,14 @@ M: m...@bu3sch.de
W: http://bu3sch.de/btgpio.php
S: Maintained
+BTR
42 matches
Mail list logo
