Re: [PATCH v10 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers
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
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
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
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
From: Herbert XuDate: 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
From: Herbert XuDate: 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
From: Herbert XuDate: 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
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
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
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
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
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().
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.
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
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
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 -~--~~~~--~~--~--~---