* RE: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
From: Xin, Xiaohui @ 2010-09-21 1:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <20100920113643.GB23898@redhat.com>
>From: Michael S. Tsirkin [mailto:mst@redhat.com]
>Sent: Monday, September 20, 2010 7:37 PM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>jdike@linux.intel.com
>Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>
>On Mon, Sep 20, 2010 at 04:08:48PM +0800, xiaohui.xin@intel.com wrote:
>> From: Xin Xiaohui <xiaohui.xin@intel.com>
>>
>> ---
>> Michael,
>> I have move the ioctl to configure the locked memory to vhost
>
>It's ok to move this to vhost but vhost does not
>know how much memory is needed by the backend.
I think the backend here you mean is mp device.
Actually, the memory needed is related to vq->num to run zero-copy
smoothly. That means mp device did not know it but vhost did.
And the rlimt stuff is per process, we use current pointer to set
and check the rlimit, the operations should be in the same process.
Now the check operations are in vhost process, as mp_recvmsg() or
mp_sendmsg() are called by vhost. So set operations should be in
vhost process too, it's natural.
>So I think we'll need another ioctl in the backend
>to tell userspace how much memory is needed?
>
Except vhost tells it to mp device, mp did not know
how much memory is needed to run zero-copy smoothly.
Is userspace interested about the memory mp is needed?
>It seems a bit cleaner as a backend ioctl as vhost
>does not lock memory itself, but I am not
>principally opposed.
>
>> and
>> check the limit with mm->locked_vm. please have a look.
>>
>> Thanks
>> Xiaohui
>>
>> drivers/vhost/mpassthru.c | 74 +++++++++----------------------------------
>> drivers/vhost/net.c | 78
>++++++++++++++++++++++++++++++++++++++------
>> include/linux/vhost.h | 3 ++
>> 3 files changed, 85 insertions(+), 70 deletions(-)
>>
>> diff --git a/drivers/vhost/mpassthru.c b/drivers/vhost/mpassthru.c
>> index d86d94c..fd3827b 100644
>> --- a/drivers/vhost/mpassthru.c
>> +++ b/drivers/vhost/mpassthru.c
>> @@ -109,9 +109,6 @@ struct page_ctor {
>> int wq_len;
>> int rq_len;
>> spinlock_t read_lock;
>> - /* record the locked pages */
>> - int lock_pages;
>> - struct rlimit o_rlim;
>> struct net_device *dev;
>> struct mpassthru_port port;
>> struct page_info **hash_table;
>> @@ -231,7 +228,6 @@ static int page_ctor_attach(struct mp_struct *mp)
>> ctor->port.ctor = page_ctor;
>> ctor->port.sock = &mp->socket;
>> ctor->port.hash = mp_lookup;
>> - ctor->lock_pages = 0;
>>
>> /* locked by mp_mutex */
>> dev->mp_port = &ctor->port;
>> @@ -264,37 +260,6 @@ struct page_info *info_dequeue(struct page_ctor *ctor)
>> return info;
>> }
>>
>> -static int set_memlock_rlimit(struct page_ctor *ctor, int resource,
>> - unsigned long cur, unsigned long max)
>> -{
>> - struct rlimit new_rlim, *old_rlim;
>> - int retval;
>> -
>> - if (resource != RLIMIT_MEMLOCK)
>> - return -EINVAL;
>> - new_rlim.rlim_cur = cur;
>> - new_rlim.rlim_max = max;
>> -
>> - old_rlim = current->signal->rlim + resource;
>> -
>> - /* remember the old rlimit value when backend enabled */
>> - ctor->o_rlim.rlim_cur = old_rlim->rlim_cur;
>> - ctor->o_rlim.rlim_max = old_rlim->rlim_max;
>> -
>> - if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
>> - !capable(CAP_SYS_RESOURCE))
>> - return -EPERM;
>> -
>> - retval = security_task_setrlimit(resource, &new_rlim);
>> - if (retval)
>> - return retval;
>> -
>> - task_lock(current->group_leader);
>> - *old_rlim = new_rlim;
>> - task_unlock(current->group_leader);
>> - return 0;
>> -}
>> -
>> static void relinquish_resource(struct page_ctor *ctor)
>> {
>> if (!(ctor->dev->flags & IFF_UP) &&
>> @@ -322,8 +287,6 @@ static void mp_ki_dtor(struct kiocb *iocb)
>> info->ctor->rq_len--;
>> } else
>> info->ctor->wq_len--;
>> - /* Decrement the number of locked pages */
>> - info->ctor->lock_pages -= info->pnum;
>> kmem_cache_free(ext_page_info_cache, info);
>> relinquish_resource(info->ctor);
>>
>> @@ -349,7 +312,7 @@ static struct kiocb *create_iocb(struct page_info *info, int size)
>> iocb->ki_dtor(iocb);
>> iocb->private = (void *)info;
>> iocb->ki_dtor = mp_ki_dtor;
>> -
>> + iocb->ki_user_data = info->pnum;
>> return iocb;
>> }
>>
>> @@ -375,10 +338,6 @@ static int page_ctor_detach(struct mp_struct *mp)
>>
>> relinquish_resource(ctor);
>>
>> - set_memlock_rlimit(ctor, RLIMIT_MEMLOCK,
>> - ctor->o_rlim.rlim_cur,
>> - ctor->o_rlim.rlim_max);
>> -
>> /* locked by mp_mutex */
>> ctor->dev->mp_port = NULL;
>> dev_put(ctor->dev);
>> @@ -565,21 +524,23 @@ static struct page_info *alloc_page_info(struct page_ctor *ctor,
>> int rc;
>> int i, j, n = 0;
>> int len;
>> - unsigned long base, lock_limit;
>> + unsigned long base, lock_limit, locked;
>> struct page_info *info = NULL;
>>
>> - lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
>> - lock_limit >>= PAGE_SHIFT;
>> + down_write(¤t->mm->mmap_sem);
>> + locked = count + current->mm->locked_vm;
>> + lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>>
>> - if (ctor->lock_pages + count > lock_limit && npages) {
>> - printk(KERN_INFO "exceed the locked memory rlimit.");
>> - return NULL;
>> - }
>> + if ((locked > lock_limit) && !capable(CAP_IPC_LOCK))
>> + goto out;
>>
>> info = kmem_cache_alloc(ext_page_info_cache, GFP_KERNEL);
>>
>> if (!info)
>> - return NULL;
>> + goto out;
>> +
>> + up_write(¤t->mm->mmap_sem);
>> +
>> info->skb = NULL;
>> info->next = info->prev = NULL;
>>
>
>Sorry I wasnt clear, I didn't really mean we copy everything
>from infiniband, just the capability checks and locked_mm use.
>These guys don't do registration on data path so
>they can play games with locked_mm etc on registration.
>But lock on data path, taking mmap sem and doing security checks
>on data path would be bad for performance.
>I would expect this to cause contention especially
>as we'll go for multiqueue.
>
>Here's what I really meant:
> SET_MEM_LOCKED gets a 32 bit integer (or a 64 bit
> if you like - just not long).
> the meaning of which is "this is how much
> memory device can lock".
> This ioctl does rlim_cur and capability checks,
> if passed immediately increments locked_vm counter
> by the *maximum amount specified*.
> Device must store the value by which we incremented
> locked_vm and the mm pointer (if this is vhost ioctl
> it has the owner already). Let's call this
> field lock_limit.
>
>
> Lock limit can also take into account
> e.g. device tx queue depth and our queue size.
> Either we give another ioctl that tells userspace
> about these and let it make the decision,
> or simply cap lock_limit ourselves
> depending on these parameters.
>
> If another SET_MEM_LOCKED ioctl is made,
> decrement lcoked_vm in the stored mm,
> and redo the operation on current->mm
> (note: might be different!).
>
> This ioctl should probably fail if backend is active
> (already has locked some pages), such an
> approach makes it easy as we do not need to
> find and unlock pages.
>
> Each time you want to lock some memory you check that
> 1. current->mm matches the stored mm.
> 2. (number of pages locked + amount we want to lock) * PAGE_SIZE <= lock_limit.
>
>
> close and RESET_OWNER decrement and drop mm reference
> (note: on close
> we decrement owner's locked_vm, not current->mm
> which might be different).
>
>
>
>
>> @@ -633,8 +594,7 @@ static struct page_info *alloc_page_info(struct page_ctor *ctor,
>> for (i = 0; i < j; i++)
>> mp_hash_insert(ctor, info->pages[i], info);
>> }
>> - /* increment the number of locked pages */
>> - ctor->lock_pages += j;
>> +
>> return info;
>>
>> failed:
>> @@ -642,7 +602,9 @@ failed:
>> put_page(info->pages[i]);
>>
>> kmem_cache_free(ext_page_info_cache, info);
>> -
>> + return NULL;
>> +out:
>> + up(¤t->mm->mmap_sem);
>> return NULL;
>> }
>>
>> @@ -1006,12 +968,6 @@ proceed:
>> count--;
>> }
>>
>> - if (!ctor->lock_pages || !ctor->rq_len) {
>> - set_memlock_rlimit(ctor, RLIMIT_MEMLOCK,
>> - iocb->ki_user_data * 4096 * 2,
>> - iocb->ki_user_data * 4096 * 2);
>> - }
>> -
>> /* Translate address to kernel */
>> info = alloc_page_info(ctor, iocb, iov, count, frags, npages, 0);
>> if (!info)
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index c4bc815..da78837 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -42,6 +42,7 @@ enum {
>> };
>>
>> static struct kmem_cache *notify_cache;
>> +static struct rlimit orig_rlim;
>>
>> enum vhost_net_poll_state {
>> VHOST_NET_POLL_DISABLED = 0,
>> @@ -136,13 +137,7 @@ static void handle_async_rx_events_notify(struct vhost_net *net,
>> struct vhost_log *vq_log = NULL;
>> int rx_total_len = 0;
>> unsigned int head, log, in, out;
>> - int size;
>> - int count;
>> -
>> - struct virtio_net_hdr_mrg_rxbuf hdr = {
>> - .hdr.flags = 0,
>> - .hdr.gso_type = VIRTIO_NET_HDR_GSO_NONE
>> - };
>> + int size, free = 0;
>>
>> if (!is_async_vq(vq))
>> return;
>> @@ -160,7 +155,7 @@ static void handle_async_rx_events_notify(struct vhost_net *net,
>> size = iocb->ki_nbytes;
>> head = iocb->ki_pos;
>> rx_total_len += iocb->ki_nbytes;
>> -
>> + free += iocb->ki_user_data;
>> if (iocb->ki_dtor)
>> iocb->ki_dtor(iocb);
>> kmem_cache_free(net->cache, iocb);
>> @@ -192,6 +187,7 @@ static void handle_async_rx_events_notify(struct vhost_net *net,
>> size = iocb->ki_nbytes;
>> head = iocb->ki_pos;
>> rx_total_len += iocb->ki_nbytes;
>> + free += iocb->ki_user_data;
>>
>> if (iocb->ki_dtor)
>> iocb->ki_dtor(iocb);
>> @@ -211,7 +207,6 @@ static void handle_async_rx_events_notify(struct vhost_net *net,
>> break;
>>
>> i++;
>> - iocb == NULL;
>> if (count)
>> iocb = notify_dequeue(vq);
>> }
>> @@ -219,6 +214,10 @@ static void handle_async_rx_events_notify(struct vhost_net *net,
>> &net->dev, vq, vq->heads, hc);
>> }
>> }
>> + /* record locked memroy */
>> + down_write(¤t->mm->mmap_sem);
>> + current->mm->locked_vm -= free;
>> + up_write(¤t->mm->mmap_sem);
>> }
>>
>> static void handle_async_tx_events_notify(struct vhost_net *net,
>> @@ -227,7 +226,7 @@ static void handle_async_tx_events_notify(struct vhost_net *net,
>> struct kiocb *iocb = NULL;
>> struct list_head *entry, *tmp;
>> unsigned long flags;
>> - int tx_total_len = 0;
>> + int tx_total_len = 0, free = 0;
>>
>> if (!is_async_vq(vq))
>> return;
>> @@ -242,7 +241,7 @@ static void handle_async_tx_events_notify(struct vhost_net *net,
>> vhost_add_used_and_signal(&net->dev, vq,
>> iocb->ki_pos, 0);
>> tx_total_len += iocb->ki_nbytes;
>> -
>> + free += iocb->ki_user_data;
>> if (iocb->ki_dtor)
>> iocb->ki_dtor(iocb);
>>
>> @@ -253,6 +252,10 @@ static void handle_async_tx_events_notify(struct vhost_net *net,
>> }
>> }
>> spin_unlock_irqrestore(&vq->notify_lock, flags);
>> + /* record locked memroy */
>> + down_write(¤t->mm->mmap_sem);
>> + current->mm->locked_vm -= free;
>> + up_write(¤t->mm->mmap_sem);
>> }
>>
>> static struct kiocb *create_iocb(struct vhost_net *net,
>> @@ -581,6 +584,7 @@ static void handle_rx_net(struct work_struct *work)
>> static int vhost_net_open(struct inode *inode, struct file *f)
>> {
>> struct vhost_net *n = kmalloc(sizeof *n, GFP_KERNEL);
>> + struct rlimit *old_rlim;
>> int r;
>> if (!n)
>> return -ENOMEM;
>> @@ -597,6 +601,12 @@ static int vhost_net_open(struct inode *inode, struct file *f)
>> n->tx_poll_state = VHOST_NET_POLL_DISABLED;
>> n->cache = NULL;
>>
>> + old_rlim = current->signal->rlim + RLIMIT_MEMLOCK;
>> +
>> + /* remember the old rlimit value when backend enabled */
>> + orig_rlim.rlim_cur = old_rlim->rlim_cur;
>> + orig_rlim.rlim_max = old_rlim->rlim_max;
>> +
>> f->private_data = n;
>>
>> return 0;
>> @@ -659,6 +669,39 @@ static void vhost_net_flush(struct vhost_net *n)
>> vhost_net_flush_vq(n, VHOST_NET_VQ_RX);
>> }
>>
>> +static long vhost_net_set_mem_locked(struct vhost_net *n,
>> + unsigned long cur,
>> + unsigned long max)
>> +{
>
>So one issue here is that when this is called on close,
>current might be different from owner, with bad results.
>
>I really think avoiding modifying rlimit is
>the simplest way to go for now.
>
>> + struct rlimit new_rlim, *old_rlim;
>> + int retval = 0;
>> +
>> + mutex_lock(&n->dev.mutex);
>> + new_rlim.rlim_cur = cur;
>> + new_rlim.rlim_max = max;
>> +
>> + old_rlim = current->signal->rlim + RLIMIT_MEMLOCK;
>> +
>> + if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
>> + !capable(CAP_SYS_RESOURCE)) {
>> + retval = -EPERM;
>> + goto err;
>> + }
>> +
>> + retval = security_task_setrlimit(RLIMIT_MEMLOCK, &new_rlim);
>> + if (retval) {
>> + retval = retval;
>> + goto err;
>> + }
>> +
>> + task_lock(current->group_leader);
>> + *old_rlim = new_rlim;
>> + task_unlock(current->group_leader);
>> +err:
>> + mutex_unlock(&n->dev.mutex);
>> + return retval;
>> +}
>> +
>> static void vhost_async_cleanup(struct vhost_net *n)
>> {
>> /* clean the notifier */
>> @@ -691,6 +734,10 @@ static int vhost_net_release(struct inode *inode, struct file *f)
>> * since jobs can re-queue themselves. */
>> vhost_net_flush(n);
>> vhost_async_cleanup(n);
>> + /* return back the rlimit */
>> + vhost_net_set_mem_locked(n,
>> + orig_rlim.rlim_cur,
>> + orig_rlim.rlim_max);
>> kfree(n);
>> return 0;
>> }
>> @@ -846,6 +893,7 @@ err:
>> return r;
>> }
>>
>> +
>> static long vhost_net_reset_owner(struct vhost_net *n)
>> {
>> struct socket *tx_sock = NULL;
>> @@ -913,6 +961,7 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
>> void __user *argp = (void __user *)arg;
>> u64 __user *featurep = argp;
>> struct vhost_vring_file backend;
>> + struct rlimit rlim;
>> u64 features;
>> int r;
>> switch (ioctl) {
>> @@ -933,6 +982,13 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
>> return vhost_net_set_features(n, features);
>> case VHOST_RESET_OWNER:
>> return vhost_net_reset_owner(n);
>> + case VHOST_SET_MEM_LOCKED:
>> + r = copy_from_user(&rlim, argp, sizeof rlim);
>> + if (r < 0)
>> + return r;
>> + return vhost_net_set_mem_locked(n,
>> + rlim.rlim_cur,
>> + rlim.rlim_max);
>> default:
>> mutex_lock(&n->dev.mutex);
>> r = vhost_dev_ioctl(&n->dev, ioctl, arg);
>> diff --git a/include/linux/vhost.h b/include/linux/vhost.h
>> index e847f1e..df93f5a 100644
>> --- a/include/linux/vhost.h
>> +++ b/include/linux/vhost.h
>> @@ -92,6 +92,9 @@ struct vhost_memory {
>> /* Specify an eventfd file descriptor to signal on log write. */
>> #define VHOST_SET_LOG_FD _IOW(VHOST_VIRTIO, 0x07, int)
>>
>> +/* Specify how much locked memory can be used */
>> +#define VHOST_SET_MEM_LOCKED _IOW(VHOST_VIRTIO, 0x08, struct rlimit)
>> +
>
>This is not a good structure to use: its size varies between
>64 and 32 bit. rlimit64 would be better.
>Also, you will have to include resource.h from here.
>
>> /* Ring setup. */
>> /* Set number of descriptors in ring. This parameter can not
>> * be modified while ring is running (bound to a device). */
>> --
>> 1.5.4.4
^ permalink raw reply
* Re: [PATCH] xmit_compl_seq: information to reclaim vmsplice buffers
From: Changli Gao @ 2010-09-21 0:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, davem, sridharr
In-Reply-To: <AANLkTi=53F3O511Uq83dP75brGkJMgN_-OR9W0VJS1p-@mail.gmail.com>
On Tue, Sep 21, 2010 at 1:50 AM, Tom Herbert <therbert@google.com> wrote:
>
>>
>> > On the server side it works well if there are a sufficient
>> > number of requests coming on the connection (resorting to the
>> > timeout if necessary as described above).
>>
>> If no response is sent out by the client, the timeout mechanism may
>> slow down the data transfer.
>>
> Why would that slow down a transfer?
vmsplice(sock, page).
epoll(sock.read_event, timeo);
/* time out */
if_the_page_is_available.
reclaim_page_and_send_the_next_data.
The page maybe available before timeout, and you may not send the next
data in time.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH v5 2/2] netfilter: save the hash of the tuple in the original direction for latter use
From: Changli Gao @ 2010-09-21 0:02 UTC (permalink / raw)
To: Patrick McHardy
Cc: David S. Miller, Eric Dumazet, Mathieu Desnoyers, akpm,
netfilter-devel, netdev, linux-kernel
In-Reply-To: <4C979515.4060908@trash.net>
On Tue, Sep 21, 2010 at 1:08 AM, Patrick McHardy <kaber@trash.net> wrote:
>
> Sure we can, dropping unconfirmed conntracks is a rare exception,
> not a common case. Even under DoS we usually drop *unassured*
> conntracks, which have already enterered the hash. If we're unable
> to do that, we won't even allocate a new conntrack.
>
Even so, saving the hash of the reply tuple isn't a good idea.
If NAT is turned on, the current code is:
mangle the reply tuple -> compute the hash of the reply tuple ->
insert into the conntrack hash table.
the new code is
compute the hash of the reply tuple -> mangle the reply tuple ->
recompute the hash of the reply tuple -> insert into the conntrack
hash table.
As you see, the hash computing is done twice, and we use more CPU
cycles than before.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH 3/3] net: core: use kernel's converter from hex to bin
From: Andy Shevchenko @ 2010-09-20 23:27 UTC (permalink / raw)
To: linux-kernel; +Cc: David S. Miller, netdev, Andy Shevchenko
In-Reply-To: <ee8a4349cc0eb3a881994b77e1e415b92ff7e669.1285024850.git.andy.shevchenko@gmail.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
net/core/pktgen.c | 10 ++++------
net/core/utils.c | 13 +++++++------
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 386c228..168e3b6 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -729,16 +729,14 @@ static int hex32_arg(const char __user *user_buffer, unsigned long maxlen,
*num = 0;
for (; i < maxlen; i++) {
+ int value;
char c;
*num <<= 4;
if (get_user(c, &user_buffer[i]))
return -EFAULT;
- if ((c >= '0') && (c <= '9'))
- *num |= c - '0';
- else if ((c >= 'a') && (c <= 'f'))
- *num |= c - 'a' + 10;
- else if ((c >= 'A') && (c <= 'F'))
- *num |= c - 'A' + 10;
+ value = hex_to_bin(*num);
+ if (value >= 0)
+ *num |= value;
else
break;
}
diff --git a/net/core/utils.c b/net/core/utils.c
index f418544..ec6bb32 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -92,18 +92,19 @@ EXPORT_SYMBOL(in_aton);
static inline int xdigit2bin(char c, int delim)
{
+ int val;
+
if (c == delim || c == '\0')
return IN6PTON_DELIM;
if (c == ':')
return IN6PTON_COLON_MASK;
if (c == '.')
return IN6PTON_DOT;
- if (c >= '0' && c <= '9')
- return (IN6PTON_XDIGIT | IN6PTON_DIGIT| (c - '0'));
- if (c >= 'a' && c <= 'f')
- return (IN6PTON_XDIGIT | (c - 'a' + 10));
- if (c >= 'A' && c <= 'F')
- return (IN6PTON_XDIGIT | (c - 'A' + 10));
+
+ val = hex_to_bin(c);
+ if (val >= 0)
+ return val | IN6PTON_XDIGIT | (val < 10 ? IN6PTON_DIGIT : 0);
+
if (delim == -1)
return IN6PTON_DELIM;
return IN6PTON_UNKNOWN;
--
1.7.2.2
^ permalink raw reply related
* [PATCH 2/3] sunrpc/cache: don't use custom hex_to_bin() converter
From: Andy Shevchenko @ 2010-09-20 23:27 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, netdev, Andy Shevchenko, Trond Myklebust,
linux-nfs
In-Reply-To: <ee8a4349cc0eb3a881994b77e1e415b92ff7e669.1285024850.git.andy.shevchenko@gmail.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs@vger.kernel.org
---
net/sunrpc/cache.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 5b7b56f..c944a24 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -1171,13 +1171,19 @@ int qword_get(char **bpp, char *dest, int bufsize)
if (bp[0] == '\\' && bp[1] == 'x') {
/* HEX STRING */
bp += 2;
- while (isxdigit(bp[0]) && isxdigit(bp[1]) && len < bufsize) {
- int byte = isdigit(*bp) ? *bp-'0' : toupper(*bp)-'A'+10;
- bp++;
- byte <<= 4;
- byte |= isdigit(*bp) ? *bp-'0' : toupper(*bp)-'A'+10;
- *dest++ = byte;
- bp++;
+ while (len < bufsize) {
+ int h, l;
+
+ h = hex_to_bin(bp[0]);
+ if (h < 0)
+ break;
+
+ l = hex_to_bin(bp[1]);
+ if (l < 0)
+ break;
+
+ *dest++ = (h << 4) | l;
+ bp += 2;
len++;
}
} else {
--
1.7.2.2
^ permalink raw reply related
* [PATCH 1/3] drivers: atm: use native kernel's hex_to_bin() func
From: Andy Shevchenko @ 2010-09-20 23:27 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, netdev, Andy Shevchenko, Chas Williams,
linux-atm-general
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Cc: linux-atm-general@lists.sourceforge.net
---
drivers/atm/horizon.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/atm/horizon.c b/drivers/atm/horizon.c
index 54720ba..dbce700 100644
--- a/drivers/atm/horizon.c
+++ b/drivers/atm/horizon.c
@@ -1645,10 +1645,8 @@ static int hrz_send (struct atm_vcc * atm_vcc, struct sk_buff * skb) {
unsigned short d = 0;
char * s = skb->data;
if (*s++ == 'D') {
- for (i = 0; i < 4; ++i) {
- d = (d<<4) | ((*s <= '9') ? (*s - '0') : (*s - 'a' + 10));
- ++s;
- }
+ for (i = 0; i < 4; ++i)
+ d = (d << 4) | hex_to_bin(*s++);
PRINTK (KERN_INFO, "debug bitmap is now %hx", debug = d);
}
}
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH] Fix race in tcp_poll
From: David Miller @ 2010-09-20 22:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: tdm.code, netdev
In-Reply-To: <1285019646.2323.267.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 20 Sep 2010 23:54:06 +0200
> Le lundi 20 septembre 2010 à 12:18 -0700, Tom Marshall a écrit :
>> If a RST comes in immediately after checking sk->sk_err, tcp_poll will
>> return POLLIN but not POLLOUT. Fix this by checking sk->sk_err at the end
>> of tcp_poll. Additionally, ensure the correct order of operations on SMP
>> machines with memory barriers.
>>
>> Signed-off-by: Tom Marshall <tdm.code@gmail.com>
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Maybe this is the last time we can avoid taking socket lock in
> tcp_poll() ;)
:-) Applied, thanks everyone.
^ permalink raw reply
* [PATCH] rose: Fix signedness issues wrt. digi count.
From: David Miller @ 2010-09-20 22:40 UTC (permalink / raw)
To: netdev; +Cc: dan.j.rosenberg
Just use explicit casts, since we really can't change the
types of structures exported to userspace which have been
around for 15 years or so.
Reported-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
The only two cases are bind() and connect(). And we only need to
guard against negative (ie. very large unsigned) values, the other
tests against addr->srose_ndigis are sane as long as we make this
check.
Committed to net-2.6
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 8e45e76..d952e7e 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -679,7 +679,7 @@ static int rose_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
if (addr_len == sizeof(struct sockaddr_rose) && addr->srose_ndigis > 1)
return -EINVAL;
- if (addr->srose_ndigis > ROSE_MAX_DIGIS)
+ if ((unsigned int) addr->srose_ndigis > ROSE_MAX_DIGIS)
return -EINVAL;
if ((dev = rose_dev_get(&addr->srose_addr)) == NULL) {
@@ -739,7 +739,7 @@ static int rose_connect(struct socket *sock, struct sockaddr *uaddr, int addr_le
if (addr_len == sizeof(struct sockaddr_rose) && addr->srose_ndigis > 1)
return -EINVAL;
- if (addr->srose_ndigis > ROSE_MAX_DIGIS)
+ if ((unsigned int) addr->srose_ndigis > ROSE_MAX_DIGIS)
return -EINVAL;
/* Source + Destination digis should not exceed ROSE_MAX_DIGIS */
^ permalink raw reply related
* Re: E1000E/82567LM-3: link reported up too soon
From: David Miller @ 2010-09-20 22:23 UTC (permalink / raw)
To: arno; +Cc: brian.haley, netdev
In-Reply-To: <87aancqf3a.fsf@small.ssi.corp>
From: arno@natisbad.org (Arnaud Ebalard)
Date: Mon, 20 Sep 2010 23:28:57 +0200
> I added printk() to see where/if those first packets get dropped in
> e1000e code. I followed those first packets to e1000_xmit_frame() and
> don't see anything obvious happening there, i.e. they are passed to the
> device as expected.
I suspect the packet is sucessfully given to the chip and the PHY simply
doesn't put it onto the wire for whatever reason.
^ permalink raw reply
* Re: [PATCH] Fix race in tcp_poll
From: Eric Dumazet @ 2010-09-20 21:54 UTC (permalink / raw)
To: Tom Marshall; +Cc: netdev
In-Reply-To: <20100920185719.GA13355@gmail.com>
Le lundi 20 septembre 2010 à 12:18 -0700, Tom Marshall a écrit :
> If a RST comes in immediately after checking sk->sk_err, tcp_poll will
> return POLLIN but not POLLOUT. Fix this by checking sk->sk_err at the end
> of tcp_poll. Additionally, ensure the correct order of operations on SMP
> machines with memory barriers.
>
> Signed-off-by: Tom Marshall <tdm.code@gmail.com>
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 3fb1428..95d75d4 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -386,8 +386,6 @@ unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
> */
>
> mask = 0;
> - if (sk->sk_err)
> - mask = POLLERR;
>
> /*
> * POLLHUP is certainly not done right. But poll() doesn't
> @@ -457,6 +455,11 @@ unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
> if (tp->urg_data & TCP_URG_VALID)
> mask |= POLLPRI;
> }
> + /* This barrier is coupled with smp_wmb() in tcp_reset() */
> + smp_rmb();
> + if (sk->sk_err)
> + mask |= POLLERR;
> +
> return mask;
> }
> EXPORT_SYMBOL(tcp_poll);
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index e663b78..149e79a 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4048,6 +4048,8 @@ static void tcp_reset(struct sock *sk)
> default:
> sk->sk_err = ECONNRESET;
> }
> + /* This barrier is coupled with smp_rmb() in tcp_poll() */
> + smp_wmb();
>
> if (!sock_flag(sk, SOCK_DEAD))
> sk->sk_error_report(sk);
>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Maybe this is the last time we can avoid taking socket lock in
tcp_poll() ;)
^ permalink raw reply
* Re: [dm-devel] idr_get_new_exact ?
From: Alasdair G Kergon @ 2010-09-20 21:38 UTC (permalink / raw)
To: device-mapper development, Roland Dreier, Ohad Ben-Cohen, akpm,
Steve Wise, linux-
In-Reply-To: <4C97D197.9070703@gmail.com>
On Mon, Sep 20, 2010 at 11:26:47PM +0200, Tejun Heo wrote:
> I agree. Wouldn't those users better off simply using radix tree?
Can't speak for the other users, but dm uses it both ways - normally
happy with any id (minor number), but sometimes user requires a specific
one.
Alasdair
^ permalink raw reply
* Re: Regression, bisected: reference leak with IPSec since ~2.6.31
From: Eric Dumazet @ 2010-09-20 21:31 UTC (permalink / raw)
To: Nick Bowler; +Cc: linux-kernel, netdev, David S. Miller
In-Reply-To: <1285013853.2323.148.camel@edumazet-laptop>
Le lundi 20 septembre 2010 à 22:17 +0200, Eric Dumazet a écrit :
> Le lundi 20 septembre 2010 à 15:52 -0400, Nick Bowler a écrit :
> > On 2010-09-20 20:20 +0200, Eric Dumazet wrote:
> > > If you change your program to send small frames (so they are not
> > > fragmented), is the problem still present ?
> >
> > I changed MAX_DGRAM_SIZE in the test program to 1000 (mtu on the
> > interface is 1500). The short answer is that the references are
> > not leaked, and things seem to get cleaned up. So the rest of this
> > mail probably describes a separate issue.
> >
> > The long answer, however, is interesting: With latest Linus' git, the
> > references are cleaned up much later than I would expect. After running
> > the test program and flushing the SAD/SPD, the reference count is still
> > 1. If I repeat the test immediately, the reference count will increase
> > further. I can easily raise the reference count to, say, 100. Now, if
> > I wait a while (10 minutes or so), the reference count will still be
> > 100. However, when I run the setkey script after this delay, the
> > reference count drops immediately to 1. If I then flush the SAD/SPD, it
> > drops to 0.
> >
> > This behaviour is new: newer than the reported leak. For example, with
> > 2.6.34, everything works perfectly with MAX_DGRAM_SIZE set to 1000 (the
> > SAs are destroyed immediately when the SAD/SPD are flushed), but the
> > leak occurs with MAX_DGRAM_SIZE set to 10000.
> >
>
> Thanks Nick
>
> I suspect a skb->truesize bug somewhere.
>
> I can see atomic_read(&sk->sk_wmem_alloc) becoming negative after a
> while...
>
> I am investigating and let you know.
>
> Thanks
>
OK, I found a bug in ip_fragment() and ip6_fragment()
In case slow_path is hit, we have a truesize mismatch
Could you try following patch ?
Thanks !
[PATCH] ip : fix truesize mismatch in ip fragmentation
We should not set frag->destructor to sock_wkfree() until we are sure we
dont hit slow path in ip_fragment(). Or we risk uncharging
frag->truesize twice, and in the end, having negative socket
sk_wmem_alloc counter, or even freeing socket sooner than expected.
Many thanks to Nick Bowler, who provided a very clean bug report and
test programs.
While Nick bisection pointed to commit 2b85a34e911bf483 (net: No more
expensive sock_hold()/sock_put() on each tx), underlying bug is older.
Reported-and-bisected-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/ip_output.c | 8 ++++----
net/ipv6/ip6_output.c | 10 +++++-----
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 04b6989..126d9b3 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -490,7 +490,6 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
if (skb_has_frags(skb)) {
struct sk_buff *frag;
int first_len = skb_pagelen(skb);
- int truesizes = 0;
if (first_len - hlen > mtu ||
((first_len - hlen) & 7) ||
@@ -510,11 +509,13 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
goto slow_path;
BUG_ON(frag->sk);
- if (skb->sk) {
+ }
+ if (skb->sk) {
+ skb_walk_frags(skb, frag) {
frag->sk = skb->sk;
frag->destructor = sock_wfree;
+ skb->truesize -= frag->truesize;
}
- truesizes += frag->truesize;
}
/* Everything is OK. Generate! */
@@ -524,7 +525,6 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
frag = skb_shinfo(skb)->frag_list;
skb_frag_list_init(skb);
skb->data_len = first_len - skb_headlen(skb);
- skb->truesize -= truesizes;
skb->len = first_len;
iph->tot_len = htons(first_len);
iph->frag_off = htons(IP_MF);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index d40b330..10983ab 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -639,7 +639,6 @@ static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
if (skb_has_frags(skb)) {
int first_len = skb_pagelen(skb);
- int truesizes = 0;
if (first_len - hlen > mtu ||
((first_len - hlen) & 7) ||
@@ -658,13 +657,15 @@ static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
goto slow_path;
BUG_ON(frag->sk);
- if (skb->sk) {
+ }
+ if (skb->sk) {
+ skb_walk_frags(skb, frag) {
frag->sk = skb->sk;
frag->destructor = sock_wfree;
- truesizes += frag->truesize;
+ skb->truesize -= frag->truesize;
}
}
-
+
err = 0;
offset = 0;
frag = skb_shinfo(skb)->frag_list;
@@ -693,7 +694,6 @@ static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
first_len = skb_pagelen(skb);
skb->data_len = first_len - skb_headlen(skb);
- skb->truesize -= truesizes;
skb->len = first_len;
ipv6_hdr(skb)->payload_len = htons(first_len -
sizeof(struct ipv6hdr));
^ permalink raw reply related
* Re: E1000E/82567LM-3: link reported up too soon
From: Arnaud Ebalard @ 2010-09-20 21:28 UTC (permalink / raw)
To: David Miller; +Cc: brian.haley, netdev
In-Reply-To: <20100920.131839.173838219.davem@davemloft.net>
Hi,
David Miller <davem@davemloft.net> writes:
> From: arno@natisbad.org (Arnaud Ebalard)
> Date: Mon, 20 Sep 2010 22:09:16 +0200
>
>> The packets sent are an IPv6 Router Solicitation (to get IPv6 subnet
>> prefixes from the router) and a DHCP Request (to get an IPv4 address
>> from the DHCP server).
>>
>> The former is sent from the unspecified address (::) and the latter from
>> 0.0.0.0. The former is sent by UMIP Mobile IPv6 daemon. The second by my
>> DHCP client. They both use netlink to do that as soon as the link is up.
>> Both are for address configuration ...
>
> So do both DHCP request and the IPV6 RS get dropped, or just the IPV6 RS?
I added printk() to see where/if those first packets get dropped in
e1000e code. I followed those first packets to e1000_xmit_frame() and
don't see anything obvious happening there, i.e. they are passed to the
device as expected.
If I find some time tomorrow, I will try and take a look at
e1000_watchdog_task() and other functions that may perform asynchronous
tasks.
Cheers,
a+
^ permalink raw reply
* Re: [RFC][PATCH 1/4] IRQ: IRQ groups for multiqueue devices
From: Thomas Gleixner @ 2010-09-20 21:27 UTC (permalink / raw)
To: Ben Hutchings
Cc: Tom Herbert, netdev, linux-net-drivers, linux-kernel,
Peter Zijlstra, Ingo Molnar
In-Reply-To: <1285009685.2282.127.camel@achroite.uk.solarflarecom.com>
Ben,
On Mon, 20 Sep 2010, Ben Hutchings wrote:
it would have been nice if I'd been cc'ed on that, but of course it's
my fault that there is no entry in MAINTAINERS. No, it's not.
> When initiating I/O on multiqueue devices, we usually want to select a
"we usually" is pretty useless for people not familiar with the
problem at hand. A [PATCH 0/4] intro would have been helpful along
with the users (aka [PATCH 2-4/4]) of the new facility.
Don't take it personally and I'm sure that you're solving a real world
problem, but I'm starting to get grumpy that especially networking
folks (aside of various driver developers) believe that adding random
stuff to kernel/irq is their private pleasure. Is it that hard to talk
to me upfront ?
> queue for which the response will be handled on the same or a nearby
> CPU. IRQ groups hold a mapping of CPU to IRQ which will be updated
> based on the inverse of IRQ CPU-affinities plus CPU topology
> information.
Can you please explain, why you need that reverse mapping including
the below code ? What problem does this solve which can not be deduced
by the exisiting information/infrastructure ? And why is that reverse
mapping tied to interrupts and not something which we want to see in
some generic available (library) code ?
More comments inline.
> ---
> include/linux/irq.h | 52 ++++++++++++++++++
> kernel/irq/manage.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 201 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index c03243a..bbddd5f 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -196,6 +196,8 @@ struct irq_desc {
> #ifdef CONFIG_SMP
> cpumask_var_t affinity;
> const struct cpumask *affinity_hint;
How about updating the kernel doc above the struct ?
> + struct irq_group *group;
Grr, how does this compile ? That needs at least a forward
declaration of struct irq_group. RFC is _NOT_ an excuse
> + u16 group_index;
What's group_index doing and what's the point of an u16 here ?
> unsigned int node;
> #ifdef CONFIG_GENERIC_PENDING_IRQ
> cpumask_var_t pending_mask;
> @@ -498,6 +500,33 @@ static inline void free_desc_masks(struct irq_desc *old_desc,
> #endif
> }
>
> +/**
> + * struct irq_group - IRQ group for multiqueue devices
> + * @closest: For each CPU, the index and distance to the closest IRQ,
> + * based on affinity masks
index of what ?
Btw, please follow the style of the other kernel doc comments in this
file where the explanation is aligned for readability sake
> + * @size: Size of the group
> + * @used: Number of IRQs currently included in the group
> + * @irq: Descriptors for IRQs in the group
That's an array of pointers to irq descriptors, right ?
Insert some sensible decription what irq groups are and for which
problem space they are useful if at all.
> + */
> +struct irq_group {
> + struct {
> + u16 index;
> + u16 dist;
> + } closest[NR_CPUS];
> + unsigned int size, used;
Separate lines please
> + struct irq_desc *irq[0];
> +};
Please separate this with a newline and add some useful comment
about the meaning and purpose of this not selfexplaining constant.
> +#define IRQ_CPU_DIST_INF 0xffff
> +static inline u16 irq_group_get_index(struct irq_group *group, int cpu)
> +{
> + return group->closest[cpu].index;
> +}
> +
So you have an accessor function for closest[cpu].index. Are the
other members meant to be accessible directly by random driver ?
> #else /* !CONFIG_SMP */
>
> static inline bool alloc_desc_masks(struct irq_desc *desc, int node,
> @@ -519,6 +548,29 @@ static inline void free_desc_masks(struct irq_desc *old_desc,
> struct irq_desc *new_desc)
> {
> }
> +
> +struct irq_group {
> +};
> +
> +static inline struct irq_group *alloc_irq_group(unsigned int size, gfp_t flags)
> +{
> + static struct irq_group dummy;
That will create one static instance per callsite. Is that on
purpose? If yes, it needs a damned good comment.
> + return &dummy;
> #endif /* CONFIG_SMP */
>
> #endif /* _LINUX_IRQ_H */
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index c3003e9..3f2b1a9 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -100,6 +100,154 @@ void irq_set_thread_affinity(struct irq_desc *desc)
> }
> }
>
> +static void irq_group_update_neigh(struct irq_group *group,
> + const struct cpumask *mask,
> + u16 index, u16 dist)
> +{
> + int cpu;
> +
> + for_each_cpu(cpu, mask) {
> + if (dist < group->closest[cpu].dist) {
> + group->closest[cpu].index = index;
> + group->closest[cpu].dist = dist;
> + }
> + }
> +}
I have not the faintest idea how group, index and dist are related
to each other. And I have no intention to decode the information
about that piecewise by reverse engineering that obfuscated code.
> +static bool irq_group_copy_neigh(struct irq_group *group, int cpu,
> + const struct cpumask *mask, u16 dist)
> +{
> + int neigh;
> +
> + for_each_cpu(neigh, mask) {
> + if (group->closest[neigh].dist <= dist) {
> + group->closest[cpu].index = group->closest[neigh].index;
> + group->closest[cpu].dist = dist;
> + return true;
> + }
> + }
> + return false;
What's the reason for copying or not ?
> +}
> +
> +/* Update the per-CPU closest IRQs following a change of affinity */
> +static void
> +irq_update_group(struct irq_desc *desc, const struct cpumask *affinity)
> +{
> + struct irq_group *group = desc->group;
> + unsigned index = desc->group_index;
> + int cpu;
> +
> + if (!group)
> + return;
> +
> + /* Invalidate old distances to this IRQ */
> + for_each_online_cpu(cpu)
> + if (group->closest[cpu].index == index)
> + group->closest[cpu].dist = IRQ_CPU_DIST_INF;
> +
> + /*
> + * Set this as the closest IRQ for all CPUs in the affinity mask,
> + * plus the following CPUs if they don't have a closer IRQ:
> + * - all other threads in the same core (distance 1);
> + * - all other cores in the same package (distance 2);
> + * - all other packages in the same NUMA node (distance 3).
> + */
> + for_each_cpu(cpu, affinity) {
> + group->closest[cpu].index = index;
> + group->closest[cpu].dist = 0;
> + irq_group_update_neigh(group, topology_thread_cpumask(cpu),
> + index, 1);
> + irq_group_update_neigh(group, topology_core_cpumask(cpu),
> + index, 2);
> + irq_group_update_neigh(group, cpumask_of_node(cpu_to_node(cpu)),
> + index, 3);
> + }
> +
> + /* Find new closest IRQ for any CPUs left with invalid distances */
> + for_each_online_cpu(cpu) {
> + if (!(group->closest[cpu].index == index &&
> + group->closest[cpu].dist == IRQ_CPU_DIST_INF))
> + continue;
> + if (irq_group_copy_neigh(group, cpu,
> + topology_thread_cpumask(cpu), 1))
> + continue;
> + if (irq_group_copy_neigh(group, cpu,
> + topology_core_cpumask(cpu), 2))
> + continue;
> + if (irq_group_copy_neigh(group, cpu,
> + cpumask_of_node(cpu_to_node(cpu)), 3))
> + continue;
> + /* We could continue into NUMA node distances, but for now
> + * we give up. */
What are the consequences of giving up ? Does not happen ? Should
not happen ? Will break ? Don't care ? ....
> + }
This is called from irq_set_affinity() with desc->lock held and
interrupts disabled. You're not serious about that, are you ?
Damned, there are two iterations over each online cpu and another
one over the affinity mask. Did you ever extrapolate how long that
runs on a really large machine ?
If CPU affinity of an IRQ changes, then it does not matter if one or
two interrupts end up in the wrong space. Those changes are not
happening every other interrupt.
> +}
> +
> +/**
> + * alloc_irq_group - allocate IRQ group
> + * @size: Size of the group
size of what ? I guess number of interrupts, right ?
> + * @flags: Allocation flags e.g. %GFP_KERNEL
> + */
> +struct irq_group *alloc_irq_group(unsigned int size, gfp_t flags)
> +{
> + struct irq_group *group =
> + kzalloc(sizeof(*group) + size * sizeof(group->irq[0]), flags);
> + int cpu;
> +
> + if (!group)
> + return NULL;
> +
> + /* Initially assign CPUs to IRQs on a rota */
> + for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + group->closest[cpu].index = cpu % size;
So here we randomly assign index with the lower cpu numbers no
matter whether they are online or possible ?
> + group->closest[cpu].dist = IRQ_CPU_DIST_INF;
> + }
> +
> + group->size = size;
> + return group;
> +}
> +EXPORT_SYMBOL(alloc_irq_group);
EXPORT_SYMBOL_GPL if at all. Same for the other exports
> +
> +/**
> + * free_irq_group - free IRQ group
> + * @group: IRQ group allocated with alloc_irq_group(), or %NULL
How is this serialized or sanity checked against free_irq() ?
> + */
> +void free_irq_group(struct irq_group *group)
> +{
> + struct irq_desc *desc;
> + unsigned int i;
> +
> + if (!group)
> + return;
> +
> + /* Remove all descriptors from the group */
> + for (i = 0; i < group->used; i++) {
> + desc = group->irq[i];
> + BUG_ON(desc->group != group || desc->group_index != i);
> + desc->group = NULL;
> + }
> +
> + kfree(group);
> +}
> +EXPORT_SYMBOL(free_irq_group);
> +
> +/**
> + * irq_group_add - add IRQ to a group
> + * @group: IRQ group allocated with alloc_irq_group()
> + * @irq: Interrupt to add to group
> + */
> +void irq_group_add(struct irq_group *group, unsigned int irq)
> +{
> + struct irq_desc *desc = irq_to_desc(irq);
Again, how is this serialized against anything else fiddling with
irq_desc[irq]?
> + BUG_ON(desc->group);
> + BUG_ON(group->used >= group->size);
> +
> + desc->group = group;
> + desc->group_index = group->used;
> + group->irq[group->used++] = desc;
> +}
> +EXPORT_SYMBOL(irq_group_add);
Thanks,
tglx
^ permalink raw reply
* Re: idr_get_new_exact ?
From: Tejun Heo @ 2010-09-20 21:26 UTC (permalink / raw)
To: Roland Dreier
Cc: Ohad Ben-Cohen, linux-kernel, Jean Delvare (PC drivers, core),
Ben Dooks (embedded platforms), Roland Dreier, Sean Hefty,
Hal Rosenstock, Steve Wise, Neil Brown, Paul Mackerras, linux-i2c,
linux-rdma, dm-devel, linux-raid, linux-ppp, netdev, akpm
In-Reply-To: <adaiq20f90h.fsf@cisco.com>
Hello,
On 09/20/2010 10:35 PM, Roland Dreier wrote:
> Looks fine to me as an improvement over the status quo, but I wonder how
> many of these places could use the radix_tree stuff instead? If you're
> not using the ability of the idr code to assign an id for you, then it
> seems the radix_tree API is a better fit.
I agree. Wouldn't those users better off simply using radix tree?
Thanks.
--
tejun
^ permalink raw reply
* Re: Regression, bisected: reference leak with IPSec since ~2.6.31
From: Nick Bowler @ 2010-09-20 21:23 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, linux-kernel, netdev
In-Reply-To: <20100920.130047.124017922.davem@davemloft.net>
On 2010-09-20 13:00 -0700, David Miller wrote:
> From: Nick Bowler <nbowler@elliptictech.com>
> > The long answer, however, is interesting: With latest Linus' git, the
> > references are cleaned up much later than I would expect.
[...]
> This is because we actually cache IPSEC routes correctly, previously
> we'd create a new routing cache entry every time a lookup happened.
But this means that the SAs, including their cryptographic keys, are
kept in memory indefinitely after the SAD/SPD entries are destroyed.
Why aren't the cache entries invalidated when this occurs?
This also makes it extremely difficult to unload the xfrm modules,
something we often need to do during testing, as references to them
are held indefinitely.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: idr_get_new_exact ?
From: Roland Dreier @ 2010-09-20 20:35 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Jean Delvare (PC drivers, core), Ben Dooks (embedded platforms),
Roland Dreier, Sean Hefty, Hal Rosenstock, Steve Wise, Neil Brown,
Paul Mackerras, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-ppp-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <AANLkTi=ZLupVyFR0e2v-TLpeNWdw1bVMZUAhgyxLJ7OV-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Occasionally, drivers care about the value that idr associates with
> their pointers.
>
> Today we have idr_get_new_above() which allocates a new idr entry
> above or equal to a given starting id, but sometimes drivers need to
> force an exact value.
>
> To overcome this small API gap, drivers are wrapping idr_get_new_above
> and then either BUG_ON() or just call idr_remove() and returns -EBUSY
> when idr allocates them an id which is different than their requested
> value.
Looks fine to me as an improvement over the status quo, but I wonder how
many of these places could use the radix_tree stuff instead? If you're
not using the ability of the idr code to assign an id for you, then it
seems the radix_tree API is a better fit.
- R.
^ permalink raw reply
* Re: E1000E/82567LM-3: link reported up too soon
From: Arnaud Ebalard @ 2010-09-20 20:22 UTC (permalink / raw)
To: David Miller; +Cc: brian.haley, netdev
In-Reply-To: <20100920.131839.173838219.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> So do both DHCP request and the IPV6 RS get dropped, or just the IPV6 RS?
both.
^ permalink raw reply
* Re: E1000E/82567LM-3: link reported up too soon
From: David Miller @ 2010-09-20 20:18 UTC (permalink / raw)
To: arno; +Cc: brian.haley, netdev
In-Reply-To: <87y6awjhxv.fsf@small.ssi.corp>
From: arno@natisbad.org (Arnaud Ebalard)
Date: Mon, 20 Sep 2010 22:09:16 +0200
> The packets sent are an IPv6 Router Solicitation (to get IPv6 subnet
> prefixes from the router) and a DHCP Request (to get an IPv4 address
> from the DHCP server).
>
> The former is sent from the unspecified address (::) and the latter from
> 0.0.0.0. The former is sent by UMIP Mobile IPv6 daemon. The second by my
> DHCP client. They both use netlink to do that as soon as the link is up.
> Both are for address configuration ...
So do both DHCP request and the IPV6 RS get dropped, or just the IPV6 RS?
^ permalink raw reply
* Re: Regression, bisected: reference leak with IPSec since ~2.6.31
From: Eric Dumazet @ 2010-09-20 20:17 UTC (permalink / raw)
To: Nick Bowler; +Cc: linux-kernel, netdev, David S. Miller
In-Reply-To: <20100920195256.GA14330@elliptictech.com>
Le lundi 20 septembre 2010 à 15:52 -0400, Nick Bowler a écrit :
> On 2010-09-20 20:20 +0200, Eric Dumazet wrote:
> > If you change your program to send small frames (so they are not
> > fragmented), is the problem still present ?
>
> I changed MAX_DGRAM_SIZE in the test program to 1000 (mtu on the
> interface is 1500). The short answer is that the references are
> not leaked, and things seem to get cleaned up. So the rest of this
> mail probably describes a separate issue.
>
> The long answer, however, is interesting: With latest Linus' git, the
> references are cleaned up much later than I would expect. After running
> the test program and flushing the SAD/SPD, the reference count is still
> 1. If I repeat the test immediately, the reference count will increase
> further. I can easily raise the reference count to, say, 100. Now, if
> I wait a while (10 minutes or so), the reference count will still be
> 100. However, when I run the setkey script after this delay, the
> reference count drops immediately to 1. If I then flush the SAD/SPD, it
> drops to 0.
>
> This behaviour is new: newer than the reported leak. For example, with
> 2.6.34, everything works perfectly with MAX_DGRAM_SIZE set to 1000 (the
> SAs are destroyed immediately when the SAD/SPD are flushed), but the
> leak occurs with MAX_DGRAM_SIZE set to 10000.
>
Thanks Nick
I suspect a skb->truesize bug somewhere.
I can see atomic_read(&sk->sk_wmem_alloc) becoming negative after a
while...
I am investigating and let you know.
Thanks
^ permalink raw reply
* Re: E1000E/82567LM-3: link reported up too soon
From: Arnaud Ebalard @ 2010-09-20 20:09 UTC (permalink / raw)
To: David Miller; +Cc: brian.haley, netdev
In-Reply-To: <20100920.125447.220082714.davem@davemloft.net>
Hi David,
David Miller <davem@davemloft.net> writes:
> From: arno@natisbad.org (Arnaud Ebalard)
> Date: Mon, 20 Sep 2010 20:57:46 +0200
>
>> On some ethernet devices (at least), link may be reported up (NEWLINK
>> received by userspace with flags indicating UP and RUNNING) before the
>> interface is really usable. When sending packets as soon as the link is
>> available, the first one may be dropped. That's what you see on the
>> capture above.
>
> The link being up doesn't mean an address has been assigned to the
> interface for the protocol you are using yet.
>
> I think you have to schedule whatever it is you need to make sure it
> runs after dhcp successfully complete.
Maybe I was a bit unclear.
The packets sent are an IPv6 Router Solicitation (to get IPv6 subnet
prefixes from the router) and a DHCP Request (to get an IPv4 address
from the DHCP server).
The former is sent from the unspecified address (::) and the latter from
0.0.0.0. The former is sent by UMIP Mobile IPv6 daemon. The second by my
DHCP client. They both use netlink to do that as soon as the link is up.
Both are for address configuration ...
Cheers,
a+
^ permalink raw reply
* Re: idr_get_new_exact ?
From: Steve Wise @ 2010-09-20 20:07 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Jean Delvare (PC drivers, core), Ben Dooks (embedded platforms),
Roland Dreier, Sean Hefty, Hal Rosenstock, Steve Wise, Neil Brown,
Paul Mackerras, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-ppp-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100920123140.f524de79.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On 09/20/2010 02:31 PM, Andrew Morton wrote:
> On Mon, 20 Sep 2010 16:11:31 +0200
> Ohad Ben-Cohen<ohad-Ix1uc/W3ht7QT0dZR+AlfA@public.gmane.org> wrote:
>
>
>> Occasionally, drivers care about the value that idr associates with
>> their pointers.
>>
>> Today we have idr_get_new_above() which allocates a new idr entry
>> above or equal to a given starting id, but sometimes drivers need to
>> force an exact value.
>>
>> To overcome this small API gap, drivers are wrapping idr_get_new_above
>> and then either BUG_ON() or just call idr_remove() and returns -EBUSY
>> when idr allocates them an id which is different than their requested
>> value.
>>
>> There are only a handful of users who need this (see below. especially
>> note the i2c comment :), but it might be nice to have such an API (a
>> bit less of code, and a bit less error prone).
>>
>> Would something like the below be desirable/acceptable ?
>>
> It seems OK to me - it's an improvement over what we have now.
>
>
Looks ok to me also. This is exactly what cxgb* needs. IE the driver
manages the ID space and never expects an idr insertion to fail because
its already inserted. That constitutes a driver bug (which is why the
BUG_ON() is there :)).
Steve.
^ permalink raw reply
* Re: Regression, bisected: reference leak with IPSec since ~2.6.31
From: David Miller @ 2010-09-20 20:00 UTC (permalink / raw)
To: nbowler; +Cc: eric.dumazet, linux-kernel, netdev
In-Reply-To: <20100920195256.GA14330@elliptictech.com>
From: Nick Bowler <nbowler@elliptictech.com>
Date: Mon, 20 Sep 2010 15:52:56 -0400
> On 2010-09-20 20:20 +0200, Eric Dumazet wrote:
>> If you change your program to send small frames (so they are not
>> fragmented), is the problem still present ?
>
> I changed MAX_DGRAM_SIZE in the test program to 1000 (mtu on the
> interface is 1500). The short answer is that the references are
> not leaked, and things seem to get cleaned up. So the rest of this
> mail probably describes a separate issue.
>
> The long answer, however, is interesting: With latest Linus' git, the
> references are cleaned up much later than I would expect. After running
> the test program and flushing the SAD/SPD, the reference count is still
> 1. If I repeat the test immediately, the reference count will increase
> further. I can easily raise the reference count to, say, 100. Now, if
> I wait a while (10 minutes or so), the reference count will still be
> 100. However, when I run the setkey script after this delay, the
> reference count drops immediately to 1. If I then flush the SAD/SPD, it
> drops to 0.
This is because we actually cache IPSEC routes correctly, previously
we'd create a new routing cache entry every time a lookup happened.
^ permalink raw reply
* 2.6.36-rc4-git5: Reported regressions 2.6.34 -> 2.6.35
From: Rafael J. Wysocki @ 2010-09-20 19:54 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some post-2.6.34 regressions introduced before
2.6.35, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.34 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-09-20 137 27 25
2010-09-12 135 26 25
2010-08-30 124 38 34
2010-08-01 100 27 23
2010-07-23 94 33 25
2010-07-09 79 45 37
2010-06-21 46 37 26
2010-06-09 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18522
Subject : [REGRESSION] cdrom drive doesn't detect removal
Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-12 9:49 (9 days old)
First-Bad-Commit: http://git.kernel.org/linus/6b4517a7913a09d3259bb1d21c9cb300f12294bd
Message-ID : <1284284969.2928.18.camel@maxim-laptop>
References : http://marc.info/?l=linux-kernel&m=128428499013930&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18272
Subject : 2.6.35.*: horrible (exponential? >linear) slowdown to unusability (ACPI idle?)
Submitter : Nix <nix-dKoSMcxRz+Te9xe1eoZjHA@public.gmane.org>
Date : 2010-09-05 0:51 (16 days old)
First-Bad-Commit: http://git.kernel.org/linus/30a564be9d9554c168a654eddc2165869cc0d7bf
Message-ID : <87zkvx2ese.fsf-AdTWujXS48Mg67Zj9sPl2A@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128364994602942&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18202
Subject : Microphone levels too low
Submitter : Alexander Hunziker <alex.hunziker-Mds7TqofYmjt3F02DXVmkw@public.gmane.org>
Date : 2010-09-09 22:20 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18032
Subject : No sound on headphone jack
Submitter : Alexander Hunziker <alex.hunziker-Mds7TqofYmjt3F02DXVmkw@public.gmane.org>
Date : 2010-09-07 21:45 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17812
Subject : Kernel completely frozen when memory is full
Submitter : Mickey86 <mikael.cordon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-05 13:09 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17772
Subject : Unable to locate IOAPIC for GSI *
Submitter : zersaa <zersaa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-04 21:28 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17732
Subject : [2.6.35.x regression] rcu_preempt_state stall warning and machine slow-downs
Submitter : Matthias Dahl <ml_kernel-Rk1lLwyeSiSCvTm3UDtA3g@public.gmane.org>
Date : 2010-09-01 6:47 (20 days old)
Message-ID : <201009010847.20236.ml_kernel-Rk1lLwyeSiSCvTm3UDtA3g@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128332418629305&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16691
Subject : IPW5100: iwlagn broken with 2.6.34.x to 2.6.35.2 update
Submitter : Can Celasun <dcelasun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-08-21 08:28 (31 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16633
Subject : ath5k + 2.6.35 x86 + hostapd - Failed to set channel
Submitter : NiTr0 <nitr0-z9XQkeP78BxUq1AO9QMCaQ@public.gmane.org>
Date : 2010-08-19 19:37 (33 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16614
Subject : [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[<ffffffffa004fbc5>] [<ffffffffa004fbc5>] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
Submitter : Sander Eikelenboom <linux-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
Date : 2010-08-10 22:12 (42 days old)
Message-ID : <61936849.20100811001257-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128152075830927&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16562
Subject : 2.6.35: cpu_idle bug report / on i7 870 cpu (x86_64)
Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
Date : 2010-08-06 22:09 (46 days old)
Message-ID : <alpine.DEB.2.00.1008061800530.5241-0qmrozcXWo8bm2hyYBkBBg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128113260904048&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16549
Subject : 2.6.35: suspicious rcu_dereference_check() usage
Submitter : Vladislav Bolkhovitin <vst-d+Crzxg7Rs0@public.gmane.org>
Date : 2010-08-04 10:56 (48 days old)
Message-ID : <4C594740.1090608-d+Crzxg7Rs0@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128091938215177&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16537
Subject : TREE_RCU hangs at boot
Submitter : Rolf Eike Beer <eike-kernel-F+mm6HnICJmzQB+pC5nmwQ@public.gmane.org>
Date : 2010-08-07 12:18 (45 days old)
Handled-By : Paul E. McKenney <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16525
Subject : unexpected high load since 2.6.35
Submitter : MadLoisae-hi6Y0CQ0nG0@public.gmane.org <MadLoisae-hi6Y0CQ0nG0@public.gmane.org>
Date : 2010-08-02 20:53 (50 days old)
Message-ID : <4C573041.1070103-hi6Y0CQ0nG0@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128078243726655&w=2
http://lkml.org/lkml/2010/9/14/105
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16515
Subject : [bisected] Radeon rv280 can't boot on kernel 2.6.35.
Submitter : Albert Gall <ss3vdr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-08-04 16:10 (48 days old)
First-Bad-Commit: http://git.kernel.org/linus/https://bugzilla.kernel.org/attachment.cgi?id=27350
Handled-By : Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16495
Subject : Kernel 2.6.35 takes almost half an hour to boot
Submitter : Claudio M. Camacho <claudiomkd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-08-02 17:16 (50 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16488
Subject : [i915] Framebuffer ID error after suspend/hibernate leading to X crash
Submitter : Milan Bouchet-Valat <nalimilan-pqIVbhRXszc@public.gmane.org>
Date : 2010-08-01 08:55 (51 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to AP on legal channel 13
Submitter : Daniel J Blueman <daniel.blueman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-25 17:06 (58 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16458
Subject : Bluetooth disabled after resume
Submitter : AttilaN <attila123456-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-25 09:33 (58 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16380
Subject : Loop devices act strangely in 2.6.35
Submitter : Artem S. Tashkinov <t.artem-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date : 2010-07-13 23:21 (70 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16322
Subject : WARNING: at /arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x5a/0x70()
Submitter : boris64 <bugzilla.kernel.org-ro/BP3KN3ujR7s880joybQ@public.gmane.org>
Date : 2010-07-01 13:54 (82 days old)
Handled-By : H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16265
Subject : Why is kslowd accumulating so much CPU time?
Submitter : Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
Date : 2010-06-09 18:36 (104 days old)
First-Bad-Commit: http://git.kernel.org/linus/fbf81762e385d3d45acad057b654d56972acf58c
Message-ID : <E1OMQ88-0002a1-Gb-UK71uKi2zisAobODsErMgNi2O/JbrIOy@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127610857819033&w=4
http://bugs.freedesktop.org/show_bug.cgi?id=29536
Handled-By : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
Submitter : Brian Bloniarz <brian.bloniarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-16 17:57 (97 days old)
Handled-By : Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-11 20:31 (102 days old)
Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16184
Subject : Container, X86-64, i386, iptables rule
Submitter : Jean-Marc Pigeon <jmp-4qkeo2rQ0gg@public.gmane.org>
Date : 2010-06-12 04:17 (101 days old)
Handled-By : Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16396
Subject : [bisected] resume from suspend freezes system
Submitter : tomas m <tmezzadra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-15 02:32 (68 days old)
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=30822
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <zdenek.kabelac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-28 9:40 (85 days old)
Message-ID : <AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/00884.html
Handled-By : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=30282
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.34 and 2.6.35, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16055
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: E1000E/82567LM-3: link reported up too soon
From: David Miller @ 2010-09-20 19:54 UTC (permalink / raw)
To: arno; +Cc: brian.haley, netdev
In-Reply-To: <878w2wnsyd.fsf@small.ssi.corp>
From: arno@natisbad.org (Arnaud Ebalard)
Date: Mon, 20 Sep 2010 20:57:46 +0200
> On some ethernet devices (at least), link may be reported up (NEWLINK
> received by userspace with flags indicating UP and RUNNING) before the
> interface is really usable. When sending packets as soon as the link is
> available, the first one may be dropped. That's what you see on the
> capture above.
The link being up doesn't mean an address has been assigned to the
interface for the protocol you are using yet.
I think you have to schedule whatever it is you need to make sure it
runs after dhcp successfully complete.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox