Re: [PATCH/RFC 00/10] Transparent proxying patches version 4
Hi Krisztian! On Wed, Jan 03, 2007 at 05:33:57PM +0100, KOVACS Krisztian wrote: > So instead of using NAT to dynamically redirect traffic to local > addresses, we now rely on "native" non-locally-bound sockets and do > early socket lookups for inbound IPv4 packets. It's good to see a solid implementation of this 'old idea'. Just as a quick historical note to netdev: This is the way how the netfilter project advised the balabit guys to implement fully transparent proxy support, after having seen the complexity of the old nat-based TPROXY patches. So I personally support this patchset and vote for it to be included (with whatever modifications netdev deems apropriate) It might be that there now is the experimental netchannels system which might provide an even better way for transparent proxy support. However, ever since ip_tables was merged in the 2.3.x days, we have lacked good support for transparent proxies. Now that the first incarnation of the NAT based TPROXY patch for 2.4.x had to be developed and maintained out-of-tree for many years, I definitely think it's better to merge the new, way less intrusive, patchset. Some interested party can work on a netchannels implementation later on, but that's the next generation... Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie signature.asc Description: Digital signature
Re: [PATCH/RFC 00/10] Transparent proxying patches version 4
On Sun, Jan 07, 2007 at 03:11:34PM +0100, Harald Welte wrote: > > So instead of using NAT to dynamically redirect traffic to local > > addresses, we now rely on "native" non-locally-bound sockets and do > > early socket lookups for inbound IPv4 packets. > > It's good to see a solid implementation of this 'old idea'. > > Just as a quick historical note to netdev: This is the way how the > netfilter project advised the balabit guys to implement fully > transparent proxy support, after having seen the complexity of the old > nat-based TPROXY patches. Didn't rusty tell the balabit guys to use the NAT approach? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20-rc4: known unfixed regressions
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject: BUG: at mm/truncate.c:60 cancel_dirty_page()
References : http://lkml.org/lkml/2007/1/7/117
Submitter : Malte Schröder <[EMAIL PROTECTED]>
Status : unknown
Subject: netfilter conntrack Oopses
References : http://lkml.org/lkml/2007/1/4/156
http://lkml.org/lkml/2007/1/7/188
Submitter : Bernhard Schmidt <[EMAIL PROTECTED]>
Peter Osterlund <[EMAIL PROTECTED]>
Status : unknown
Subject: ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[EMAIL PROTECTED]>
Caused-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Status : problem is being debugged
Subject: BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter : Cijoml Cijomlovic Cijomlov <[EMAIL PROTECTED]>
Status : unknown
Subject: BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl <[EMAIL PROTECTED]>
Damien Wyart <[EMAIL PROTECTED]>
Aaron Sethman <[EMAIL PROTECTED]>
Status : unknown
Subject: problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <[EMAIL PROTECTED]>
Status : unknown
Subject: x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101
http://lkml.org/lkml/2007/1/3/9
Submitter : Tobias Diedrich <[EMAIL PROTECTED]>
Caused-By : Andi Kleen <[EMAIL PROTECTED]>
commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu <[EMAIL PROTECTED]>
Eric W. Biederman <[EMAIL PROTECTED]>
Status : patches are being discussed
Subject: USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha <[EMAIL PROTECTED]>
Status : unknown
Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[EMAIL PROTECTED]>
Handled-By : Alexey Starikovskiy <[EMAIL PROTECTED]>
Status : problem is being debugged
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20-rc4: known regressions with patches available
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: bluetooth oopses because of multiple kobject_add() References : http://lkml.org/lkml/2007/1/2/101 Submitter : Pavel Machek <[EMAIL PROTECTED]> Handled-By : Marcel Holtmann <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/2/147 Status : patch available Subject: forcedeth.c 0.59: problem with sideband managment References : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Submitter : Michael Reske <[EMAIL PROTECTED]> Handled-By : Ayaz Abdulla <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Status : patch available Subject: nVidia CK804 chipset: not detecting HT MSI capabilities References : http://lkml.org/lkml/2007/1/5/215 Submitter : Brice Goglin <[EMAIL PROTECTED]> Robert Hancock <[EMAIL PROTECTED]> Handled-By : Brice Goglin <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/5/215 Status : patch available - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bluetooth fixes for 2.6.20-rc4
Hi Dave, here are the missing fixes for the Bluetooth subsystem that should go in before the final 2.6.20 release. Please forward them to Linus as soon as possible. Regards Marcel Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git This will update the following files: drivers/bluetooth/hci_usb.c |7 +++ net/bluetooth/cmtp/capi.c | 39 +-- net/bluetooth/hci_sysfs.c |7 ++- net/bluetooth/rfcomm/sock.c |5 +++-- net/bluetooth/rfcomm/tty.c | 22 +++--- 5 files changed, 64 insertions(+), 16 deletions(-) through these ChangeSets: Commit: e2fe5c641a149ec0a136f6c40b582a36acd48e29 Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:57 +0100 [Bluetooth] Correct SCO buffer for Broadcom based Dell laptops The SCO buffer size values on Dell laptops with a Bluetooth chip from Broadcom are wrong. The USB Bluetooth driver has to set a quirk to correct the SCO buffer size values. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Commit: ad84b8efd5c82d3081e13718b82141afba59cae6 Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:50 +0100 [Bluetooth] Correct SCO buffer for Broadcom based HP laptops The SCO buffer size values on HP laptops with a Bluetooth chip from Broadcom are wrong. The USB Bluetooth driver has to set a quirk to correct the SCO buffer size values. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Commit: b4dc4e184068a7462cb8e5934152f3dece27bd33 Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:47 +0100 [Bluetooth] Correct SCO buffer size for another ThinkPad laptop The ThinkPad R60E uses a Broadcom based Bluetooth chip and even this version needs the quirk to correct the SCO buffer size values. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Commit: 0772e9f351bc5dc5ee0c55302b4aa943fca33705 Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:41 +0100 [Bluetooth] Handle device registration failures In the case the device registration for a new Bluetooth low-level connection fails there is no need to unregister it when the temporary data structure has been removed. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Commit: 2b2e64be763c5e64d4ae4a061825b18decf1edf7 Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:33 +0100 [Bluetooth] Fix uninitialized return value for RFCOMM sendmsg() When calling send() with a zero length parameter on a RFCOMM socket it returns a positive value. In this rare case the variable err is used uninitialized and unfortunately its value is returned. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Commit: 9d1e13e54d56999804d5d025d236900056ebe7bf Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:22 +0100 [Bluetooth] More checks if DLC is still attached to the TTY If the DLC device is no longer attached to the TTY device, then return errors or default values for various callbacks of the TTY layer. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Commit: 7c778531f600749801de1cbca297c94083c5f217 Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 00:59:58 +0100 [Bluetooth] Add packet size checks for CAPI messages With malformed packets it might be possible to overwrite internal CMTP and CAPI data structures. This patch adds additional length checks to prevent these kinds of remote attacks. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc4
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Mon, 08 Jan 2007 01:31:44 +0100 > Commit: 2b2e64be763c5e64d4ae4a061825b18decf1edf7 > Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:33 +0100 > > [Bluetooth] Fix uninitialized return value for RFCOMM sendmsg() > > When calling send() with a zero length parameter on a RFCOMM socket > it returns a positive value. In this rare case the variable err is > used uninitialized and unfortunately its value is returned. > > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> You can't fix this bug like that. If sendmsg() sends any bytes, it should return the number of bytes sent even if an error occurs mid-stream. With this change, you'll now return the error instead of the number of bytes sent. That's what the new "sent = err" assignment does. You have to do sendmsg() with those semantics, or else you lose information in that the user can never know how many bytes were actually sent successfully. Losing the error after successfully sent bytes is OK, if the error persists the user will get it when it recalls sendmsg() to push the rest of the remaining bytes out. The original code tried to do it right. If the bug is that 'err' is uninitialized, why try to fix this by being fancy, just initialize it :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc4
Hi Dave, > > Commit: 2b2e64be763c5e64d4ae4a061825b18decf1edf7 > > Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:33 +0100 > > > > [Bluetooth] Fix uninitialized return value for RFCOMM sendmsg() > > > > When calling send() with a zero length parameter on a RFCOMM socket > > it returns a positive value. In this rare case the variable err is > > used uninitialized and unfortunately its value is returned. > > > > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> > > You can't fix this bug like that. > > If sendmsg() sends any bytes, it should return the number of > bytes sent even if an error occurs mid-stream. > > With this change, you'll now return the error instead of > the number of bytes sent. That's what the new "sent = err" > assignment does. > > You have to do sendmsg() with those semantics, or else you lose > information in that the user can never know how many bytes were > actually sent successfully. Losing the error after successfully sent > bytes is OK, if the error persists the user will get it when it > recalls sendmsg() to push the rest of the remaining bytes out. > > The original code tried to do it right. > > If the bug is that 'err' is uninitialized, why try to fix this > by being fancy, just initialize it :-) We have "int sent = 0" and exactly that is returned if "len == 0". Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc4
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Mon, 08 Jan 2007 02:19:13 +0100 > Hi Dave, > > > > Commit: 2b2e64be763c5e64d4ae4a061825b18decf1edf7 > > > Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:33 > > > +0100 > > > > > > [Bluetooth] Fix uninitialized return value for RFCOMM sendmsg() > > > > > > When calling send() with a zero length parameter on a RFCOMM socket > > > it returns a positive value. In this rare case the variable err is > > > used uninitialized and unfortunately its value is returned. > > > > > > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> > > > > You can't fix this bug like that. > > > > If sendmsg() sends any bytes, it should return the number of > > bytes sent even if an error occurs mid-stream. > > > > With this change, you'll now return the error instead of > > the number of bytes sent. That's what the new "sent = err" > > assignment does. > > > > You have to do sendmsg() with those semantics, or else you lose > > information in that the user can never know how many bytes were > > actually sent successfully. Losing the error after successfully sent > > bytes is OK, if the error persists the user will get it when it > > recalls sendmsg() to push the rest of the remaining bytes out. > > > > The original code tried to do it right. > > > > If the bug is that 'err' is uninitialized, why try to fix this > > by being fancy, just initialize it :-) > > We have "int sent = 0" and exactly that is returned if "len == 0". Marcel, please reread my email, then you can hit reply again ok :) You broke the case where len != 0, you're going to return an error code when "sent != 0" and that's a bug, sendmsg() must return the number of bytes sent if non-zero even if an error occurs. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc4
Hi Dave, > > > > Commit: 2b2e64be763c5e64d4ae4a061825b18decf1edf7 > > > > Author: Marcel Holtmann <[EMAIL PROTECTED]> Mon, 08 Jan 2007 01:00:33 > > > > +0100 > > > > > > > > [Bluetooth] Fix uninitialized return value for RFCOMM sendmsg() > > > > > > > > When calling send() with a zero length parameter on a RFCOMM socket > > > > it returns a positive value. In this rare case the variable err is > > > > used uninitialized and unfortunately its value is returned. > > > > > > > > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> > > > > > > You can't fix this bug like that. > > > > > > If sendmsg() sends any bytes, it should return the number of > > > bytes sent even if an error occurs mid-stream. > > > > > > With this change, you'll now return the error instead of > > > the number of bytes sent. That's what the new "sent = err" > > > assignment does. > > > > > > You have to do sendmsg() with those semantics, or else you lose > > > information in that the user can never know how many bytes were > > > actually sent successfully. Losing the error after successfully sent > > > bytes is OK, if the error persists the user will get it when it > > > recalls sendmsg() to push the rest of the remaining bytes out. > > > > > > The original code tried to do it right. > > > > > > If the bug is that 'err' is uninitialized, why try to fix this > > > by being fancy, just initialize it :-) > > > > We have "int sent = 0" and exactly that is returned if "len == 0". > > Marcel, please reread my email, then you can hit reply again ok :) > > You broke the case where len != 0, you're going to return an error > code when "sent != 0" and that's a bug, sendmsg() must return the > number of bytes sent if non-zero even if an error occurs. it is way too late and you are absolutely right. However since the current code doesn't produce a compiler warning of an uninitialized variable, I prefer to not go with a "int err = 0" to make this work. I rebuild the tree with the correct fix in it and it is now ready to be pulled. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20-rc4: known regressions with patches available
Hi Adrian, > This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19 > with patches available. > > If you find your name in the Cc header, you are either submitter of one > of the bugs, maintainer of an affectected subsystem or driver, a patch > of you caused a breakage or I'm considering you in any other way possibly > involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. > > > Subject: bluetooth oopses because of multiple kobject_add() > References : http://lkml.org/lkml/2007/1/2/101 > Submitter : Pavel Machek <[EMAIL PROTECTED]> > Handled-By : Marcel Holtmann <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/1/2/147 > Status : patch available the patch has been forwarded to Dave Miller. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] 3 ixgb fixes, please pull
Auke Kok wrote: Hi, These 3 patches were earlier submitted and ACKed by Jeff Garzik on 12/08, 12/11. They were part of a larger submission that also included e1000 patches. The ixgb patches still need to be merged. The spurious NETIF_F_TSO flags were removed from patch "Fix early TSO completion" as requested. These patches apply against netdev-2.6 #upstream-fixes commit 81f4e6c190a0fa016fd7eecaf76a5f95d121afc2. Please pull: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes pulled - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull request for 'qla3xxx-upstream-fixes-20070103-00' tag
Francois Romieu wrote: Please pull from tag 'qla3xxx-upstream-fixes-20070103-00' in repository git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git tag qla3xxx-upstream-fixes-20070103-00 to get the changes below. Distance from 'netdev-2.6-upstream-fixes' - 736272c636cea8593e0907a8c44ec411710c06c1 81f4e6c190a0fa016fd7eecaf76a5f95d121afc2 <- netdev-2.6-upstrem-fixes I grabbed Ron's patches #1 and #2.. BTW, git is annoying in that it downloads your tag into my tree. Using branches would be a lot prettier :) Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc4
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Mon, 08 Jan 2007 02:44:41 +0100 > it is way too late and you are absolutely right. However since the > current code doesn't produce a compiler warning of an uninitialized > variable, I prefer to not go with a "int err = 0" to make this work. > > I rebuild the tree with the correct fix in it and it is now ready to be > pulled. That version of the fix is much better, pulled and pushed back out to kernel.org, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
On Mon, Jan 08, 2007 at 11:12:28AM +0800, Li Yang-r58472 wrote: > > From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED] > > > > Hi, > > A kmalloc casting cleanup patch. > > Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]> [..] > > - (u32) (kmalloc((u32) (length + align), > > - GFP_KERNEL)); > > + kmalloc((u32) (length + align), GFP_KERNEL); > > + > > if (ugeth->tx_bd_ring_offset[j] != 0) > > ugeth->p_tx_bd_ring[j] = [..] > > - (u32) (kmalloc((u32) (length + align), GFP_KERNEL)); > > + kmalloc((u32) (length + align), GFP_KERNEL); > > NACK about the 2 clean-ups above. Cast from pointer to integer is > required here. Are the casts from pointer to integer just needed to suppress gcc warnings or there's something technically important about them ? I'll send the modified patch without the NACKed parts in minutes .. -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
On Mon, Jan 08, 2007 at 11:12:28AM +0800, Li Yang-r58472 wrote:
>
> NACK about the 2 clean-ups above. Cast from pointer to integer is
> required here.
>
Hi, here's the modified patch.
A patch to switch kmalloc to kzalloc and clean some redundant kmalloc
casts.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 8243150..0f58f5f 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2926,10 +2926,9 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
/* Init Tx bds */
for (j = 0; j < ug_info->numQueuesTx; j++) {
/* Setup the skbuff rings */
- ugeth->tx_skbuff[j] =
- (struct sk_buff **)kmalloc(sizeof(struct sk_buff *) *
- ugeth->ug_info->bdRingLenTx[j],
- GFP_KERNEL);
+ ugeth->tx_skbuff[j] = kmalloc(sizeof(struct sk_buff *) *
+ ugeth->ug_info->bdRingLenTx[j],
+ GFP_KERNEL);
if (ugeth->tx_skbuff[j] == NULL) {
ugeth_err("%s: Could not allocate tx_skbuff",
@@ -2958,10 +2957,9 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
/* Init Rx bds */
for (j = 0; j < ug_info->numQueuesRx; j++) {
/* Setup the skbuff rings */
- ugeth->rx_skbuff[j] =
- (struct sk_buff **)kmalloc(sizeof(struct sk_buff *) *
- ugeth->ug_info->bdRingLenRx[j],
- GFP_KERNEL);
+ ugeth->rx_skbuff[j] = kmalloc(sizeof(struct sk_buff *) *
+ ugeth->ug_info->bdRingLenRx[j],
+ GFP_KERNEL);
if (ugeth->rx_skbuff[j] == NULL) {
ugeth_err("%s: Could not allocate rx_skbuff",
@@ -3450,19 +3448,16 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
* resource.
* This shadow structure keeps a copy of what was done so that the
* allocated resources can be released when the channel is freed.
+* *p_init_enet_param_shadow is zeroed by kzalloc
*/
- if (!(ugeth->p_init_enet_param_shadow =
-(struct ucc_geth_init_pram *) kmalloc(sizeof(struct
ucc_geth_init_pram),
- GFP_KERNEL))) {
+ if (!(ugeth->p_init_enet_param_shadow =
+ kzalloc(sizeof(struct ucc_geth_init_pram), GFP_KERNEL))) {
ugeth_err
("%s: Can not allocate memory for"
" p_UccInitEnetParamShadows.", __FUNCTION__);
ucc_geth_memclean(ugeth);
return -ENOMEM;
}
- /* Zero out *p_init_enet_param_shadow */
- memset((char *)ugeth->p_init_enet_param_shadow,
- 0, sizeof(struct ucc_geth_init_pram));
/* Fill shadow InitEnet command parameter structure */
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
On Fri, Jan 05, 2007 at 12:33:43PM -0800, Ben Greear wrote: ... > So, I do believe this was the problem we were hitting, and it seems fixed. Congratulations! But I can see one strange thing in vlan.c: /* Must be invoked with RCU read lock (no preempt) */ static struct vlan_group *__vlan_find_group(int real_dev_ifindex) ... * Must be invoked with RCU read lock (no preempt) */ struct net_device *__find_vlan_dev(struct net_device *real_dev, ... But later in this file no sign of disabling preemption for these calls and for hlist_add_head_rcu and hlist_del_rcu. I can't imagine how this works? Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
> -Original Message- > From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED] > Sent: Monday, January 08, 2007 12:27 PM > To: Li Yang-r58472 > Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org > Subject: Re: [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups > > On Mon, Jan 08, 2007 at 11:12:28AM +0800, Li Yang-r58472 wrote: > > > From: Ahmed S. Darwish [mailto:[EMAIL PROTECTED] > > > > > > Hi, > > > A kmalloc casting cleanup patch. > > > Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]> > > [..] > > > > - (u32) (kmalloc((u32) (length + align), > > > - GFP_KERNEL)); > > > + kmalloc((u32) (length + align), GFP_KERNEL); > > > + > > > if (ugeth->tx_bd_ring_offset[j] != 0) > > > ugeth->p_tx_bd_ring[j] = > > [..] > > > > - (u32) (kmalloc((u32) (length + align), GFP_KERNEL)); > > > + kmalloc((u32) (length + align), GFP_KERNEL); > > > > NACK about the 2 clean-ups above. Cast from pointer to integer is > > required here. > > Are the casts from pointer to integer just needed to suppress gcc > warnings or there's something technically important about them ? It is to suppress the warnings. IMHO, most type casts are not technically important but for sanity check. - Leo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
