lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 27 May 2015 18:24:31 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	"Simmons, James A." <simmonsja@...l.gov>
Cc:	James Simmons <jsimmons@...radead.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Drokin <oleg.drokin@...el.com>,
	"HPDD-discuss@...1.01.org" <HPDD-discuss@...1.01.org>,
	"lustre-devel@...ts.lustre.org" <lustre-devel@...ts.lustre.org>
Subject: Re: [lustre-devel] [PATCH 5/6] staging:lustre: style cleanups for
 lib-socket.c

On Wed, May 27, 2015 at 03:01:37PM +0000, Simmons, James A. wrote:
> >>On Fri, May 22, 2015 at 02:32:31PM -0400, James Simmons wrote:
> >> @@ -167,13 +164,14 @@ lnet_ipif_enumerate (char ***namesp)
> >>  		if (nalloc * sizeof(*ifr) > PAGE_CACHE_SIZE) {
> >>  			toobig = 1;
> >>  			nalloc = PAGE_CACHE_SIZE/sizeof(*ifr);
> >> -			CWARN("Too many interfaces: only enumerating first %d\n",
> >> -			      nalloc);
> >> +			CWARN("Too many interfaces: only enumerating "
> >> +			      "first %d\n", nalloc);
> >>  		}
> >
> >Don't split string literals, it makes them hard to grep for.
> 
> Will fix. The CWARN will go over 80 characters but from the recent emails that is more acceptable.
> If this is the only problem then this patch set it ready.

Normally the right thing to do here would be to send a fixed
[patch 5/6 v2] using the --in-reply-to option so that it appears as a
reply to the original [patch 5/6].

> I have more patch series that are dependent
> on this first one. Should I push the other patch series with a note that it is dependent on the tcpip
> cleanup or wait until it is merged? Also how does one find out when the patch has been merged?

You will get an email when these are merged.

This is the only issue, I had.  No one else has complained so that means
no one else has any objections.  Greg hasn't merged it yet and he might
find a problem with it, but it seems like a straight forward patchset
so that's unlikely.

The only issue is that this patchset was sent in a confusing way.  It
doesn't have a v2 tag and it was tacked on to the old thread.  Greg
tends to not waste time being confused and just deletes the whole thread
when that happens.

The notes that "This depends on XXX being applied." are kind of nice but
no one spends a lot of time worrying about that stuff.  Greg just
applies the patches in the order that they hit his inbox and they either
apply or he tells people to update and resend.

So send your follow on patches.  If everything applies then good.  If
not then you can resend, which is a few commands in git and not a big
deal.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ