search for: treewide

On 10/17/20 10:43 PM, Greg KH wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: >> From: Tom Rix <trix at redhat.com> >> >> This is a upcoming change to clean up a new warning treewide. >> I am wondering if the change could be one mega patch (see below) or >> normal patch per file about 100 patches or somewhere half way by collecting >> early acks. > Please break it up into one-patch-per-subsystem, like normal, and get it > merged that way. OK. Thanks,...

On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > From: Tom Rix <trix at redhat.com> > > This is a upcoming change to clean up a new warning treewide. > I am wondering if the change could be one mega patch (see below) or > normal patch per file about 100 patches or somewhere half way by collecting > early acks. Please break it up into one-patch-per-subsystem, like normal, and get it merged that way. Sending us a patch, without even a...

...17, 2020 at 10:43 PM Greg KH <gregkh at linuxfoundation.org> wrote: > > > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > > > From: Tom Rix <trix at redhat.com> > > > > > > This is a upcoming change to clean up a new warning treewide. > > > I am wondering if the change could be one mega patch (see below) or > > > normal patch per file about 100 patches or somewhere half way by collecting > > > early acks. > > > > Please break it up into one-patch-per-subsystem, like normal, and get it >...

On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh at linuxfoundation.org> wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > > From: Tom Rix <trix at redhat.com> > > > > This is a upcoming change to clean up a new warning treewide. > > I am wondering if the change could be one mega patch (see below) or > > normal patch per file about 100 patches or somewhere half way by collecting > > early acks. > > Please break it up into one-patch-per-subsystem, like normal, and get it > merged that way. > &g...

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches <joe at perches.com> wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate > define pr_warning for that directory tree and pr_warn is > not used

On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote: > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <joe at perches.com> wrote: > > There are ~4300 uses of pr_warn and ~250 uses of the older > > pr_warning in the kernel source tree. > > > > Make the use of pr_warn consistent across all kernel files. > > > > This excludes all files in tools/ as there

On Thu, 2017-02-23 at 17:41 +0000, Emil Velikov wrote: > On 23 February 2017 at 17:18, Joe Perches <joe at perches.com> wrote: > > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote: > > > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <joe at perches.com> wrote: > > > > There are ~4300 uses of pr_warn and ~250 uses of the older > > > >

On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote: > fallthrough to a separate case/default label break; isn't very readable. > > Convert pseudo-keyword fallthrough; statements to a simple break; when > the next label is case or default and the only statement in the next > label block is break; > > Found using: > > $ grep-2.5.4 -rP --include=*.[ch] -n

On 2020-09-09 21:06, Joe Perches wrote: > fallthrough to a separate case/default label break; isn't very readable. > > Convert pseudo-keyword fallthrough; statements to a simple break; when > the next label is case or default and the only statement in the next > label block is break; > > Found using: > > $ grep-2.5.4 -rP --include=*.[ch] -n

On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote: > diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c > index eea0f453cfb6..8aac5bc60f4c 100644 > --- a/crypto/tcrypt.c > +++ b/crypto/tcrypt.c > @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32 mask, int m, u32 num_mb) > test_hash_speed("streebog512", sec, >

On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > clang has a number of useful, new warnings see > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ Please get your IT department to remove that stupidity. If you can't, please send email from a

On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote: > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > > > clang has a number of useful, new warnings see > > >

On 23 February 2017 at 17:18, Joe Perches <joe at perches.com> wrote: > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote: >> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <joe at perches.com> wrote: >> > There are ~4300 uses of pr_warn and ~250 uses of the older >> > pr_warning in the kernel source tree. >> > >> > Make the use of pr_warn

On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote: > fs/btrfs/ioctl.c | 2 +- > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index 40b729dce91c..eab3f8510426 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -2691,7 +2691,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp) >

Last time you sent this we couldn't decide which tree it should go through. Either the crypto tree or through Andrew seems like the right thing to me. Also the other issue is that it risks breaking things if people add new kzfree() instances while we are doing the transition. Could you just add a "#define kzfree kfree_sensitive" so that things continue to compile and we can remove

On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > v4: > - Break out the memzero_explicit() change as suggested by Dan Carpenter > so that it can be backported to stable. > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > now as there can be a bit more discussion on what is best. It will be > introduced as a separate patch

On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > v4: > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > so that it can be backported to stable. > > > - Drop the

On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote: > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > Not just performance critical, but correctness critical. Since kvfree() > > may allocate from the vmalloc allocator, I really think that kvfree() > > should assert that it's !in_atomic(). Otherwise we can get into trouble > > if we end up calling

On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote: > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > > If you call vfree() under > > a spinlock, you're in trouble. in_atomic() only knows if we hold a > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > > in __vfree(). So we need the warning in order that preempt people can

On Thu, 2020-06-18 at 00:31 +0300, Denis Efremov wrote: > > On 6/16/20 9:53 PM, Joe Perches wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > v4: > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > so that it can be backported to stable. > > > - Drop the "crypto: Remove unnecessary