Re: size of git repository (was Re: [BUG] New Kernel Bugs)
On Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote: > > * Pavel Machek <[EMAIL PROTECTED]> wrote: > > > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > > Ingo Molnar wrote: > > > > > > > >for example git-bisect was godsent. I remember that > > > >years ago bisection of a bug was a very laborous task > > > >so that it was only used as a final, last-ditch > > > >approach for really nasty bugs. Today we can > > > >autonomouly bisect build bugs via a simple shell > > > >command around "git-bisect run", without any human > > > >interaction! This freed up testing resources > > > .. > > > > > > It's only a godsend for the few people who happen to be > > > kernel developers > > > and who happen to already use git. > > > > > > It's a 540MByte download over a slow link for everyone > > > else. > > > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > > git-prune-packed. What am I doing wrong? > > "git-repack -a -d" gives me ~220 MB: > > $ du -s .git > 222064 .git > > anyone who can download a 43 MB tar.bz2 tarball for a kernel release > should be able to afford a _one time_ download size of 250 MB (the size > of the current kernel.org git repository). If not, burning a CD or DVD > and carrying it home ought to do the trick. Git is very > bandwidth-efficient after that point - lots of people behind narrow > pipes are using it - it's just the initial clone that takes time. And > given all the history and metadata that the git repository carries (full > changelogs, annotations, etc.) it's a no-brainer that kernel developers > should be using it. > > (and you can shrink the 250 MB further down by using shallow clones, > etc.) > > yes, some people complained when distros stopped doing floppy installs. > Some people complained when distros stopped doing CD installs. Yes, i've > myself done a 250+ MB download over a 56 kbit modem in the past, and > while it indeed took overnight to finish, it's very much doable. It's > not really qualitatively different from the 1.5 hours a kernel tar.bz2 > took to download. Probably that once in a while, we should set up a complete tree in a tar.bz2 format on kernel.org. It would help a lot of people behind small pipes. I have been encountering problems with git-clone when the link is unstable. After the smallest error, it erases everything and you have to retry from start, which is quite frustrating and expensive. At least, downloading a tar.bz2 with FTP would be easier and a lot more reliable. Also, people could download it from their workplace and bring it home. Willy - 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/2] [IPV4] UDP: Always checksum even if without socket filter
On Sun, Nov 18, 2007 at 02:40:10PM -0800, David Miller wrote:
>
> This can be fixed, the above cannot.
That's a good point. Perhaps one way of getting that info to
the user without putting it in UDPInDatagrams is to create an
inet_diag interface for UDP and put the number of queued packets
for each socket in it.
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 1/2] [IPV4] UDP: Always checksum even if without socket filter
David Miller said the following on 2007-11-19 6:40: > We could defer the increment until we check the checksum, > but that is likely to break even more things because people > (as Wang Chen did initially) will send a packet to some > port with an app that doesn't eat the packets, and expect the > InDatagrams counter to increase once the stack eats the packet. As Herbert referred, RFC1213 says that udpInDatagrams records "The total number of UDP datagrams delivered to UDP users." So if "udp_queue_rcv_skb() doing sucessfully" means "a UDP datagrams delivered to UDP users", the InDatagrams should be increased in udp_queue_rcv_skb(). Otherwise it should be increased until the UDP datagrams is actually delivered to UDP users. - 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] Fix buglets in mpc5200 FEC code that are corrupting memory.
On 11/9/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/9/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> > On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > > This is the reason I couldn't get user space started or connect to my
> > > nfs server. Patch is against current linus git.
> > >
> > > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > > where the wrong skb buffer was being referenced.
> > >
> > > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
> >
> > Acked-by: Domen Puncer <[EMAIL PROTECTED]>
>
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
>
> Jeff, can you please pick this up for .24?
This is didn't make it into rc3. Without this patch this driver is broken.
>
> Thanks,
> g.
>
> >
> > I can't test it at the moment, but the patch is obviously correct,
> > mapped buffer should be the _same_ as submitted.
> >
> > >
> > > ---
> > >
> > > drivers/net/fec_mpc52xx.c |4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > >
> > > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > > index a8a0ee2..ddfcc0b 100644
> > > --- a/drivers/net/fec_mpc52xx.c
> > > +++ b/drivers/net/fec_mpc52xx.c
> > > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > > irq, void *dev_id)
> > >
> > > rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > > (struct bcom_bd **)&bd);
> > > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len,
> > > DMA_FROM_DEVICE);
> > > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len,
> > > DMA_FROM_DEVICE);
> > >
> > > /* Test for errors in received frame */
> > > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > > irq, void *dev_id)
> > > bcom_prepare_next_buffer(priv->rx_dmatsk);
> > >
> > > bd->status = FEC_RX_BUFFER_SIZE;
> > > - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> > > + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> > > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> > >
> > > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> > >
> > >
> > > --
> > > Jon Smirl
> > > [EMAIL PROTECTED]
> >
> > --
> > Domen Puncer | Research & Development
> > .
> > Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
> > .
> > www.telargo.com
> >
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> [EMAIL PROTECTED]
> (403) 399-0195
>
--
Jon Smirl
[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: [TCP]: Fix TCP header misalignment
David Miller <[EMAIL PROTECTED]> wrote:
>
> I'm getting this without IPSEC FWIW. I believe it occurs when I talk
> to sites with sub-1500 MTUs.
It is possible to get this with any MTU that's not a multiple
of 4. I was basing my comment above on the fact that such MTUs
are usually rare. However, perhaps that is no longer the case
on today's Internet :)
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 1/2] [IPV4] UDP: Always checksum even if without socket filter
On Sun, Nov 18, 2007 at 02:40:10PM -0800, David Miller wrote:
>
> The networking stack DID receive the packet. Just because a socket
> owner is busy doing something else or blocked on some other event
> is no excuse not to bump the InDataGgrams counter.
Actually if we ever implement the memory reclaim stuff for UDP
when we're short on system memory then it could be possible for
us to want to remove packets that are sitting on a socket's rcv
queue. In that case it would be nice if InDataGrams wasn't
incremented until the app took the packet off the socket.
In any case, I just looked up RFC1213 and it says:
udpInDatagrams OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of UDP datagrams delivered to
UDP users."
::= { udp 1 }
So I think incrementing it in recvmsg is acceptable.
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
[PATCH 1/2] virtio: fix net driver loop case where we fail to restart
skb is only NULL the first time around: it's more correct to test for
being under-budget.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 2a94425ac7d5 drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100
+++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:44 2007 +1100
@@ -198,8 +198,8 @@ again:
if (vi->num < vi->max / 2)
try_fill_recv(vi);
- /* All done? */
- if (!skb) {
+ /* Out of packets? */
+ if (received < budget) {
netif_rx_complete(vi->dev, napi);
if (unlikely(!vi->rvq->vq_ops->restart(vi->rvq))
&& netif_rx_reschedule(vi->dev, napi))
-
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] virtio: free transmit skbs when notified, not on next xmit.
This fixes a potential dangling xmit problem.
We also suppress refill interrupts until we need them.
(Anthony and I have been working on performance recently, so this
is a WIP).
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 586fb6ff29dd drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c Thu Nov 15 23:19:12 2007 +1100
+++ b/drivers/net/virtio_net.c Thu Nov 15 23:21:18 2007 +1100
@@ -35,6 +35,8 @@ struct virtnet_info
struct net_device *dev;
struct napi_struct napi;
+ struct tasklet_struct xmit_free;
+
/* TX coalescing. */
struct hrtimer tx_timer;
@@ -59,13 +61,40 @@ static inline void vnet_hdr_to_sg(struct
sg_init_one(sg, skb_vnet_hdr(skb), sizeof(struct virtio_net_hdr));
}
+static unsigned free_old_xmit_skbs(struct virtnet_info *vi)
+{
+ struct sk_buff *skb;
+ unsigned int len, i = 0;
+
+ while ((skb = vi->svq->vq_ops->get_buf(vi->svq, &len)) != NULL) {
+ pr_debug("Sent skb %p\n", skb);
+ __skb_unlink(skb, &vi->send);
+ vi->dev->stats.tx_bytes += len;
+ vi->dev->stats.tx_packets++;
+ kfree_skb(skb);
+ i++;
+ }
+ return i;
+}
+
+static void xmit_free(unsigned long data)
+{
+ struct virtnet_info *vi = (void *)data;
+
+ netif_tx_lock(vi->dev);
+ free_old_xmit_skbs(vi);
+ netif_tx_unlock(vi->dev);
+
+ /* In case we were waiting for output buffers. */
+ netif_wake_queue(vi->dev);
+}
+
static bool skb_xmit_done(struct virtqueue *rvq)
{
struct virtnet_info *vi = rvq->vdev->priv;
- /* In case we were waiting for output buffers. */
- netif_wake_queue(vi->dev);
- return true;
+ tasklet_schedule(&vi->xmit_free);
+ return false;
}
static void receive_skb(struct net_device *dev, struct sk_buff *skb,
@@ -216,20 +245,6 @@ again:
return received;
}
-static void free_old_xmit_skbs(struct virtnet_info *vi)
-{
- struct sk_buff *skb;
- unsigned int len;
-
- while ((skb = vi->svq->vq_ops->get_buf(vi->svq, &len)) != NULL) {
- pr_debug("Sent skb %p\n", skb);
- __skb_unlink(skb, &vi->send);
- vi->dev->stats.tx_bytes += len;
- vi->dev->stats.tx_packets++;
- kfree_skb(skb);
- }
-}
-
static enum hrtimer_restart kick_xmit(struct hrtimer *t)
{
struct virtnet_info *vi = container_of(t,struct virtnet_info,tx_timer);
@@ -256,8 +271,6 @@ static int start_xmit(struct sk_buff *sk
sg_init_table(sg, 1+MAX_SKB_FRAGS);
pr_debug("%s: xmit %p %s\n", dev->name, skb, print_mac(mac, dest));
-
- free_old_xmit_skbs(vi);
/* Encode metadata header at front. */
hdr = skb_vnet_hdr(skb);
@@ -290,11 +303,25 @@ static int start_xmit(struct sk_buff *sk
vnet_hdr_to_sg(sg, skb);
num = skb_to_sgvec(skb, sg+1, 0, skb->len) + 1;
__skb_queue_head(&vi->send, skb);
+
+again:
err = vi->svq->vq_ops->add_buf(vi->svq, sg, num, 0, skb);
if (err) {
+ /* Can we free any used skbs? */
+ if (free_old_xmit_skbs(vi))
+ goto again;
+
+ /* Activate callback for using skbs: if this fails it
+* means some were used in the meantime. */
+ if (unlikely(!vi->svq->vq_ops->restart(vi->svq))) {
+ printk("Unlikely: restart svq failed\n");
+ goto again;
+ }
+
+ __skb_unlink(skb, &vi->send);
+
pr_debug("%s: virtio not prepared to send\n", dev->name);
- skb_unlink(skb, &vi->send);
if (vi->out_max != vi->out_num)
printk("%s: out_max changed from %u to %u\n",
dev->name, vi->out_max, vi->out_num);
vi->out_max = vi->out_num;
@@ -400,5 +428,7 @@ static int virtnet_probe(struct virtio_d
vi->out_max = -1U;
+ tasklet_init(&vi->xmit_free, xmit_free, (unsigned long)vi);
+
/* We expect two virtqueues, receive then send. */
vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
if (IS_ERR(vi->rvq)) {
-
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/2] [IPV4] UDP: Always checksum even if without socket filter
From: Andi Kleen <[EMAIL PROTECTED]> Date: Sun, 18 Nov 2007 22:45:15 +0100 > > We could defer the increment until we check the checksum, > > but that is likely to break even more things because people > > (as Wang Chen did initially) will send a packet to some > > port with an app that doesn't eat the packets, and expect the > > InDatagrams counter to increase once the stack eats the packet. > > Who expects that? Is there really any program who relies on that? > > If it's just a human: there are a couple of "non intuitive" behaviours > in the stack. This would be just another one. Not too big a deal. I would consider this a legitimate thing to check in a test suite such as TAHI or similar. The networking stack DID receive the packet. Just because a socket owner is busy doing something else or blocked on some other event is no excuse not to bump the InDataGgrams counter. The behavior would suck. > > But it won't until the application does the read. > > > > All of our options suck, we just have to choose the least sucking one > > and right now to me that's decrementing the counter as much as I > > empathize with the SNMP application overflow detection issue. > > If the SNMP monitor detects an false overflow the error it reports > will be much worse than a single missing packet. So you would replace > one error with a worse error. This can be fixed, the above cannot. - 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/2] [IPV4] UDP: Always checksum even if without socket filter
David Miller wrote: From: Andi Kleen <[EMAIL PROTECTED]> Date: Sat, 17 Nov 2007 14:18:46 +0100 Wang Chen <[EMAIL PROTECTED]> writes: Herbert Xu said the following on 2007-11-16 12:11: Wang Chen <[EMAIL PROTECTED]> wrote: So, I think the checksum in udp_queue_rcv_skb() actually does the work, not that in udp_recvmsg() and udp_poll(). If I am wrong, please point out. We may have a bug in the accounting area. Check the recent patch made to UDP/IPv6 which is probably needed here as well. Like dave said, decrementing the InDataGrams in this case is an option. I will check the same place of UDP/IPv6. And like Benny pointed out it's probably a bad idea because decrementing counters will be an unexpected ABI change for monitoring programs who have no other way to detect overflow. We could defer the increment until we check the checksum, but that is likely to break even more things because people (as Wang Chen did initially) will send a packet to some port with an app that doesn't eat the packets, and expect the InDatagrams counter to increase once the stack eats the packet. But it won't until the application does the read. All of our options suck, we just have to choose the least sucking one and right now to me that's decrementing the counter as much as I empathize with the SNMP application overflow detection issue. More majordomo info at http://vger.kernel.org/majordomo-info.html You might be able hide the problem by adding some "defered tick logic" so that the counter is monotonic. Kind of like the NTP clock holding hack. - 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/2] [IPV4] UDP: Always checksum even if without socket filter
> We could defer the increment until we check the checksum, > but that is likely to break even more things because people > (as Wang Chen did initially) will send a packet to some > port with an app that doesn't eat the packets, and expect the > InDatagrams counter to increase once the stack eats the packet. Who expects that? Is there really any program who relies on that? If it's just a human: there are a couple of "non intuitive" behaviours in the stack. This would be just another one. Not too big a deal. > But it won't until the application does the read. > > All of our options suck, we just have to choose the least sucking one > and right now to me that's decrementing the counter as much as I > empathize with the SNMP application overflow detection issue. If the SNMP monitor detects an false overflow the error it reports will be much worse than a single missing packet. So you would replace one error with a worse error. -Andi - 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: [TCP]: Fix TCP header misalignment
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sun, 18 Nov 2007 20:15:30 +0800 > [TCP]: Fix TCP header misalignment > > Indeed my previous change to alloc_pskb has made it possible > for the TCP header to be misaligned iff the MTU is not a multiple > of 4 (and less than a page). So I suspect the optimised IPsec > MTU calculation is giving you just such an MTU :) > > This patch fixes it by changing alloc_pskb to make sure that > the size is at least 32-bit aligned. This does not cause the > problem fixed by the previous patch because max_header is always > 32-bit aligned which means that in the SG/NOTSO case this will > be a no-op. > > I thought about putting this in the callers but all the current > callers are from TCP. If and when we get a non-TCP caller we > can always create a TCP wrapper for this function and move the > alignment over there. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> I'm getting this without IPSEC FWIW. I believe it occurs when I talk to sites with sub-1500 MTUs. I'll test your patch and let you know how it goes, 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: r8169 crash
Denys <[EMAIL PROTECTED]> : > > Before it happens on 2.6.22, i tried to attach good cable, plug-unplug, > whatever, interface up/down - card still remains dead. A few things have changed since 2.6.22 but I'll take that it is a real bug and that 2.6.23 would not recover either. Can you fill a PR at http://bugzilla.kernel.org, add a lspci -vvv and a dmesg ? A dmesg including the watchdog message would be nice but if you can not retrieve one, a dmesg from your current 2.6.23.x kernel should be enough. I'll take care of it once I am done with the sis190 watchdog failure (nothing hard, simply ugly). [...] > I try to plug cable to laptop with rtl8139 and pc with e100 - it is worked > when i shake bad cable(interface was going up/down as well), and good cable > also worked fine, and never crashed. On 2.6.22 i was able to reproduce it > easily, but later i can't cause it is server in internet cafe, and customers > going crazy. :o/ -- Ueimor - 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
crash in ieee80211_rate with linux-2.6.24-rc3
I'm trying to get the iwl3945 driver working on my laptop, using the latest kernels. Upon boot, when udev loads the driver, it does not create the proper device. This is the contents of the kernel log: [ 29.694882] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection [ 29.781011] Bluetooth: HCI USB driver ver 2.9 [ 29.781104] usbcore: registered new interface driver hci_usb [ 30.145481] iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels [ 30.145742] phy0: Selected rate control algorithm 'iwl-3945-rs' [ 30.145756] phy0: Failed to initialize wep [ 30.153205] iwl3945: Failed to register network device (error -12) [ 30.357032] lp0: using parport0 (interrupt-driven). [ 30.369224] ieee80211_crypt: registered algorithm 'NULL' [ 30.371757] ieee80211_crypt: registered algorithm 'WEP' [ 30.374179] ieee80211_crypt: registered algorithm 'TKIP' [ 30.376401] ieee80211_crypt: registered algorithm 'CCMP' I suspect loading ieee80211_crypt after iwl3945 has something to do with it. Do I need to build ieee80211_crypt in the monolithic kernel (as opposed to a module)? Anyway, the module is loaded - but just sitting there. If I rmmod it then insmod it back, I get this: [ 64.830431] ACPI: PCI interrupt for device :03:00.0 disabled [ 64.877506] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.1.17kds [ 64.877515] iwl3945: Copyright(c) 2003-2007 Intel Corporation [ 64.877632] ACPI: PCI Interrupt :03:00.0[A] -> GSI 17 (level, low) -> IRQ 17 [ 64.877656] PCI: Setting latency timer of device :03:00.0 to 64 [ 64.879326] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection [ 64.947524] iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels [ 64.947539] WARNING: at net/mac80211/ieee80211_rate.c:35 ieee80211_rate_control_register() [ 64.947543] [ 64.947544] Call Trace: [ 64.947586] [] :mac80211:ieee80211_rate_control_register+0xa7/0xdd [ 64.947606] [] :iwl3945:iwl_bg_alive_start+0xc97/0xefa [ 64.947617] [] thread_return+0x3d/0x81 [ 64.947636] [] :iwl3945:iwl_bg_alive_start+0x0/0xefa [ 64.947645] [] run_workqueue+0x7f/0x10b [ 64.947652] [] worker_thread+0x0/0xe4 [ 64.947657] [] worker_thread+0xda/0xe4 [ 64.947664] [] autoremove_wake_function+0x0/0x2e [ 64.947671] [] kthread+0x47/0x74 [ 64.947678] [] child_rip+0xa/0x12 [ 64.947688] [] kthread+0x0/0x74 [ 64.947694] [] child_rip+0x0/0x12 And the machine becomes unhappy enough that is not willing to start new terminals, or reboot cleanly. The userspace is Ubuntu 7.10, only the kernel is vanilla from git. The hardware is a Thinkpad T60, with the kernel compiled for AMD64. Let me know if you need more details or if you want me to try a patch. Cheers, florin -- Bruce Schneier expects the Spanish Inquisition. http://geekz.co.uk/schneierfacts/fact/163 signature.asc Description: Digital signature
Re: Netfilter: kernel panic with REDIRECT target. (2.6.23 and 2.6.23.8)
David wrote: Ismail Dönmez wrote: Sunday 18 November 2007 Tarihinde 21:00:12 yazmıştı: I'm (very) far from being firewall configuration expert, but I'm seeing a consistent kernel panic when the following rule is triggered. iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp --dport 5061 --to-ports 5060 (I'm trying to redirect an alternate port to a SIP server) Am I just being very stupid, or is there something I'm not seeing here? Also post the kernel panic log. This is a bit difficult since the server is headless (normally). I can try to obtain the panic via a temporary console, but it may have to wait for a day or two. Please try if this patch fixes the problem. [NETFILTER]: Fix NULL pointer dereference in nf_nat_move_storage() Reported by Chuck Ebbert as: https://bugzilla.redhat.com/show_bug.cgi?id=259501#c14 This routine is called each time hash should be replaced, nf_conn has extension list which contains pointers to connection tracking users (like nat, which is right now the only such user), so when replace takes place it should copy own extensions. Loop above checks for own extension, but tries to move higer-layer one, which can lead to above oops. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> --- commit 7799652557d966e49512479f4d3b9079bbc01fff tree c0895084e075bf53697a66816e6bfcbe28d3859d parent a5a97263a9fd6a94f954d41ae3233ea65a90bd8a author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 15 Nov 2007 15:52:32 -0800 committer David S. Miller <[EMAIL PROTECTED]> Thu, 15 Nov 2007 15:52:32 -0800 net/netfilter/nf_conntrack_extend.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c index a1a65a1..cf6ba66 100644 --- a/net/netfilter/nf_conntrack_extend.c +++ b/net/netfilter/nf_conntrack_extend.c @@ -109,7 +109,7 @@ void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp) rcu_read_lock(); t = rcu_dereference(nf_ct_ext_types[i]); if (t && t->move) - t->move(ct, ct->ext + ct->ext->offset[id]); + t->move(ct, ct->ext + ct->ext->offset[i]); rcu_read_unlock(); } kfree(ct->ext);
Re: Netfilter: kernel panic with REDIRECT target. (2.6.23 and 2.6.23.8)
Ismail Dönmez wrote: > Sunday 18 November 2007 Tarihinde 21:00:12 yazmıştı: > >> I'm (very) far from being firewall configuration expert, but I'm seeing >> a consistent kernel panic when the following rule is triggered. >> >> iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp --dport >> 5061 --to-ports 5060 >> >> (I'm trying to redirect an alternate port to a SIP server) >> >> Am I just being very stupid, or is there something I'm not seeing here? >> > > Also post the kernel panic log. > This is a bit difficult since the server is headless (normally). I can try to obtain the panic via a temporary console, but it may have to wait for a day or two. David - 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: Netfilter: kernel panic with REDIRECT target. (2.6.23 and 2.6.23.8)
Sunday 18 November 2007 Tarihinde 21:00:12 yazmıştı: > I'm (very) far from being firewall configuration expert, but I'm seeing > a consistent kernel panic when the following rule is triggered. > > iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp --dport > 5061 --to-ports 5060 > > (I'm trying to redirect an alternate port to a SIP server) > > Am I just being very stupid, or is there something I'm not seeing here? Also post the kernel panic log. -- Faith is believing what you know isn't so -- Mark Twain - 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
Netfilter: kernel panic with REDIRECT target. (2.6.23 and 2.6.23.8)
I'm (very) far from being firewall configuration expert, but I'm seeing a consistent kernel panic when the following rule is triggered. iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp --dport 5061 --to-ports 5060 (I'm trying to redirect an alternate port to a SIP server) Am I just being very stupid, or is there something I'm not seeing here? Thanks David - 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 00/33] Swap over NFS -v14
On Wed, Oct 31, 2007 at 01:56:53PM +0100, Peter Zijlstra wrote: >On Wed, 2007-10-31 at 08:16 -0400, Jeff Garzik wrote: >> Thoughts: >> 1) I absolutely agree that NFS is far more prominent and useful than any >> network block device, at the present time. >> >> 2) Nonetheless, swap over NFS is a pretty rare case. I view this work >> as interesting, but I really don't see a huge need, for swapping over >> NBD or swapping over NFS. I tend to think swapping to a remote resource >> starts to approach "migration" rather than merely swapping. Yes, we can >> do it... but given the lack of burning need one must examine the price. > >There is a large corporate demand for this, which is why I'm doing this. > >The typical usage scenarios are: > - cluster/blades, where having local disks is a cost issue (maintenance > of failures, heat, etc) HPC clusters are increasingly diskless, especially at the high end. for all the reasons you mention, but also because networks are faster than disks. >But please, people who want this (I'm sure some of you are reading) do >speak up. I'm just the motivated corporate drone implementing the >feature :-) swap to iSCSI has worked well in the past with your anti-deadlock patches, and I'd definitely like to see that continue and to be merged into mainline!! swap-to-network is a highly desirable feature for modern clusters. performance and scalability of NFS is poor, so it's not a good option. actually swap to a file on Lustre(*) would be best, but iSER and iSCSI would be my next choices. iSER is better than iSCSI as it's ~5x faster in practice, and InfiniBand seems to be here to stay. hmmm - any idea what the issues are with RDMA in low memory situations? presumably if DMA regions are mapped early then there's not actually much of a problem? I might try it with tgtd's iSER... cheers, robin (*) obviously not your responsibility. although Lustre (Sun/CFS) could presumably use your infrastructure once you have it in mainline. >> 3) You note >> > Swap over network has the problem that the network subsystem does not use >> > fixed >> > sized allocations, but heavily relies on kmalloc(). This makes mempools >> > unusable. >> >> True, but IMO there are mitigating factors that should be researched and >> taken into account: >> >> a) To give you some net driver background/history, most mainstream net >> drivers were coded to allocate RX skbs of size 1538, under the theory >> that they would all be allocating out of the same underlying slab cache. >> It would not be difficult to update a great many of the [non-jumbo] >> cases to create a fixed size allocation pattern. > >One issue that comes to mind is how to ensure we'd still overflow the >IP-reassembly buffers. Currently those are managed on the number of >bytes present, not the number of fragments. > >One of the goals of my approach was to not rewrite the network subsystem >to accomodate this feature (and I hope I succeeded). > >> b) Spare-time experiments and anecdotal evidence points to RX and TX skb >> recycling as a potentially valuable area of research. If you are able >> to do something like that, then memory suddenly becomes a lot more >> bounded and predictable. >> >> >> So my gut feeling is that taking a hard look at how net drivers function >> in the field should give you a lot of good ideas that approach the >> shared goal of making network memory allocations more predictable and >> bounded. > >Note that being bounded only comes from dropping most packets before >trying them to a socket. That is the crucial part of the RX path, to >receive all packets from the NIC (regardless their size) but to not pass >them on to the network stack - unless they belong to a 'special' socket >that promises undelayed processing. > >Thanks for these ideas, I'll look into them. - 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: size of git repository (was Re: [BUG] New Kernel Bugs)
On 18-11-07 15:35, James Bottomley wrote: clean-cg? But failure to run "git repack -a -d" every once in a while? Actually, the best command is git gc which does a repack (into a single pack file rather than an incremenal), and then removes all the objects now in the pack. If, like me, you work on temporary branches which you keep rebasing, you can add a --prune to gc which will erase all unreferenced objects as it packs (use this one with care. I usually never use it but run a git prune -n just to see what would be removed, and then run git prune separately if it looks OK). Thanks for the comment. That managed to indeed shave a few extra bytes off my already "repack -a -d" packed repo still. Rene. - 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: size of git repository (was Re: [BUG] New Kernel Bugs)
* Pavel Machek <[EMAIL PROTECTED]> wrote: > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > Ingo Molnar wrote: > > > > > >for example git-bisect was godsent. I remember that > > >years ago bisection of a bug was a very laborous task > > >so that it was only used as a final, last-ditch > > >approach for really nasty bugs. Today we can > > >autonomouly bisect build bugs via a simple shell > > >command around "git-bisect run", without any human > > >interaction! This freed up testing resources > > .. > > > > It's only a godsend for the few people who happen to be > > kernel developers > > and who happen to already use git. > > > > It's a 540MByte download over a slow link for everyone > > else. > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > git-prune-packed. What am I doing wrong? "git-repack -a -d" gives me ~220 MB: $ du -s .git 222064 .git anyone who can download a 43 MB tar.bz2 tarball for a kernel release should be able to afford a _one time_ download size of 250 MB (the size of the current kernel.org git repository). If not, burning a CD or DVD and carrying it home ought to do the trick. Git is very bandwidth-efficient after that point - lots of people behind narrow pipes are using it - it's just the initial clone that takes time. And given all the history and metadata that the git repository carries (full changelogs, annotations, etc.) it's a no-brainer that kernel developers should be using it. (and you can shrink the 250 MB further down by using shallow clones, etc.) yes, some people complained when distros stopped doing floppy installs. Some people complained when distros stopped doing CD installs. Yes, i've myself done a 250+ MB download over a 56 kbit modem in the past, and while it indeed took overnight to finish, it's very much doable. It's not really qualitatively different from the 1.5 hours a kernel tar.bz2 took to download. Ingo - 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: size of git repository (was Re: [BUG] New Kernel Bugs)
On Sun, 2007-11-18 at 13:58 +0100, Rene Herman wrote: > On 18-11-07 13:44, Pavel Machek wrote: > > > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > >> It's a 540MByte download over a slow link for everyone > >> else. > > > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > > git-prune-packed. What am I doing wrong? > > clean-cg? But failure to run "git repack -a -d" every once in a while? Actually, the best command is git gc which does a repack (into a single pack file rather than an incremenal), and then removes all the objects now in the pack. If, like me, you work on temporary branches which you keep rebasing, you can add a --prune to gc which will erase all unreferenced objects as it packs (use this one with care. I usually never use it but run a git prune -n just to see what would be removed, and then run git prune separately if it looks OK). James - 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: size of git repository (was Re: [BUG] New Kernel Bugs)
On 18-11-07 13:44, Pavel Machek wrote: On Tue 2007-11-13 12:50:08, Mark Lord wrote: It's a 540MByte download over a slow link for everyone else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? clean-cg? But failure to run "git repack -a -d" every once in a while? Rene. - 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
size of git repository (was Re: [BUG] New Kernel Bugs)
On Tue 2007-11-13 12:50:08, Mark Lord wrote: > Ingo Molnar wrote: > > > >for example git-bisect was godsent. I remember that > >years ago bisection of a bug was a very laborous task > >so that it was only used as a final, last-ditch > >approach for really nasty bugs. Today we can > >autonomouly bisect build bugs via a simple shell > >command around "git-bisect run", without any human > >interaction! This freed up testing resources > .. > > It's only a godsend for the few people who happen to be > kernel developers > and who happen to already use git. > > It's a 540MByte download over a slow link for everyone > else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[TCP]: Fix TCP header misalignment
Hi Dave:
[TCP]: Fix TCP header misalignment
Indeed my previous change to alloc_pskb has made it possible
for the TCP header to be misaligned iff the MTU is not a multiple
of 4 (and less than a page). So I suspect the optimised IPsec
MTU calculation is giving you just such an MTU :)
This patch fixes it by changing alloc_pskb to make sure that
the size is at least 32-bit aligned. This does not cause the
problem fixed by the previous patch because max_header is always
32-bit aligned which means that in the SG/NOTSO case this will
be a no-op.
I thought about putting this in the callers but all the current
callers are from TCP. If and when we get a non-TCP caller we
can always create a TCP wrapper for this function and move the
alignment over there.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
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
--
diff --git a/include/net/sock.h b/include/net/sock.h
index 567e468..6f67b91 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1236,6 +1236,9 @@ static inline struct sk_buff *sk_stream_alloc_pskb(struct
sock *sk,
{
struct sk_buff *skb;
+ /* The TCP header must be at least 32-bit aligned. */
+ size = ALIGN(size, 4);
+
skb = alloc_skb_fclone(size + sk->sk_prot->max_header, gfp);
if (skb) {
skb->truesize += mem;
-
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
