[trivial PATCH] treewide: Add __GFP_NOWARN to k.alloc calls with v.alloc fallbacks

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 j...@perches.com --- drivers/block/drbd/drbd_bitmap.c | 2 +- drivers/infiniband/hw/ehca

Re: [trivial PATCH] treewide: Add __GFP_NOWARN to k.alloc calls with v.alloc fallbacks

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 rejecting these sorts

Re: btrfs zero divide (was: Re: Linux 3.10 problem reports (yes, plural))

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

Re: btrfs zero divide

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

Re: btrfs zero divide

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

[PATCH] btrfs: MAINTAINERS entry

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

[PATCH 55/62] fs/btrfs/tree-log.c: Remove unnecessary semicolons

Signed-off-by: Joe Perches j...@perches.com --- 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

Re: [PATCH] btrfs/ioctl.c: quiet sparse warnings

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);

[PATCH 4/8] btrfs: Use printk_get_level and printk_skip_level, add __printf, fix fallout

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

[PATCH 0/8] Rework KERN_LEVEL

KERN_LEVEL 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_LEVEL Joe Perches (8): printk: Add generic functions to find KERN_LEVEL headers printk: Add kern_levels.h

Re: [PATCH 0/8] Rework KERN_LEVEL

On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote: Unfortunately the n thing is part of the kernel ABI: echo 4foo /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

Re: [PATCH 0/8] Rework KERN_LEVEL

On Tue, 2012-06-05 at 15:17 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012 15:11:43 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote: Unfortunately the n thing is part of the kernel ABI: echo 4foo /dev/kmsg Which works

Re: [PATCH 0/8] Rework KERN_LEVEL

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 +

Re: [PATCH 0/8] Rework KERN_LEVEL

On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote: On Wed, Jun 6, 2012 at 1:35 AM, Joe Perches j...@perches.com 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 level will be altered

Re: [PATCH 0/8] Rework KERN_LEVEL

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 n prefix for printk_emit. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the

Re: [PATCH 0/8] Rework KERN_LEVEL

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 style for

Re: [PATCH 0/8] Rework KERN_LEVEL

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

Re: [PATCH 0/8] Rework KERN_LEVEL

On Wed, 2012-06-06 at 02:28 +0200, Kay Sievers wrote: On Wed, Jun 6, 2012 at 2:19 AM, Joe Perches j...@perches.com 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: echo -e \x01\x02Hello /dev

Re: [PATCH 0/8] Rework KERN_LEVEL

On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches j...@perches.com wrote: 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

Re: [PATCH 0/8] Rework KERN_LEVEL

On Wed, 2012-06-06 at 03:10 +0200, Kay Sievers wrote: On Wed, Jun 6, 2012 at 2:46 AM, Andrew Morton a...@linux-foundation.org wrote: On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012 17:07

[PATCH 9/8] printk: Only look for prefix levels in kernel messages

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 j...@perches.com --- kernel/printk.c | 32 +--- 1 files changed, 17 insertions(+), 15 deletions(-) diff

Re: [PATCH v2 1/2] Return a value from printk_ratelimited

On Fri, 2014-09-19 at 13:21 -0400, Steven Rostedt wrote: On Fri, 19 Sep 2014 02:01:29 -0700 Omar Sandoval osan...@osandov.com 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:

Re: [PATCH v2 1/2] Return a value from printk_ratelimited

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 osan...@osandov.com wrote: printk returns an integer

Re: [PATCH v3 1/2] Return a value from printk_ratelimited

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 osan...@osandov.com Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com --- I'd prefer to keep it the way it is

Re: [PATCH v5] Move BTRFS RCU string to common library

On Fri, 2014-11-07 at 15:21 -0500, Chris Mason wrote: On Fri, Nov 7, 2014 at 3:17 PM, Omar Sandoval osan...@osandov.com 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

Re: [PATCH v6] Move BTRFS RCU string to common library

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

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters

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, >  

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80

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 > > > >

Re: [PATCH] Btrfs: ctree: added lines after variable declarations

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, >  

Re: [PATCH] Btrfs: ctree: added lines after variable declarations

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-02-22

Re: [PATCH] Btrfs: compression: added line after variable declaration

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, >   >  

Re: [PATCH] Btrfs: ctree: added lines after variable declarations

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

Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

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

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

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

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

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?

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

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-&

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

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