* Executor of the estate of Late Mr. Christopher Friedrich [Reply To: lawfirmchambers16@yahoo.com.hk]
From: Marinús Pires Lima Soares @ 2010-10-24 5:27 UTC (permalink / raw)
Late Mr. Christopher Friedrich bequeathed US$20, 500,000.00 USD, to you in his will. More info,contact your attorney(Browne Jacobson Esq.) via email address; lawfirmchambers16@yahoo.com.hk<mailto:lawfirmchambers16@yahoo.com.hk> or call;+447024057921
^ permalink raw reply
* PLEASE DO REPLY FOR MORE DETAILS.
From: Mr.Ziman @ 2010-10-24 5:45 UTC (permalink / raw)
My name is Mr Zima Roland.I work with bank of Africa here in Burkina Faso West Africa. I have a deal which I will need your assistant, so that we can join hand together and claim this fund transfer into your bank account. Please do reply for more detail.Note that you are going to contact me via my privete email: zima.roland33@gmail.com
Thanks
Mr Zima Roland.
+22675437292.
^ permalink raw reply
* RE: [PATCH v2 11/14] bnx2x: Update bnx2x to use new vlan accleration.
From: Vladislav Zolotarov @ 2010-10-24 9:21 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Hao Zheng, Eilon Greenstein
In-Reply-To: <AANLkTinudtxjGAEcc9cLjn+7Y7kqcaQXMW_5SRoNe5QU@mail.gmail.com>
> >
> > We hit the same BUG() both when VLAN stripping is disabled.
>
> This one surprises me because that function shouldn't get called at
> all when VLAN stripping is disabled. Are you sure that it is
> disabled? From my reading of the bnx2x driver it seems like it is
> always enabled.
I tried to check all possibilities and to check at which level the problem is,
so I patched the bnx2x not to do the stripping and recompiled it with the
kernel having CONFIG_VLAN_8021Q disabled. Then I saw the (same) BUG() message
again. It seems to me that your patch series were meant to remove the
handling of this configuration (CONFIG_VLAN_8021Q) from the L2 drivers
as well, isn't it? This means that the same VLAN flows, both accelerated and none
accelerated should be "active" both when this configuration is present and
when it's not... Do I get it right?
Thanks,
vlad
^ permalink raw reply
* Re: tap0 device stopped working in 2.6.36 (ok in 2.6.35)
From: Jim @ 2010-10-24 9:59 UTC (permalink / raw)
To: Nolan Leake; +Cc: netdev
In-Reply-To: <1287862760.7499.225.camel@voxel>
Nolan,
Thanks for explaining the purpose of the patch.
But it appears something is missing and I think it breaks current
userspace. I use this tap0 device together with VirtualBox, I have a
virtual machine setup as bridged to tap0, not a very odd or strange
setup (this used to be the only method).
On the host side I run dhcpd to hand out IP address to the virtual
machine, but despite the dhcpd running on the tap0 device it never got
'ready' in the sense that no IP packets made it out from the host to the
guest.
On 10/23/2010 09:39 PM, Nolan Leake wrote:
> On Sat, 2010-10-23 at 14:55 +0200, Jim wrote:
>> After some checking noticed that apparently link isn't ready:
>> modprobe tun
>> tunctl -b
>> ifconfig tap0 192.168.20.1 up
>> Gives:
>> [ 26.411932] ADDRCONF(NETDEV_UP): tap0: link is not ready
>>
>> Bisected it all the way to this commit:
>>
>> =================
>>
>> # git bisect good
>> bee31369ce16fc3898ec9a54161248c9eddb06bc is the first bad commit
>> commit bee31369ce16fc3898ec9a54161248c9eddb06bc
>> Author: Nolan Leake <nolan@cumulusnetworks.com>
>> Date: Tue Jul 27 13:53:43 2010 +0000
>>
>> tun: keep link (carrier) state up to date
>>
>> Currently, only ethtool can get accurate link state of a tap device.
>> With this patch, IFF_RUNNING and IF_OPER_UP/DOWN are kept up to date as
>> well.
>>
>> Signed-off-by: Nolan Leake <nolan@cumulusnetworks.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Hello Jim,
>
> Thank you for the report and the bisect. Please allow me to explain the
> intention of this patch.
>
> Previous to this patch, tun.c only kept the ethtool link state up to
> date. IFF_ and IF_OPER_ state were always RUNNING and UP, respectively.
>
> Ethtool link state was (and is) controlled by mapping "tun device FD
> open" to link up, and "tun device FD closed" to link down. Obviously if
> you've just used tunctl to create a tap device, and no process has yet
> opened the /dev/net/tun backing FD, then this method establishes the
> link as down. Ethtool on a kernel that predates this patch will confirm
> this.
>
> What this patch does is make the IFF_RUNNING/IFF_OPER_UP state also
> match this interpretation of link state. Making RUNNING and OPER_UP
> consistent with ethtool's concept of link state is, I believe,
> consistent with how other ethernet devices work. The presence of a
> process that is sending and receiving packets via the tap device is a
> decent analog of link-state for a physical ethernet device.
>
> Could your use-case be solved by a udev rule that assigns the IP address
> when the link state changes to UP/RUNNING?
>
> If this is a common way to use tap devices, one possible solution is to
> make newly created but unattached tap devices default to UP/RUNNING (and
> presumably ethtool link-up, for consistency), and then only begin
> accurately reporting link state for subsequent open/closes of
> the /dev/net/tun device.
>
> - nolan
>
^ permalink raw reply
* RE: [PATCH v2 11/14] bnx2x: Update bnx2x to use new vlan accleration.
From: Vladislav Zolotarov @ 2010-10-24 10:11 UTC (permalink / raw)
To: Vladislav Zolotarov, Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Hao Zheng, Eilon Greenstein
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDEE6B11FD@SJEXCHCCR02.corp.ad.broadcom.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Vladislav Zolotarov
> Sent: Sunday, October 24, 2010 11:22 AM
> To: Jesse Gross
> Cc: David Miller; netdev@vger.kernel.org; Hao Zheng; Eilon Greenstein
> Subject: RE: [PATCH v2 11/14] bnx2x: Update bnx2x to use new vlan
> accleration.
>
>
>
> > >
> > > We hit the same BUG() both when VLAN stripping is disabled.
> >
> > This one surprises me because that function shouldn't get called at
> > all when VLAN stripping is disabled. Are you sure that it is
> > disabled? From my reading of the bnx2x driver it seems like it is
> > always enabled.
>
> I tried to check all possibilities and to check at which level the
> problem is,
> so I patched the bnx2x not to do the stripping and recompiled it with
> the
> kernel having CONFIG_VLAN_8021Q disabled. Then I saw the (same) BUG()
> message
> again. It seems to me that your patch series were meant to remove the
> handling of this configuration (CONFIG_VLAN_8021Q) from the L2 drivers
> as well, isn't it? This means that the same VLAN flows, both
> accelerated and none
> accelerated should be "active" both when this configuration is present
> and
> when it's not... Do I get it right?
>
> Thanks,
> vlad
Jesse, from the fix u posted I conclude that the answer on the above questions is
obviously "yes"... ;)
I first answered your question and only then looked at the "fixing"
thread, my apologies... ;)
thanks,
vlad
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (adding ipv6 address to interface)
From: Michael Leun @ 2010-10-24 13:15 UTC (permalink / raw)
Cc: David Lamparter, Eric W. Biederman, Greg KH, netdev, davem,
linux-kernel, Alexey Dobriyan, Patrick McHardy
In-Reply-To: <20101022190532.00e9e5d8@xenia.leun.net>
On Fri, 22 Oct 2010 19:05:32 +0200
Michael Leun <lkml20100708@newton.leun.net> wrote:
> On Fri, 22 Oct 2010 14:48:58 +0200
> David Lamparter <equinox@diac24.net> wrote:
>
> > On Thu, Oct 21, 2010 at 05:15:32PM +0200, Michael Leun wrote:
> > > unfortunately the bug described below originally reported in
> > > 2.6.35-rcX is still there in 2.6.36.
> >
> > can you post your full kernel .config?
>
> Please find below.
>
> > I'm using network namespaces quite extensively - OpenVPN and IPv6
> > included - and i haven't hit this bug. That makes it rather likely
> > it depends on some option difference.
>
> I take candidates for options to change for test... ;-)
>
> Maybe I will try to strip it down for test towards a minimal config.
Now I have tried a kernel config with almost everything disabled -
please find below.
If I have overlooked anything I should disable (or if you suggest I
should not disable, but enable any option) - please tell me.
I've created an ~2.5MB bootable ISO image based on buildroot/busybox
with this kernel, which also shows this bug (e.g. when run in
VirtualBox).
If anybody is interested I could send this image as mail attachment or
provide a download link.
ml@xenia:~> grep -v "^#" .config |grep -v "^ *$"
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_EARLY_RES=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_LZMA=y
CONFIG_TREE_RCU=y
CONFIG_RCU_FANOUT=32
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_NAMESPACES=y
CONFIG_NET_NS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_LZO=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_EVENTS=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_IOSCHED_NOOP=y
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_INLINE_SPIN_UNLOCK=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_M586=y
CONFIG_X86_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=5
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_XADD=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_DMI=y
CONFIG_NR_CPUS=1
CONFIG_PREEMPT_NONE=y
CONFIG_VM86=y
CONFIG_HIGHMEM4G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_NEED_NODE_MEMMAP_SIZE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_MTRR=y
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PHYSICAL_START=0x1000000
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_DOMAINS=y
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
CONFIG_BINFMT_ELF=y
CONFIG_HAVE_AOUT=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_NET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_FIB_HASH=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_IPV6=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_HAVE_IDE=y
CONFIG_SCSI_MOD=y
CONFIG_NETDEVICES=y
CONFIG_VETH=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=576
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPORT=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_SSB_POSSIBLE=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_FILE_LOCKING=y
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_FRAME_WARN=2048
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_TRACING_SUPPORT=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_EARLY_PRINTK=y
CONFIG_DOUBLEFAULT=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_HAVE_KVM=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
--
MfG,
Michael Leun
^ permalink raw reply
* [PATCH] netlink: fix netlink_change_ngroups()
From: Eric Dumazet @ 2010-10-24 14:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Johannes Berg, Paul E. McKenney
commit 6c04bb18ddd633 (netlink: use call_rcu for netlink_change_ngroups)
used a somewhat convoluted and racy way to perform call_rcu().
The old block of memory is freed after a grace period, but the rcu_head
used to track it is located in new block.
This can clash if we call two times or more netlink_change_ngroups(),
and a block is freed before another. call_rcu() called on different cpus
makes no guarantee in order of callbacks.
Fix this using a more standard way of handling this : Each block of
memory contains its own rcu_head, so that no 'use after free' can
happens.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Johannes Berg <johannes@sipsolutions.net>
CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
net/netlink/af_netlink.c | 65 +++++++++++++------------------------
1 files changed, 24 insertions(+), 41 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index cd96ed3..478181d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -83,9 +83,9 @@ struct netlink_sock {
struct module *module;
};
-struct listeners_rcu_head {
- struct rcu_head rcu_head;
- void *ptr;
+struct listeners {
+ struct rcu_head rcu;
+ unsigned long masks[0];
};
#define NETLINK_KERNEL_SOCKET 0x1
@@ -119,7 +119,7 @@ struct nl_pid_hash {
struct netlink_table {
struct nl_pid_hash hash;
struct hlist_head mc_list;
- unsigned long *listeners;
+ struct listeners __rcu *listeners;
unsigned int nl_nonroot;
unsigned int groups;
struct mutex *cb_mutex;
@@ -338,7 +338,7 @@ netlink_update_listeners(struct sock *sk)
if (i < NLGRPLONGS(nlk_sk(sk)->ngroups))
mask |= nlk_sk(sk)->groups[i];
}
- tbl->listeners[i] = mask;
+ tbl->listeners->masks[i] = mask;
}
/* this function is only called with the netlink table "grabbed", which
* makes sure updates are visible before bind or setsockopt return. */
@@ -936,7 +936,7 @@ EXPORT_SYMBOL(netlink_unicast);
int netlink_has_listeners(struct sock *sk, unsigned int group)
{
int res = 0;
- unsigned long *listeners;
+ struct listeners *listeners;
BUG_ON(!netlink_is_kernel(sk));
@@ -944,7 +944,7 @@ int netlink_has_listeners(struct sock *sk, unsigned int group)
listeners = rcu_dereference(nl_table[sk->sk_protocol].listeners);
if (group - 1 < nl_table[sk->sk_protocol].groups)
- res = test_bit(group - 1, listeners);
+ res = test_bit(group - 1, listeners->masks);
rcu_read_unlock();
@@ -1498,7 +1498,7 @@ netlink_kernel_create(struct net *net, int unit, unsigned int groups,
struct socket *sock;
struct sock *sk;
struct netlink_sock *nlk;
- unsigned long *listeners = NULL;
+ struct listeners *listeners = NULL;
BUG_ON(!nl_table);
@@ -1523,8 +1523,7 @@ netlink_kernel_create(struct net *net, int unit, unsigned int groups,
if (groups < 32)
groups = 32;
- listeners = kzalloc(NLGRPSZ(groups) + sizeof(struct listeners_rcu_head),
- GFP_KERNEL);
+ listeners = kzalloc(sizeof(*listeners) + NLGRPSZ(groups), GFP_KERNEL);
if (!listeners)
goto out_sock_release;
@@ -1541,7 +1540,7 @@ netlink_kernel_create(struct net *net, int unit, unsigned int groups,
netlink_table_grab();
if (!nl_table[unit].registered) {
nl_table[unit].groups = groups;
- nl_table[unit].listeners = listeners;
+ rcu_assign_pointer(nl_table[unit].listeners, listeners);
nl_table[unit].cb_mutex = cb_mutex;
nl_table[unit].module = module;
nl_table[unit].registered = 1;
@@ -1572,43 +1571,28 @@ netlink_kernel_release(struct sock *sk)
EXPORT_SYMBOL(netlink_kernel_release);
-static void netlink_free_old_listeners(struct rcu_head *rcu_head)
+static void listeners_free_rcu(struct rcu_head *head)
{
- struct listeners_rcu_head *lrh;
-
- lrh = container_of(rcu_head, struct listeners_rcu_head, rcu_head);
- kfree(lrh->ptr);
+ kfree(container_of(head, struct listeners, rcu));
}
int __netlink_change_ngroups(struct sock *sk, unsigned int groups)
{
- unsigned long *listeners, *old = NULL;
- struct listeners_rcu_head *old_rcu_head;
+ struct listeners *new, *old;
struct netlink_table *tbl = &nl_table[sk->sk_protocol];
if (groups < 32)
groups = 32;
if (NLGRPSZ(tbl->groups) < NLGRPSZ(groups)) {
- listeners = kzalloc(NLGRPSZ(groups) +
- sizeof(struct listeners_rcu_head),
- GFP_ATOMIC);
- if (!listeners)
+ new = kzalloc(sizeof(*new) + NLGRPSZ(groups), GFP_ATOMIC);
+ if (!new)
return -ENOMEM;
- old = tbl->listeners;
- memcpy(listeners, old, NLGRPSZ(tbl->groups));
- rcu_assign_pointer(tbl->listeners, listeners);
- /*
- * Free the old memory after an RCU grace period so we
- * don't leak it. We use call_rcu() here in order to be
- * able to call this function from atomic contexts. The
- * allocation of this memory will have reserved enough
- * space for struct listeners_rcu_head at the end.
- */
- old_rcu_head = (void *)(tbl->listeners +
- NLGRPLONGS(tbl->groups));
- old_rcu_head->ptr = old;
- call_rcu(&old_rcu_head->rcu_head, netlink_free_old_listeners);
+ old = rcu_dereference_raw(tbl->listeners);
+ memcpy(new->masks, old->masks, NLGRPSZ(tbl->groups));
+ rcu_assign_pointer(tbl->listeners, new);
+
+ call_rcu(&old->rcu, listeners_free_rcu);
}
tbl->groups = groups;
@@ -2104,18 +2088,17 @@ static void __net_exit netlink_net_exit(struct net *net)
static void __init netlink_add_usersock_entry(void)
{
- unsigned long *listeners;
+ struct listeners *listeners;
int groups = 32;
- listeners = kzalloc(NLGRPSZ(groups) + sizeof(struct listeners_rcu_head),
- GFP_KERNEL);
+ listeners = kzalloc(sizeof(*listeners) + NLGRPSZ(groups), GFP_KERNEL);
if (!listeners)
- panic("netlink_add_usersock_entry: Cannot allocate listneres\n");
+ panic("netlink_add_usersock_entry: Cannot allocate listeners\n");
netlink_table_grab();
nl_table[NETLINK_USERSOCK].groups = groups;
- nl_table[NETLINK_USERSOCK].listeners = listeners;
+ rcu_assign_pointer(nl_table[NETLINK_USERSOCK].listeners, listeners);
nl_table[NETLINK_USERSOCK].module = THIS_MODULE;
nl_table[NETLINK_USERSOCK].registered = 1;
^ permalink raw reply related
* (unknown),
From: CHARITY DONATION & ECOWAS @ 2010-10-24 18:20 UTC (permalink / raw)
CHARITY DONATION & ECOWAS
http://www.comm.ecowas.int/
Worldwide Donation Program "helping one to help others...."
==========================================
I have been directed to inform you that you have been chosen for a cash
grant of US$1,000,000.00 by the board of trustees of the above stated
non-governmental aid organisation.
Your grant number is B01-0147. Contact Rev David Rex via telephone
+234-8077-801517 email: ecowas00@aol.com, and provide these details:
1).Full name.
2).Address
3).Telephone number. [Cell preferably]
4).Occupation.
Regards.
Tracy Nicholson
Coordinator.
^ permalink raw reply
* (unknown),
From: CHARITY DONATION & ECOWAS @ 2010-10-24 18:26 UTC (permalink / raw)
CHARITY DONATION & ECOWAS
http://www.comm.ecowas.int/
Worldwide Donation Program "helping one to help others...."
==========================================
I have been directed to inform you that you have been chosen for a cash
grant of US$1,000,000.00 by the board of trustees of the above stated
non-governmental aid organisation.
Your grant number is B01-0147. Contact Rev David Rex via telephone
+234-8077-801517 email: ecowas00@aol.com, and provide these details:
1).Full name.
2).Address
3).Telephone number. [Cell preferably]
4).Occupation.
Regards.
Tracy Nicholson
Coordinator.
^ permalink raw reply
* [PATCH 2/2] typhoon: update to new VLAN acceleration model
From: David Dillow @ 2010-10-24 20:20 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1287951621-25170-1-git-send-email-dave@thedillows.org>
Also correct the byteswapping as we keep the TCI in host order.
Signed-off-by: David Dillow <dave@thedillows.org>
---
drivers/net/typhoon.c | 88 ++++++++++++++-----------------------------------
1 files changed, 25 insertions(+), 63 deletions(-)
diff --git a/drivers/net/typhoon.c b/drivers/net/typhoon.c
index 5957d4e..b550da0 100644
--- a/drivers/net/typhoon.c
+++ b/drivers/net/typhoon.c
@@ -24,10 +24,6 @@
3XP Processor. It has been tested on x86 and sparc64.
KNOWN ISSUES:
- *) The current firmware always strips the VLAN tag off, even if
- we tell it not to. You should filter VLANs at the switch
- as a workaround (good practice in any event) until we can
- get this fixed.
*) Cannot DMA Rx packets to a 2 byte aligned address. Also firmware
issue. Hopefully 3Com will fix it.
*) Waiting for a command response takes 8ms due to non-preemptable
@@ -280,8 +276,6 @@ struct typhoon {
struct pci_dev * pdev;
struct net_device * dev;
struct napi_struct napi;
- spinlock_t state_lock;
- struct vlan_group * vlgrp;
struct basic_ring rxHiRing;
struct basic_ring rxBuffRing;
struct rxbuff_ent rxbuffers[RXENT_ENTRIES];
@@ -695,44 +689,6 @@ out:
return err;
}
-static void
-typhoon_vlan_rx_register(struct net_device *dev, struct vlan_group *grp)
-{
- struct typhoon *tp = netdev_priv(dev);
- struct cmd_desc xp_cmd;
- int err;
-
- spin_lock_bh(&tp->state_lock);
- if(!tp->vlgrp != !grp) {
- /* We've either been turned on for the first time, or we've
- * been turned off. Update the 3XP.
- */
- if(grp)
- tp->offload |= TYPHOON_OFFLOAD_VLAN;
- else
- tp->offload &= ~TYPHOON_OFFLOAD_VLAN;
-
- /* If the interface is up, the runtime is running -- and we
- * must be up for the vlan core to call us.
- *
- * Do the command outside of the spin lock, as it is slow.
- */
- INIT_COMMAND_WITH_RESPONSE(&xp_cmd,
- TYPHOON_CMD_SET_OFFLOAD_TASKS);
- xp_cmd.parm2 = tp->offload;
- xp_cmd.parm3 = tp->offload;
- spin_unlock_bh(&tp->state_lock);
- err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
- if(err < 0)
- netdev_err(tp->dev, "vlan offload error %d\n", -err);
- spin_lock_bh(&tp->state_lock);
- }
-
- /* now make the change visible */
- tp->vlgrp = grp;
- spin_unlock_bh(&tp->state_lock);
-}
-
static inline void
typhoon_tso_fill(struct sk_buff *skb, struct transmit_ring *txRing,
u32 ring_dma)
@@ -818,7 +774,7 @@ typhoon_start_tx(struct sk_buff *skb, struct net_device *dev)
first_txd->processFlags |=
TYPHOON_TX_PF_INSERT_VLAN | TYPHOON_TX_PF_VLAN_PRIORITY;
first_txd->processFlags |=
- cpu_to_le32(ntohs(vlan_tx_tag_get(skb)) <<
+ cpu_to_le32(htons(vlan_tx_tag_get(skb)) <<
TYPHOON_TX_PF_VLAN_TAG_SHIFT);
}
@@ -1198,6 +1154,20 @@ typhoon_get_rx_csum(struct net_device *dev)
return 1;
}
+static int
+typhoon_set_flags(struct net_device *dev, u32 data)
+{
+ /* There's no way to turn off the RX VLAN offloading and stripping
+ * on the current 3XP firmware -- it does not respect the offload
+ * settings -- so we only allow the user to toggle the TX processing.
+ */
+ if (!(data & ETH_FLAG_RXVLAN))
+ return -EINVAL;
+
+ return ethtool_op_set_flags(dev, data,
+ ETH_FLAG_RXVLAN | ETH_FLAG_TXVLAN);
+}
+
static void
typhoon_get_ringparam(struct net_device *dev, struct ethtool_ringparam *ering)
{
@@ -1224,6 +1194,8 @@ static const struct ethtool_ops typhoon_ethtool_ops = {
.set_sg = ethtool_op_set_sg,
.set_tso = ethtool_op_set_tso,
.get_ringparam = typhoon_get_ringparam,
+ .set_flags = typhoon_set_flags,
+ .get_flags = ethtool_op_get_flags,
};
static int
@@ -1309,9 +1281,9 @@ typhoon_init_interface(struct typhoon *tp)
tp->offload = TYPHOON_OFFLOAD_IP_CHKSUM | TYPHOON_OFFLOAD_TCP_CHKSUM;
tp->offload |= TYPHOON_OFFLOAD_UDP_CHKSUM | TSO_OFFLOAD_ON;
+ tp->offload |= TYPHOON_OFFLOAD_VLAN;
spin_lock_init(&tp->command_lock);
- spin_lock_init(&tp->state_lock);
/* Force the writes to the shared memory area out before continuing. */
wmb();
@@ -1762,13 +1734,10 @@ typhoon_rx(struct typhoon *tp, struct basic_ring *rxRing, volatile __le32 * read
} else
skb_checksum_none_assert(new_skb);
- spin_lock(&tp->state_lock);
- if(tp->vlgrp != NULL && rx->rxStatus & TYPHOON_RX_VLAN)
- vlan_hwaccel_receive_skb(new_skb, tp->vlgrp,
- ntohl(rx->vlanTag) & 0xffff);
- else
- netif_receive_skb(new_skb);
- spin_unlock(&tp->state_lock);
+ if (rx->rxStatus & TYPHOON_RX_VLAN)
+ __vlan_hwaccel_put_tag(new_skb,
+ ntohl(rx->vlanTag) & 0xffff);
+ netif_receive_skb(new_skb);
received++;
budget--;
@@ -1989,11 +1958,9 @@ typhoon_start_runtime(struct typhoon *tp)
goto error_out;
INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_SET_OFFLOAD_TASKS);
- spin_lock_bh(&tp->state_lock);
xp_cmd.parm2 = tp->offload;
xp_cmd.parm3 = tp->offload;
err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
- spin_unlock_bh(&tp->state_lock);
if(err < 0)
goto error_out;
@@ -2231,13 +2198,9 @@ typhoon_suspend(struct pci_dev *pdev, pm_message_t state)
if(!netif_running(dev))
return 0;
- spin_lock_bh(&tp->state_lock);
- if(tp->vlgrp && tp->wol_events & TYPHOON_WAKE_MAGIC_PKT) {
- spin_unlock_bh(&tp->state_lock);
- netdev_err(dev, "cannot do WAKE_MAGIC with VLANS\n");
- return -EBUSY;
- }
- spin_unlock_bh(&tp->state_lock);
+ /* TYPHOON_OFFLOAD_VLAN is always on now, so this doesn't work */
+ if(tp->wol_events & TYPHOON_WAKE_MAGIC_PKT)
+ netdev_warn(dev, "cannot do WAKE_MAGIC with VLAN offloading\n");
netif_device_detach(dev);
@@ -2338,7 +2301,6 @@ static const struct net_device_ops typhoon_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = typhoon_set_mac_address,
.ndo_change_mtu = eth_change_mtu,
- .ndo_vlan_rx_register = typhoon_vlan_rx_register,
};
static int __devinit
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] typhoon: wait for RX mode commands to finish
From: David Dillow @ 2010-10-24 20:20 UTC (permalink / raw)
To: netdev; +Cc: davem
When adding VLAN devices, we can get several calls to
typhoon_set_rx_mode() in quick succession. Because we didn't wait for
the commands to complete, we could run out of command descriptors and
fail to set the RX mode.
Signed-off-by: David Dillow <dave@thedillows.org>
---
drivers/net/typhoon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/typhoon.c b/drivers/net/typhoon.c
index 1cc6713..5957d4e 100644
--- a/drivers/net/typhoon.c
+++ b/drivers/net/typhoon.c
@@ -936,7 +936,7 @@ typhoon_set_rx_mode(struct net_device *dev)
filter |= TYPHOON_RX_FILTER_MCAST_HASH;
}
- INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_SET_RX_FILTER);
+ INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_SET_RX_FILTER);
xp_cmd.parm1 = filter;
typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH] Add support for new VLAN acceleration model
From: David Dillow @ 2010-10-24 20:24 UTC (permalink / raw)
To: netdev; +Cc: jgarzik, davem, jesse
Signed-off-by: David Dillow <dave@thedillows.org>
---
I used this during testing of the typhoon conversion.
ethtool-copy.h | 2 ++
ethtool.c | 23 +++++++++++++++++++----
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 894f1da..557425e 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -308,6 +308,8 @@ struct ethtool_perm_addr {
* flag differs from the read-only value.
*/
enum ethtool_flags {
+ ETH_FLAG_TXVLAN = (1 << 7), /* TX VLAN offload enabled */
+ ETH_FLAG_RXVLAN = (1 << 8), /* RX VLAN offload enabled */
ETH_FLAG_LRO = (1 << 15), /* LRO is enabled */
ETH_FLAG_NTUPLE = (1 << 27), /* N-tuple filters enabled */
ETH_FLAG_RXHASH = (1 << 28),
diff --git a/ethtool.c b/ethtool.c
index 6b2b7c8..b6d3bfb 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -202,6 +202,8 @@ static struct option {
" [ lro on|off ]\n"
" [ ntuple on|off ]\n"
" [ rxhash on|off ]\n"
+ " [ rxvlan on|off ]\n"
+ " [ txvlan on|off ]\n"
},
{ "-i", "--driver", MODE_GDRV, "Show driver information" },
{ "-d", "--register-dump", MODE_GREGS, "Do a register dump",
@@ -439,6 +441,10 @@ static struct cmdline_info cmdline_offload[] = {
ETH_FLAG_NTUPLE, &off_flags_unwanted },
{ "rxhash", CMDL_FLAG, &off_flags_wanted, NULL,
ETH_FLAG_RXHASH, &off_flags_unwanted },
+ { "txvlan", CMDL_FLAG, &off_flags_wanted, NULL,
+ ETH_FLAG_TXVLAN, &off_flags_unwanted },
+ { "rxvlan", CMDL_FLAG, &off_flags_wanted, NULL,
+ ETH_FLAG_RXVLAN, &off_flags_unwanted },
};
static struct cmdline_info cmdline_pause[] = {
@@ -1732,7 +1738,8 @@ static int dump_coalesce(void)
}
static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
- int gro, int lro, int ntuple, int rxhash)
+ int gro, int lro, int ntuple, int rxhash, int rxvlan,
+ int txvlan)
{
fprintf(stdout,
"rx-checksumming: %s\n"
@@ -1744,7 +1751,9 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
"generic-receive-offload: %s\n"
"large-receive-offload: %s\n"
"ntuple-filters: %s\n"
- "receive-hashing: %s\n",
+ "receive-hashing: %s\n"
+ "rx-vlan-offload: %s\n"
+ "tx-vlan-offload: %s\n",
rx ? "on" : "off",
tx ? "on" : "off",
sg ? "on" : "off",
@@ -1754,7 +1763,9 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
gro ? "on" : "off",
lro ? "on" : "off",
ntuple ? "on" : "off",
- rxhash ? "on" : "off");
+ rxhash ? "on" : "off",
+ rxvlan ? "on" : "off",
+ txvlan ? "on" : "off");
return 0;
}
@@ -2076,6 +2087,7 @@ static int do_goffload(int fd, struct ifreq *ifr)
struct ethtool_value eval;
int err, allfail = 1, rx = 0, tx = 0, sg = 0;
int tso = 0, ufo = 0, gso = 0, gro = 0, lro = 0, ntuple = 0, rxhash = 0;
+ int rxvlan = 0, txvlan = 0;
fprintf(stdout, "Offload parameters for %s:\n", devname);
@@ -2148,6 +2160,8 @@ static int do_goffload(int fd, struct ifreq *ifr)
lro = (eval.data & ETH_FLAG_LRO) != 0;
ntuple = (eval.data & ETH_FLAG_NTUPLE) != 0;
rxhash = (eval.data & ETH_FLAG_RXHASH) != 0;
+ rxvlan = (eval.data & ETH_FLAG_RXVLAN) != 0;
+ txvlan = (eval.data & ETH_FLAG_TXVLAN) != 0;
allfail = 0;
}
@@ -2166,7 +2180,8 @@ static int do_goffload(int fd, struct ifreq *ifr)
return 83;
}
- return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, ntuple, rxhash);
+ return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, ntuple, rxhash,
+ rxvlan, txvlan);
}
static int do_soffload(int fd, struct ifreq *ifr)
--
1.7.2.3
^ permalink raw reply related
* [PATCH] drivers: rtl818x: request DMA-able memory
From: Serafeim Zanikolas @ 2010-10-24 20:32 UTC (permalink / raw)
To: herton, htl10, Larry.Finger, linville, joe, davem, linux-wireless,
netdev
Cc: Serafeim Zanikolas
Despite the indicated intention in comment, the kmalloc() call was not
explicitly requesting memory from ZONE_DMA.
Signed-off-by: Serafeim Zanikolas <sez@debian.org>
---
drivers/net/wireless/rtl818x/rtl8187_dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index 38fa824..771794d 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1343,7 +1343,8 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
priv->is_rtl8187b = (id->driver_info == DEVICE_RTL8187B);
/* allocate "DMA aware" buffer for register accesses */
- priv->io_dmabuf = kmalloc(sizeof(*priv->io_dmabuf), GFP_KERNEL);
+ priv->io_dmabuf = kmalloc(sizeof(*priv->io_dmabuf),
+ GFP_DMA | GFP_KERNEL);
if (!priv->io_dmabuf) {
err = -ENOMEM;
goto err_free_dev;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] connector: remove lazy workqueue creation
From: David Miller @ 2010-10-24 21:21 UTC (permalink / raw)
To: tj; +Cc: zbr, netdev, fweisbec
In-Reply-To: <4CB8250A.7040902@kernel.org>
From: Tejun Heo <tj@kernel.org>
Date: Fri, 15 Oct 2010 11:55:22 +0200
> Commit 1a5645bc (connector: create connector workqueue only while
> needed once) implements lazy workqueue creation for connector
> workqueue. With cmwq now in place, lazy workqueue creation doesn't
> make much sense while adding a lot of complexity. Remove it and
> allocate an ordered workqueue during initialization.
>
> This also removes a call to flush_scheduled_work() which is deprecated
> and scheduled to be removed.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
Applied, thank you.
^ permalink raw reply
* Re: PROBLEM: NULL pointer dereference in rpcauth_refreshcred
From: Trond Myklebust @ 2010-10-24 21:29 UTC (permalink / raw)
To: Rob Leslie
Cc: J. Bruce Fields, Neil Brown, David S. Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3DE04C32-0B15-4BBF-A541-27152D3EC69B-O+g/SLjAo04@public.gmane.org>
On Sat, 2010-10-23 at 14:50 -0700, Rob Leslie wrote:
> [1.] One line summary of the problem:
>
> NULL pointer dereference in rpcauth_refreshcred
Hi Rob,
I suspect the following one-line patch should fix the problem.
Cheers
Trond
------------------------------------------------------------------------------------------------------
>From 118df3d17f11733b294ea2cd988d56ee376ef9fd Mon Sep 17 00:00:00 2001
From: Trond Myklebust <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
Date: Sun, 24 Oct 2010 17:17:31 -0400
Subject: [PATCH] SUNRPC: After calling xprt_release(), we must restart from call_reserve
Rob Leslie reports seeing the following Oops after his Kerberos session
expired.
BUG: unable to handle kernel NULL pointer dereference at 00000058
IP: [<e186ed94>] rpcauth_refreshcred+0x11/0x12c [sunrpc]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/platform/pc87360.26144/temp3_input
Modules linked in: autofs4 authenc esp4 xfrm4_mode_transport ipt_LOG ipt_REJECT xt_limit xt_state ipt_REDIRECT xt_owner xt_HL xt_hl xt_tcpudp xt_mark cls_u32 cls_tcindex sch_sfq sch_htb sch_dsmark geodewdt deflate ctr twofish_generic twofish_i586 twofish_common camellia serpent blowfish cast5 cbc xcbc rmd160 sha512_generic sha1_generic hmac crypto_null af_key rpcsec_gss_krb5 nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip_gre sit tunnel4 dummy ext3 jbd nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables pc8736x_gpio nsc_gpio pc87360 hwmon_vid loop aes_i586 aes_generic sha256_generic dm_crypt cs5535_gpio serio_raw cs5535_mfgpt hifn_795x des_generic geode_rng rn
g_core led_class ext4 mbcache jbd2 crc16 dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sd_mod crc_t10dif ide_pci_generic cs5536 amd74xx ide_core pata_cs5536 ata_generic libata usb_storage via_rhine mii scsi_mod btrfs zlib_deflate crc32c libcrc32c [last unloaded: scsi_wait_scan]
Pid: 12875, comm: sudo Not tainted 2.6.36-net5501 #1 /
EIP: 0060:[<e186ed94>] EFLAGS: 00010292 CPU: 0
EIP is at rpcauth_refreshcred+0x11/0x12c [sunrpc]
EAX: 00000000 EBX: defb13a0 ECX: 00000006 EDX: e18683b8
ESI: defb13a0 EDI: 00000000 EBP: 00000000 ESP: de571d58
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sudo (pid: 12875, ti=de570000 task=decd1430 task.ti=de570000)
Stack:
e186e008 00000000 defb13a0 0000000d deda6000 e1868f22 e196f12b defb13a0
<0> defb13d8 00000000 00000000 e186e0aa 00000000 defb13a0 de571dac 00000000
<0> e186956c de571e34 debea5c0 de571dc8 e186967a 00000000 debea5c0 de571e34
Call Trace:
[<e186e008>] ? rpc_wake_up_next+0x114/0x11b [sunrpc]
[<e1868f22>] ? call_decode+0x24a/0x5af [sunrpc]
[<e196f12b>] ? nfs4_xdr_dec_access+0x0/0xa2 [nfs]
[<e186e0aa>] ? __rpc_execute+0x62/0x17b [sunrpc]
[<e186956c>] ? rpc_run_task+0x91/0x97 [sunrpc]
[<e186967a>] ? rpc_call_sync+0x40/0x5b [sunrpc]
[<e1969ca2>] ? nfs4_proc_access+0x10a/0x176 [nfs]
[<e19572fa>] ? nfs_do_access+0x2b1/0x2c0 [nfs]
[<e186ed61>] ? rpcauth_lookupcred+0x62/0x84 [sunrpc]
[<e19573b6>] ? nfs_permission+0xad/0x13b [nfs]
[<c0177824>] ? exec_permission+0x15/0x4b
[<c0177fbd>] ? link_path_walk+0x4f/0x456
[<c017867d>] ? path_walk+0x4c/0xa8
[<c0179678>] ? do_path_lookup+0x1f/0x68
[<c017a3fb>] ? user_path_at+0x37/0x5f
[<c016359c>] ? handle_mm_fault+0x229/0x55b
[<c0170a2d>] ? sys_faccessat+0x93/0x146
[<c0170aef>] ? sys_access+0xf/0x13
[<c02cf615>] ? syscall_call+0x7/0xb
Code: 0f 94 c2 84 d2 74 09 8b 44 24 0c e8 6a e9 8b de 83 c4 14 89 d8 5b 5e 5f 5d c3 55 57 56 53 83 ec 1c fc 89 c6 8b 40 10 89 44 24 04 <8b> 58 58 85 db 0f 85 d4 00 00 00 0f b7 46 70 8b 56 20 89 c5 83
EIP: [<e186ed94>] rpcauth_refreshcred+0x11/0x12c [sunrpc] SS:ESP 0068:de571d58
CR2: 0000000000000058
This appears to be caused by the function rpc_verify_header() first
calling xprt_release(), then doing a call_refresh. If we release the
transport slot, we should _always_ jump back to call_reserve before
calling anything else.
Signed-off-by: Trond Myklebust <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
Cc: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
---
net/sunrpc/clnt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 2388d83..3d28ae8 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1677,7 +1677,7 @@ rpc_verify_header(struct rpc_task *task)
rpcauth_invalcred(task);
/* Ensure we obtain a new XID! */
xprt_release(task);
- task->tk_action = call_refresh;
+ task->tk_action = call_reserve;
goto out_retry;
case RPC_AUTH_BADCRED:
case RPC_AUTH_BADVERF:
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v1] can: Topcliff: Update PCH_CAN driver to 2.6.35
From: David Miller @ 2010-10-24 21:43 UTC (permalink / raw)
To: masa-korg-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CB8506C.3060600-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Masayuki Ohtak <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Fri, 15 Oct 2010 22:00:28 +0900
> CAN driver of Topcliff PCH
>
> Topcliff PCH is the platform controller hub that is going to be used in
> Intel's upcoming general embedded platform. All IO peripherals in
> Topcliff PCH are actually devices sitting on AMBA bus.
> Topcliff PCH has CAN I/F. This driver enables CAN function.
>
> Signed-off-by: Masayuki Ohtake <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 00/10] can: at91: bugfixes and improvements
From: David Miller @ 2010-10-24 21:48 UTC (permalink / raw)
To: mkl; +Cc: socketcan-core, netdev
In-Reply-To: <1287658882-26914-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu, 21 Oct 2010 13:01:12 +0200
> this series of patches fixes three bugs (CAN_CTRLMODE_3_SAMPLES,
> extended frames, use-after-free), a compiler warning (uninit'ed variable) and
> a section mismatch. Further it add the implementation of the
> do_get_berr_counter callback, the bittiming setting is now done in chip_start.
> As requested by Russell King the driver uses __raw_readl instead of readl.
>
> The last two patches do some cleanups, they convert dev_<level> printing
> to netdev_<level> and add the KBUILD_MODNAME to the bit timing constant
> to identify the driver.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v1] can: Topcliff: Update PCH_CAN driver to 2.6.35
From: David Miller @ 2010-10-24 21:55 UTC (permalink / raw)
To: masa-korg-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20101024.144312.104048720.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Please send a patch against the current driver which will fix these
build warnings that occur when CONFIG_PM is disabled:
drivers/net/can/pch_can.c:258:13: warning: 'pch_can_set_int_custom' defined but not used
drivers/net/can/pch_can.c:269:13: warning: 'pch_can_get_int_enables' defined but not used
drivers/net/can/pch_can.c:420:13: warning: 'pch_can_get_rx_enable' defined but not used
drivers/net/can/pch_can.c:438:13: warning: 'pch_can_get_tx_enable' defined but not used
drivers/net/can/pch_can.c:462:13: warning: 'pch_can_set_rx_buffer_link' defined but not used
drivers/net/can/pch_can.c:480:13: warning: 'pch_can_get_rx_buffer_link' defined but not used
Thank you.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v1] can: Topcliff: Update PCH_CAN driver to 2.6.35
From: Marc Kleine-Budde @ 2010-10-24 22:05 UTC (permalink / raw)
To: David Miller
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, chripell-VaTbYqLCNhc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
morinaga526-ECg8zkTtlr0C6LszWs/t0g, wg-5Yr1BZd7O62+XT7JhA+gdA,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20101024.144312.104048720.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1062 bytes --]
On 10/24/2010 11:43 PM, David Miller wrote:
> From: Masayuki Ohtak <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
> Date: Fri, 15 Oct 2010 22:00:28 +0900
>
>> CAN driver of Topcliff PCH
>>
>> Topcliff PCH is the platform controller hub that is going to be used in
>> Intel's upcoming general embedded platform. All IO peripherals in
>> Topcliff PCH are actually devices sitting on AMBA bus.
>> Topcliff PCH has CAN I/F. This driver enables CAN function.
>>
>> Signed-off-by: Masayuki Ohtake <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
>
> Applied, thanks.
IMHO this driver needs some improvements. There are some open points
from Wolfgangs and my review. On the other side, it's a new driver and
there's some time left before it hits mainline.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH 06/12] ipconfig: make local variables/function static
From: David Miller @ 2010-10-24 22:06 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20101021175148.504406585@vyatta.com>
git grep ic_set_manually -- arch/sparc
^ permalink raw reply
* Re: [PATCH net-next-2.6 v1] can: Topcliff: Update PCH_CAN driver to 2.6.35
From: David Miller @ 2010-10-24 22:09 UTC (permalink / raw)
To: mkl-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, chripell-VaTbYqLCNhc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
morinaga526-ECg8zkTtlr0C6LszWs/t0g, wg-5Yr1BZd7O62+XT7JhA+gdA,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CC4ADA5.8-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Date: Mon, 25 Oct 2010 00:05:25 +0200
> On 10/24/2010 11:43 PM, David Miller wrote:
>> From: Masayuki Ohtak <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
>> Date: Fri, 15 Oct 2010 22:00:28 +0900
>>
>>> CAN driver of Topcliff PCH
>>>
>>> Topcliff PCH is the platform controller hub that is going to be used in
>>> Intel's upcoming general embedded platform. All IO peripherals in
>>> Topcliff PCH are actually devices sitting on AMBA bus.
>>> Topcliff PCH has CAN I/F. This driver enables CAN function.
>>>
>>> Signed-off-by: Masayuki Ohtake <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
>>
>> Applied, thanks.
>
> IMHO this driver needs some improvements. There are some open points
> from Wolfgangs and my review. On the other side, it's a new driver and
> there's some time left before it hits mainline.
When people have more than a week to review and provide feedback,
and don't, I have zero sympathy especially this early in the
release cycle.
So if adding it to the tree is what I have to do to get you guys to
post your comments and suggest fixes, then that's what I am going to
(continue) to do. :-)
^ permalink raw reply
* Re: [PATCH net-next-2.6 v1] can: Topcliff: Update PCH_CAN driver to 2.6.35
From: Marc Kleine-Budde @ 2010-10-24 22:15 UTC (permalink / raw)
To: David Miller
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
qi.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <20101024.150905.39179588.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1813 bytes --]
On 10/25/2010 12:09 AM, David Miller wrote:
> From: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Date: Mon, 25 Oct 2010 00:05:25 +0200
>
>> On 10/24/2010 11:43 PM, David Miller wrote:
>>> From: Masayuki Ohtak <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
>>> Date: Fri, 15 Oct 2010 22:00:28 +0900
>>>
>>>> CAN driver of Topcliff PCH
>>>>
>>>> Topcliff PCH is the platform controller hub that is going to be used in
>>>> Intel's upcoming general embedded platform. All IO peripherals in
>>>> Topcliff PCH are actually devices sitting on AMBA bus.
>>>> Topcliff PCH has CAN I/F. This driver enables CAN function.
>>>>
>>>> Signed-off-by: Masayuki Ohtake <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
>>>
>>> Applied, thanks.
>>
>> IMHO this driver needs some improvements. There are some open points
>> from Wolfgangs and my review. On the other side, it's a new driver and
>> there's some time left before it hits mainline.
>
> When people have more than a week to review and provide feedback,
> and don't, I have zero sympathy especially this early in the
> release cycle.
Let me see....Crap, it's my fault, I just replied to the socketcan
mailinglist ;( [1]
> So if adding it to the tree is what I have to do to get you guys to
> post your comments and suggest fixes, then that's what I am going to
> (continue) to do. :-)
...or to learn how to reply properly :)
regards, Marc
[1]
https://lists.berlios.de/pipermail/socketcan-core/2010-October/004757.html
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH net-next-2.6] mlx4: make functions local and remove dead code.
From: David Miller @ 2010-10-24 22:19 UTC (permalink / raw)
To: shemminger; +Cc: yevgenyp, netdev, eli
In-Reply-To: <20101021095920.17bd21f1@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 21 Oct 2010 09:59:20 -0700
> Make the following function static: mlx4_UNMAP_ICM
> Remove the following unused function: mlx4_MAP_ICM_page
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/12] last of the namespace cleanups
From: David Miller @ 2010-10-24 22:20 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20101021175045.625707607@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 21 Oct 2010 10:50:45 -0700
> These are the last of the cleanups to networking for 2.6.37 based
> on "make namespacecheck" reports.
All applied except the ipconfig patch that breaks the sparc build.
Thanks.
^ permalink raw reply
* Re: [PATCH] macb: Don't re-enable interrupts while in polling mode
From: David Miller @ 2010-10-24 22:23 UTC (permalink / raw)
To: Joshua.Hoke
Cc: nicolas.ferre, jpirko, peter.korsgaard, eric.dumazet,
haavard.skinnemoen, netdev, linux-kernel, akpm
In-Reply-To: <C8F551D39A7C724E987CF8DD11D3178304D02F88@svr3.sixnetio.com>
From: "Joshua Hoke" <Joshua.Hoke@sixnet.com>
Date: Tue, 19 Oct 2010 12:48:22 -0400
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index ff2f158..36cf594 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -515,14 +515,15 @@ static int macb_poll(struct napi_struct *napi, int
> budget)
Your email client is breaking up long lines which corrupts the
patch.
Please fix this up in your email client and resubmit.
Thank you.
^ 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