Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote: > On 10/22, Jarek Poplawski wrote: ... > > OK, I know I'm dumber and dumber everyday, > > You are not alone. I have the same feeling about myself! Feeling is not the same, only true knowledge counts! > > > these all flushes are > > rtnl lockup vulnerable wrt. other work functions, but cancel_work_sync > > looks perfectly fine > > Yes, > > > Then, if by any chance I'm right, something like flush_work_sync > > (or changed flush_scheduled_work, if there is no problem with such > > a change of implementation) could be safely (if it's called without > > locks used by flushed work only) done cancel_work_sync() way, by > > running a work function after try_to_grab_pending() returns 1 > > If this work doesn't rearm itself - yes. (otherwise, the same ->func > can run twice _at the same time_) > > But again, in this case wait_on_work() after try_to_grab_pending() == 1 > doesn't block, so we can just do > > if (cancel_work_sync(w)) > w->func(); Of course, I should have written it much shorter by saying flush_scheduled_work could be done internally just like you suggested! My point is to make this all safer and simpler, so we don't have to remember each time about these differences wrt. locking. Then checking of such patches could be much easier. Unless this current behavior of flush_scheduled_work has any real advantages, worth of this potential unsafety. (Btw. is there any reason to use this with rearming works, anyway?) Thanks, 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: [ANNOUNCE] iproute2-2.6.23
On Wed, Oct 17, 2007 at 09:10:02AM +0800, Herbert Xu wrote:
>
> Any chance you could include the NAT patch for the next release?
>
> [TC]: Add NAT action
>
> This patch adds the parser for the nat action which is used
> for stateless NAT.
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Hi Stephen:
Is there a problem with merging this patch?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: attach additional value to skb
On Mon, Oct 22, 2007 at 10:03:47PM +0200, Yakov Lerner wrote: > I want to add my custom destructor to the skb, the function pointer > to be called at skb destruction time. Will the following work: if I > push address of my_destructor to the > sk-buff->destructor field, and then when my_destructor > is called, I call the (saved) old value of sk-buff->destructor ? > Will this work ? It might, provided nothing else runs after you that will unilaterally change the ->destructor field. I.e., it depends at which point in the skb's life-time you set your hook. Cheers, Muli -- SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007 http://www.haifa.il.ibm.com/Workshops/systor2007/ Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007 - 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 5/7] pci: Export the pci_restore_msi_state() function
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote: > On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote: > > > > On pseries there's a chance it will work for PCI error recovery, but if > > so it's just lucky that firmware has left everything configured the same > > way. > > ? The papr is quite clear that i is up to the OS to restore the msi > state after an eeh error. Perhaps. I see R1-7.3.10.5.1-10, which says we should restore the config space after a reset operation, but after an isolate/unisolate we must recall RTAS. I thought EEH was doing the isolate/unisolate, but if it's just a reset then just blatting the config space back should work. > > Yes I think so. That way we can properly reconfigure via the firmware > > interface. The other option would be to design some new arch hook to do > > resume, but just doing a disable/enable seems simpler to me. > > Err, If you read the code for suspend/resume, it never actually calls > disable/enable (and thus doesn't go to the firmware); it calls > restore_msi_state() function! I know. That was a proposed solution, to explicitly call disable/enable instead of restore_msi_state(). > If suspend/resume needs to call firmware to restore the state, then, > at the moment, suspend/resume is broken. As I mentioned earlier, > I presumed that no powerpc laptops currently use msi-enabled devices, > as otherwise, this would have been flushed out. On _pseries_ suspend/resume with MSI is broken. The other powerpc platforms that implement MSI should be fine, although I don't think anyone's tested them, because they're not laptops and so suspend/resume is not that interesting. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [PATCH] - trivial - Improve appletalk checksum calculation
On Mon, 2007-10-22 at 20:30 -0700, Stephen Hemminger wrote:
> > Corrected fast code is:
> >
> > while (len--) {
> > sum += *data++;
> > sum <<= 1;
> > sum = (((sum & 0x1) >> 16) + sum) & 0x;
> > }
> >
> > At least it is correct on the standalone random data test, and the
> > new code is 30% faster for the cached memory case (13.7 clks/byte vs 18
> > clks/byte).
> Your code looks different...
Both are 16 bit rotate lefts.
Which looks clearer?
-
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] - trivial - Improve appletalk checksum calculation
Joe Perches <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-22 at 18:43 -0700, David Miller wrote:
>> Ok, but again did you test it?
>
> Nope. Stephen Hemminger did in 2003.
But your code differs significantly from Stephen's version.
However, if it is correct it does look like a good improvement.
So please write a simple test program. It can't that bad since
there are only 65536 values to test :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] [POWERPC] ucc_geth: Eliminate compile warnings
> -Original Message- > From: Medve Emilian-EMMEDVE1 > Sent: Monday, October 22, 2007 9:48 PM > To: David Miller > Cc: [EMAIL PROTECTED]; Li Yang-r58472; > netdev@vger.kernel.org; [EMAIL PROTECTED] > Subject: RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings > > Hello David, > > > > No piece of code in the kernel should live in a vacuum. > > > > In order to improve overall code quality, every piece of > driver code > > should avoid assuming things about pointer sizes and things of this > > nature. > > I'm afraid we might be talking about orthogonal issues here. > I actively agree that all code (not only kernel) should be > written up to the coding/quality standards you mention above, > but I see a difference between fixing a warning and making a > driver portable (to 64-bit PowerPCs, to other platforms, > etc.). If there is a kernel todo list somewhere lets add to > it the task to make the ucc_geth more portable. > > > Then the driver can get enabled into the build on every > platform, and > > therefore nobody will break the build of this driver again since it > > will get hit by "allmodconfig" > > et al. builds even on platforms other than the one it is meant for. > > > > This hack fix is not acceptable, really. > > Are you suggesting we leave those warnings there until > somebody decides to fix all the portability issues of this > driver? My patch is a small and insignificant improvement and > not the revolution you're asking for, but is an small > improvement today (I dislike warnings) vs. an improbable big > one in the future. I'd say we can not use our way of doing things while working with the community. The community has to consider the kernel as a whole and thus has its own virtue. The warning has been there for some time. It stays as an indicator that we have something to do to improve the portability. I will work on a patch to fix this portability issue. - 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
Re: [PATCH] - trivial - Improve appletalk checksum calculation
On Mon, 22 Oct 2007 12:36:19 -0700
Joe Perches <[EMAIL PROTECTED]> wrote:
> It's a bit after 2.6.1 now...
>
> Removes unnecessary if, uses 16 bit rotate left.
> Performance improves ~30%
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
> index 7c0b515..1c50f4c 100644
> --- a/net/appletalk/ddp.c
> +++ b/net/appletalk/ddp.c
> @@ -925,15 +925,9 @@ static int atrtr_ioctl(unsigned int cmd, void __user
> *arg)
> static unsigned long atalk_sum_partial(const unsigned char *data,
> int len, unsigned long sum)
> {
> - /* This ought to be unwrapped neatly. I'll trust gcc for now */
> while (len--) {
> - sum += *data;
> - sum <<= 1;
> - if (sum & 0x1) {
> - sum++;
> - sum &= 0x;
> - }
> - data++;
> + sum += *data++;
> + sum = ((sum & 0x8000)>>15) | ((sum & 0x7fff)<<1);
> }
> return sum;
> }
>
The end of the message you quoted was:
> Corrected fast code is:
>
> while (len--) {
> sum += *data++;
> sum <<= 1;
> sum = (((sum & 0x1) >> 16) + sum) & 0x;
> }
>
> At least it is correct on the standalone random data test, and the
> new code is 30% faster for the cached memory case (13.7 clks/byte vs 18
> clks/byte).
Your code looks different...
--
Stephen Hemminger <[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: [PATCH] - trivial - Improve appletalk checksum calculation
On Mon, 2007-10-22 at 17:35 -0700, David Miller wrote: > Your code is rotating bit 15 down by one bit and bits 0-14 up by one > bit. Yes, a 16 bit rotate left. There was a discussion a few years ago: http://oss.sgi.com/archives/netdev/2003-10/msg00734.html >From the spec: Implementers of DDP should treat generating the checksum as an optional feature. The 16-bit DDP checksum is computed as follows: CkSum := 0 ; FOR each datagram byte starting with the byte immediately following this Checksum field REPEAT the following algorithm: CkSum := CkSum + byte; (unsigned addition) Rotate CkSum left one bit, rotating the most significant bit in least significant bit; IF, at the end, CkSum = 0 THEN CkSum := $ (all ones). Reception of a datagram with CkSum equal to 0 implies that a checksum is not performed. - 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] - trivial - Improve appletalk checksum calculation
On Mon, 2007-10-22 at 18:43 -0700, David Miller wrote: > Ok, but again did you test it? Nope. Stephen Hemminger did in 2003. - 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] - trivial - Improve appletalk checksum calculation
From: Joe Perches <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 18:36:28 -0700 > On Mon, 2007-10-22 at 17:35 -0700, David Miller wrote: > > Your code is rotating bit 15 down by one bit and bits 0-14 up by one > > bit. > > Yes, a 16 bit rotate left. > > There was a discussion a few years ago: > http://oss.sgi.com/archives/netdev/2003-10/msg00734.html > > >From the spec: ... > Reception of a datagram with CkSum equal to 0 implies that a checksum is > not performed. Ok, but again did you test 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: [PATCH] wan: new driver retina
A quick look only:
Matti Linnanvuori <[EMAIL PROTECTED]> writes:
> +++ linux-2.6.24/drivers/net/wan/retina.c
> + CHANGES
> + ---
> +
> + v1.0.0 (JK) - May 27, 2003:
> + * Original driver.
> +
> + v1.1.0 (JK) - June, 2003:
> +* final Flexibilis driver
> +
> + v1.2.0: NO_ARP option back again
> +
> +v1.2.1: (JT) - Aug 21, 2003:
> + * Added support for Retina C5400 card including PROC stuff.
> +
> + v1.2.2: (Petri Ahonen) - Sep 19, 2003:
And so on - I'm not sure such logs belong here.
> +#define DRV_NAME "retina"
> +#define DRV_VERSION "1.2.5"
> +#define DRV_RELDATE "November 14, 2003"
Hmm...
> +/* obsolete
> + see retina_noarp_with_ptp
> +define FEPCI_NO_ARP */
If it's obsolete (or rather unused), just drop it.
> +#undef inb
> +#undef inw
> +#undef inl
> +#undef outb
> +#undef outw
> +#undef outl
> +#define inb nonexistent /* force using only 32bit access */
> +#define inw nonexistent /* force using only 32bit access */
> +#define inl(x) le32_to_cpu(readl(x))
> +#define outb nonexistent /* force using only 32bit access */
> +#define outw nonexistent /* force using only 32bit access */
> +#define outl(value, address) writel(cpu_to_le32(value), address)
Any code like that is write-only, why don't just use readl()/
writel() in the actual code?
Are you sure about this cpu_to_le32? readl()/writel() already
preserve the value.
> +#define VMA_OFFSET(vma) ((vma)->vm_pgoff << PAGE_SHIFT)
Not sure about such things in a driver.
> +enum pci_id_flags_bits {
> + /* Set PCI command register bits before calling probe */
> + PCI_USES_IO = 1, PCI_USES_MEM = 2, PCI_USES_MASTER = 4,
> + /* Read and map the single following PCI BAR */
> + PCI_ADDR0 = 0 << 4, PCI_ADDR1 = 1 << 4, PCI_ADDR2 =
> + 2 << 4, PCI_ADDR3 = 3 << 4,
> + PCI_ADDR_64BITS = 0x100, PCI_NO_ACPI_WAKE =
> + 0x200, PCI_NO_MIN_LATENCY = 0x400,
> + PCI_UNUSED_IRQ = 0x800,
> +};
We already have such things in PCI headers, don't we?
> +/* Linux 2.4 appears to drop POINTOPOINT,BROADCAST and NOARP flags
Linux 2.4?
> +/* proc filesystem functions introduced: */
I'm not sure we're adding new /proc files.
Perhaps you should investigate sysfs and friends?
> + case FEPCI_IOCTL_R_SHARED_MEM:
> + DBG_PRINT(" %s: ioctl read shared mem commanded.\n",
> + fepci_NAME);
> + fepci_copy_to_user(arg, ioaddr + FEPCI_SHARED_MEM_OFFSETT,
> +_IOC_SIZE(cmd), 0);
> + break;
> + case FEPCI_IOCTL_W_SHARED_MEM:
> + DBG_PRINT(" %s: ioctl write shared mem commanded.\n",
> + fepci_NAME);
> + fepci_copy_from_user(ioaddr + FEPCI_SHARED_MEM_OFFSETT,
> + arg, _IOC_SIZE(cmd), 0);
> + break;
> + case FEPCI_IOCTL_G_IDENTIFICATION:
> + DBG_PRINT(" %s: IOCTL_G_IDENTIFICATION commanded.\n",
> + fepci_NAME);
> + fepci_copy_to_user(arg,
> +ioaddr + FEPCI_IDENTIFICATION_OFFSETT,
> +_IOC_SIZE(cmd), 1);
> + break;
> + case FEPCI_IOCTL_G_FEATURES:
> + DBG_PRINT(" %s: IOCTL_G_FEATURES commanded.\n", fepci_NAME);
> + fepci_copy_to_user(arg, ioaddr + FEPCI_FEATURES_OFFSETT,
> +_IOC_SIZE(cmd), 1);
> + break;
Are you sure these ioctls are a good idea? Perhaps sysfs attributes
would be much better?
> + if (length == 0) {
> + fp->rx_packets_of_size_0_stream++;
> + } else if (length == 1) {
> + fp->rx_packets_of_size_1_stream++;
> + } else if (length == 2) {
> + fp->rx_packets_of_size_2_stream++;
> + } else if (length == 3) {
> + fp->rx_packets_of_size_3_stream++;
> + } else if (length < 8) {
> + fp->rx_packets_of_size_4_7_stream++;
> + } else if (length < 16) {
...
I think style details are really a personal thing but this would
look much better without the braces.
> + }
> + temp_tx = (temp_tx + 1) & (TX_RING_SIZE - 1);
> + temp_tx_unit = (temp_tx_unit + 1);
> + temp_tx_unit *= temp_tx_unit < fp->units;
> + }
> +
> + return IRQ_HANDLED;
No unhandled IRQ protection anymore?
> +#ifdef FEPCI_POINT_TO_POINT
> +static int is_ptp_interface(struct net_device *dev)
> +{
> + char **p_ptp_if_name = retina_ptp_interfaces;
> + unsigned int i = interfaces;
> + while (i > 0 && *p_ptp_if_name != NULL) {
> + if (!strncmp(dev->name, *p_ptp_if_name, sizeof(dev->name))) {
> + return 1;
> + } else {
> + }
> + p_ptp_if_nam
Re: [PATCH] - trivial - Improve appletalk checksum calculation
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 12:36:19 -0700
> It's a bit after 2.6.1 now...
>
> Removes unnecessary if, uses 16 bit rotate left.
> Performance improves ~30%
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
I'm not sure your transformation is equivalent. Did you
actually test this with appletalk traffic to make sure
the sum is computed correctly? Or more simply, did you
write a test program to send some test data through the
old and new functions?
Here is what I think the problem is:
> static unsigned long atalk_sum_partial(const unsigned char *data,
> int len, unsigned long sum)
> {
> - /* This ought to be unwrapped neatly. I'll trust gcc for now */
> while (len--) {
> - sum += *data;
> - sum <<= 1;
> - if (sum & 0x1) {
> - sum++;
> - sum &= 0x;
> - }
> - data++;
> + sum += *data++;
> + sum = ((sum & 0x8000)>>15) | ((sum & 0x7fff)<<1);
> }
> return sum;
> }
The old code is handling overflow, so that when bit 16 gets set by and
addition, that overflow bit gets cleared and then added back into the
sum.
Your code is rotating bit 15 down by one bit and bits 0-14 up by one
bit, my remedial math knowledge tell me that's likely not the same
thing. :-)
-
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] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Mon, 2007-10-22 at 17:23 -0700, David Miller wrote: > From: [EMAIL PROTECTED] (Linas Vepstas) > Date: Mon, 22 Oct 2007 14:54:52 -0500 > > > As discussed in the other thread, I'll try to set up a patch > > for an arch callback for restoring msi state. >From what it looks like at this stage, pSeries might need to differenciate restoring MSI state after a device reset (PCI error recovery) from restoring MSI state after suspend/resume (if we ever implement that one). The former apparently require manual saving & restoring of the config space bits. (Linas, do you have a pointer to the bit of PAPR spec that specifies that we need to save & restore the MSI message ourselves ?) For the later (suspend/resume), that will definitely not work, or at least, will not be enough, especially with something like suspend to disk, where we'll need to have the firmware reconfigure the MSIs for us (to make sure, among others, that the interrupt controllers are properly configured for MSIs etc...). Ben. - 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 5/7] pci: Export the pci_restore_msi_state() function
> > I don't know why you keep talking about powerpc laptops here ... > > Well, there are Apple laptops, right? Aren't those the "powermac" > platform? Now, I don't know if they support MSI, but if they do, > I get the impression that they might not restore msi state correctly, > after being put into hardware suspend. But perhaps I'm mistaken; > I was simply grepping for various msi-related functions in various > arch subdirectories, comparing x86 to other arches, and noticed > that code that would restore msi state seems to be missing for > most arches and most powerpc platforms. Ah ok, i see. Well, platforms that use write_msi_msg() shouldn't need anything special right ? So only pSeries is an issue here PowerBooks don't indeed have MSI support, though G5's do and some people have been toying around with suspend/resume on them (hibernation only at that stage) but it doesn't matter at this stage. We are specifically talking about pSeries which is the "special" case here. Ben. - 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] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: [EMAIL PROTECTED] (Linas Vepstas) Date: Mon, 22 Oct 2007 14:54:52 -0500 > As discussed in the other thread, I'll try to set up a patch > for an arch callback for restoring msi state. Thank you. - 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 5/7] pci: Export the pci_restore_msi_state() function
On Tue, Oct 23, 2007 at 07:24:27AM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote: > > On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote: > > > > > > On pseries there's a chance it will work for PCI error recovery, but if > > > so it's just lucky that firmware has left everything configured the same > > > way. > > > > ? The papr is quite clear that i is up to the OS to restore the msi > > state after an eeh error. > > Via direct config space access or via firmware change-msi calls ? Direct config space access. It says that the OS is supposed to read the MSI config (after its been set up), save it, and restore it, (via direct config space writes) if the device is ever reset. > I don't know why you keep talking about powerpc laptops here ... Well, there are Apple laptops, right? Aren't those the "powermac" platform? Now, I don't know if they support MSI, but if they do, I get the impression that they might not restore msi state correctly, after being put into hardware suspend. But perhaps I'm mistaken; I was simply grepping for various msi-related functions in various arch subdirectories, comparing x86 to other arches, and noticed that code that would restore msi state seems to be missing for most arches and most powerpc platforms. --linas - 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
[MIPS] MIPSnet: Delete all the useless debugging printks.
Plus minor formatting fixes.
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
---
drivers/net/mipsnet.c | 44
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/drivers/net/mipsnet.c b/drivers/net/mipsnet.c
index 37707a0..aafc3ce 100644
--- a/drivers/net/mipsnet.c
+++ b/drivers/net/mipsnet.c
@@ -30,6 +30,7 @@ static int ioiocpy_frommipsnet(struct net_device *dev,
unsigned char *kdata,
int len)
{
uint32_t available_len = inl(mipsnet_reg_address(dev, rxDataCount));
+
if (available_len < len)
return -EFAULT;
@@ -45,14 +46,8 @@ static inline ssize_t mipsnet_put_todevice(struct net_device
*dev,
int count_to_go = skb->len;
char *buf_ptr = skb->data;
- pr_debug("%s: %s(): telling MIPSNET txDataCount(%d)\n",
-dev->name, __FUNCTION__, skb->len);
-
outl(skb->len, mipsnet_reg_address(dev, txDataCount));
- pr_debug("%s: %s(): sending data to MIPSNET txDataBuffer(%d)\n",
-dev->name, __FUNCTION__, skb->len);
-
for (; count_to_go; buf_ptr++, count_to_go--)
outb(*buf_ptr, mipsnet_reg_address(dev, txDataBuffer));
@@ -64,10 +59,8 @@ static inline ssize_t mipsnet_put_todevice(struct net_device
*dev,
static int mipsnet_xmit(struct sk_buff *skb, struct net_device *dev)
{
- pr_debug("%s:%s(): transmitting %d bytes\n",
-dev->name, __FUNCTION__, skb->len);
-
- /* Only one packet at a time. Once TXDONE interrupt is serviced, the
+ /*
+* Only one packet at a time. Once TXDONE interrupt is serviced, the
* queue will be restarted.
*/
netif_stop_queue(dev);
@@ -94,8 +87,6 @@ static inline ssize_t mipsnet_get_fromdev(struct net_device
*dev, size_t count)
skb->protocol = eth_type_trans(skb, dev);
skb->ip_summed = CHECKSUM_UNNECESSARY;
- pr_debug("%s:%s(): pushing RXed data to kernel\n",
-dev->name, __FUNCTION__);
netif_rx(skb);
dev->stats.rx_packets++;
@@ -112,44 +103,29 @@ static irqreturn_t mipsnet_interrupt(int irq, void
*dev_id)
uint64_t interruptFlags;
if (irq == dev->irq) {
- pr_debug("%s:%s(): irq %d for device\n",
-dev->name, __FUNCTION__, irq);
-
retval = IRQ_HANDLED;
interruptFlags =
inl(mipsnet_reg_address(dev, interruptControl));
- pr_debug("%s:%s(): intCtl=0x%016llx\n", dev->name,
-__FUNCTION__, interruptFlags);
if (interruptFlags & MIPSNET_INTCTL_TXDONE) {
- pr_debug("%s:%s(): got TXDone\n",
-dev->name, __FUNCTION__);
outl(MIPSNET_INTCTL_TXDONE,
mipsnet_reg_address(dev, interruptControl));
/* only one packet at a time, we are done. */
netif_wake_queue(dev);
} else if (interruptFlags & MIPSNET_INTCTL_RXDONE) {
- pr_debug("%s:%s(): got RX data\n",
-dev->name, __FUNCTION__);
mipsnet_get_fromdev(dev,
inl(mipsnet_reg_address(dev, rxDataCount)));
- pr_debug("%s:%s(): clearing RX int\n",
-dev->name, __FUNCTION__);
outl(MIPSNET_INTCTL_RXDONE,
mipsnet_reg_address(dev, interruptControl));
} else if (interruptFlags & MIPSNET_INTCTL_TESTBIT) {
- pr_debug("%s:%s(): got test interrupt\n",
-dev->name, __FUNCTION__);
/*
* TESTBIT is cleared on read.
* And takes effect after a write with 0
*/
outl(0, mipsnet_reg_address(dev, interruptControl));
} else {
- pr_debug("%s:%s(): no valid fags 0x%016llx\n",
-dev->name, __FUNCTION__, interruptFlags);
/* Maybe shared IRQ, just ignore, no clearing. */
retval = IRQ_NONE;
}
@@ -165,22 +141,15 @@ static irqreturn_t mipsnet_interrupt(int irq, void
*dev_id)
static int mipsnet_open(struct net_device *dev)
{
int err;
- pr_debug("%s: mipsnet_open\n", dev->name);
err = request_irq(dev->irq, &mipsnet_interrupt,
IRQF_SHARED, dev->name, (void *) dev);
if (err) {
- pr_debug("%s: %s(): can't get irq %d\n",
-dev->name, __FUNCTION__, dev->irq);
release_region(dev->base_addr, MIPSNET_IO_EXTENT);
return err;
}
- pr_debug("%s: %s(): got IO region at 0x%04
rfkill causes oops with NULL parent device
I'm trying to add support for the bluetooth device on Toshiba laptops
using rfkill. The device is controlled only via software and doesn't
exist at all unless enabled, at which point it appears on the USB bus.
However, doing something along the lines of:
toshiba_bluetooth_rfkill = rfkill_allocate(NULL, RFKILL_TYPE_BLUETOOTH);
if (toshiba_bluetooth_rfkill != NULL) {
result = rfkill_register(toshiba_bluetooth_rfkill);
}
causes an oops; the laptop I'm testing on doesn't have serial so it's
hard to capture the backtrace, but it's the call to device_add in
rfkill_register and there's mention of get_device_parent.
This is with 2.6.23. If rfkill *requires* a parent device then I would
have thought it should return an error if passed NULL in _allocate?
J.
--
] http://www.earth.li/~noodles/ [] I am Elmer of Borg, be vewy quiet, [
] PGP/GPG Key @ the.earth.li [] I'm assimilating wabbits. [
] via keyserver, web or email. [] [
] RSA: 4DC4E7FD / DSA: 5B430367 [] [
-
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 5/7] pci: Export the pci_restore_msi_state() function
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote: > On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote: > > > > On pseries there's a chance it will work for PCI error recovery, but if > > so it's just lucky that firmware has left everything configured the same > > way. > > ? The papr is quite clear that i is up to the OS to restore the msi > state after an eeh error. Via direct config space access or via firmware change-msi calls ? > > Yes I think so. That way we can properly reconfigure via the firmware > > interface. The other option would be to design some new arch hook to do > > resume, but just doing a disable/enable seems simpler to me. > > Err, If you read the code for suspend/resume, it never actually calls > disable/enable (and thus doesn't go to the firmware); it calls > restore_msi_state() function! > > If suspend/resume needs to call firmware to restore the state, then, > at the moment, suspend/resume is broken. As I mentioned earlier, > I presumed that no powerpc laptops currently use msi-enabled devices, > as otherwise, this would have been flushed out. I don't know why you keep talking about powerpc laptops here ... Ben. - 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: attach additional value to skb
On 10/22/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: > 1. How can I attach my 32-bit value to the skb in the > PRE_ROUTNIG hook such that FORWARD and POST_ROUTING > hooks can later access this value from the skb ? > > Can I use sk_buff->cb for that ? In IP layer cb is used by IP as structure inet_skb_param. It is written by ip_rcv_options() (in function ip_rcv_finish()) between PRE_ROUTING and FORWARD/POST_ROUTING. In my opinion, cb is only used when one exclusively owns the skb. Regards, Wenhua - 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: kernel panic when running tcpdump
> > I'm seeing reproducible oops on 2.6.23-mm1 when trying to run tcpdump > > over ppp0 interface. > > Can you please test the latest Linus kernel from > ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/? Sure. > Because all netwrking things which were in 2.6.23-mm1 are now in mainline. > So if mainline is OK then that bug presumably got fixed. You're right. 2.6.23-git17 runs fine so the bug must have been fixed. Regards, Mariusz - 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
[PATCH] sky2: crash on remove
Fix off-by one in remove logic that just got introduced. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- This only occurs in new post 2.6.23 code. --- a/drivers/net/sky2.c2007-10-22 09:38:11.0 -0700 +++ b/drivers/net/sky2.c2007-10-22 12:11:22.0 -0700 @@ -4271,7 +4271,7 @@ static void __devexit sky2_remove(struct del_timer_sync(&hw->watchdog_timer); cancel_work_sync(&hw->restart_work); - for (i = hw->ports; i >= 0; --i) + for (i = hw->ports-1; i >= 0; --i) unregister_netdev(hw->dev[i]); sky2_write32(hw, B0_IMSK, 0); @@ -4289,7 +4289,7 @@ static void __devexit sky2_remove(struct pci_release_regions(pdev); pci_disable_device(pdev); - for (i = hw->ports; i >= 0; --i) + for (i = hw->ports-1; i >= 0; --i) free_netdev(hw->dev[i]); iounmap(hw->regs); - 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
attach additional value to skb
1. How can I attach my 32-bit value to the skb in the PRE_ROUTNIG hook such that FORWARD and POST_ROUTING hooks can later access this value from the skb ? Can I use sk_buff->cb for that ? 2. I want to add my custom destructor to the skb, the function pointer to be called at skb destruction time. Will the following work: if I push address of my_destructor to the sk-buff->destructor field, and then when my_destructor is called, I call the (saved) old value of sk-buff->destructor ? Will this work ? Yakov - 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] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Fri, Oct 19, 2007 at 05:53:08PM -0700, David Miller wrote:
> From: [EMAIL PROTECTED] (Linas Vepstas)
> Date: Fri, 19 Oct 2007 19:46:10 -0500
>
> > FWIW, it looks like not all that many arches do this; the output
> > for grep -r address_hi * is pretty thin. Then, looking at
> > i386/kernel/io_apic.c as an example, one can see that the
> > msi state save happens "by accident" if CONFIG_SMP is enabled;
> > and so its surely broekn on uniprocesor machines.
>
> I don't see this, in all cases write_msi_msg() will transfer
> the given "*msg" to entry->msg by this assignment in
> drivers/pci/msi.c:
>
> void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> {
> ...
> entry->msg = *msg;
> }
>
> So as long as write_msi_msg() is invoked, it will be saved
> properly.
As Michael Ellerman points out, the pseries msi setup is done
by firmware, and so this bit never happens.
As discussed in the other thread, I'll try to set up a patch
for an arch callback for restoring msi state.
-linas
-
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: appletalk bugs
Eric W. Biederman wrote:
> Gabriel C <[EMAIL PROTECTED]> writes:
>
>> Hi,
>>
>> modprobing appletalk on current git gives a warning in dmesg :
>>
>> [38506.600269] sysctl table check failed: /net/appletalk .3.7 procname does
>> not
>> match binary path procname
>
> Oops. My apologies it appears I made a mistake when creating my
> table to check up on sysctl values.
>
> This should fix it.
Yes it does, thx.
>
> Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
> index 3c9ef5a..ed6fe51 100644
> --- a/kernel/sysctl_check.c
> +++ b/kernel/sysctl_check.c
> @@ -731,7 +731,7 @@ static struct trans_ctl_table trans_net_table[] = {
> { NET_UNIX, "unix", trans_net_unix_table },
> { NET_IPV4, "ipv4", trans_net_ipv4_table },
> { NET_IPX, "ipx", trans_net_ipx_table },
> - { NET_ATALK,"atalk",trans_net_atalk_table },
> + { NET_ATALK,"appletalk",trans_net_atalk_table },
> { NET_NETROM, "netrom", trans_net_netrom_table },
> { NET_AX25, "ax25", trans_net_ax25_table },
> { NET_BRIDGE, "bridge", trans_net_bridge_table },
>
-
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
[PATCH] - trivial - Improve appletalk checksum calculation
It's a bit after 2.6.1 now...
Removes unnecessary if, uses 16 bit rotate left.
Performance improves ~30%
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index 7c0b515..1c50f4c 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -925,15 +925,9 @@ static int atrtr_ioctl(unsigned int cmd, void __user *arg)
static unsigned long atalk_sum_partial(const unsigned char *data,
int len, unsigned long sum)
{
- /* This ought to be unwrapped neatly. I'll trust gcc for now */
while (len--) {
- sum += *data;
- sum <<= 1;
- if (sum & 0x1) {
- sum++;
- sum &= 0x;
- }
- data++;
+ sum += *data++;
+ sum = ((sum & 0x8000)>>15) | ((sum & 0x7fff)<<1);
}
return sum;
}
-
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] [net/ipv4]: fib_seq_show function adjustment to get a more sensable output of /proc/net/route
Denis Cheng a écrit : the temporary bf[127] char array is redundant, and the specified width 127 make the output of /proc/net/route include many trailing spaces; since most terminal's cols are less than 127, this made every fib entry occupy two lines, after applied this patch, the output of /proc/net/route is more sensable like this: Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth00001A8C000010 0 0 00FF0 0 0 lo 007F00010 0 0 00FF0 0 0 eth00101A8C000030 0 0 0 0 0 Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> Hum... did you test your patch with many routes declared ? (more than 32 on i386/x86_64) 127 is not a random value, but chosen as a power of two minus 1. PAGE_SIZE is garanted to be a multiple of 128 (127 chars + line_feed) on all arches. So each read() on /proc/net/route delivers PAGE_SIZE/128 lines. With your patch, some lines might be truncated (one every 32 on i386) - 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: [linux-usb-devel] [PATCH] USB: net: Fix asix read transfer buffer allocations.
Oliver Neukum wrote:
Am Montag 22 Oktober 2007 schrieb Valentine Barshak:
static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
{
struct usbnet *dev = netdev_priv(netdev);
+ void *buf;
u16 res;
mutex_lock(&dev->phy_mutex);
asix_set_sw_mii(dev);
+
+ buf = kmalloc(2, GFP_KERNEL);
This is done under lock. Can you allocate the buffer once and reuse it?
Regards
Oliver
I think we can use 2 bytes of the usbnet data buffer for this.
I'll submit a new patch soon.
Thanks,
Valentine.
-
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: kernel panic when running tcpdump
On Mon, 22 Oct 2007 20:40:18 +0200 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: > I'm seeing reproducible oops on 2.6.23-mm1 when trying to run tcpdump > over ppp0 interface. Can you please test the latest Linus kernel from ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/? Because all netwrking things which were in 2.6.23-mm1 are now in mainline. So if mainline is OK then that bug presumably got fixed. 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 1/6] Convert bonding timers to workqueues
Jeff Garzik <[EMAIL PROTECTED]> wrote: [...] >I wasn't aware this brand-new code is a bug fix? > >Normally brand new code needs to be posted and reviewed and committed to a >tree -before- the merge window opens. I had thought this was going in ok, as you'd attempted to apply it after the IPoIB stuff a week or so ago, but it needed to be rebased and you'd had concerns about bisect. In any event, I'd argue it's changes to fix locking bugs (various "sleep with lock held" and ASSERT_RTNLs, e.g., bug 7974 on bugzilla.kernel.org); this isn't a feature add or a refactor just for efficiency. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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: appletalk bugs
Gabriel C <[EMAIL PROTECTED]> writes:
> Hi,
>
> modprobing appletalk on current git gives a warning in dmesg :
>
> [38506.600269] sysctl table check failed: /net/appletalk .3.7 procname does
> not
> match binary path procname
Oops. My apologies it appears I made a mistake when creating my
table to check up on sysctl values.
This should fix it.
Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
---
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 3c9ef5a..ed6fe51 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -731,7 +731,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_UNIX, "unix", trans_net_unix_table },
{ NET_IPV4, "ipv4", trans_net_ipv4_table },
{ NET_IPX, "ipx", trans_net_ipx_table },
- { NET_ATALK,"atalk",trans_net_atalk_table },
+ { NET_ATALK,"appletalk",trans_net_atalk_table },
{ NET_NETROM, "netrom", trans_net_netrom_table },
{ NET_AX25, "ax25", trans_net_ax25_table },
{ NET_BRIDGE, "bridge", trans_net_bridge_table },
-
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
kernel panic when running tcpdump
Hello,
I'm seeing reproducible oops on 2.6.23-mm1 when trying to run tcpdump
over ppp0 interface. To reproduce I type simply:
# tcpdump -i ppp0
and wait a few seconds. I captured two oopses with a bit different stack
trace but EIP always points to packet_rcv():
(gdb) l* 0xc02d7d49
0xc02d7d49 is in packet_rcv (include/linux/netdevice.h:830).
825 static inline int dev_parse_header(const struct sk_buff *skb,
826unsigned char *haddr)
827 {
828 const struct net_device *dev = skb->dev;
829
830 if (!dev->header_ops->parse)
831 return 0;
832 return dev->header_ops->parse(skb, haddr);
833 }
834
Please find pics attached (sorry for poor quality - I can provide you with
better ones
tommorow if needed):
http://tuxland.pl/misc/2.6.23-mm1/DSC00136.JPG
http://tuxland.pl/misc/2.6.23-mm1/DSC00142.JPG
Regards,
Mariusz
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-mm1
# Fri Oct 12 09:13:32 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_KPAGEMAP=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_
Re: [PATCH 1/6] Convert bonding timers to workqueues
Mike Snitzer wrote: Given that Jay rebased and posted updated bonding locking patches on Oct 17 will you be pushing them for inclusion in 2.6.24-rc1? or 2.6.24-rcX? I don't see them queued in your netdev-2.6 tree. These bonding locking issues have been a problem for some time and it would be very good to get them fixed upstream sooner rather than later. I wasn't aware this brand-new code is a bug fix? Normally brand new code needs to be posted and reviewed and committed to a tree -before- the merge window opens. 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
[PATCH] [net/ipv4]: fib_seq_show function adjustment to get a more sensable output of /proc/net/route
the temporary bf[127] char array is redundant, and the specified width 127 make
the output of /proc/net/route include many trailing spaces;
since most terminal's cols are less than 127, this made every fib entry occupy
two lines,
after applied this patch, the output of /proc/net/route is more sensable like
this:
Iface Destination Gateway Flags RefCnt Use Metric Mask
MTU Window IRTT
eth00001A8C000010 0 0
00FF0 0 0
lo 007F00010 0 0
00FF0 0 0
eth00101A8C000030 0 0
0 0 0
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
net/ipv4/fib_hash.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
index 527a6e0..2a4033e 100644
--- a/net/ipv4/fib_hash.c
+++ b/net/ipv4/fib_hash.c
@@ -992,7 +992,6 @@ static unsigned fib_flag_trans(int type, __be32 mask,
struct fib_info *fi)
static int fib_seq_show(struct seq_file *seq, void *v)
{
struct fib_iter_state *iter;
- char bf[128];
__be32 prefix, mask;
unsigned flags;
struct fib_node *f;
@@ -1000,9 +999,9 @@ static int fib_seq_show(struct seq_file *seq, void *v)
struct fib_info *fi;
if (v == SEQ_START_TOKEN) {
- seq_printf(seq, "%-127s\n", "Iface\tDestination\tGateway "
+ seq_printf(seq, "Iface\tDestination\tGateway "
"\tFlags\tRefCnt\tUse\tMetric\tMask\t\tMTU"
- "\tWindow\tIRTT");
+ "\tWindow\tIRTT\n");
goto out;
}
@@ -1014,18 +1013,18 @@ static int fib_seq_show(struct seq_file *seq, void *v)
mask= FZ_MASK(iter->zone);
flags = fib_flag_trans(fa->fa_type, mask, fi);
if (fi)
- snprintf(bf, sizeof(bf),
-"%s\t%08X\t%08X\t%04X\t%d\t%u\t%d\t%08X\t%d\t%u\t%u",
+ seq_printf(seq,
+"%s\t%08X\t%08X\t%04X\t%d\t%u\t%d\t%08X\t%d\t%u\t%u\n",
fi->fib_dev ? fi->fib_dev->name : "*", prefix,
fi->fib_nh->nh_gw, flags, 0, 0, fi->fib_priority,
mask, (fi->fib_advmss ? fi->fib_advmss + 40 : 0),
fi->fib_window,
fi->fib_rtt >> 3);
else
- snprintf(bf, sizeof(bf),
-"*\t%08X\t%08X\t%04X\t%d\t%u\t%d\t%08X\t%d\t%u\t%u",
+ seq_printf(seq,
+"*\t%08X\t%08X\t%04X\t%d\t%u\t%d\t%08X\t%d\t%u\t%u\n",
prefix, 0, flags, 0, 0, 0, mask, 0, 0, 0);
- seq_printf(seq, "%-127s\n", bf);
+
out:
return 0;
}
--
1.5.3.4
-
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 5/7] pci: Export the pci_restore_msi_state() function
On Sun, Oct 21, 2007 at 09:45:20PM -0700, David Miller wrote: > > The core issue is that the ARCH level MSI code invokes > write_msi_msg(), not the generic code, exactly because there > are platform level issues wherein the firmware is the only > legal way to write the MSI settings in PCI config space. > > However, the MSI state restore code was not architected similarly. It > does the write_msi_msg() directly, instead of letting platform level > code is in ARCH hooks. Yes, exactly. > Therefore I think we need to attack this in two stages: > > 1) First changeset moves the write_msi_msg() call currently in >__pci_restore_msi_state() into an ARCH overridable handler. > >This would allow powerpc to deal with this properly. Yes! I'll try to put together a patch later today, if I can get a fabled "round tuit". >pci_restor_msi_state() can get exported to modules in this >change OK. > 2) The Tigon3 error recovery changes, as they were. > > But I have to ask, can anyone see how e1000 handles MSI properly > in it's PCI error support? It doesn't. None of them do. :-( I didn't get access to msi-capable hardware until a few weeks ago; that's why this is coming up just now. --linas - 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 5/7] pci: Export the pci_restore_msi_state() function
On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote: > > On pseries there's a chance it will work for PCI error recovery, but if > so it's just lucky that firmware has left everything configured the same > way. ? The papr is quite clear that i is up to the OS to restore the msi state after an eeh error. > Yes I think so. That way we can properly reconfigure via the firmware > interface. The other option would be to design some new arch hook to do > resume, but just doing a disable/enable seems simpler to me. Err, If you read the code for suspend/resume, it never actually calls disable/enable (and thus doesn't go to the firmware); it calls restore_msi_state() function! If suspend/resume needs to call firmware to restore the state, then, at the moment, suspend/resume is broken. As I mentioned earlier, I presumed that no powerpc laptops currently use msi-enabled devices, as otherwise, this would have been flushed out. --linas - 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: [Bugme-new] [Bug 9208] New: Oops on sky2, delete_module causes SIGKILL
On Mon, 22 Oct 2007 06:58:37 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9208 > >Summary: Oops on sky2, delete_module causes SIGKILL >Product: Drivers >Version: 2.5 > KernelVersion: linux-2.6.23-git17 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Network > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur: > linux-2.6.23-git-13 > > Distribution: > gentoo > > Hardware Environment: > macbook revision2 > > Software Environment: > gcc-4.2.2, glibc-2.6.1-r0, 2.6.23-git14...17 x86_64 > sys-devel/binutils: 2.18-r1 > sys-apps/module-init-tools-3.2.2-r3 > > Problem Description: > on dmesg > > sky2 eth0: enabling interface > sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both > hda: selected mode 0x44 > appletouch: incomplete data package (first byte: 2, length: 4). > Unable to handle kernel NULL pointer dereference at 03b0 RIP: > [] unregister_netdevice+0x21/0x180 > PGD abb2067 PUD 3ee9067 PMD 0 > Oops: [1] SMP > CPU 1 > Modules linked in: snd_hda_intel snd_pcm snd_page_alloc i2c_i801 sky2 > Pid: 4791, comm: modprobe Not tainted 2.6.23-git17 #2 > RIP: 0010:[] [] > unregister_netdevice+0x21/0x180 > RSP: 0018:81000a9addf8 EFLAGS: 00010246 > RAX: RBX: RCX: > RDX: RSI: RDI: 80639050 > RBP: 810003da5e80 R08: R09: 102a > R10: R11: 8029f6a0 R12: 8100022c0800 > R13: 8800c440 R14: 8800c498 R15: 8800c490 > FS: 2b16510c3b00() GS:810002076e40() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 03b0 CR3: 0aaf4000 CR4: 26e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process modprobe (pid: 4791, threadinfo 81000a9ac000, task > 810003e1a740) > Stack: 804ae2d1 88004670 > 8100022c0870 8100022c0800 8100022c6870 80393a4c > 8800c440 8100022c0870 8800c440 803f91c2 > Call Trace: > [] unregister_netdev+0x11/0x20 > [] :sky2:sky2_remove+0x40/0xf0 > [] pci_device_remove+0x2c/0x60 > [] __device_release_driver+0x82/0xc0 > [] driver_detach+0xf5/0x100 > [] bus_remove_driver+0x8d/0xb0 > [] pci_unregister_driver+0x18/0x90 > [] sys_delete_module+0x14d/0x1e0 > [] __up_write+0x22/0x130 > [] system_call+0x7e/0x83 > > > Code: 8b 83 b0 03 00 00 85 c0 75 39 48 89 da 48 89 de 48 c7 c7 20 > RIP [] unregister_netdevice+0x21/0x180 > RSP > CR2: 03b0 > > > Steps to reproduce: > rmmod sky2 > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. - 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 5/7] pci: Export the pci_restore_msi_state() function
On Sun, Oct 21, 2007 at 04:21:31PM -0700, David Miller wrote: > From: "Matt Carlson" <[EMAIL PROTECTED]> > Date: Fri, 19 Oct 2007 14:36:56 -0700 > > > This patch exports the pci_restore_msi_state() function. This function > > is needed to restore the MSI state during PCI error recovery. > > > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> > > I'm not so sure about this. > > Perhaps, instead, you should do a pci_msi_disable() and > pci_msi_enable() in the error detection and recovery sequence. > > Or, alternatively, save/restore those MSI registers by hand. > > I'm trying to figure out how the E1000 driver handles this correctly, > but I can't see it just by reading it over quickly. The e1000 and the ixgb are broken as well ... right now, any driver that uses msi together with the pci error recovery will fail to get recovered correctly. There are several distinct bugs; one is that, msi state is not being restored; and the call to pci_restore_msi_state() was supposed to aid with that. I'd rather not use pci_msi_disable(), because that has the side-effect of enabling legacy interupts; I'm concerned that this will have the potential for causing havoc of all sorts. --linas - 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] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
On 10/22, Jarek Poplawski wrote: > > On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote: > > On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote: > > > On 10/18, Jarek Poplawski wrote: > > > > > > > > +/** > > > > + * flush_work_sync - block until a work_struct's callback has > > > > terminated > > > > > > ^^^ > > > Hmm... > > > > > > > + * Similar to cancel_work_sync() but will only busy wait (without > > > > cancel) > > > > + * if the work is queued. > > > > > > Yes, it won't block, but will spin in busy-wait loop until all other works > > > scheduled before this work are finished. Not good. After that it really > > > blocks waiting for this work to complete. > > > > > > And I am a bit confused. We can't use flush_workqueue() because some of > > > the > > > queued work_structs may take rtnl_lock, yes? But in that case we can't use > > > the new flush_work_sync() helper as well, no? > > OK, I know I'm dumber and dumber everyday, You are not alone. I have the same feeling about myself! > these all flushes are > rtnl lockup vulnerable wrt. other work functions, but cancel_work_sync > looks perfectly fine Yes, > Then, if by any chance I'm right, something like flush_work_sync > (or changed flush_scheduled_work, if there is no problem with such > a change of implementation) could be safely (if it's called without > locks used by flushed work only) done cancel_work_sync() way, by > running a work function after try_to_grab_pending() returns 1 If this work doesn't rearm itself - yes. (otherwise, the same ->func can run twice _at the same time_) But again, in this case wait_on_work() after try_to_grab_pending() == 1 doesn't block, so we can just do if (cancel_work_sync(w)) w->func(); Oleg. - 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: [linux-usb-devel] [PATCH] USB: net: Fix asix read transfer buffer allocations.
Am Montag 22 Oktober 2007 schrieb Valentine Barshak:
> static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
> {
> struct usbnet *dev = netdev_priv(netdev);
> + void *buf;
> u16 res;
>
> mutex_lock(&dev->phy_mutex);
> asix_set_sw_mii(dev);
> +
> + buf = kmalloc(2, GFP_KERNEL);
This is done under lock. Can you allocate the buffer once and reuse it?
Regards
Oliver
-
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
[PATCH] defxx.c: dfx_bus_init() is __devexit not __devinit
The dfx_bus_uninit() call is called from dfx_unregister() which is
__devexit and which is ultimately the ->remove call for the device.
Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---
It should be obvious. Please apply.
Maciej
patch-mips-2.6.23-rc5-20070904-defxx-devexit-0
diff -up --recursive --new-file
linux-mips-2.6.23-rc5-20070904.macro/drivers/net/defxx.c
linux-mips-2.6.23-rc5-20070904/drivers/net/defxx.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/net/defxx.c2007-09-04
04:55:41.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/net/defxx.c 2007-10-12
00:21:35.0 +
@@ -806,7 +806,7 @@ static void __devinit dfx_bus_init(struc
* Interrupts are disabled at the adapter bus-specific logic.
*/
-static void __devinit dfx_bus_uninit(struct net_device *dev)
+static void __devexit dfx_bus_uninit(struct net_device *dev)
{
DFX_board_t *bp = netdev_priv(dev);
struct device *bdev = bp->bus_dev;
-
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: CC2420 (802.15.4) Speed Issue
Michael Whyte wrote: Hi Guys, I'm currently writing my first bit of Linux kernel code so be gentle. It's a driver for TI CC2420 802.15.4 radio and I'm observing strange behavior. I am currently testing just by transferring a ~300kb file over HTTP between two of these devices. Into which revision of the kernel are you inserting your driver? The strange thing is, when ever you start the transfer it starts humming along at 5k/s which is not far off what I'd expect these devices to achieve, then at some random point along the transfer or sometimes not at all... it suddenly drops fairly deterministically to 150byte/s and finishes the transfer at that speed, maybe rising to 170bytes/s by the end of the transfer is I'm lucky. I don't really know where to start looking to solve the problem, it seems everything is functioning as it should at least some of the time as in some cases it will complete the whole transfer at the 5k/s speed. Is it just tcp throttling very harshly (i.e. 50x) when it loses a packet? See below re packet traces and stats. Is it the Xscale chip scaling down the CPU frequency mid-transfer, I've got no idea how to check this? Knowing nothing about Xscale I'd wonder if there wasn't a regsiter on it somewhere you could query for its current CPU frequency. Otherwise, if the CPU is slowing down, presumably that should show-up as a change in power consumption for the whole device which you could in theory measure with a power meter. It is some sort of resonance affect happening with the two radios CCA although I'm not seeing any CCA timeouts. Can any one give any hints what to play with or where to look to try find the cause and get the transfers to run reliabily without the sudden bottoming out of speeds? (if you stop the transfer and initiate a new one immediately it will start at full speed again) Might also check the netstat statistics for TCP - netstat -s -t. You might find that at the point where the performance drops there was a non-trivial packet loss event taking the congestion window down. Should show-up in a packet trace as well. If you want to eliminate any possibility of http server issues (as close to epsilon as they probably are) you could use a netperf TCP_CRR test: netperf -H -t TCP_CRR -l -- -r 256,300K You could also add some -s and -S options to the end of that to constrain the TCP windows which might be an interesting experiment. rick jones - 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: [RFC] remove netpoll receive code
[annoyed as ever about never being cc:ed on this stuff] On Wed, Oct 17, 2007 at 01:21:31PM -0700, Stephen Hemminger wrote: > The netpoll receive code is: > 1. Not used by any in-tree features, it is used by kgdb-over-ether. And various crashdump over network tools. > 2. A nice hook for people doing nasty things like private binary network > stacks or rootkits. It's a completely useless hook for a binary network stack. It only supports UDP and only point to point. And it will have crap performance. It's much less useful here than, say, TUN/TAP. It doesn't buy anything for a rootkit either, which will continue to trivially hide servers in userspace as they already do. This point is completely FUD. > 3. Unsecured by any of the normal firewalling code. This is correct. It also applies to the TX side of things. The point, of course, is to bypass as much of the stack as possible so that when the kernel crashes, we're more likely to actually get our netpoll data. > I propose that we take out all the whole netpoll rx path. If/when > kgdb gets submitted a better and alternative receive path can be > added. Let's hear about this better alternative first, shall we? I for one am a little skeptical of its existence. Going through a larger fraction of the network stack, running softirqs, etc., are all big (potentially fatal) steps backward from the point of view of a debugger. -- Mathematics is the supreme nostalgia of our time. - 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: Regression in current git - Network Manager fails (bisected)
On Mon, 2007-10-22 at 13:22 +0400, Denis V. Lunev wrote: > We have spent some time with the problem with Alexey and there are no > guesses for now. > > Is it possible to name exact version of Network Manager and all > libraries related + provide us an output of strace with full buffers > send/received from netlink. Something like > strace -v -x -s 32768 NM uses netlink in two places; libnl (from Thomas Graf) and some custom code for listening for interface up/down events and wireless events. It looks like that code comes from libnl's lib/handlers.c where it thinks the received message is invalid. I'm pretty sure the code that checks carrier status of the device isn't libnl code; so maybe the error message (which should get fixed of course) isn't in the same path as the link detection. The link detection comes from src/nm-netlink-monitor.c, so maybe we should look at debugging there. Dan > Regards, > Den > > Joseph Fannin wrote: > > Network Manager (the freedesktop.org one) fails to work with Linus's > > current git on a couple of different boxes I have here. All the boxes > > have different NIC types, with different drivers. > > > > I've bisected it down to cd40b7d3983c708aabe3d3008ec64ffce56d33b0 , > > "[NET]: make netlink user -> kernel interface synchronious". I've > > double checked this by testing the kernel as of the immediately > > previous commit; Network Manager works with that one, as it did on all > > my machines in 2.6.23-mm1. > > > > The netlink change seems to confuse N-M, and it somehow decides that > > there's no link beat, so doesn't try to bring up the interface. If I > > run "ifconfig eth0 up", N-M will decide there's a carrier after all > > and takes over. Ethtool detects the link state correctly even with > > the interface down. > > > > If I down the interface again with ifconfig, N-M brings it right back > > up without a problem, but if I kill N-M, it'll down the interface > > before it exits, and fail in the same way as before when restarted. > > > > N-M also emits this error: > > > > "-- Error: Invalid message: type=DONE length=20 flags= > > sequence-nr=1193012574 pid=1185943630" > > > > ...which it doesn't do on kernels where it works normally. > > strace'ing NetworkManager shows that it prints that message just after > > talking over a netlink socket. > > > > Networking otherwise works fine here with the latest git and N-M, if I > > use the ifconfig "trick" to get the link up. > > > > -- > > Joseph Fannin > > [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 - 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
[PATCH] Explicitly call fib_get_table() in fib_frontend.c
In case the "multiple tables" config option is y, the ip_fib_local_table
is not a variable, but a macro, that calls fib_get_table(RT_TABLE_LOCAL).
Some code uses this "variable" *3* times in one place, thus implicitly
making 3 calls. Fix it.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 78b514b..6012390 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -128,13 +128,14 @@ struct net_device * ip_dev_find(__be32 addr)
struct flowi fl = { .nl_u = { .ip4_u = { .daddr = addr } } };
struct fib_result res;
struct net_device *dev = NULL;
+ struct fib_table *local_table;
#ifdef CONFIG_IP_MULTIPLE_TABLES
res.r = NULL;
#endif
- if (!ip_fib_local_table ||
- ip_fib_local_table->tb_lookup(ip_fib_local_table, &fl, &res))
+ local_table = fib_get_table(RT_TABLE_LOCAL);
+ if (!local_table || local_table->tb_lookup(local_table, &fl, &res))
return NULL;
if (res.type != RTN_LOCAL)
goto out;
@@ -152,6 +153,7 @@ unsigned inet_addr_type(__be32 addr)
struct flowifl = { .nl_u = { .ip4_u = { .daddr = addr } } };
struct fib_result res;
unsigned ret = RTN_BROADCAST;
+ struct fib_table *local_table;
if (ZERONET(addr) || BADCLASS(addr))
return RTN_BROADCAST;
@@ -162,10 +164,10 @@ unsigned inet_addr_type(__be32 addr)
res.r = NULL;
#endif
- if (ip_fib_local_table) {
+ local_table = fib_get_table(RT_TABLE_LOCAL);
+ if (local_table) {
ret = RTN_UNICAST;
- if (!ip_fib_local_table->tb_lookup(ip_fib_local_table,
- &fl, &res)) {
+ if (!local_table->tb_lookup(local_table, &fl, &res)) {
ret = res.type;
fib_res_put(&res);
}
-
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
[PATCH] USB: net: Fix asix read transfer buffer allocations.
On systems with noncoherent cache, allocating dma buffers
on the stack for USB IN transfers causes kernel crash,
because usb map_urb_for_dma() code calls dma_map_single(),
that invalidates data cache for DMA_FROM_DEVICE transfer direction
and causes stack data loss if transfer size is less than cache line
and not cache-line aligned. This patch makes asix usb network
driver allocate USB IN transfer buffers with kmalloc instead of
directly using variables on stack.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/usb/asix.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/usb/asix.c
linux-2.6/drivers/net/usb/asix.c
--- linux-2.6.orig/drivers/net/usb/asix.c 2007-10-19 20:10:18.0
+0400
+++ linux-2.6/drivers/net/usb/asix.c2007-10-19 20:35:33.0 +0400
@@ -568,12 +568,20 @@ static void asix_set_multicast(struct ne
static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
{
struct usbnet *dev = netdev_priv(netdev);
+ void *buf;
u16 res;
mutex_lock(&dev->phy_mutex);
asix_set_sw_mii(dev);
+
+ buf = kmalloc(2, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
- (__u16)loc, 2, (u16 *)&res);
+ (__u16)loc, 2, buf);
+ res = *((u16 *)buf);
+ kfree(buf);
+
asix_set_hw_mii(dev);
mutex_unlock(&dev->phy_mutex);
@@ -622,13 +630,22 @@ static void
asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
{
struct usbnet *dev = netdev_priv(net);
+ void *buf;
u8 opt;
- if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
+ buf = kmalloc(1, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, buf) < 0) {
wolinfo->supported = 0;
wolinfo->wolopts = 0;
+ kfree(buf);
return;
}
+ opt = *((u8 *)buf);
+ kfree(buf);
+
wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
wolinfo->wolopts = 0;
if (opt & AX_MONITOR_MODE) {
-
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
[PATCH 3/3] Use BUILD_BUG_ON in net/core/flowi.c
Instead of ugly extern not-existing function. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/net/core/flow.c b/net/core/flow.c index 0ab5234..3ed2b4b 100644 --- a/net/core/flow.c +++ b/net/core/flow.c @@ -142,8 +142,6 @@ typedef u64 flow_compare_t; typedef u32 flow_compare_t; #endif -extern void flowi_is_missized(void); - /* I hear what you're saying, use memcmp. But memcmp cannot make * important assumptions that we can here, such as alignment and * constant size. @@ -153,8 +151,7 @@ static int flow_key_compare(struct flowi *key1, struct flowi *key2) flow_compare_t *k1, *k1_lim, *k2; const int n_elem = sizeof(struct flowi) / sizeof(flow_compare_t); - if (sizeof(struct flowi) % sizeof(flow_compare_t)) - flowi_is_missized(); + BUILD_BUG_ON(sizeof(struct flowi) % sizeof(flow_compare_t)); k1 = (flow_compare_t *) key1; k1_lim = k1 + n_elem; -- 1.5.3.4 - 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
[PATCH 2/3] Remove in-code externs for some functions from net/core/dev.c
Inconsistent prototype and real type for functions may have worse consequences, than those for variables, so move them into a header. Since they are used privately in net/core, make this file reside in the same place. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/net/core/dev.c b/net/core/dev.c index 8726589..9ea3665 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -120,6 +120,8 @@ #include #include +#include "net-sysfs.h" + /* * The list of packet types we will receive (as opposed to discard) * and the routines to invoke. @@ -249,10 +251,6 @@ static RAW_NOTIFIER_HEAD(netdev_chain); DEFINE_PER_CPU(struct softnet_data, softnet_data); -extern int netdev_kobject_init(void); -extern int netdev_register_kobject(struct net_device *); -extern void netdev_unregister_kobject(struct net_device *); - #ifdef CONFIG_DEBUG_LOCK_ALLOC /* * register_netdevice() inits dev->_xmit_lock and sets lockdep class diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c index 6628e45..61ead1d 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -18,6 +18,8 @@ #include #include +#include "net-sysfs.h" + #ifdef CONFIG_SYSFS static const char fmt_hex[] = "%#x\n"; static const char fmt_long_hex[] = "%#lx\n"; diff --git a/net/core/net-sysfs.h b/net/core/net-sysfs.h new file mode 100644 index 000..a41683d --- /dev/null +++ b/net/core/net-sysfs.h @@ -0,0 +1,8 @@ +#ifndef __NET_SYSFS_H__ +#define __NET_SYSFS_H__ + +int netdev_kobject_init(void); +int netdev_register_kobject(struct net_device *); +void netdev_unregister_kobject(struct net_device *); + +#endif -- 1.5.3.4 - 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
[PATCH 1/3] Don't declare extern variables in net/core/sysctl_net_core.c
Some are already declared in include/linux/netdevice.h, while
some others (xfrm ones) need to be declared.
The driver/net/rrunner.c just uses same extern as well, so
cleanup it also.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/rrunner.c b/drivers/net/rrunner.c
index 19152f5..b822859 100644
--- a/drivers/net/rrunner.c
+++ b/drivers/net/rrunner.c
@@ -79,12 +79,10 @@ static char version[] __devinitdata = "rrunner.c: v0.50
11/11/2002 Jes Sorensen
*/
/*
- * These are checked at init time to see if they are at least 256KB
- * and increased to 256KB if they are not. This is done to avoid ending
- * up with socket buffers smaller than the MTU size,
+ * sysctl_[wr]mem_max are checked at init time to see if they are at
+ * least 256KB and increased to 256KB if they are not. This is done to
+ * avoid ending up with socket buffers smaller than the MTU size,
*/
-extern __u32 sysctl_wmem_max;
-extern __u32 sysctl_rmem_max;
static int __devinit rr_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 688f6f5..58dfa82 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -37,6 +37,8 @@
extern struct sock *xfrm_nl;
extern u32 sysctl_xfrm_aevent_etime;
extern u32 sysctl_xfrm_aevent_rseqth;
+extern int sysctl_xfrm_larval_drop;
+extern u32 sysctl_xfrm_acq_expires;
extern struct mutex xfrm_cfg_mutex;
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 6d5ea97..113cc72 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -9,25 +9,12 @@
#include
#include
#include
+#include
#include
+#include
#ifdef CONFIG_SYSCTL
-extern int netdev_max_backlog;
-extern int weight_p;
-
-extern __u32 sysctl_wmem_max;
-extern __u32 sysctl_rmem_max;
-
-extern int sysctl_core_destroy_delay;
-
-#ifdef CONFIG_XFRM
-extern u32 sysctl_xfrm_aevent_etime;
-extern u32 sysctl_xfrm_aevent_rseqth;
-extern int sysctl_xfrm_larval_drop;
-extern u32 sysctl_xfrm_acq_expires;
-#endif
-
ctl_table core_table[] = {
#ifdef CONFIG_NET
{
--
1.5.3.4
-
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: appletalk bugs
Nick wrote: [ restoring CC ] > Fascinating ... Are you using chooser or NetInfo? No I don't. I fact I don't even know why that module got loaded. > On Mon, 2007-10-22 at 16:19 +0200, Gabriel C wrote: >> Hi, >> >> modprobing appletalk on current git gives a warning in dmesg : >> >> [38506.600269] sysctl table check failed: /net/appletalk .3.7 procname does >> not match binary path procname >> >> on rmmod appletalk I get an Oops : >> >> >> [38541.525258] BUG: unable to handle kernel NULL pointer dereference at >> virtual address 000c >> [38541.525266] printing eip: c011d4f0 *pde = >> [38541.525274] Oops: [#1] PREEMPT SMP >> [38541.525282] Modules linked in: appletalk psnap llc pc87360 hwmon_vid >> eeprom adm1021 sr_mod shpchp pci_hotplug iTCO_wdt iTCO_vendor_support >> intel_agp i82860_edac i2c_i801 edac_core cdrom agpgart 3c59x mii ext4dev >> jbd2 crc16 loop lp parport_pc parport evdev >> [38541.525312] >> [38541.525316] Pid: 28887, comm: rmmod Not tainted (2.6.23-gcfa76f02 #341) >> [38541.525321] EIP: 0060:[] EFLAGS: 00010202 CPU: 0 >> [38541.525334] EIP is at unregister_sysctl_table+0x11/0x70 >> [38541.525339] EAX: 0001 EBX: e8ef2180 ECX: 0002 EDX: >> [38541.525343] ESI: EDI: 0880 EBP: cc094000 ESP: cc095f38 >> [38541.525347] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > >> [38541.525389] Call Trace: >> [38541.525395] [] atalk_exit+0x5/0x4b [appletalk] >> [38541.525410] [] sys_delete_module+0x187/0x1b5 >> [38541.525420] [] do_page_fault+0x18b/0x51a >> [38541.525426] [] do_munmap+0x19b/0x1b4 >> [38541.525437] [] sysenter_past_esp+0x5f/0x85 > > > - 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: about multiple network interface
thank you very much.. 2007/10/22, Evgeniy Polyakov <[EMAIL PROTECTED]>: > On Mon, Oct 22, 2007 at 10:09:38AM +0800, wit ([EMAIL PROTECTED]) wrote: > > But this does work until I add a ifcfg-eth0 in > > sysconfig/network-script with the following content: > > DEVICE=eth0 > > ONBOOT=yes > > > > What is the relationship between these two files? And sometimes, I see > > It depends on your distro - when script calls "modprobe $DEVICE" > this ends up with modprobe eth0, which will check modprobe.conf. > > > this message: > > Bringing up interface eth0: e100 device does not seem to be present, > > delaying e > > th0 initialization. > > Why?? > > This is fedora, right? Check you kernel config, scripts and whatever is > needed to load driver first and only then try to setup an address. > > -- >Evgeniy Polyakov > - 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] wan: new driver retina
On Mon, 22 Oct 2007 04:14:57 -0700 (PDT) Matti Linnanvuori wrote: > From: Matti Linnanvuori <[EMAIL PROTECTED]> > > Retina G.703 and G.SHDSL driver. > > Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> > --- Hi, Just a few basic questions... I'm not reviewing any of the code parts. > Fixed Kconfig and the body of the explanation. > > diff -Napur > linux-2.6.23/drivers/net/wan/Kconfig > linux-2.6.24/drivers/net/wan/Kconfig > --- linux-2.6.23/drivers/net/wan/Kconfig 2007-10-09 23:31:38.0 > +0300 > +++ linux-2.6.24/drivers/net/wan/Kconfig 2007-10-22 13:54:55.383644167 > +0300 > @@ -494,4 +494,15 @@ config SBNI_MULTILINE > > If unsure, say N. > > +config RETINA > + tristate "Retina support" > + depends on m && PCI > + help > + Driver for Retina C5400 and E2200 network cards, which > + support G.703, G.SHDSL, Ethernet encapsulation and PCI. > + > + The driver will be compiled as a module: the > + module will be called retina. Why is the driver restricted/limited to module only? > + > endif # WAN > diff -Napur linux-2.6.23/drivers/net/wan/retina.c > linux-2.6.24/drivers/net/wan/retina.c > --- linux-2.6.23/drivers/net/wan/retina.c 1970-01-01 02:00:00.0 > +0200 > +++ linux-2.6.24/drivers/net/wan/retina.c 2007-10-22 12:01:44.856033562 > +0300 > @@ -0,0 +1,4503 @@ > +/* V1.2.4 */ > + > +/* retina.c: */ > + > + > +#define DRV_NAME "retina" > +#define DRV_VERSION "1.2.5" > +#define DRV_RELDATE "November 14, 2003" huh? > +#if !defined(__OPTIMIZE__) > +#warning You must compile this file with correct options. > +#warning See the last lines of the source file. > +#error You have to compile this driver with "-O". > +#endif What defines __OPTIMIZE__ in the kernel build environment? > diff -Napur linux-2.6.23/drivers/net/wan/retina.h > linux-2.6.24/drivers/net/wan/retina.h > --- linux-2.6.23/drivers/net/wan/retina.h 1970-01-01 02:00:00.0 > +0200 > +++ linux-2.6.24/drivers/net/wan/retina.h 2007-10-22 12:01:44.856033562 > +0300 > @@ -0,0 +1,164 @@ > diff -Napur linux-2.6.23/MAINTAINERS linux-2.6.24/MAINTAINERS > --- linux-2.6.23/MAINTAINERS 2007-10-09 23:31:38.0 +0300 > +++ linux-2.6.24/MAINTAINERS 2007-10-22 11:50:13.190983316 +0300 > @@ -3149,6 +3149,11 @@ L: [EMAIL PROTECTED] > W: http://www.namesys.com > S: Supported > > +RETINA DRIVER > +P: Matti Linnanvuori > +M: [EMAIL PROTECTED] and what mailing list? > +S: Supported > + > ROCKETPORT DRIVER > P: Comtrol Corp. > W: http://www.comtrol.com --- ~Randy - 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: e100 problems in .23rc8 ?
David Mack wrote: > Then I got very, very lucky, since I have successfully rebooted > 2.6.23.1-23.fc8 four times (zero panics) and this is the first time a > 2.6.23 kernel has not panicked on me in months. > > This does not fill me with confidence in the theory that the panics I've > been seeing are due to a race condition. I'll agree with the testing results, at least. I booted successfully *60* times with 2.6.23.1-23.fc8, booting the stock F8test3 kernel would oops every 5 or 6 boots. It may well be a race, but if so something is apparently opening/closing the window on us! :) -Eric - 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 1/6] Convert bonding timers to workqueues
On 10/15/07, Jay Vosburgh <[EMAIL PROTECTED]> wrote: > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > >Jay Vosburgh wrote: > >> Convert bonding timers to workqueues. This converts the various > >> monitor functions to run in periodic work queues instead of timers. This > >> patch introduces the framework and convers the calls, but does not resolve > >> various locking issues, and does not stand alone. > >> > >> Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]> > >> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]> > > > >"does not stand alone" == it is not bisectable? That's a problem. > > The patch will compile fine (this is true for any point in the > series), but it's possible for bonding to deadlock or misbehave when > doing certain operations. Those problems are addressed in the later > patches. > > I didn't want to just vomit out one big mega-patch that has the > whole set of changes, because that's harder to understand, and the later > patches generally address discrete issues. > > Does that make you more or less nervous about its bisectability? > I can repost the whole thing as a big blob if that's what you'd prefer. > > >Anyway, we have more fun fish to fry: after applying the IPoIB bonding > >patchset, this no longer applies... > > Yah, I'll rebase it (once I know your blob vs. not-blob > preference). I wasn't sure how long the IPoIB mystery bug hunt was > going to take. Jeff, Given that Jay rebased and posted updated bonding locking patches on Oct 17 will you be pushing them for inclusion in 2.6.24-rc1? or 2.6.24-rcX? I don't see them queued in your netdev-2.6 tree. These bonding locking issues have been a problem for some time and it would be very good to get them fixed upstream sooner rather than later. thanks, Mike - 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: e100 problems in .23rc8 ?
On 10/18/2007 01:59 PM, Kok, Auke wrote: > David Mack wrote: >> It appears that the needed e100 fix made it into the Fedora >> 2.6.23.1-23.fc8 kernel. Boots reliably now. >> >> Huge thanks and great work, guys. > > > DaveJ, I didn't push anything upstream. Can you verify this now works? > One of our users just posted this: We observed the same panic on a Dell Dimension 5150 (E510), although not limited to warm boots. We noticed that the following trace is possible: - when starting the interface, e100_up() gets called - it calls e100_hw_init(), which disables e100 IRQ generation (e100_disable_irq()) - it registers the interrupt handler - the interrupt handler (e100_intr()) gets called - this happens because the IRQ line is shared with another device (in this case, the SATA controller) - the interrupt handler examines the stat_ack register of the interface: even though interrupts are disabled, an event is indicated and the interrupt handler proceeds - the interrupt handler calls netif_rx_schedule_prep(), which sets the __LINK_STATE_RX_SCHED bit, and __netif_rx_schedule(), which adds the interface to the poll list - when the interrupt handler returns, e100_up() calls netif_poll_enable(), thus clearing the __LINK_STATE_RX_SCHED bit - now the NET RX softirq (net_rx_action) calls e100_poll(), which in turn calls netif_rx_complete() - netif_rx_complete() checks whether the __LINK_STATE_RX_SCHED bit is set and triggers the panic To avoid this situation, where the interrupt handler executes although e100 interrupts are disabled, we suggest the attached patch. It lets the interrupt handler check the interrupt mask bit before proceeding with the interrupt handling. Authors: Christof Efkemann <[EMAIL PROTECTED]>, Kai Thomsen <[EMAIL PROTECTED]> Description: Avoid interrupt handler execution if e100 interrupts are disabled. Checks the interrupt mask bit before proceeding with the interrupt handling. --- drivers/net/e100.c.old 2007-10-20 18:32:40.0 +0200 +++ drivers/net/e100.c 2007-10-20 18:36:02.0 +0200 @@ -1960,11 +1960,13 @@ struct net_device *netdev = dev_id; struct nic *nic = netdev_priv(netdev); u8 stat_ack = ioread8(&nic->csr->scb.stat_ack); + u8 cmd_hi = ioread8(&nic->csr->scb.cmd_hi); DPRINTK(INTR, DEBUG, "stat_ack = 0x%02X\n", stat_ack); if(stat_ack == stat_ack_not_ours || /* Not our interrupt */ - stat_ack == stat_ack_not_present)/* Hardware is ejected */ + stat_ack == stat_ack_not_present || /* Hardware is ejected */ + cmd_hi & irq_mask_all) /* Interrupts masked */ return IRQ_NONE; /* Ack interrupt(s) */ - 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
[patch 2/2] s390 MAINTAINERS
From: Ursula Braun <[EMAIL PROTECTED]> adding Frank Blaschka to s390 networking maintainers Signed-off-by: Frank Blaschka <[EMAIL PROTECTED]> Signed-off-by: Ursula Braun <[EMAIL PROTECTED]> --- MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6-uschi/MAINTAINERS === --- linux-2.6-uschi.orig/MAINTAINERS +++ linux-2.6-uschi/MAINTAINERS @@ -3246,6 +3246,8 @@ S:Supported S390 NETWORK DRIVERS P: Ursula Braun M: [EMAIL PROTECTED] +P: Frank Blaschka +M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.ibm.com/developerworks/linux/linux390/ -- - 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
[patch 1/2] : remove header_ops bug in qeth driver
From: Ursula Braun <[EMAIL PROTECTED]>
Remove qeth bug caused by commit:
[NET]: Move hardware header operations out of netdevice.
This is the second part of the qeth header_ops patch, since
first patch sent 10/19 has been insufficient.
Nevertheless first patch is still valid and should be kept.
Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
---
include/linux/netdevice.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-uschi/include/linux/netdevice.h
===
--- linux-2.6-uschi.orig/include/linux/netdevice.h
+++ linux-2.6-uschi/include/linux/netdevice.h
@@ -834,7 +834,7 @@ static inline int dev_hard_header(struct
const void *daddr, const void *saddr,
unsigned len)
{
- if (!dev->header_ops)
+ if (!dev->header_ops || !dev->header_ops->create)
return 0;
return dev->header_ops->create(skb, dev, type, daddr, saddr, len);
--
-
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
[patch 0/2] remove header_ops bug in qeth driver (part 2)
-- Jeff, another patch in include/linux/netdevice.h is necessary to solve the qeth bug of 2.6.23-git And an update of the MAINTAINERS file is appended. Regards, Ursula Braun - 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
appletalk bugs
Hi, modprobing appletalk on current git gives a warning in dmesg : [38506.600269] sysctl table check failed: /net/appletalk .3.7 procname does not match binary path procname on rmmod appletalk I get an Oops : [38541.525258] BUG: unable to handle kernel NULL pointer dereference at virtual address 000c [38541.525266] printing eip: c011d4f0 *pde = [38541.525274] Oops: [#1] PREEMPT SMP [38541.525282] Modules linked in: appletalk psnap llc pc87360 hwmon_vid eeprom adm1021 sr_mod shpchp pci_hotplug iTCO_wdt iTCO_vendor_support intel_agp i82860_edac i2c_i801 edac_core cdrom agpgart 3c59x mii ext4dev jbd2 crc16 loop lp parport_pc parport evdev [38541.525312] [38541.525316] Pid: 28887, comm: rmmod Not tainted (2.6.23-gcfa76f02 #341) [38541.525321] EIP: 0060:[] EFLAGS: 00010202 CPU: 0 [38541.525334] EIP is at unregister_sysctl_table+0x11/0x70 [38541.525339] EAX: 0001 EBX: e8ef2180 ECX: 0002 EDX: [38541.525343] ESI: EDI: 0880 EBP: cc094000 ESP: cc095f38 [38541.525347] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [38541.525352] Process rmmod (pid: 28887, ti=cc094000 task=e0da0560 task.ti=cc094000) [38541.525355] Stack: 0001 0296 cebf5020 fff5 0880 e8ef2180 e8eed5b1 [38541.525367]c01353b2 6c707061 6c617465 b7ee006b e0da0560 c01101fd c2bf3a50 [38541.525378]c0148684 b7fd5000 c31a2004 b7fd4000 b7fd5000 0004 00095fb8 [38541.525389] Call Trace: [38541.525395] [] atalk_exit+0x5/0x4b [appletalk] [38541.525410] [] sys_delete_module+0x187/0x1b5 [38541.525420] [] do_page_fault+0x18b/0x51a [38541.525426] [] do_munmap+0x19b/0x1b4 [38541.525437] [] sysenter_past_esp+0x5f/0x85 [38541.525448] === [38541.525450] Code: ff ff ff f7 d8 eb 06 c7 03 00 00 00 00 e8 65 df ff ff 89 07 31 c0 5b 5e 5f c3 56 53 83 ec 14 89 c6 b8 b8 1c 3c c0 e8 c6 42 1f 00 <83> 7e 0c 00 74 2e c7 04 24 00 00 00 00 8d 44 24 04 e8 66 a2 00 [38541.525502] EIP: [] unregister_sysctl_table+0x11/0x70 SS:ESP 0068:cc095f38 [38541.525513] note: rmmod[28887] exited with preempt_count 1 Regards, Gabriel C - 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: e100 problems in .23rc8 ?
Then I got very, very lucky, since I have successfully rebooted
2.6.23.1-23.fc8 four times (zero panics) and this is the first time a
2.6.23 kernel has not panicked on me in months.
This does not fill me with confidence in the theory that the panics I've
been seeing are due to a race condition.
Dave
> -Original Message-
> From: Dave Jones [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 21, 2007 6:05 PM
> To: Kok, Auke
> Cc: David Mack; Herbert Xu; netdev@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: e100 problems in .23rc8 ?
>
> On Thu, Oct 18, 2007 at 10:59:59AM -0700, Kok, Auke wrote:
> > David Mack wrote:
> > > It appears that the needed e100 fix made it into the Fedora
> > > 2.6.23.1-23.fc8 kernel. Boots reliably now.
> > >
> > > Huge thanks and great work, guys.
> >
> > DaveJ, I didn't push anything upstream. Can you verify
> this now works?
>
> There was no e100 changes in the kernel above, so David just
> got lucky. (The race doesn't always occur, so it sometimes appears
> something got fixed.).
>
> I included the patch below in the latest build, but I've not had
> chance to try it on an e100 box yet..
>
> Dave
>
> --- linux-2.6.23.noarch/drivers/net/e100.c~ 2007-10-18
> 16:10:40.0 -0400
> +++ linux-2.6.23.noarch/drivers/net/e100.c2007-10-18
> 16:16:02.0 -0400
> @@ -2682,6 +2682,8 @@ static int __devinit e100_probe(struct p
> if (err)
> DPRINTK(PROBE, ERR, "Error clearing wake event\n");
>
> + netif_poll_disable(netdev);
> +
> strcpy(netdev->name, "eth%d");
> if((err = register_netdev(netdev))) {
> DPRINTK(PROBE, ERR, "Cannot register net
> device, aborting.\n");
>
> --
> http://www.codemonkey.org.uk
>
-
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] [POWERPC] ucc_geth: Eliminate compile warnings
Hello David, > No piece of code in the kernel should live in a vacuum. > > In order to improve overall code quality, every piece of > driver code should avoid assuming things about pointer > sizes and things of this nature. I'm afraid we might be talking about orthogonal issues here. I actively agree that all code (not only kernel) should be written up to the coding/quality standards you mention above, but I see a difference between fixing a warning and making a driver portable (to 64-bit PowerPCs, to other platforms, etc.). If there is a kernel todo list somewhere lets add to it the task to make the ucc_geth more portable. > Then the driver can get enabled into the build on every > platform, and therefore nobody will break the build of > this driver again since it will get hit by "allmodconfig" > et al. builds even on platforms other than the one it is > meant for. > > This hack fix is not acceptable, really. Are you suggesting we leave those warnings there until somebody decides to fix all the portability issues of this driver? My patch is a small and insignificant improvement and not the revolution you're asking for, but is an small improvement today (I dislike warnings) vs. an improbable big one in the future. Leo, as author and maintainer of this driver, what's your take on this? Cheers, Emil. - 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: [Devel] [PATCH 1/5] Cut off br_port fied from net_device
Alexey Dobriyan wrote: > On Mon, Oct 22, 2007 at 04:33:33PM +0400, Pavel Emelyanov wrote: >> And add the forward declaration for br_handle_frame_hook in >> include/linux/if_bridge.h > >> --- a/include/linux/netdevice.h >> +++ b/include/linux/netdevice.h >> @@ -699,8 +699,10 @@ struct net_device >> /* Network namespace this network device is inside */ >> struct net *nd_net; >> >> +#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) >> /* bridge stuff */ >> struct net_bridge_port *br_port; >> +#endif > > Such ifdefs are troublesome, because one can compile kernel with > CONFIG_BRIDGE=n and later decide he needs BRIDGE=m and go boom. You will have to recompile the whole kernel when this config is on. Look at netif_receive_skb() ;) > IPv6 -- the biggest violator of this rule should not be taken as > example. :^) > > - 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: [Devel] [PATCH 1/5] Cut off br_port fied from net_device
On Mon, Oct 22, 2007 at 04:33:33PM +0400, Pavel Emelyanov wrote: > And add the forward declaration for br_handle_frame_hook in > include/linux/if_bridge.h > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -699,8 +699,10 @@ struct net_device > /* Network namespace this network device is inside */ > struct net *nd_net; > > +#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) > /* bridge stuff */ > struct net_bridge_port *br_port; > +#endif Such ifdefs are troublesome, because one can compile kernel with CONFIG_BRIDGE=n and later decide he needs BRIDGE=m and go boom. IPv6 -- the biggest violator of this rule should not be taken as example. :^) - 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
[PATCH 5/5] Cut off dn_ptr from net_device
And remove a BUG_TRAP from netdev_run_todo as well. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 472d9cc..e94c636 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -577,7 +577,9 @@ struct net_device void*atalk_ptr; /* AppleTalk link */ void*ip_ptr;/* IPv4 specific data */ +#if defined(CONFIG_DECNET) || defined(CONFIG_DECNET_MODULE) void*dn_ptr;/* DECnet specific data */ +#endif void*ip6_ptr; /* IPv6 specific data */ #if defined(CONFIG_ECONET) || defined(CONFIG_ECONET_MODULE) void*ec_ptr;/* Econet specific data */ diff --git a/net/core/dev.c b/net/core/dev.c index 8726589..3ac35fe 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3781,7 +3781,9 @@ void netdev_run_todo(void) BUG_ON(atomic_read(&dev->refcnt)); BUG_TRAP(!dev->ip_ptr); BUG_TRAP(!dev->ip6_ptr); +#if defined(CONFIG_DECNET) || defined(CONFIG_DECNET_MODULE) BUG_TRAP(!dev->dn_ptr); +#endif if (dev->destructor) dev->destructor(dev); -- 1.5.3.4 - 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
[PATCH 4/5] Cut off ec_ptr from net_device
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 504f843..472d9cc 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -579,7 +579,9 @@ struct net_device void*ip_ptr;/* IPv4 specific data */ void*dn_ptr;/* DECnet specific data */ void*ip6_ptr; /* IPv6 specific data */ +#if defined(CONFIG_ECONET) || defined(CONFIG_ECONET_MODULE) void*ec_ptr;/* Econet specific data */ +#endif #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) void*ax25_ptr; /* AX.25 specific data */ #endif -- 1.5.3.4 - 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
[PATCH 3/5] Cut off ax25_ptr from net_device
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index c41a5c4..504f843 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -580,7 +580,9 @@ struct net_device void*dn_ptr;/* DECnet specific data */ void*ip6_ptr; /* IPv6 specific data */ void*ec_ptr;/* Econet specific data */ +#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) void*ax25_ptr; /* AX.25 specific data */ +#endif struct wireless_dev *ieee80211_ptr; /* IEEE 802.11 specific data, assign before registering */ -- 1.5.3.4 - 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
[PATCH 1/5] Cut off br_port fied from net_device
And add the forward declaration for br_handle_frame_hook in include/linux/if_bridge.h Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h index 58e43e5..a718586 100644 --- a/include/linux/if_bridge.h +++ b/include/linux/if_bridge.h @@ -104,6 +104,8 @@ struct __fdb_entry #include +struct net_bridge_port; + extern void brioctl_set(int (*ioctl_hook)(struct net *, unsigned int, void __user *)); extern struct sk_buff *(*br_handle_frame_hook)(struct net_bridge_port *p, struct sk_buff *skb); diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 4a3f54e..469e04f 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -699,8 +699,10 @@ struct net_device /* Network namespace this network device is inside */ struct net *nd_net; +#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) /* bridge stuff */ struct net_bridge_port *br_port; +#endif /* macvlan */ struct macvlan_port *macvlan_port; -- 1.5.3.4 - 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
[PATCH 2/5] Cut off macvlan_port from net_device
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 469e04f..c41a5c4 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -703,8 +703,10 @@ struct net_device /* bridge stuff */ struct net_bridge_port *br_port; #endif +#if defined(CONFIG_MACVLAN) || defined(CONFIG_MACVLAN_MODULE) /* macvlan */ struct macvlan_port *macvlan_port; +#endif /* class/net/name entry */ struct device dev; -- 1.5.3.4 - 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
[PATCH 0/5] Diet struct net_device a bit
There are some pointers, that are used in protocols/drivers/etc in this struct. E.g. br_port, macvlan_port, ec_ptr, etc. Some of them can be simply compile out with ifdefs, some require a bit closer look. Here's the summary: Compiled out in this set with appropriate ifdef: * br_port * macvlan_port * dn_ptr * ec_ptr * ax25_ptr Require a closer look: * atalk_ptr is shared with irda with "should we get our own field?" comment; * ip_ptr and * ip6_ptr are used in headers and gcc complains when trying to compile net/socket.c that these fields are unreclared; * ieee80211_ptr is used in many wireless drivers. Need time to check for the config dependencies. Signed-off-by: Pavel Emelyanov <[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: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
On Mon, 2007-22-10 at 15:11 +0900, Masahide NAKAMURA wrote: > This patch introduces statistics about transformation error (or almost error) > factor at packet processing for developer. > It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter > designed from current transformation source code. > > Comment please. very nice - these stats make IPSEC a lot more usable (I will go look and see if theres anything that i have used for debug before that you dont have and send you mail). Two comments: 1) Since these are not MIB stats, it sounds like a good idea not to use _MIB_ extender in the naming. Maybe something like _NOTMIB_ ;-> or totaly leave it out. One other approach is to push these to be a MIB at IETF since they are sensible to have. 2) Why /proc? Are you going to make these available also via netlink? cheers, jamal - 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
[PATCH 1/2] NFS: change the ip_map cache code to handle IPv6 addresses
Here is a patch for the ip_map caching code part in nfs server.
I have updated the code to use Brian
Haley's ipv6_addr_v4mapped function, and corrected pointed out mistakes.
So the first patch in attachment must be applied on a vanilla kernel
before.
In case of bad formatting due to my mailer, you can also find the patch
in attachment.
Tests: tested with only IPv4 network and basic nfs ops (mount, file
creation and modification)
Signed-off-by: Aurelien Charbon <[EMAIL PROTECTED]>
---
diff -p -u -r -N linux-2.6.23-haley/fs/nfsd/export.c
linux-2.6.23-ipmap/fs/nfsd/export.c
--- linux-2.6.23-haley/fs/nfsd/export.c2007-10-22 09:43:17.0
+0200
+++ linux-2.6.23-ipmap/fs/nfsd/export.c2007-10-22 13:04:50.0
+0200
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#define NFSDDBG_FACILITYNFSDDBG_EXPORT
@@ -1559,6 +1560,7 @@ exp_addclient(struct nfsctl_client *ncp)
{
struct auth_domain*dom;
inti, err;
+struct in6_addr addr6;
/* First, consistency check. */
err = -EINVAL;
@@ -1577,9 +1579,11 @@ exp_addclient(struct nfsctl_client *ncp)
goto out_unlock;
/* Insert client into hashtable. */
-for (i = 0; i < ncp->cl_naddr; i++)
-auth_unix_add_addr(ncp->cl_addrlist[i], dom);
-
+for (i = 0; i < ncp->cl_naddr; i++) {
+/* Mapping address */
+ipv6_addr_set(&addr6, 0, 0, htonl(0x),
ncp->cl_addrlist[i].s_addr);
+auth_unix_add_addr(&addr6, dom);
+}
auth_unix_forget_old(dom);
auth_domain_put(dom);
diff -p -u -r -N linux-2.6.23-haley/fs/nfsd/nfsctl.c
linux-2.6.23-ipmap/fs/nfsd/nfsctl.c
--- linux-2.6.23-haley/fs/nfsd/nfsctl.c2007-10-22 09:43:17.0
+0200
+++ linux-2.6.23-ipmap/fs/nfsd/nfsctl.c2007-10-22 10:32:51.0
+0200
@@ -37,6 +37,7 @@
#include
#include
+#include
/*
*We have a single directory with 9 nodes in it.
@@ -222,6 +223,7 @@ static ssize_t write_getfs(struct file *
struct auth_domain *clp;
int err = 0;
struct knfsd_fh *res;
+struct in6_addr in6;
if (size < sizeof(*data))
return -EINVAL;
@@ -236,7 +238,11 @@ static ssize_t write_getfs(struct file *
res = (struct knfsd_fh*)buf;
exp_readlock();
-if (!(clp = auth_unix_lookup(sin->sin_addr)))
+
+/* IPv6 address mapping */
+ipv6_addr_set(&in6, 0, 0, htonl(0x), (((struct
sockaddr_in *)&data->gd_addr)->sin_addr.s_addr));
+
+if (!(clp = auth_unix_lookup(in6)))
err = -EPERM;
else {
err = exp_rootfh(clp, data->gd_path, res, data->gd_maxlen);
@@ -257,6 +263,7 @@ static ssize_t write_getfd(struct file *
int err = 0;
struct knfsd_fh fh;
char *res;
+struct in6_addr in6;
if (size < sizeof(*data))
return -EINVAL;
@@ -271,7 +278,11 @@ static ssize_t write_getfd(struct file *
res = buf;
sin = (struct sockaddr_in *)&data->gd_addr;
exp_readlock();
-if (!(clp = auth_unix_lookup(sin->sin_addr)))
+
+/* IPv6 address mapping */
+ipv6_addr_set(&in6, 0, 0, htonl(0x), (((struct
sockaddr_in *)&data->gd_addr)->sin_addr.s_addr));
+
+if (!(clp = auth_unix_lookup(in6)))
err = -EPERM;
else {
err = exp_rootfh(clp, data->gd_path, &fh, NFS_FHSIZE);
diff -p -u -r -N linux-2.6.23-haley/include/linux/sunrpc/svcauth.h
linux-2.6.23-ipmap/include/linux/sunrpc/svcauth.h
--- linux-2.6.23-haley/include/linux/sunrpc/svcauth.h2007-10-22
09:43:04.0 +0200
+++ linux-2.6.23-ipmap/include/linux/sunrpc/svcauth.h2007-10-22
10:10:37.0 +0200
@@ -120,10 +120,10 @@ extern voidsvc_auth_unregister(rpc_auth
extern struct auth_domain *unix_domain_find(char *name);
extern void auth_domain_put(struct auth_domain *item);
-extern int auth_unix_add_addr(struct in_addr addr, struct auth_domain
*dom);
+extern int auth_unix_add_addr(struct in6_addr *addr, struct auth_domain
*dom);
extern struct auth_domain *auth_domain_lookup(char *name, struct
auth_domain *new);
extern struct auth_domain *auth_domain_find(char *name);
-extern struct auth_domain *auth_unix_lookup(struct in_addr addr);
+extern struct auth_domain *auth_unix_lookup(struct in6_addr *addr);
extern int auth_unix_forget_old(struct auth_domain *dom);
extern void svcauth_unix_purge(void);
extern void svcauth_unix_info_release(void *);
diff -p -u -r -N linux-2.6.23-haley/include/net/ipv6.h
linux-2.6.23-ipmap/include/net/ipv6.h
--- linux-2.6.23-haley/include/net/ipv6.h2007-10-22
09:42:58.0 +0200
+++ linux-2.6.23-ipmap/include/net/ipv6.h2007-10-22
10:10:59.0 +0200
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define SIN6_LEN_RFC213324
@@ -167,6 +168,12 @@ DECLARE_SNMP_STAT(struct udp_mib, udplit
if (is_udplite) SNMP_INC_STATS_USER(udplite_stats_in6,
field); \
elseSNMP_INC_STATS_USER(udp_stats_in6, field);} while(0)
+#define IS_ADDR_MAPPED(a) \
+(((uint32_t *) (a))[0] == 0\
+
[PATCH 2/2] NFS: handle IPv6 addresses in nfs ctl
Here is a second missing part of the IPv6 support in NFS server code
concerning knfd syscall interface.
It updates write_getfd and write_getfd to accept IPv6 addresses.
I've updated it according to Brian's comments, and removed some unused code.
Applies on a kernel including ip_map cache modifications
Tests: tested with only IPv4 network and basic nfs ops (mount, file
creation and modification)
Signed-off-by: Aurelien Charbon <[EMAIL PROTECTED]>
---
diff -p -u -r -N linux-2.6.23-ipmap/fs/nfsd/nfsctl.c
linux-2.6.23-nfsctl/fs/nfsd/nfsctl.c
--- linux-2.6.23-ipmap/fs/nfsd/nfsctl.c2007-10-22 10:32:51.0
+0200
+++ linux-2.6.23-nfsctl/fs/nfsd/nfsctl.c2007-10-22
11:06:13.0 +0200
@@ -219,7 +219,7 @@ static ssize_t write_unexport(struct fil
static ssize_t write_getfs(struct file *file, char *buf, size_t size)
{
struct nfsctl_fsparm *data;
-struct sockaddr_in *sin;
+struct sockaddr_in6 *sin6, sin6_storage;
struct auth_domain *clp;
int err = 0;
struct knfsd_fh *res;
@@ -229,9 +229,20 @@ static ssize_t write_getfs(struct file *
return -EINVAL;
data = (struct nfsctl_fsparm*)buf;
err = -EPROTONOSUPPORT;
-if (data->gd_addr.sa_family != AF_INET)
+switch (data->gd_addr.sa_family) {
+case AF_INET6:
+sin6 = &sin6_storage;
+sin6 = (struct sockaddr_in6 *)&data->gd_addr;
+ipv6_addr_copy(&in6, &(sin6->sin6_addr));
+break;
+case AF_INET:
+/* Map v4 address into v6 structure */
+ipv6_addr_set(&in6, 0, 0, htonl(0x), (((struct
sockaddr_in *)&data->gd_addr)->sin_addr.s_addr));
+break;
+default:
goto out;
-sin = (struct sockaddr_in *)&data->gd_addr;
+}
+
if (data->gd_maxlen > NFS3_FHSIZE)
data->gd_maxlen = NFS3_FHSIZE;
@@ -239,10 +250,7 @@ static ssize_t write_getfs(struct file *
exp_readlock();
-/* IPv6 address mapping */
-ipv6_addr_set(&in6, 0, 0, htonl(0x), (((struct
sockaddr_in *)&data->gd_addr)->sin_addr.s_addr));
-
-if (!(clp = auth_unix_lookup(in6)))
+if (!(clp = auth_unix_lookup(&in6)))
err = -EPERM;
else {
err = exp_rootfh(clp, data->gd_path, res, data->gd_maxlen);
@@ -258,7 +266,7 @@ static ssize_t write_getfs(struct file *
static ssize_t write_getfd(struct file *file, char *buf, size_t size)
{
struct nfsctl_fdparm *data;
-struct sockaddr_in *sin;
+struct sockaddr_in6 *sin6, sin6_storage;
struct auth_domain *clp;
int err = 0;
struct knfsd_fh fh;
@@ -269,20 +277,30 @@ static ssize_t write_getfd(struct file *
return -EINVAL;
data = (struct nfsctl_fdparm*)buf;
err = -EPROTONOSUPPORT;
-if (data->gd_addr.sa_family != AF_INET)
+if (data->gd_addr.sa_family != AF_INET && data->gd_addr.sa_family
!= AF_INET6)
goto out;
err = -EINVAL;
if (data->gd_version < 2 || data->gd_version > NFSSVC_MAXVERS)
goto out;
res = buf;
-sin = (struct sockaddr_in *)&data->gd_addr;
exp_readlock();
-
-/* IPv6 address mapping */
-ipv6_addr_set(&in6, 0, 0, htonl(0x), (((struct
sockaddr_in *)&data->gd_addr)->sin_addr.s_addr));
-if (!(clp = auth_unix_lookup(in6)))
+switch (data->gd_addr.sa_family) {
+case AF_INET:
+/* IPv6 address mapping */
+ipv6_addr_set(&in6, 0, 0, htonl(0x), ((struct
sockaddr_in *)&data->gd_addr)->sin_addr.s_addr);
+break;
+case AF_INET6:
+sin6 = &sin6_storage;
+sin6 = (struct sockaddr_in6 *)&data->gd_addr;
+ipv6_addr_copy(&in6, &(sin6->sin6_addr));
+break;
+default:
+BUG();
+}
+
+if (!(clp = auth_unix_lookup(&in6)))
err = -EPERM;
else {
err = exp_rootfh(clp, data->gd_path, &fh, NFS_FHSIZE);
--
Aurelien Charbon
Linux NFSv4 team
Bull SAS
Echirolles - France
http://nfsv4.bullopensource.org/
diff -p -u -r -N linux-2.6.23-ipmap/fs/nfsd/nfsctl.c linux-2.6.23-nfsctl/fs/nfsd/nfsctl.c
--- linux-2.6.23-ipmap/fs/nfsd/nfsctl.c 2007-10-22 10:32:51.0 +0200
+++ linux-2.6.23-nfsctl/fs/nfsd/nfsctl.c 2007-10-22 11:06:13.0 +0200
@@ -219,7 +219,7 @@ static ssize_t write_unexport(struct fil
static ssize_t write_getfs(struct file *file, char *buf, size_t size)
{
struct nfsctl_fsparm *data;
- struct sockaddr_in *sin;
+ struct sockaddr_in6 *sin6, sin6_storage;
struct auth_domain *clp;
int err = 0;
struct knfsd_fh *res;
@@ -229,9 +229,20 @@ static ssize_t write_getfs(struct file *
return -EINVAL;
data = (struct nfsctl_fsparm*)buf;
err = -EPROTONOSUPPORT;
- if (data->gd_addr.sa_family != AF_INET)
+ switch (data->gd_addr.sa_family) {
+ case AF_INET6:
+ sin6 = &sin6_storage;
+ sin6 = (struct sockaddr_in6 *)&data->gd_addr;
+ ipv6_addr_copy(&in6, &(sin6->sin6_addr));
+ break;
+ case AF_INET:
+ /* Map v4 address into v6 structure */
+ ipv6_addr_set(&in6, 0,
Re: net: alignment problem in icmp code
Pierre Ossman a écrit : On Mon, 22 Oct 2007 02:05:38 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 10:42:08 +0200 This seems like a rather evil layering violation. This has a 10+ year precedence and it's why the Linux networking stack is so fast. If you read any other driver you would have seen the skb_reserve() call every one of them do to align the headers. The norm seems to be to not comment this call. It's hardly obvious. This is not obvious you are right, but documented in include/linux/skbuff.h (lines 1150 ...) /* * CPUs often take a performance hit when accessing unaligned memory * locations. The actual performance hit varies, it can be small if the * hardware handles it or large if we have to take an exception and fix it * in software. * * Since an ethernet header is 14 bytes network drivers often end up with * the IP header at an unaligned offset. The IP header can be aligned by * shifting the start of the packet by 2 bytes. Drivers should do this * with: * * skb_reserve(NET_IP_ALIGN); * * The downside to this alignment of the IP header is that the DMA is now * unaligned. On some architectures the cost of an unaligned DMA is high * and this cost outweighs the gains made by aligning the IP header. * * Since this trade off varies between architectures, we allow NET_IP_ALIGN * to be overridden. */ #ifndef NET_IP_ALIGN #define NET_IP_ALIGN2 #endif But then, many drivers dont use NET_IP_ALIGN but a hardcoded 2 drivers/net/pcnet32.c:608: skb_reserve(rx_skbuff, 2); drivers/net/pcnet32.c:1214: skb_reserve(newskb, 2); drivers/net/pcnet32.c:1245: skb_reserve(skb, 2);/* 16 byte align */ drivers/net/pcnet32.c:2396: skb_reserve(rx_skbuff, 2); drivers/net/sundance.c:989: skb_reserve(skb, 2);/* 16 byte align the IP header. */ drivers/net/sundance.c:1312:skb_reserve(skb, 2);/* 16 byte align the IP header */ drivers/net/sundance.c:1375:skb_reserve(skb, 2); /* Align IP on 16 byte boundaries */ - 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] [IPSEC] IPV6: Fix to add tunnel mode SA correctly.
From: Herbert Xu <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 16:37:20 +0800 > On Mon, Oct 22, 2007 at 03:09:34PM +0900, Masahide NAKAMURA wrote: > > Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> > > Thanks for catching my silly bug! Applied, 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: net: alignment problem in icmp code
On Mon, 22 Oct 2007 02:05:38 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Pierre Ossman <[EMAIL PROTECTED]> > Date: Mon, 22 Oct 2007 10:42:08 +0200 > > > This seems like a rather evil layering violation. > > This has a 10+ year precedence and it's why the Linux networking stack > is so fast. If you read any other driver you would have seen the > skb_reserve() call every one of them do to align the headers. > The norm seems to be to not comment this call. It's hardly obvious. > I think I've tolerated this long enough. > > Are you going keep teaching me how the C language works, how GCC > interprets it, and how evil the Linux networking is, or are you going > to fix the bug in your driver? :-) Settle down, "bug" fixed even before this discussion even began. I just don't like papering over problems so I want to know why this is needed and if it isn't indicative of a larger problem. If you don't want the discussions, make sure people know the gotchas. (And I wasn't try to teach anyone. I was giving my view on things, and if you think I'm off my meds, feel free to say so. Groveling and excessively putting every statement as a question demeans us both. ;)) Rgds Pierre signature.asc Description: PGP signature
Re: Regression in current git - Network Manager fails (bisected)
We have spent some time with the problem with Alexey and there are no guesses for now. Is it possible to name exact version of Network Manager and all libraries related + provide us an output of strace with full buffers send/received from netlink. Something like strace -v -x -s 32768 Regards, Den Joseph Fannin wrote: Network Manager (the freedesktop.org one) fails to work with Linus's current git on a couple of different boxes I have here. All the boxes have different NIC types, with different drivers. I've bisected it down to cd40b7d3983c708aabe3d3008ec64ffce56d33b0 , "[NET]: make netlink user -> kernel interface synchronious". I've double checked this by testing the kernel as of the immediately previous commit; Network Manager works with that one, as it did on all my machines in 2.6.23-mm1. The netlink change seems to confuse N-M, and it somehow decides that there's no link beat, so doesn't try to bring up the interface. If I run "ifconfig eth0 up", N-M will decide there's a carrier after all and takes over. Ethtool detects the link state correctly even with the interface down. If I down the interface again with ifconfig, N-M brings it right back up without a problem, but if I kill N-M, it'll down the interface before it exits, and fail in the same way as before when restarted. N-M also emits this error: "-- Error: Invalid message: type=DONE length=20 flags= sequence-nr=1193012574 pid=1185943630" ...which it doesn't do on kernels where it works normally. strace'ing NetworkManager shows that it prints that message just after talking over a netlink socket. Networking otherwise works fine here with the latest git and N-M, if I use the ifconfig "trick" to get the link up. -- Joseph Fannin [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: about multiple network interface
On Mon, Oct 22, 2007 at 10:09:38AM +0800, wit ([EMAIL PROTECTED]) wrote: > But this does work until I add a ifcfg-eth0 in > sysconfig/network-script with the following content: > DEVICE=eth0 > ONBOOT=yes > > What is the relationship between these two files? And sometimes, I see It depends on your distro - when script calls "modprobe $DEVICE" this ends up with modprobe eth0, which will check modprobe.conf. > this message: > Bringing up interface eth0: e100 device does not seem to be present, > delaying e > th0 initialization. > Why?? This is fedora, right? Check you kernel config, scripts and whatever is needed to load driver first and only then try to setup an address. -- Evgeniy Polyakov - 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: net: alignment problem in icmp code
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 10:42:08 +0200 > This seems like a rather evil layering violation. This has a 10+ year precedence and it's why the Linux networking stack is so fast. If you read any other driver you would have seen the skb_reserve() call every one of them do to align the headers. I think I've tolerated this long enough. Are you going keep teaching me how the C language works, how GCC interprets it, and how evil the Linux networking is, or are you going to fix the bug in your driver? :-) - 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: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
Monday 22 October 2007 17:50, Herbert Xu wrote: > On Mon, Oct 22, 2007 at 03:11:06PM +0900, Masahide NAKAMURA wrote: > > This patch introduces statistics about transformation error (or almost > > error) > > factor at packet processing for developer. > > It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter > > designed from current transformation source code. > > > > Comment please. > > Looks fine to me. But could you hold onto this for a few days? > I'm in the process of merging the input paths of IPv4 and IPv6. > Once that's done you'll only need to count things once rather > than once for IPv4 and again for IPv6. No problem, I'll fix my patches upon your work and resend them. Regards, -- Masahide NAKAMURA - 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] netdev: Interfamily support for IPSEC BEET
On Mon, Oct 22, 2007 at 09:59:02AM +0300, Joakim Koskela wrote:
>
> Ok, this really sounds like a good development. Do you think it could make it
> in time for 2.6.24?
Sorry, I think it's 2.6.25 material.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec
On Mon, Oct 22, 2007 at 09:55:53AM +0300, Joakim Koskela wrote:
>
> Hi, and thanks for the feedback. True, this one affects only one level of
> inter-family, and supporting more would require a lot more changes in the
> bundle creation (perhaps combining both versions and taking better into
> account the outer family of the last transformation..).
I think I should have this fixed with my current tree. I'll
either post that tonight or tomorrow.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
On Mon, Oct 22, 2007 at 03:11:06PM +0900, Masahide NAKAMURA wrote:
> This patch introduces statistics about transformation error (or almost error)
> factor at packet processing for developer.
> It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter
> designed from current transformation source code.
>
> Comment please.
Looks fine to me. But could you hold onto this for a few days?
I'm in the process of merging the input paths of IPv4 and IPv6.
Once that's done you'll only need to count things once rather
than once for IPv4 and again for IPv6.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: net: alignment problem in icmp code
On Mon, 22 Oct 2007 01:31:05 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > On fast paths we aren't going to add things like get_unaligned() > calls. > > Every architecture should handle unaligned accesses properly, and for > the fast paths the network driver should provide the packet fully > aligned or take steps to make it so if it can't DMA directly into > 2-byte offset buffers (such as copying the packet). > This seems like a rather evil layering violation. The hardware driver needs to be aware of every layer between itself and the IP stack for this to work. And what does "aligned" mean in this context? 32-bit aligned? 64-bit aligned? The entire thing is severely underdocumented (which is why I got hit by the problem in the first place). Also, since I developed the code on a forgiving platform (x86), I didn't notice this requirement. Perhaps a WARN_ON(NET_IP_ALIGN && (skb->data & 0x3));? > What is the specific reason why you see packet headers unaligned? > It's probably just some AVR networking driver that needs tweaks. It's my own driver (if_sdio for libertas), which did not reserve two bytes as that voodoo was unknown to me. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH] [IPSEC] IPV6: Fix to add tunnel mode SA correctly.
On Mon, Oct 22, 2007 at 03:09:34PM +0900, Masahide NAKAMURA wrote:
> Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
Thanks for catching my silly bug!
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: net: alignment problem in icmp code
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 09:23:50 +0200 > As for other instances of unaligned accesses, is there any active > work on getting rid of those? And would you accept more patches for > fixing them? (Code complexity being the downside) On fast paths we aren't going to add things like get_unaligned() calls. Every architecture should handle unaligned accesses properly, and for the fast paths the network driver should provide the packet fully aligned or take steps to make it so if it can't DMA directly into 2-byte offset buffers (such as copying the packet). What is the specific reason why you see packet headers unaligned? It's probably just some AVR networking driver that needs tweaks. - 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 patches for 2.6.24
Hi Dave, > > > these are the Bluetooth patches for the 2.6.24 kernel release. Please > > > pull and send them to Linus. > > > > one of the cleanup patches slipped through the net. If you already > > pulled my tree, then please re-pull. I pushed it on top of it. > > I think I got it all, thanks. > > Please get Bluetooth updates to me much sooner than 8 > days after the merge window opens up. sorry for that, but I wanted to make sure that the new generic Bluetooth SDIO driver makes it in and is working with the SDIO framework merge. For the next releases, I don't see any dependencies on other merges, so that should be no longer problem. Thanks for pulling. 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 0/1] remove header_ops bug in qeth driver
On Fri, Oct 19, 2007 at 11:55:38PM +0200, Ursula Braun wrote: > -- > Remove qeth driver bug introduced by this commit: > > commit 3b04ddde02cf1b6f14f2697da5c20eca5715017f > Author: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Tue Oct 9 01:40:57 2007 -0700 > > [NET]: Move hardware header operations out of netdevice. Still broken: Kernel BUG at 0002 [verbose debug info unavailable] illegal operation: 0001 [#1] Modules linked in: CPU:1Not tainted Process ip (pid: 2170, task: 01f1d038, ksp: 02d87b30) Krnl PSW : 070420018000 0002 (0x2) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 Krnl GPRS: 0038 027c2800 016d6000 86dd 029f8b78 029f8b00 029f8b40 027c2800 02d874c8 016d6000 003cb960 002c58d2 02d874c8 Krnl Code:>0002: unknown 0004: unknown 0006: unknown 0008: unknown 000a: unknown 000c: unknown 000e: unknown 0010: unknown Call Trace: ([<002c588e>] neigh_connected_output+0x76/0x118) [<00339e00>] ip6_output2+0x22c/0x478 [<0033a46c>] ip6_output+0x250/0x10fc [<0034d65e>] __ndisc_send+0x416/0x768 [<0034da1c>] ndisc_send_rs+0x6c/0x7c [<00340776>] addrconf_dad_completed+0xb2/0x100 [<0034269c>] addrconf_dad_start+0xa4/0x134 [<0034279e>] addrconf_add_linklocal+0x72/0xa4 [<003439d4>] addrconf_notify+0x6ec/0x8bc [<0039905a>] notifier_call_chain+0x5e/0xa4 [<00062832>] __raw_notifier_call_chain+0x26/0x38 [<00062872>] raw_notifier_call_chain+0x2e/0x40 [<002beaa8>] call_netdevice_notifiers+0x34/0x48 [<002c0288>] dev_open+0xd4/0xe0 [<002bed42>] dev_change_flags+0x14e/0x1c4 [<00316cb2>] devinet_ioctl+0x5d2/0x724 [<0031753c>] inet_ioctl+0xf4/0x130 [<002ac6fa>] sock_ioctl+0x86/0x300 [<000c8124>] do_ioctl+0x50/0xe0 [<000c8440>] vfs_ioctl+0x28c/0x3e4 [<000c85e8>] sys_ioctl+0x50/0x8c [<000ff744>] dev_ifsioc+0xb8/0x4c8 [<000fc15c>] compat_sys_ioctl+0x11c/0x444 [<000229d0>] sysc_noemu+0x10/0x16 [<77f3b9ca>] 0x77f3b9ca - 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: net: alignment problem in icmp code
On Sun, 21 Oct 2007 22:15:24 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > Sure. But the language defines that the types in question > must be 64-bit aligned, so it is legal for the compiler to > emit this code. > > It's not a GCC bug. > I've confirmed this behaviour on the AVR32 arch, and had a second look in the spec. The only way GCC can get away with this is by using a very creative interpretation of the result of casting a pointer to one type to a pointer to another type (which ISO C leaves undefined). Basically: 1. A cast from a pointer to one type to a pointer to a second type does not change the value. (GCC behaviour which we rely on heavily, even in your suggested patch). 2. A cast from a pointer to one type to a pointer to a second type changes the value so that it properly aligns with the second type. (As a cast to void*, which memcpy() requires, is safe according to ISO C, the pointer modification must be from char* to struct icmphdr*). As 1 and 2 conflict, GCC's behaviour for pointer casts is still rather undefined. So although within the requirements of ISO C, it's rather user hostile. And it casts doubt on every pointer cast used. > If you want to let the compiler know that a pointer to a type might > not be aligned, you have to tell it so. Which you can't do within the confines of ISO C. The get_unaligned() macro uses some GCC trickery (even outside what GCC documents as defined behaviour). To stay "clean", you have to avoid casting char* to foo*. With all that said, as GCC does what it does, we can't really rely on a memcpy() anyway, so I support your patch. As for other instances of unaligned accesses, is there any active work on getting rid of those? And would you accept more patches for fixing them? (Code complexity being the downside) Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH 2.4.35.3] Fix the "InAddrErrors" increasing problem
From: Gui Jianfeng <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 15:10:46 +0800 > sorry for my careless, here is the correct one > > Signed-off-by: Gui Jianfeng <[EMAIL PROTECTED]> BTW, I would also like to say that I think a statistics correction is totally inappropriate for the 2.4.x kernel series which is in super maintainence mode. Only crash fixes and fixes for bugs that severely harm functionality should go into that tree. These obscure statistic counter cases absolutely do not qualify. - 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.4.35.3] Fix the "InAddrErrors" increasing problem
Krishna Kumar2 写道:
> Gui Jianfeng wrote on 10/22/2007 11:37:07 AM:
>
>> @@ -310,8 +310,12 @@ static inline int ip_rcv_finish(struct s
>> * how the packet travels inside Linux networking.
>> */
>> if (skb->dst == NULL) {
>> - if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
>> - goto drop;
>> + int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
> dev);
>> + if (unlikely(err)) {
>> + if (err == -EHOSTUNREACH)
>> +IP_INC_STATS_BH(IpInAddrErrors);
>> + }
>> + goto drop;
>> }
>
> Shouldn't the "goto drop" be inside the "if (unlikely(err)) {" case?
> And normally it is nice to have a blank line after variable declaration.
sorry for my careless, here is the correct one
Signed-off-by: Gui Jianfeng <[EMAIL PROTECTED]>
---
diff -Narup linux-2.4.35.3/net/ipv4/ip_input.c
linux-2.4.35.3-prep/net/ipv4/ip_input.c
--- linux-2.4.35.3/net/ipv4/ip_input.c 2007-09-24 06:02:58.0 +0800
+++ linux-2.4.35.3-prep/net/ipv4/ip_input.c 2007-09-26 11:30:22.0
+0800
@@ -310,8 +310,13 @@ static inline int ip_rcv_finish(struct s
* how the packet travels inside Linux networking.
*/
if (skb->dst == NULL) {
- if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
+ int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
dev);
+
+ if (unlikely(err)) {
+ if (err == -EHOSTUNREACH)
+ IP_INC_STATS_BH(IpInAddrErrors);
goto drop;
+ }
}
#ifdef CONFIG_NET_CLS_ROUTE
diff -Narup linux-2.4.35.3/net/ipv4/route.c linux-2.4.35.3-prep/net/ipv4/route.c
--- linux-2.4.35.3/net/ipv4/route.c 2007-09-24 06:02:58.0 +0800
+++ linux-2.4.35.3-prep/net/ipv4/route.c2007-09-26 11:29:19.0
+0800
@@ -1450,7 +1450,7 @@ int ip_route_input_slow(struct sk_buff *
*/
if ((err = fib_lookup(&key, &res)) != 0) {
if (!IN_DEV_FORWARD(in_dev))
- goto e_inval;
+ goto e_hostunreach;
goto no_route;
}
free_res = 1;
@@ -1499,7 +1499,7 @@ int ip_route_input_slow(struct sk_buff *
}
if (!IN_DEV_FORWARD(in_dev))
- goto e_inval;
+ goto e_hostunreach;
if (res.type != RTN_UNICAST)
goto martian_destination;
@@ -1668,6 +1668,11 @@ martian_destination:
"%u.%u.%u.%u, dev %s\n",
NIPQUAD(daddr), NIPQUAD(saddr), dev->name);
#endif
+
+e_hostunreach:
+ err = -EHOSTUNREACH;
+ goto done;
+
e_inval:
err = -EINVAL;
goto done;
>
> - KK
>
>
>
-
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] netdev: Interfamily support for IPSEC BEET
On Friday 19 October 2007 17:22:22 Herbert Xu wrote: > > Please hold onto this. I've got a more generic version of this > that doesn't duplicate the inter-family logic between BEET mode > and tunnel mode. > > Instead I've created a generic function that reads info from the > inner header and puts them in an address-neutral format which is > then picked up by either BEET or tunnel mode. Ok, this really sounds like a good development. Do you think it could make it in time for 2.6.24? Thanks, Joakim - 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] netdev: Reset ipv4 flags during bundle creation on interfamily ipsec
On Friday 19 October 2007 17:25:49 Herbert Xu wrote: > Joakim Koskela <[EMAIL PROTECTED]> wrote: > > I'm not sure I follow. This affects the ipv6 bundling only where the > > struct (fl_tunnel) has previously been used for ipv6 addresses. Not that > > we are using the same block for holding the ipv4 info, the tos-value is > > really undefined before we reset it. > > You're right. But sure the same bug could affect IPv4 as well > if you had a 4-6-4 configuration. Let me think about this one > a bit more. Hi, and thanks for the feedback. True, this one affects only one level of inter-family, and supporting more would require a lot more changes in the bundle creation (perhaps combining both versions and taking better into account the outer family of the last transformation..). Another quite annoying example of this is that 6 in 4 actually crashes the kernel on 64 bit, as xfrm_dst_lookup around xfrm6_policy.c:197 changes rt from a rt6_info to a rtable. On 64 bit, rt->rt61i_node will usually contain something (due to the larger pointer size), making the path_cookie assignment on line 208 crash. I've been trying address this in a proper manner, but it hasn't really progressed quite the way I've wanted (..thus this shallow patch, just to make 6-4 inter-work in most cases on the standard kernel). Needless to say, any work done for this would be greatly appreciated :) - 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
