Re: [PATCH v10 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-02 Thread David Miller
From: Coly Li 
Date: Fri,  2 Oct 2020 16:27:27 +0800

> As Sagi Grimberg suggested, the original fix is refind to a more common
> inline routine:
> static inline bool sendpage_ok(struct page *page)
> {
> return  (!PageSlab(page) && page_count(page) >= 1);
> }
> If sendpage_ok() returns true, the checking page can be handled by the
> concrete zero-copy sendpage method in network layer.

Series applied.

> The v10 series has 7 patches, fixes a WARN_ONCE() usage from v9 series,
 ...

I still haven't heard from you how such a fundamental build failure
was even possible.

If the v9 patch series did not even compile, how in the world did you
perform functional testing of these changes?

Please explain this to me, instead of just quietly fixing it and
posting an updated series.

Thank you.


Re: [PATCH v9 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-02 Thread David Miller
From: David Miller 
Date: Thu, 01 Oct 2020 12:43:45 -0700 (PDT)

> Series applied and queued up for -stable, thank you.

Actually, this doesn't even build:

In file included from ./arch/x86/include/asm/bug.h:93,
 from ./include/linux/bug.h:5,
 from ./include/linux/mmdebug.h:5,
 from ./include/linux/mm.h:9,
 from net/socket.c:55:
net/socket.c: In function ‘kernel_sendpage’:
./include/asm-generic/bug.h:97:3: error: too few arguments to function 
‘__warn_printk’
   97 |   __warn_printk(arg); \
  |   ^

Was this even build tested?



Re: [PATCH v9 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-02 Thread David Miller
From: Coly Li 
Date: Fri, 2 Oct 2020 16:30:12 +0800

> Obviously my fault and no excuse for leaking this uncompleted version to
> you. I just re-post a v10 version which I make sure all patches are the
> latest version.
> 
> Sorry for the inconvenience and thank you in advance for taking this set.

How did this happen?

How did you functionally test the patch set if it didn't even compile?

I want you to explain why you sent a completely untested patch set.


Re: [PATCH v9 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-02 Thread David Miller
From: Coly Li 
Date: Thu,  1 Oct 2020 15:54:01 +0800

> This series was original by a bug fix in nvme-over-tcp driver which only
> checked whether a page was allocated from slab allcoator, but forgot to
> check its page_count: The page handled by sendpage should be neither a
> Slab page nor 0 page_count page.
> 
> As Sagi Grimberg suggested, the original fix is refind to a more common
> inline routine:
> static inline bool sendpage_ok(struct page *page)
> {
> return  (!PageSlab(page) && page_count(page) >= 1);
> }
> If sendpage_ok() returns true, the checking page can be handled by the
> concrete zero-copy sendpage method in network layer.
> 
> The v9 series has 7 patches, no change from v8 series,
> - The 1st patch in this series introduces sendpage_ok() in header file
>   include/linux/net.h.
> - The 2nd patch adds WARN_ONCE() for improper zero-copy send in
>   kernel_sendpage().
> - The 3rd patch fixes the page checking issue in nvme-over-tcp driver.
> - The 4th patch adds page_count check by using sendpage_ok() in
>   do_tcp_sendpages() as Eric Dumazet suggested.
> - The 5th and 6th patches just replace existing open coded checks with
 ...

Series applied and queued up for -stable, thank you.


Re: [PATCH 26/26] tcp: Use ahash

2016-01-25 Thread David Miller
From: Herbert Xu 
Date: Sun, 24 Jan 2016 21:20:23 +0800

> This patch replaces uses of the long obsolete hash interface with
> ahash.
> 
> Signed-off-by: Herbert Xu 

Acked-by: David S. Miller 


Re: [PATCH 25/26] sctp: Use shash

2016-01-25 Thread David Miller
From: Herbert Xu 
Date: Sun, 24 Jan 2016 21:20:12 +0800

> This patch replaces uses of the long obsolete hash interface with
> shash.
> 
> Signed-off-by: Herbert Xu 

Acked-by: David S. Miller 


Re: [PATCH 19/26] ipsec: Use skcipher and ahash when probing algorithms

2016-01-25 Thread David Miller
From: Herbert Xu 
Date: Sun, 24 Jan 2016 21:19:11 +0800

> This patch removes the last reference to hash and ablkcipher from
> IPsec and replaces them with ahash and skcipher respectively.  For
> skcipher there is currently no difference at all, while for ahash
> the current code is actually buggy and would prevent asynchronous
> algorithms from being discovered.
> 
> Signed-off-by: Herbert Xu 

Acked-by: David S. Miller 


Re: cxgb4i submission

2010-04-08 Thread David Miller
From: Rakesh Ranjan rak...@chelsio.com
Date: Thu,  8 Apr 2010 17:44:12 +0530

 This driver depends upon cxgb4 driver, posted recently on netdev and
 now part of net-next repo.

It went into the net-2.6 repo, not net-next-2.6

And it is even in Linus's tree now.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: [RESEND PATCH 1/1]cxgb3i: Fix a login over vlan issue

2010-01-04 Thread David Miller
From: Rakesh Ranjan rak...@chelsio.com
Date: Sun, 27 Dec 2009 12:41:58 +0530 (IST)

 From: Rakesh Ranjan rak...@chelsio.com
 Date: Sun, 27 Dec 2009 12:33:08 +0530
 Fix a target login issue, when parent interface is vlan and we are using 
 cxgb3i sepecific
 private ip address in '/etc/iscsi/ifaces/' iface file.
 
 Acked-by: Karen Xie k...@chelsio.com
 Signed-off-by: Rakesh Ranjan rak...@chelsio.com

Applied.

--

You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.




Re: [RFC-PATCH] libiscsi dhcp handler

2009-11-18 Thread David Miller
From: Rakesh Ranjan rak...@chelsio.com
Date: Wed, 18 Nov 2009 08:56:55 +0530

 ping ...

I'm too busy, if you're waiting for me.  It could take weeks for me to
get to this, sorry.

--

You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=.




Re: [RFC-PATCH] libiscsi dhcp handler

2009-11-16 Thread David Miller

From: Rakesh Ranjan rak...@chelsio.com
Date: Mon, 16 Nov 2009 18:41:49 +0530

 Herein attached patches to support dhcp based provisioning for iSCSI
 offload capable cards. I have made dhcp code as generic as possible,
 please go through the code. Based on the feedback I will submit final
 version of these patches.

You can't really add objects to the build before the patch that
adds the source for that object.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: [PATCH v2 0/2] cxgb3/cxgb3i: added support of private MAC address and provisioning packet handler for iSCSI

2009-09-28 Thread David Miller

From: Karen Xie k...@chelsio.com
Date: Fri, 25 Sep 2009 15:34:22 -0700

 Hmm, I am wondering how could this merge activity to be coordinated? If
 only the driver/scsi change is merged, then it won't compile either,
 since it requires the driver/net change.

That's rediculious, frankly.

Since they are two seperate changes you are knowingly creating
a bisection point that will not work.  That's wrong.

You need to split up the changes so that each and every one of them
are independant and the tree can be checked out at either of them and
everything can be expected to work.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: [PATCH] iscsi: Use GFP_ATOMIC in iscsi_offload_mesg().

2009-07-31 Thread David Miller

From: Mike Christie micha...@cs.wisc.edu
Date: Wed, 29 Jul 2009 20:40:50 -0500

 On 07/29/2009 01:49 PM, Michael Chan wrote:
 Changing to GFP_ATOMIC because the only caller in cnic/bnx2i may
 be calling this function while holding spin_lock.

 This problem was discovered by Mike Christie.

 Signed-off-by: Michael Chanmc...@broadcom.com
 ...
 Acked-by: Mike Christie micha...@cs.wisc.edu
 
 Dave Miller probably wants to take this in his tree since it fixes a
 bug with this patch
 http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=6d7760a88c25057c2c2243e5dfe2d731064bd31d

Yep I'll take it, thanks everyone.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: [PATCH] cnic: Fix ISCSI_KEVENT_IF_DOWN message handling.

2009-07-28 Thread David Miller

From: Michael Chan mc...@broadcom.com
Date: Wed, 22 Jul 2009 20:01:55 -0700

 When a net device goes down or when the bnx2i driver is unloaded,
 the code was not generating the ISCSI_KEVENT_IF_DOWN message
 properly and this could cause the userspace driver to crash.
 
 This is fixed by sending the message properly in the shutdown path.
 cnic_uio_stop() is also added to send the message when bnx2i is
 unregistering.
 
 Signed-off-by: Michael Chan mc...@broadcom.com

Applied.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: [PATCH 0/3 2.6.29] cxgb3i -- driver fixes updates

2008-12-08 Thread David Miller

From: Karen Xie [EMAIL PROTECTED]
Date: Sat, 6 Dec 2008 23:09:36 -0800

 It is based on the cxgb3i branch of Mike's linux-2.6-iscsi tree. It needs the
 patch Mike sent several days ago on preparing the iscsi core libary for pdu
 offload (http://marc.info/?l=linux-scsim=122819956917473).

If this dependency exists I probably can't pull this into the
net-next-2.6 then, just FYI but you probably already understand
this :-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---



Re: [PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver

2008-08-23 Thread David Miller

From: [EMAIL PROTECTED]
Date: Sat, 23 Aug 2008 14:37:53 +0530

 Exactly. And I am also suggesting that the driver version is not
 standard among different vendors.

It should not be standardized because every driver maintainer works
differently, and every driver is developed differently, and therefore
has different needs and desires for the version number.

All that matters is that the driver version makes sense to the
person maintaining the driver, and works for them when reviewing
bug reports.

Look, what you're suggesting is to change existing practice and that
doesn't belong in the discussion of the review of a specific driver.
If you want to bring that up as a topic and change globally how that
is handled, bring that up as a seperate topic on linux-kernel.

Don't bug the poor driver submitter who is just following existing
and accepted practice.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---