* Re: [patch 2/4] mISDN: add support for group membership check
From: David Miller @ 2013-09-20 17:14 UTC (permalink / raw)
To: ben; +Cc: jslaby, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <20130920163043.GN7729@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Fri, 20 Sep 2013 17:30:44 +0100
> On Fri, Sep 20, 2013 at 12:21:42PM -0400, David Miller wrote:
>> From: Jiri Slaby <jslaby@suse.cz>
>> Date: Fri, 20 Sep 2013 18:18:02 +0200
>>
>> > Ok, let's leave the hole in there then.
>>
>> Jiri, don't turn this on me.
>>
>> The issue is not whether something needs to be fixed or not, I never
>> said "don't fix this" and therefore I'd like to ask politely that you
>> not make it seem like I have.
>>
>> Rather, I'm saying that the implementation is terrible, sets a bad
>> precendence for fixing similar problems, and therefore not is in
>> a state where we can apply it.
>>
>> So, I'm not saying "don't fix this", I'm saying "fix it properly."
>
> I think Jiri's last suggestion was to add the capability check to
> device renaming (which I think everyone agrees is needed) and not
> to add any group identity checks for any operation.
>
> Isn't that fixing it properly?
I'm saying that using a module parameter for this is a deeper and
even more important problem with this change.
He seems to agree with me.
^ permalink raw reply
* [PATCH] qlge: call ql_core_dump() only if dump memory was allocated.
From: Malahal Naineni @ 2013-09-20 16:59 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130920.120201.1305554403409938708.davem@davemloft.net>
Also changed a log message to indicate that memory was not allocated
instead of memory not available!
Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
---
drivers/net/ethernet/qlogic/qlge/qlge_dbg.c | 4 ++--
drivers/net/ethernet/qlogic/qlge/qlge_mpi.c | 12 +++++++-----
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
index 10093f0..6bc5db7 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
@@ -740,8 +740,8 @@ int ql_core_dump(struct ql_adapter *qdev, struct ql_mpi_coredump *mpi_coredump)
int i;
if (!mpi_coredump) {
- netif_err(qdev, drv, qdev->ndev, "No memory available\n");
- return -ENOMEM;
+ netif_err(qdev, drv, qdev->ndev, "No memory allocated\n");
+ return -EINVAL;
}
/* Try to get the spinlock, but dont worry if
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c b/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
index ff2bf8a..99a3e07 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
@@ -1274,11 +1274,13 @@ void ql_mpi_reset_work(struct work_struct *work)
return;
}
- if (!ql_core_dump(qdev, qdev->mpi_coredump)) {
- netif_err(qdev, drv, qdev->ndev, "Core is dumped!\n");
- qdev->core_is_dumped = 1;
- queue_delayed_work(qdev->workqueue,
- &qdev->mpi_core_to_log, 5 * HZ);
+ if (qdev->mpi_coredump) {
+ if (!ql_core_dump(qdev, qdev->mpi_coredump)) {
+ netif_err(qdev, drv, qdev->ndev, "Core is dumped!\n");
+ qdev->core_is_dumped = 1;
+ queue_delayed_work(qdev->workqueue,
+ &qdev->mpi_core_to_log, 5 * HZ);
+ }
}
ql_soft_reset_mpi_risc(qdev);
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH iproute2] tc: support TCA_STATS_RATE_EST64
From: Stephen Hemminger @ 2013-09-20 16:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1379416743.29845.15.camel@edumazet-glaptop>
On Tue, 17 Sep 2013 04:19:03 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Since linux-3.11, rate estimator can provide TCA_STATS_RATE_EST64
> when rate (bytes per second) is above 2^32 (~34 Mbits)
>
> Change tc to use this attribute for high rates.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
Applied
^ permalink raw reply
* Re: [PATCH] iproute2: bridge: document mdb
From: Stephen Hemminger @ 2013-09-20 16:45 UTC (permalink / raw)
To: Petr Písař; +Cc: netdev, shemminger
In-Reply-To: <1379580086-31784-2-git-send-email-ppisar@redhat.com>
On Thu, 19 Sep 2013 10:41:26 +0200
Petr Písař <ppisar@redhat.com> wrote:
> This augments bridge(8) manual page with `bridge mdb' and `bridge
> monitor mdb' commands which have been added recently.
>
> Signed-off-by: Petr Písař <ppisar@redhat.com>
Applied thanks.
^ permalink raw reply
* Re: IPv6 kernel warning
From: Yuchung Cheng @ 2013-09-20 16:40 UTC (permalink / raw)
To: Michele Baldessari; +Cc: Russell King - ARM Linux, netdev
In-Reply-To: <20130920160830.GA4241@marquez.int.rhx>
On Fri, Sep 20, 2013 at 9:08 AM, Michele Baldessari <michele@acksyn.org> wrote:
> Hi Russell,
>
> On Fri, Sep 20, 2013 at 02:11:53PM +0100, Russell King - ARM Linux wrote:
>> While running v3.11 on my firewall, I saw this warning. I'm not sure
>> what it means or what its implications are:
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 0 at /home/rmk/git/linux-rmk/net/ipv4/tcp_input.c:2711 tcp_fastretrans_alert+0x178/0x840()
>> Modules linked in: ipt_REJECT xt_multiport iptable_filter ipt_MASQUERADE xt_nat
>> xt_mark iptable_nat nf_nat_ipv4 nf_nat ip6table_mangle xt_LOG xt_limit nf_conntrack_ipv6 nf_defrag_ipv6 xt_state ip6table_filter pata_pcmcia libata scsi_mod 3c589_cs ide_gd_mod ide_cs ide_core sa1111_cs sa1100_cs sa11xx_base soc_common sa11x0_dma virt_dma usbcore usb_common
>> CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0+ #15
>> Backtrace:
>> [<c02111a8>] (dump_backtrace+0x0/0x114) from [<c02115a0>] (show_stack+0x18/0x1c) r6:c0520824 r5:00000009 r4:00000000
>> [<c0211588>] (show_stack+0x0/0x1c) from [<c04d65e0>] (dump_stack+0x20/0x28)
>> [<c04d65c0>] (dump_stack+0x0/0x28) from [<c021bfb0>] (warn_slowpath_common+0x68/0x88)
>> [<c021bf48>] (warn_slowpath_common+0x0/0x88) from [<c021bff4>] (warn_slowpath_null+0x24/0x28)
>> r8:00000000 r7:00000001 r6:00000006 r5:00004320 r4:c11c6580
>> [<c021bfd0>] (warn_slowpath_null+0x0/0x28) from [<c04515bc>] (tcp_fastretrans_alert+0x178/0x840)
>> [<c0451444>] (tcp_fastretrans_alert+0x0/0x840) from [<c045273c>] (tcp_ack+0xa14/0xc18)
>> [<c0451d28>] (tcp_ack+0x0/0xc18) from [<c0453138>] (tcp_rcv_established+0x494/0x594)
>> [<c0452ca4>] (tcp_rcv_established+0x0/0x594) from [<c04a977c>] (tcp_v6_do_rcv+0xd0/0x428)
>> [<c04a96ac>] (tcp_v6_do_rcv+0x0/0x428) from [<c04a9e70>] (tcp_v6_rcv+0x340/0x63c)
>> [<c04a9b30>] (tcp_v6_rcv+0x0/0x63c) from [<c048b334>] (ip6_input_finish+0x214/0x3c4)
>> [<c048b120>] (ip6_input_finish+0x0/0x3c4) from [<c048ba60>] (ip6_input+0x64/0x74)
>> [<c048b9fc>] (ip6_input+0x0/0x74) from [<c048b564>] (ip6_rcv_finish+0x80/0x8c)
>> r4:c1c9ee20
>> [<c048b4e4>] (ip6_rcv_finish+0x0/0x8c) from [<c048b994>] (ipv6_rcv+0x424/0x48c)
>> r4:c1c9ee20
>> [<c048b570>] (ipv6_rcv+0x0/0x48c) from [<c0407624>] (__netif_receive_skb_core+0x618/0x688)
>> r8:0000dd86 r7:00000000 r6:c11f6800 r5:c05ee6cc r4:c05f1b98
>> [<c040700c>] (__netif_receive_skb_core+0x0/0x688) from [<c040770c>] (__netif_receive_skb+0x78/0x80)
>> [<c0407694>] (__netif_receive_skb+0x0/0x80) from [<c04077a8>] (process_backlog+0x94/0x14c)
>> r5:c06091e0 r4:c0609220
>> [<c0407714>] (process_backlog+0x0/0x14c) from [<c0407af4>] (net_rx_action+0x78/0x1ac)
>> [<c0407a7c>] (net_rx_action+0x0/0x1ac) from [<c021f500>] (__do_softirq+0xb4/0x198)
>> [<c021f44c>] (__do_softirq+0x0/0x198) from [<c021f90c>] (irq_exit+0x74/0xc8)
>> [<c021f898>] (irq_exit+0x0/0xc8) from [<c020f1ac>] (handle_IRQ+0x68/0x88)
>> r4:0000000b
>> [<c020f144>] (handle_IRQ+0x0/0x88) from [<c0208210>] (asm_do_IRQ+0x10/0x14)
>> r5:60000013 r4:c0246818
>> [<c0208200>] (asm_do_IRQ+0x0/0x14) from [<c0211fcc>] (__irq_svc+0x2c/0x98)
>> Exception stack(0xc05e7f54 to 0xc05e7f9c)
>> 7f40: 00000000 00000000 00000000
>> 7f60: 60000013 c05e6000 c06092a4 c05ee080 00000001 c0204000 6901b115 c05e0800
>> 7f80: c05e7fb8 c05e7f9c c05e7f9c c020f348 c0246818 60000013 ffffffff
>> [<c0246794>] (cpu_startup_entry+0x0/0xe8) from [<c04d4d70>] (rest_init+0x64/0x7c)
>> r7:c05f3940 r6:c0922200 r5:c0609340 r4:c05ee0c0
>> [<c04d4d0c>] (rest_init+0x0/0x7c) from [<c05c3acc>] (start_kernel+0x350/0x3ac)
>> [<c05c377c>] (start_kernel+0x0/0x3ac) from [<c0208040>] (0xc0208040)
>> ---[ end trace ab55f0e3f592fa5e ]---
>
> there's been multiple reports about this one:
> https://bugzilla.redhat.com/show_bug.cgi?id=989251
> http://bugzilla.kernel.org/show_bug.cgi?id=60779
>
> Could you try Yuchung's debug patch?
> http://www.spinics.net/lists/netdev/msg250193.html
Yes it looks like the same bug. Please try that patch to help identify
this elusive bug.
>
> thanks,
> Michele
> --
> Michele Baldessari <michele@acksyn.org>
> C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
^ permalink raw reply
* Re: [PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers
From: Mark Brown @ 2013-09-20 16:36 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, Takashi Iwai, linux-mmc, linux-fbdev,
linux-nvme, Jaroslav Kysela, Peter Ujfalusi, linux-ide, devel,
linux-samsung-soc, linux-scsi, e1000-devel, b43-dev, linux-media,
devicetree, Haojian Zhuang, Timur Tabi, Kukjin Kim, dri-devel,
Ben Dooks, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, Eric Miao, Sangbeom Kim
In-Reply-To: <E1VMm9m-0007ij-ER@rmk-PC.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 261 bytes --]
On Thu, Sep 19, 2013 at 10:53:02PM +0100, Russell King wrote:
> This code sequence is unsafe in modules:
>
> static u64 mask = DMA_BIT_MASK(something);
> ...
> if (!dev->dma_mask)
> dev->dma_mask = &mask;
Acked-by: Mark Brown <broonie@linaro.org>
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: Francesco Ruggeri @ 2013-09-20 16:34 UTC (permalink / raw)
To: ebiederm
Cc: edumazet, jiri, alexander.h.duyck, amwang, netdev,
Francesco Ruggeri
In-Reply-To: <871u4mh781.fsf@tw-ebiederman.twitter.com>
Just an update.
I have been testing this patch in 3.4 (that is the environment where I can
stress things a bit more) and I have also manually tested cases that were
causing problems before.
This is essentially Eric's patch except that it maintains per-namespace
counters and wait queues to avoid unnecessary wakeup calls.
Everything seems to be working fine.
We just started using lockdep and I did see a couple of warnings though.
They do not seem to be related to the patch to me, but I am attaching them
to see what you think.
Index: linux-3.4.x86_64/include/net/net_namespace.h
===================================================================
--- linux-3.4.x86_64.orig/include/net/net_namespace.h
+++ linux-3.4.x86_64/include/net/net_namespace.h
@@ -68,6 +68,8 @@ struct net {
struct hlist_head *dev_name_head;
struct hlist_head *dev_index_head;
unsigned int dev_base_seq; /* protected by rtnl_mutex */
+ int dev_unregistering; /* protected by rtnl_mutex */
+ wait_queue_head_t dev_unregistering_wait;
/* core fib_rules */
struct list_head rules_ops;
Index: linux-3.4.x86_64/net/core/net_namespace.c
===================================================================
--- linux-3.4.x86_64.orig/net/core/net_namespace.c
+++ linux-3.4.x86_64/net/core/net_namespace.c
@@ -153,6 +153,8 @@ static __net_init int setup_net(struct n
atomic_set(&net->count, 1);
atomic_set(&net->passive, 1);
net->dev_base_seq = 1;
+ net->dev_unregistering = 0;
+ init_waitqueue_head(&net->dev_unregistering_wait);
#ifdef NETNS_REFCNT_DEBUG
atomic_set(&net->use_count, 0);
Index: linux-3.4.x86_64/net/core/dev.c
===================================================================
--- linux-3.4.x86_64.orig/net/core/dev.c
+++ linux-3.4.x86_64/net/core/dev.c
@@ -5191,6 +5191,7 @@ static LIST_HEAD(net_todo_list);
static void net_set_todo(struct net_device *dev)
{
list_add_tail(&dev->todo_list, &net_todo_list);
+ dev_net(dev)->dev_unregistering++;
}
static void rollback_registered_many(struct list_head *head)
@@ -5815,6 +5816,12 @@ void netdev_run_todo(void)
if (dev->destructor)
dev->destructor(dev);
+ rtnl_lock();
+ BUG_ON(dev_net(dev)->dev_unregistering <= 0);
+ if (--dev_net(dev)->dev_unregistering == 0)
+ wake_up(&dev_net(dev)->dev_unregistering_wait);
+ __rtnl_unlock();
+
/* Free network device */
kobject_put(&dev->dev.kobj);
}
@@ -6478,6 +6485,26 @@ static void __net_exit default_device_ex
rtnl_unlock();
}
+static void netdev_wait_unregistering_and_lock(struct list_head *net_list)
+{
+ struct net *net;
+
+retry:
+ /* Wait until any devices in namespaces in net_list that were
+ unregistered by other processes are destroyed */
+ list_for_each_entry(net, net_list, exit_list) {
+ wait_event(net->dev_unregistering_wait,
+ net->dev_unregistering == 0);
+ }
+ rtnl_lock();
+ list_for_each_entry(net, net_list, exit_list) {
+ if (net->dev_unregistering) {
+ __rtnl_unlock();
+ goto retry;
+ }
+ }
+}
+
static void __net_exit default_device_exit_batch(struct list_head *net_list)
{
/* At exit all network devices most be removed from a network
@@ -6489,7 +6516,7 @@ static void __net_exit default_device_ex
struct net *net;
LIST_HEAD(dev_kill_list);
- rtnl_lock();
+ netdev_wait_unregistering_and_lock(net_list);
list_for_each_entry(net, net_list, exit_list) {
for_each_netdev_reverse(net, dev) {
if (dev->rtnl_link_ops)
================== LOCKDEP:
Sep 19 01:48:46 bs341 kernel: ===============================
Sep 19 01:48:46 bs341 kernel: [ INFO: suspicious RCU usage. ]
Sep 19 01:48:46 bs341 kernel: 3.4.43-1432884.2010AroraNoureddine.7.fc14.x86_64 #1 Not tainted
Sep 19 01:48:46 bs341 kernel: -------------------------------
Sep 19 01:48:46 bs341 kernel: drivers/net/macvtap.c:97 suspicious rcu_dereference_check() usage!
Sep 19 01:48:46 bs341 kernel:
Sep 19 01:48:46 bs341 kernel: other info that might help us debug this:
Sep 19 01:48:46 bs341 kernel:
Sep 19 01:48:46 bs341 kernel:
Sep 19 01:48:46 bs341 kernel: rcu_scheduler_active = 1, debug_locks = 1
Sep 19 01:48:46 bs341 kernel: 1 lock held by libvirtd/29791:
Sep 19 01:48:46 bs341 kernel: #0: (macvtap_lock){+.+...}, at: [<ffffffffa033000a>] macvtap_open+0x157/0x1f3 [macvtap]
Sep 19 01:48:46 bs341 kernel:
Sep 19 01:48:46 bs341 kernel: stack backtrace:
Sep 19 01:48:46 bs341 kernel: Pid: 29791, comm: libvirtd Not tainted 3.4.43-1432884.2010AroraNoureddine.7.fc14.x86_64 #1
Sep 19 01:48:46 bs341 kernel: Call Trace:
Sep 19 01:48:46 bs341 kernel: [<ffffffff8106e3e4>] lockdep_rcu_suspicious+0xfc/0x105
Sep 19 01:48:46 bs341 kernel: [<ffffffffa032f51d>] get_slot+0x5f/0x7f [macvtap]
Sep 19 01:48:46 bs341 kernel: [<ffffffffa033001e>] macvtap_open+0x16b/0x1f3 [macvtap]
Sep 19 01:48:46 bs341 kernel: [<ffffffff81105f38>] chrdev_open+0x12b/0x154
Sep 19 01:48:46 bs341 kernel: [<ffffffff81105e0d>] ? cdev_put+0x23/0x23
Sep 19 01:48:46 bs341 kernel: [<ffffffff81100b58>] __dentry_open+0x176/0x29f
Sep 19 01:48:46 bs341 kernel: [<ffffffff8110191f>] nameidata_to_filp+0x63/0x6a
Sep 19 01:48:46 bs341 kernel: [<ffffffff8110e690>] do_last+0x569/0x596
Sep 19 01:48:46 bs341 kernel: [<ffffffff8110edee>] path_openat+0xce/0x348
Sep 19 01:48:46 bs341 kernel: [<ffffffff81008765>] ? native_sched_clock+0x35/0x37
Sep 19 01:48:46 bs341 kernel: [<ffffffff81008770>] ? sched_clock+0x9/0xd
Sep 19 01:48:46 bs341 kernel: [<ffffffff8110f156>] do_filp_open+0x38/0x84
Sep 19 01:48:46 bs341 kernel: [<ffffffff81488775>] ? _raw_spin_unlock+0x26/0x2a
Sep 19 01:48:46 bs341 kernel: [<ffffffff81119d82>] ? alloc_fd+0x173/0x185
Sep 19 01:48:46 bs341 kernel: [<ffffffff81101996>] do_sys_open+0x70/0x102
Sep 19 01:48:46 bs341 kernel: [<ffffffff81141c29>] compat_sys_open+0x16/0x18
Sep 19 01:48:46 bs341 kernel: [<ffffffff814908a6>] sysenter_dispatch+0x7/0x26
Sep 19 01:48:46 bs341 kernel: [<ffffffff812467de>] ? trace_hardirqs_on_thunk+0x3a/0x3f
Sep 19 02:00:40 bs341 kernel: ======================================================
Sep 19 02:00:40 bs341 kernel: [ INFO: possible circular locking dependency detected ]
Sep 19 02:00:40 bs341 kernel: 3.4.43-1432884.2010AroraNoureddine.7.fc14.x86_64 #1 Not tainted
Sep 19 02:00:40 bs341 kernel: -------------------------------------------------------
Sep 19 02:00:40 bs341 kernel: [manager]/6158 is trying to acquire lock:
Sep 19 02:00:40 bs341 kernel: (rtnl_mutex){+.+.+.}, at: [<ffffffff813bccfe>] rtnl_lock+0x12/0x14
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: but task is already holding lock:
Sep 19 02:00:40 bs341 kernel: (&mm->mmap_sem){++++++}, at: [<ffffffff810e3702>] vm_munmap+0x35/0x5c
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: which lock already depends on the new lock.
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: the existing dependency chain (in reverse order) is:
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: -> #1 (&mm->mmap_sem){++++++}:
Sep 19 02:00:40 bs341 kernel: [<ffffffff8107222b>] lock_acquire+0xbe/0x101
Sep 19 02:00:40 bs341 kernel: [<ffffffff810dcbef>] might_fault+0x68/0x8b
Sep 19 02:00:40 bs341 kernel: [<ffffffff813abdbd>] copy_from_user+0x19/0x2c
Sep 19 02:00:40 bs341 kernel: [<ffffffff813b1375>] dev_ioctl+0x57/0x683
Sep 19 02:00:40 bs341 kernel: [<ffffffff81399ef5>] sock_do_ioctl+0x38/0x43
Sep 19 02:00:40 bs341 kernel: [<ffffffff8139a320>] sock_ioctl+0x20e/0x21d
Sep 19 02:00:40 bs341 kernel: [<ffffffff811115a2>] do_vfs_ioctl+0x488/0x4c9
Sep 19 02:00:40 bs341 kernel: [<ffffffff81111634>] sys_ioctl+0x51/0x75
Sep 19 02:00:40 bs341 kernel: [<ffffffff8148f2b9>] system_call_fastpath+0x16/0x1b
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: -> #0 (rtnl_mutex){+.+.+.}:
Sep 19 02:00:40 bs341 kernel: [<ffffffff810719fa>] __lock_acquire+0xb41/0xe50
Sep 19 02:00:40 bs341 kernel: [<ffffffff8107222b>] lock_acquire+0xbe/0x101
Sep 19 02:00:40 bs341 kernel: [<ffffffff814862c2>] __mutex_lock_common+0x4c/0x392
Sep 19 02:00:40 bs341 kernel: [<ffffffff81486667>] mutex_lock_nested+0x16/0x18
Sep 19 02:00:40 bs341 kernel: [<ffffffff813bccfe>] rtnl_lock+0x12/0x14
Sep 19 02:00:40 bs341 kernel: [<ffffffff814684f8>] packet_release+0xd7/0x267
Sep 19 02:00:40 bs341 kernel: [<ffffffff8139c429>] sock_release+0x1a/0x77
Sep 19 02:00:40 bs341 kernel: [<ffffffff8139c4a8>] sock_close+0x22/0x26
Sep 19 02:00:40 bs341 kernel: [<ffffffff81103c65>] fput+0xff/0x1d4
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e26ee>] remove_vma+0x37/0x6c
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e36b4>] do_munmap+0x2ed/0x306
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e3710>] vm_munmap+0x43/0x5c
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e3851>] sys_munmap+0x21/0x2a
Sep 19 02:00:40 bs341 kernel: [<ffffffff814908a6>] sysenter_dispatch+0x7/0x26
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: other info that might help us debug this:
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: Possible unsafe locking scenario:
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: CPU0 CPU1
Sep 19 02:00:40 bs341 kernel: ---- ----
Sep 19 02:00:40 bs341 kernel: lock(&mm->mmap_sem);
Sep 19 02:00:40 bs341 kernel: lock(rtnl_mutex);
Sep 19 02:00:40 bs341 kernel: lock(&mm->mmap_sem);
Sep 19 02:00:40 bs341 kernel: lock(rtnl_mutex);
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: *** DEADLOCK ***
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: 1 lock held by [manager]/6158:
Sep 19 02:00:40 bs341 kernel: #0: (&mm->mmap_sem){++++++}, at: [<ffffffff810e3702>] vm_munmap+0x35/0x5c
Sep 19 02:00:40 bs341 kernel:
Sep 19 02:00:40 bs341 kernel: stack backtrace:
Sep 19 02:00:40 bs341 kernel: Pid: 6158, comm: [manager] Not tainted 3.4.43-1432884.2010AroraNoureddine.7.fc14.x86_64 #1
Sep 19 02:00:40 bs341 kernel: Call Trace:
Sep 19 02:00:40 bs341 kernel: [<ffffffff8106e906>] print_circular_bug+0x1f8/0x209
Sep 19 02:00:40 bs341 kernel: [<ffffffff810719fa>] __lock_acquire+0xb41/0xe50
Sep 19 02:00:40 bs341 kernel: [<ffffffff8100d93c>] ? save_stack_trace+0x2a/0x47
Sep 19 02:00:40 bs341 kernel: [<ffffffff813bccfe>] ? rtnl_lock+0x12/0x14
Sep 19 02:00:40 bs341 kernel: [<ffffffff8107222b>] lock_acquire+0xbe/0x101
Sep 19 02:00:40 bs341 kernel: [<ffffffff813bccfe>] ? rtnl_lock+0x12/0x14
Sep 19 02:00:40 bs341 kernel: [<ffffffff814862c2>] __mutex_lock_common+0x4c/0x392
Sep 19 02:00:40 bs341 kernel: [<ffffffff813bccfe>] ? rtnl_lock+0x12/0x14
Sep 19 02:00:40 bs341 kernel: [<ffffffff8106da2a>] ? trace_hardirqs_off+0xd/0xf
Sep 19 02:00:40 bs341 kernel: [<ffffffff8105c972>] ? local_clock+0x36/0x4d
Sep 19 02:00:40 bs341 kernel: [<ffffffff813bccfe>] ? rtnl_lock+0x12/0x14
Sep 19 02:00:40 bs341 kernel: [<ffffffff81072144>] ? lock_release+0x1d8/0x201
Sep 19 02:00:40 bs341 kernel: [<ffffffff81486667>] mutex_lock_nested+0x16/0x18
Sep 19 02:00:40 bs341 kernel: [<ffffffff813bccfe>] rtnl_lock+0x12/0x14
Sep 19 02:00:40 bs341 kernel: [<ffffffff814684f8>] packet_release+0xd7/0x267
Sep 19 02:00:40 bs341 kernel: [<ffffffff8139c429>] sock_release+0x1a/0x77
Sep 19 02:00:40 bs341 kernel: [<ffffffff8139c4a8>] sock_close+0x22/0x26
Sep 19 02:00:40 bs341 kernel: [<ffffffff81103c65>] fput+0xff/0x1d4
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e26ee>] remove_vma+0x37/0x6c
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e36b4>] do_munmap+0x2ed/0x306
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e3710>] vm_munmap+0x43/0x5c
Sep 19 02:00:40 bs341 kernel: [<ffffffff810e3851>] sys_munmap+0x21/0x2a
Sep 19 02:00:40 bs341 kernel: [<ffffffff814908a6>] sysenter_dispatch+0x7/0x26
Sep 19 02:00:40 bs341 kernel: [<ffffffff812467de>] ? trace_hardirqs_on_thunk+0x3a/0x3f
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: Ben Hutchings @ 2013-09-20 16:30 UTC (permalink / raw)
To: David Miller
Cc: jslaby, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <20130920.122142.1032350399957506112.davem@davemloft.net>
On Fri, Sep 20, 2013 at 12:21:42PM -0400, David Miller wrote:
> From: Jiri Slaby <jslaby@suse.cz>
> Date: Fri, 20 Sep 2013 18:18:02 +0200
>
> > Ok, let's leave the hole in there then.
>
> Jiri, don't turn this on me.
>
> The issue is not whether something needs to be fixed or not, I never
> said "don't fix this" and therefore I'd like to ask politely that you
> not make it seem like I have.
>
> Rather, I'm saying that the implementation is terrible, sets a bad
> precendence for fixing similar problems, and therefore not is in
> a state where we can apply it.
>
> So, I'm not saying "don't fix this", I'm saying "fix it properly."
I think Jiri's last suggestion was to add the capability check to
device renaming (which I think everyone agrees is needed) and not
to add any group identity checks for any operation.
Isn't that fixing it properly?
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: Jiri Slaby @ 2013-09-20 16:30 UTC (permalink / raw)
To: David Miller; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <20130920.122142.1032350399957506112.davem@davemloft.net>
On 09/20/2013 06:21 PM, David Miller wrote:
> From: Jiri Slaby <jslaby@suse.cz>
> Date: Fri, 20 Sep 2013 18:18:02 +0200
>
>> Ok, let's leave the hole in there then.
>
> Jiri, don't turn this on me.
>
> The issue is not whether something needs to be fixed or not, I never
> said "don't fix this" and therefore I'd like to ask politely that you
> not make it seem like I have.
>
> Rather, I'm saying that the implementation is terrible, sets a bad
> precendence for fixing similar problems, and therefore not is in
> a state where we can apply it.
>
> So, I'm not saying "don't fix this", I'm saying "fix it properly."
Yeah, I understand your point and agree, that the parameter is ugly as
hell. But investing any more time in ISDN is not worth it, I think.
Look, I sent the patch a couple times to the ISDN maintainers and they
didn't even bother to reply. And I am not familiar with the code and do
not want to spend more time than putting there a single check, sorry.
Hence, if there is anybody from the ISDN fellows to take care of that,
nice. If not, we will just live with this patch locally some more years
and drop it when the ISDN subsystem is dropped from the kernel, if
dropped at all.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: David Miller @ 2013-09-20 16:21 UTC (permalink / raw)
To: jslaby; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <523C753A.8040401@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 20 Sep 2013 18:18:02 +0200
> Ok, let's leave the hole in there then.
Jiri, don't turn this on me.
The issue is not whether something needs to be fixed or not, I never
said "don't fix this" and therefore I'd like to ask politely that you
not make it seem like I have.
Rather, I'm saying that the implementation is terrible, sets a bad
precendence for fixing similar problems, and therefore not is in
a state where we can apply it.
So, I'm not saying "don't fix this", I'm saying "fix it properly."
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: Jiri Slaby @ 2013-09-20 16:18 UTC (permalink / raw)
To: David Miller; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <20130920.121535.1653382964468102292.davem@davemloft.net>
On 09/20/2013 06:15 PM, David Miller wrote:
> From: Jiri Slaby <jslaby@suse.cz>
> Date: Fri, 20 Sep 2013 18:14:28 +0200
>
>> On 09/20/2013 05:56 PM, David Miller wrote:
>>> From: Jiri Slaby <jslaby@suse.cz>
>>> Date: Fri, 20 Sep 2013 15:44:33 +0200
>>>
>>>> On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>>>>>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>>>>>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>>>>>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>>>>>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>>>>>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>>>>>> sizeof(dn))) { err = -EFAULT;
>>>>>
>>>>> This seems to be the important bit: renaming of devices (if allowed
>>>>> at all) ought to be limited to CAP_SYS_ADMIN or possibly
>>>>> CAP_NET_ADMIN. But why should the group that is allowed to use
>>>>> mISDN data sockets also be allowed to do this?
>>>>
>>>> This is based on an old patch we are dragging in SUSE since 2009:
>>>> http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
>>>> https://bugzilla.novell.com/show_bug.cgi?id=564423
>>>>
>>>> The whole point of the gid-based access was to still allow some user
>>>> group to manipulate the device in an arbitrary way.
>>>>
>>>> So if everybody agrees I will just disallow rename to
>>>> non-CAP_NET_ADMIN users and we are done?
>>>
>>> No we are not done, sorry.
>>>
>>> Having a device specific module parameter for this is wrong on several
>>> fundamental levels.
>>
>> What I'm suggesting is just to put a !capable(CAP_NET_ADMIN) test into
>> the rename path and nothing more.
>
> And I'm saying that regardless of such a change, the patch itself
> is fundamentally implemented incorrectly and not acceptable for
> upstream inclusion until the interface for configuration is changed.
Ok, let's leave the hole in there then.
--
js
suse labs
^ permalink raw reply
* net-next is now OPEN
From: David Miller @ 2013-09-20 16:17 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
Please feel free to submit changes against it for the next merge
window.
Thanks.
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: David Miller @ 2013-09-20 16:15 UTC (permalink / raw)
To: jslaby; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <523C7464.3070007@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 20 Sep 2013 18:14:28 +0200
> On 09/20/2013 05:56 PM, David Miller wrote:
>> From: Jiri Slaby <jslaby@suse.cz>
>> Date: Fri, 20 Sep 2013 15:44:33 +0200
>>
>>> On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>>>>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>>>>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>>>>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>>>>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>>>>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>>>>> sizeof(dn))) { err = -EFAULT;
>>>>
>>>> This seems to be the important bit: renaming of devices (if allowed
>>>> at all) ought to be limited to CAP_SYS_ADMIN or possibly
>>>> CAP_NET_ADMIN. But why should the group that is allowed to use
>>>> mISDN data sockets also be allowed to do this?
>>>
>>> This is based on an old patch we are dragging in SUSE since 2009:
>>> http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
>>> https://bugzilla.novell.com/show_bug.cgi?id=564423
>>>
>>> The whole point of the gid-based access was to still allow some user
>>> group to manipulate the device in an arbitrary way.
>>>
>>> So if everybody agrees I will just disallow rename to
>>> non-CAP_NET_ADMIN users and we are done?
>>
>> No we are not done, sorry.
>>
>> Having a device specific module parameter for this is wrong on several
>> fundamental levels.
>
> What I'm suggesting is just to put a !capable(CAP_NET_ADMIN) test into
> the rename path and nothing more.
And I'm saying that regardless of such a change, the patch itself
is fundamentally implemented incorrectly and not acceptable for
upstream inclusion until the interface for configuration is changed.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Bastian Blank @ 2013-09-20 16:14 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, Ian Campbell, Wei Liu, David Vrabel, xen-devel
In-Reply-To: <1379685460-25032-3-git-send-email-paul.durrant@citrix.com>
On Fri, Sep 20, 2013 at 02:57:40PM +0100, Paul Durrant wrote:
> Some old Windows frontends fail to transition through the xenbus Closing
> state and move directly from Connected to Closed. Handle this case properly.
What happens in this case? Are there other state changes that will do
unwanted things?
Bastian
--
If there are self-made purgatories, then we all have to live in them.
-- Spock, "This Side of Paradise", stardate 3417.7
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: Jiri Slaby @ 2013-09-20 16:14 UTC (permalink / raw)
To: David Miller; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <20130920.115634.1931451843075283025.davem@davemloft.net>
On 09/20/2013 05:56 PM, David Miller wrote:
> From: Jiri Slaby <jslaby@suse.cz>
> Date: Fri, 20 Sep 2013 15:44:33 +0200
>
>> On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>>>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>>>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>>>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>>>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>>>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>>>> sizeof(dn))) { err = -EFAULT;
>>>
>>> This seems to be the important bit: renaming of devices (if allowed
>>> at all) ought to be limited to CAP_SYS_ADMIN or possibly
>>> CAP_NET_ADMIN. But why should the group that is allowed to use
>>> mISDN data sockets also be allowed to do this?
>>
>> This is based on an old patch we are dragging in SUSE since 2009:
>> http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
>> https://bugzilla.novell.com/show_bug.cgi?id=564423
>>
>> The whole point of the gid-based access was to still allow some user
>> group to manipulate the device in an arbitrary way.
>>
>> So if everybody agrees I will just disallow rename to
>> non-CAP_NET_ADMIN users and we are done?
>
> No we are not done, sorry.
>
> Having a device specific module parameter for this is wrong on several
> fundamental levels.
What I'm suggesting is just to put a !capable(CAP_NET_ADMIN) test into
the rename path and nothing more.
--
js
suse labs
^ permalink raw reply
* Re: IPv6 kernel warning
From: Michele Baldessari @ 2013-09-20 16:08 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: netdev, ycheng
In-Reply-To: <20130920131153.GF12758@n2100.arm.linux.org.uk>
Hi Russell,
On Fri, Sep 20, 2013 at 02:11:53PM +0100, Russell King - ARM Linux wrote:
> While running v3.11 on my firewall, I saw this warning. I'm not sure
> what it means or what its implications are:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at /home/rmk/git/linux-rmk/net/ipv4/tcp_input.c:2711 tcp_fastretrans_alert+0x178/0x840()
> Modules linked in: ipt_REJECT xt_multiport iptable_filter ipt_MASQUERADE xt_nat
> xt_mark iptable_nat nf_nat_ipv4 nf_nat ip6table_mangle xt_LOG xt_limit nf_conntrack_ipv6 nf_defrag_ipv6 xt_state ip6table_filter pata_pcmcia libata scsi_mod 3c589_cs ide_gd_mod ide_cs ide_core sa1111_cs sa1100_cs sa11xx_base soc_common sa11x0_dma virt_dma usbcore usb_common
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0+ #15
> Backtrace:
> [<c02111a8>] (dump_backtrace+0x0/0x114) from [<c02115a0>] (show_stack+0x18/0x1c) r6:c0520824 r5:00000009 r4:00000000
> [<c0211588>] (show_stack+0x0/0x1c) from [<c04d65e0>] (dump_stack+0x20/0x28)
> [<c04d65c0>] (dump_stack+0x0/0x28) from [<c021bfb0>] (warn_slowpath_common+0x68/0x88)
> [<c021bf48>] (warn_slowpath_common+0x0/0x88) from [<c021bff4>] (warn_slowpath_null+0x24/0x28)
> r8:00000000 r7:00000001 r6:00000006 r5:00004320 r4:c11c6580
> [<c021bfd0>] (warn_slowpath_null+0x0/0x28) from [<c04515bc>] (tcp_fastretrans_alert+0x178/0x840)
> [<c0451444>] (tcp_fastretrans_alert+0x0/0x840) from [<c045273c>] (tcp_ack+0xa14/0xc18)
> [<c0451d28>] (tcp_ack+0x0/0xc18) from [<c0453138>] (tcp_rcv_established+0x494/0x594)
> [<c0452ca4>] (tcp_rcv_established+0x0/0x594) from [<c04a977c>] (tcp_v6_do_rcv+0xd0/0x428)
> [<c04a96ac>] (tcp_v6_do_rcv+0x0/0x428) from [<c04a9e70>] (tcp_v6_rcv+0x340/0x63c)
> [<c04a9b30>] (tcp_v6_rcv+0x0/0x63c) from [<c048b334>] (ip6_input_finish+0x214/0x3c4)
> [<c048b120>] (ip6_input_finish+0x0/0x3c4) from [<c048ba60>] (ip6_input+0x64/0x74)
> [<c048b9fc>] (ip6_input+0x0/0x74) from [<c048b564>] (ip6_rcv_finish+0x80/0x8c)
> r4:c1c9ee20
> [<c048b4e4>] (ip6_rcv_finish+0x0/0x8c) from [<c048b994>] (ipv6_rcv+0x424/0x48c)
> r4:c1c9ee20
> [<c048b570>] (ipv6_rcv+0x0/0x48c) from [<c0407624>] (__netif_receive_skb_core+0x618/0x688)
> r8:0000dd86 r7:00000000 r6:c11f6800 r5:c05ee6cc r4:c05f1b98
> [<c040700c>] (__netif_receive_skb_core+0x0/0x688) from [<c040770c>] (__netif_receive_skb+0x78/0x80)
> [<c0407694>] (__netif_receive_skb+0x0/0x80) from [<c04077a8>] (process_backlog+0x94/0x14c)
> r5:c06091e0 r4:c0609220
> [<c0407714>] (process_backlog+0x0/0x14c) from [<c0407af4>] (net_rx_action+0x78/0x1ac)
> [<c0407a7c>] (net_rx_action+0x0/0x1ac) from [<c021f500>] (__do_softirq+0xb4/0x198)
> [<c021f44c>] (__do_softirq+0x0/0x198) from [<c021f90c>] (irq_exit+0x74/0xc8)
> [<c021f898>] (irq_exit+0x0/0xc8) from [<c020f1ac>] (handle_IRQ+0x68/0x88)
> r4:0000000b
> [<c020f144>] (handle_IRQ+0x0/0x88) from [<c0208210>] (asm_do_IRQ+0x10/0x14)
> r5:60000013 r4:c0246818
> [<c0208200>] (asm_do_IRQ+0x0/0x14) from [<c0211fcc>] (__irq_svc+0x2c/0x98)
> Exception stack(0xc05e7f54 to 0xc05e7f9c)
> 7f40: 00000000 00000000 00000000
> 7f60: 60000013 c05e6000 c06092a4 c05ee080 00000001 c0204000 6901b115 c05e0800
> 7f80: c05e7fb8 c05e7f9c c05e7f9c c020f348 c0246818 60000013 ffffffff
> [<c0246794>] (cpu_startup_entry+0x0/0xe8) from [<c04d4d70>] (rest_init+0x64/0x7c)
> r7:c05f3940 r6:c0922200 r5:c0609340 r4:c05ee0c0
> [<c04d4d0c>] (rest_init+0x0/0x7c) from [<c05c3acc>] (start_kernel+0x350/0x3ac)
> [<c05c377c>] (start_kernel+0x0/0x3ac) from [<c0208040>] (0xc0208040)
> ---[ end trace ab55f0e3f592fa5e ]---
there's been multiple reports about this one:
https://bugzilla.redhat.com/show_bug.cgi?id=989251
http://bugzilla.kernel.org/show_bug.cgi?id=60779
Could you try Yuchung's debug patch?
http://www.spinics.net/lists/netdev/msg250193.html
thanks,
Michele
--
Michele Baldessari <michele@acksyn.org>
C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
^ permalink raw reply
* Re: [PATCH] qlge: call ql_core_dump() only if dump memory was allocated.
From: David Miller @ 2013-09-20 16:02 UTC (permalink / raw)
To: malahal; +Cc: netdev
In-Reply-To: <1379691031-28666-1-git-send-email-malahal@us.ibm.com>
From: Malahal Naineni <malahal@us.ibm.com>
Date: Fri, 20 Sep 2013 10:30:31 -0500
> Also changed a log message to indicate that memory was not allocated
> instead of memory not available!
This change is not submitted properly, in particular it is missing
a signoff.
^ permalink raw reply
* Re: [PATCH] stable_kernel_rules.txt: Exclude networking from stable rules
From: David Miller @ 2013-09-20 15:59 UTC (permalink / raw)
To: joe; +Cc: stephen, netdev, mpatocka, gregkh, rob, linux-doc, linux-kernel
In-Reply-To: <1379688880.2021.38.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Fri, 20 Sep 2013 07:54:40 -0700
> On Thu, 2013-09-19 at 11:31 -0700, Joe Perches wrote:
>> Networking is once again "special", so at least document
>> how it's working today in the hope that doing so makes
>> less work for all that actually read the documentation.
>
> David, why did you mark this N/A is patchwork?
> It's your rule, why not document it?
Because it should go through whoever maintains that document, and
that isn't me.
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: David Miller @ 2013-09-20 15:56 UTC (permalink / raw)
To: jslaby; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <523C5141.4080608@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 20 Sep 2013 15:44:33 +0200
> On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>>> sizeof(dn))) { err = -EFAULT;
>>
>> This seems to be the important bit: renaming of devices (if allowed
>> at all) ought to be limited to CAP_SYS_ADMIN or possibly
>> CAP_NET_ADMIN. But why should the group that is allowed to use
>> mISDN data sockets also be allowed to do this?
>
> This is based on an old patch we are dragging in SUSE since 2009:
> http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
> https://bugzilla.novell.com/show_bug.cgi?id=564423
>
> The whole point of the gid-based access was to still allow some user
> group to manipulate the device in an arbitrary way.
>
> So if everybody agrees I will just disallow rename to
> non-CAP_NET_ADMIN users and we are done?
No we are not done, sorry.
Having a device specific module parameter for this is wrong on several
fundamental levels.
Module parameters are wrong because you're going to eventually want to
do this for other ISDN or other devices, and nobody is going to make
sure the name of the parameter nor the semantics all match up.
This is the worst possible user experience.
You need to make it so that there is a standard, regular, interface
for performing this task or making this setting. Module parameters
are not it.
The reason this patch has rotted since 2009 is that it really is far
from suitable for upstream inclusion, and I really don't see that much
thought or care has been put into how it is implemented, so I wonder
how much anyone really cares about the change.
^ permalink raw reply
* Re: [PATCH 18/51] DMA-API: staging: et131x: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Ben Hutchings @ 2013-09-20 15:42 UTC (permalink / raw)
To: Russell King; +Cc: devel, netdev
In-Reply-To: <E1VMm05-0007hG-5T@rmk-PC.arm.linux.org.uk>
[Trimmed cc's]
On Thu, 2013-09-19 at 22:43 +0100, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/staging/et131x/et131x.c | 17 ++---------------
> 1 files changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
> index f73e58f..98edfa8 100644
> --- a/drivers/staging/et131x/et131x.c
> +++ b/drivers/staging/et131x/et131x.c
> @@ -4797,21 +4797,8 @@ static int et131x_pci_setup(struct pci_dev *pdev,
> pci_set_master(pdev);
>
> /* Check the DMA addressing support of this device */
> - if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> - rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
> - if (rc < 0) {
> - dev_err(&pdev->dev,
> - "Unable to obtain 64 bit DMA for consistent allocations\n");
> - goto err_release_res;
> - }
> - } else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
> - rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> - if (rc < 0) {
> - dev_err(&pdev->dev,
> - "Unable to obtain 32 bit DMA for consistent allocations\n");
> - goto err_release_res;
> - }
> - } else {
> + if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) ||
> + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))) {
Surely we want && here.
Ben.
> dev_err(&pdev->dev, "No usable DMA addressing method\n");
> rc = -EIO;
> goto err_release_res;
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] skge: fix broken driver
From: Igor Gnatenko @ 2013-09-20 15:35 UTC (permalink / raw)
To: Mikulas Patocka; +Cc: Francois Romieu, David Miller, stephen, netdev
In-Reply-To: <alpine.LRH.2.02.1309201030420.30821@file01.intranet.prod.int.rdu2.redhat.com>
On Fri, 2013-09-20 at 10:32 -0400, Mikulas Patocka wrote:
>
>
> On Thu, 19 Sep 2013, Francois Romieu wrote:
>
> > Mikulas Patocka <mpatocka@redhat.com> :
> > [...]
> > > I see. My patch is a bit simpler - it doesn't allocate the structure
> > > skge_element on the stack.
> >
> > Both patches don't behave exactly the same wrt pci_unmap_single.
> >
> > --
> > Ueimor
>
> I see, my patch passes a wrong value to pci_unmap_single. So I made this
> change to make it pass the correct value. Do you agree with this patch?
>
> ---
>
> skge: fix invalid value passed to pci_unmap_sigle
>
> In my patch c194992cbe71c20bb3623a566af8d11b0bfaa721 I didn't fix the skge
> bug correctly. The value of the new mapping (not old) was passed to
> pci_unmap_single.
>
> If we enable CONFIG_DMA_API_DEBUG, it results in this warning:
> WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:986 check_sync+0x4c4/0x580()
> skge 0000:02:07.0: DMA-API: device driver tries to sync DMA memory it has
> not allocated [device address=0x000000023a0096c0] [size=1536 bytes]
>
> This patch makes the skge driver pass the correct value to
> pci_unmap_single and fixes the warning. It copies the old descriptor to
> on-stack variable "ee" and unmaps it if mapping of the new descriptor
> succeeded.
>
> This patch should be backported to 3.11-stable.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Reported-by: Francois Romieu <romieu@fr.zoreil.com>
> Tested-by: Mikulas Patocka <mpatocka@redhat.com>
>
> ---
> drivers/net/ethernet/marvell/skge.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> Index: linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c
> ===================================================================
> --- linux-3.11.1-fast.orig/drivers/net/ethernet/marvell/skge.c 2013-09-20 16:13:24.000000000 +0200
> +++ linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c 2013-09-20 16:18:13.000000000 +0200
> @@ -3086,13 +3086,16 @@ static struct sk_buff *skge_rx_get(struc
> PCI_DMA_FROMDEVICE);
> skge_rx_reuse(e, skge->rx_buf_size);
> } else {
> + struct skge_element ee;
> struct sk_buff *nskb;
>
> nskb = netdev_alloc_skb_ip_align(dev, skge->rx_buf_size);
> if (!nskb)
> goto resubmit;
>
> - skb = e->skb;
> + ee = *e;
> +
> + skb = ee.skb;
> prefetch(skb->data);
>
> if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
> @@ -3101,8 +3104,8 @@ static struct sk_buff *skge_rx_get(struc
> }
>
> pci_unmap_single(skge->hw->pdev,
> - dma_unmap_addr(e, mapaddr),
> - dma_unmap_len(e, maplen),
> + dma_unmap_addr(&ee, mapaddr),
> + dma_unmap_len(&ee, maplen),
> PCI_DMA_FROMDEVICE);
> }
>
Mikulas, I think you should send this patch separate..
--
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.1-300.fc20.x86_64
^ permalink raw reply
* [PATCH] qlge: call ql_core_dump() only if dump memory was allocated.
From: Malahal Naineni @ 2013-09-20 15:30 UTC (permalink / raw)
To: netdev
Also changed a log message to indicate that memory was not allocated
instead of memory not available!
---
drivers/net/ethernet/qlogic/qlge/qlge_dbg.c | 4 ++--
drivers/net/ethernet/qlogic/qlge/qlge_mpi.c | 12 +++++++-----
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
index 10093f0..6bc5db7 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
@@ -740,8 +740,8 @@ int ql_core_dump(struct ql_adapter *qdev, struct ql_mpi_coredump *mpi_coredump)
int i;
if (!mpi_coredump) {
- netif_err(qdev, drv, qdev->ndev, "No memory available\n");
- return -ENOMEM;
+ netif_err(qdev, drv, qdev->ndev, "No memory allocated\n");
+ return -EINVAL;
}
/* Try to get the spinlock, but dont worry if
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c b/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
index ff2bf8a..99a3e07 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
@@ -1274,11 +1274,13 @@ void ql_mpi_reset_work(struct work_struct *work)
return;
}
- if (!ql_core_dump(qdev, qdev->mpi_coredump)) {
- netif_err(qdev, drv, qdev->ndev, "Core is dumped!\n");
- qdev->core_is_dumped = 1;
- queue_delayed_work(qdev->workqueue,
- &qdev->mpi_core_to_log, 5 * HZ);
+ if (qdev->mpi_coredump) {
+ if (!ql_core_dump(qdev, qdev->mpi_coredump)) {
+ netif_err(qdev, drv, qdev->ndev, "Core is dumped!\n");
+ qdev->core_is_dumped = 1;
+ queue_delayed_work(qdev->workqueue,
+ &qdev->mpi_core_to_log, 5 * HZ);
+ }
}
ql_soft_reset_mpi_risc(qdev);
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
From: Felipe Balbi @ 2013-09-20 15:15 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Felipe Balbi, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920134938.GO25647@n2100.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1239 bytes --]
Hi,
On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > > Use platform_device_register_full() for those drivers which can, to
> > > avoid messing directly with DMA masks. This can only be done when
> > > the driver does not need to access the allocated musb platform device
> > > from within its callbacks, which may be called during the musb
> > > device probing.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > you want me to carry this one through my tree or you prefer getting my
> > Acked-by ? Either way works for me:
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
> >
> > there's also the third option of me setting up a branch with only this
> > patch and we both merge it, that'd also work.
>
> I think this patch is sufficiently stand-alone that it should be fine
> if you want to take it through your tree. That may be better in the
> long run to avoid conflicts with this patch and any future work in
> this area during this cycle.
awesome, i'll take this one early next week.
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 1/2] xen-netback: add a vif-is-connected flag
From: Paul Durrant @ 2013-09-20 15:02 UTC (permalink / raw)
To: David Vrabel, Wei Liu
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org, Ian Campbell
In-Reply-To: <523C5BA7.2010500@citrix.com>
> -----Original Message-----
> From: David Vrabel
> Sent: 20 September 2013 15:29
> To: Wei Liu
> Cc: Paul Durrant; netdev@vger.kernel.org; xen-devel@lists.xen.org; Ian
> Campbell
> Subject: Re: [PATCH net-next 1/2] xen-netback: add a vif-is-connected flag
>
> On 20/09/13 14:31, Wei Liu wrote:
> > On Fri, Sep 20, 2013 at 01:56:30PM +0100, Paul Durrant wrote:
> >> Having applied my patch to separate vif disconnect and free, I ran into a
> >> BUG when testing resume from S3 with a Windows frontend because the
> vif task
> >> pointer was not cleared by xenvif_disconnect() and so a double call to this
> >> function tries to stop the thread twice.
> >> Rather than applying a point fix for that issue it seems better to introduce
> >> a boolean to indicate whether the vif is connected or not such that
> repeated
> >> calls to either xenvif_connect() or xenvif_disconnect() behave
> appropriately.
>
> We already have a backend state of CONNECTED/CLOSED/etc. why do we
> need
> an additional bit of state outside of this?
>
It's not really additional state; we were essentially inferring connected-ness from the value of tx_irq. This patch really just removes that inference and created something with the intended meaning.
> Does something like this in frontend_changed() fix it?
>
It may well do, but it's a far more invasive change and would require more testing. It certainly sounds like a good thing to do in the longer term.
Paul
> case XenbusStateClosing:
> switch (dev->state) {
> case XenbusStateClosed;
> break;
> case XenbusStateConnected:
> disconnect_backend(dev);
> /* fall through */
> default:
> xenbus_switch_state(dev, XenbusStateClosing);
> break;
> }
> break;
>
> case XenbusStateClosed:
> switch (dev->state) {
> case XenbusStateConnected;
> disconnect_backend(dev);
> /* fall through */
> default:
> xenbus_switch_state(dev, XenbusStateClosed);
> break;
> }
> if (xenbus_dev_is_online(dev))
> break;
> /* fall through if not online */
>
> Can you also remove destroy_backend()? It's not needed any more.
>
> I'd also recommend waiting a bit for other review feedback before
> posting an updated series.
>
> David
^ permalink raw reply
* Re: [PATCH] stable_kernel_rules.txt: Exclude networking from stable rules
From: Joe Perches @ 2013-09-20 14:54 UTC (permalink / raw)
To: David Miller
Cc: stephen, netdev, Mikulas Patocka, Greg Kroah-Hartman, Rob Landley,
linux-doc, LKML
In-Reply-To: <1379615474.22168.13.camel@joe-AO722>
On Thu, 2013-09-19 at 11:31 -0700, Joe Perches wrote:
> Networking is once again "special", so at least document
> how it's working today in the hope that doing so makes
> less work for all that actually read the documentation.
David, why did you mark this N/A is patchwork?
It's your rule, why not document it?
^ 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