* Re: pull request: wireless-2.6 2011-02-08
From: David Miller @ 2011-02-08 20:14 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110208195530.GB6244@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 8 Feb 2011 14:55:30 -0500
> Here is the latest round of wireless fixes intended for 2.6.38.
> Included is a carl9170 fix (described as a typo) for receiving buffered
> broadcasts, an iwlagn fix to properly monitor the rfkill switch when
> the interface is down, a mac80211 fix to correctly check for cloned
> skbs when resizing, a null pointer fix for wl1251 if it fails to get
> a beacon, a mac80211 fix related to off-channel tx, an ssb fix for
> using the wrong pointer for getting invariance for pcmcia devices,
> an ath9k double-free fix, and a one-line iwlagn fix to correctly
> describe an antenna configuration.
Pulled, thanks John.
^ permalink raw reply
* Re: [net-2.6 0/7][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-02-08 20:17 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <1297158279-20277-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 8 Feb 2011 01:44:32 -0800
> The following series contains the addition of a PHY id for e1000,
> fix for e1000e, and several ixgbe fixes.
>
> We are currently still working on the patch:
> ixgbe: DDP last buffer size work around
> which was in the previous pull request, and has been removed from this
> pull request.
>
> The following are changes since commit 429a01a70f301baf0c8fc780f891a18c296d5e24:
> Merge branch 'batman-adv/merge' of git://git.open-mesh.org/ecsv/linux-merge
>
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-2.6 master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [net-next-2.6 03/16] e1000e: do not wakeup Tx queue until ready
From: David Miller @ 2011-02-08 20:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: bruce.w.allan, netdev, gospo, bphilips
In-Reply-To: <1297168167-15755-4-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 8 Feb 2011 04:29:14 -0800
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> When restarting the adapter via calls to e1000e_down() followed by
> e1000e_up() (for example when restarting autonegotiation via ethtool),
> packets can be queued for transmit before link is actually up and
> netif_carrier_on is set. This was causing the watchdog_task to do an
> extra unnecessary reset of the adapter. Delaying the wakeup of the Tx
> queue until link is up prevents the reset.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
You should not control the TX queue based upon link status information.
That's the job of netif_carrier_{on,off}().
The TX queue state should be set based solely upon that state of the
TX ring, whether it is full or not.
When the netif carrier is off, the packet scheduler is blocked from
sending packets to the driver.
If that isn't happening, that's a bug which you need to track down.
Maybe you're not doing netif_carrier_off() early enough.
^ permalink raw reply
* pull request: wireless-next-2.6 2011-02-08
From: John W. Linville @ 2011-02-08 20:41 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is the latest round of wireless bits intended for 2.6.39.
This is mostly driver updates (as usual), including a flurry of
wl1251 patches from David Gnedt. ath5k, ath9k, and iwlwifi are
well represented, of course. Interestingly, this batch includes a
number of mac80211 patches -- most of them _not_ from Johannes Berg!
I doubt if that holds for long... :-) And, zd1211rw grows AP support.
Also, this includes a wireless-2.6 pull to resolve some merge conflicts.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 2360d2e8f01043632d6b651672bec66c49892f94:
enic: Update MAINTAINERS (2011-02-07 11:49:04 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Arik Nemtsov (3):
mac80211: do not calc frame duration when using HW rate-control
mac80211: add HW flag for disabling auto link-PS in AP mode
mac80211: pass up beacons from external BSS when operating as AP
Ben Greear (7):
mac80211: Be more careful when changing channels.
mac80211: Show configured channel-type in netdev debugfs.
mac80211: Warn users if HT fails because of freq mismatch.
ath9k: Show channel type and frequency in debugfs.
mac80211: Recalculate channel-type on iface removal.
mac80211: Optimize scans on current operating channel.
mac80211: Make some mlme timers module paramaters.
Christian Lamparter (1):
mac80211: fix race between next beacon dtim and ieee80211_get_buffered_bc
Dan Carpenter (1):
mac80211: remove unneeded check
David Gnedt (6):
wl1251: fix queue stopping/waking for TX path
wl1251: fix 4-byte TX buffer alignment
wl1251: enable beacon early termination while in power-saving mode
wl1251: implement connection quality monitoring
wl1251: enable adhoc mode
wl1251: set rate index and preamble flag on received packets
Felix Fietkau (3):
mac80211: do not send duplicate data frames to the cooked monitor interface
ath9k: add additional checks for the baseband hang detection
mac80211: as a 4-addr station, do not receive packets for other stations
Johannes Berg (6):
iwlwifi: support RSN IBSS
iwlwifi: advertise max aggregate size
iwlwifi: use maximum aggregation size
iwlwifi: fix beacon notification parsing
mac80211: allow GO to scan like AP
iwlwifi: remove unnecessary locking
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
Jouni Malinen (3):
mac80211: Remove obsolete TKIP flexibility
mac80211: Add testing functionality for TKIP
ath: Fix clearing of secondary key cache entry for TKIP
Jussi Kivilinna (21):
zd1211rw: use urb anchors for tx and fix tx-queue disabling
zd1211rw: cancel process_intr work on zd_chip_disable_int()
zd1211rw: add locking for mac->process_intr
zd1211rw: fix beacon interval setup
zd1211rw: move set_multicast_hash and set_rx_filter from workers to configure_filter
zd1211rw: move set_rts_cts_work to bss_info_changed
zd1211rw: support setting BSSID for AP mode
zd1211rw: fix ack_pending in filter_ack causing tx-packet ordering problem on monitor
zd1211rw: let zd_set_beacon_interval() set dtim_period and add AP-beacon flag
zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
zd1211rw: add beacon watchdog and setting HW beacon more failsafe
zd1211rw: batch beacon config commands together
zd1211rw: use stack and preallocated memory for small cmd-buffers
zd1211rw: change interrupt URB buffer to DMA buffer
zd1211rw: lower hw command timeouts
zd1211rw: collect driver settings and add function to restore theim
zd1211rw: add TX watchdog and device resetting
zd1211rw: reset device when CR_BCN_FIFO_SEMAPHORE freezes in beacon setup
zd1211rw: reset rx urbs after idle period of 30 seconds
zd1211rw: enable NL80211_IFTYPE_AP
zd1211rw: add useful debug output
Justin P. Mattock (1):
drivers:net:ipw2100.c change a typo comamnd to command
Juuso Oikarinen (1):
cfg80211: Fix power save state after interface type change
Mohammed Shafi Shajakhan (3):
ath9k: Fix memory leak due to failed PAPRD frames
mac80211: Update comments on radiotap MCS index
ath9k: Update comments for not parsing DTIM period
Nick Kossifidis (1):
ath5k: Fix fast channel switching
Rajkumar Manoharan (7):
ath9k_htc: cancel ani work in ath9k_htc_stop
ath9k: use common get current channel function
ath9k: move update tx power to common
ath9k_htc: make use common of function to update txpower
ath9k: do not access hw registers in FULL SLEEP
ath9k: reserve a beacon slot on beaconing vif addition
mac80211: do not restart ps timer during scan or offchannel
Vasily Khoruzhick (2):
libertas_spi: Use workqueue in hw_host_to_card
libertas: Prepare stuff for if_spi.c pm support
Wey-Yi Guy (8):
iwlwifi: check ucode loading error and restart
iwlagn: adjust rate table
iwlagn: add IQ inversion support for 2000 series devices
iwlwifi: always support idle mode for agn devices
iwlagn: use 2030 macro for 2030 devices
iwlagn: remove unsupported BT SCO command
iiwlagn: remove unused parameter
iwlwifi: fix compiling error with different configuration
drivers/net/wireless/ath/ath5k/phy.c | 142 +++++---
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +
drivers/net/wireless/ath/ath9k/beacon.c | 5 +-
drivers/net/wireless/ath/ath9k/common.c | 11 +
drivers/net/wireless/ath/ath9k/common.h | 2 +
drivers/net/wireless/ath/ath9k/debug.c | 23 ++-
drivers/net/wireless/ath/ath9k/htc.h | 1 -
drivers/net/wireless/ath/ath9k/htc_drv_gpio.c | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 +-
drivers/net/wireless/ath/ath9k/main.c | 96 +++---
drivers/net/wireless/ath/key.c | 5 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 1 -
drivers/net/wireless/iwlwifi/iwl-2000.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 32 ++-
drivers/net/wireless/iwlwifi/iwl-6000.c | 3 -
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 28 --
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 29 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 8 -
drivers/net/wireless/iwlwifi/iwl-agn.c | 87 ++++--
drivers/net/wireless/iwlwifi/iwl-commands.h | 8 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 3 +-
drivers/net/wireless/iwlwifi/iwl-csr.h | 2 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 3 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 14 +-
drivers/net/wireless/libertas/cmd.c | 10 +-
drivers/net/wireless/libertas/dev.h | 2 +
drivers/net/wireless/libertas/if_spi.c | 368 +++++++++++++-------
drivers/net/wireless/libertas/main.c | 77 +++--
drivers/net/wireless/wl1251/acx.c | 53 +++
drivers/net/wireless/wl1251/acx.h | 72 ++++
drivers/net/wireless/wl1251/event.c | 18 +
drivers/net/wireless/wl1251/main.c | 18 +-
drivers/net/wireless/wl1251/ps.c | 11 +
drivers/net/wireless/wl1251/rx.c | 46 +++-
drivers/net/wireless/wl1251/tx.c | 74 ++---
drivers/net/wireless/wl1251/wl1251.h | 7 +
drivers/net/wireless/zd1211rw/zd_chip.c | 134 +++++---
drivers/net/wireless/zd1211rw/zd_chip.h | 5 +-
drivers/net/wireless/zd1211rw/zd_mac.c | 448 +++++++++++++++++++------
drivers/net/wireless/zd1211rw/zd_mac.h | 24 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 444 +++++++++++++++++++------
drivers/net/wireless/zd1211rw/zd_usb.h | 30 ++-
include/net/mac80211.h | 58 ++++-
net/mac80211/cfg.c | 26 ++-
net/mac80211/debugfs_netdev.c | 108 ++++++-
net/mac80211/ieee80211_i.h | 14 +-
net/mac80211/iface.c | 9 +-
net/mac80211/main.c | 53 +++-
net/mac80211/mlme.c | 60 +++-
net/mac80211/offchannel.c | 68 ++--
net/mac80211/rx.c | 59 +++--
net/mac80211/scan.c | 88 ++++--
net/mac80211/sta_info.c | 3 +-
net/mac80211/status.c | 4 +
net/mac80211/tx.c | 12 +-
net/mac80211/work.c | 66 +++-
net/mac80211/wpa.c | 39 +--
net/wireless/core.c | 20 +-
61 files changed, 2215 insertions(+), 872 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-02-08.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [Bugme-new] [Bug 28532] New: Link state change detection problem on Moschip MCS7832 [mcs7830]
From: Andreas Mohr @ 2011-02-08 20:52 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
myxal.mxl-Re5JQEeQqe8AvxtiuMwx3w, Andreas Mohr
In-Reply-To: <20110207151401.d1db088a.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Hi,
> > I have a network adapter which uses the aforementioned driver and while
> > checking for the link state via ethtool reports the correct state, many
> > networking userspace utilities seem to have no clue about it (NM 0.8.1 starts
> > dhclient BEFORE any cable is plugged) - and more importantly, don't notice when
> > the cable is (dis)connected. Since there's not even a kernel message when
> > (dis)connecting the cable, I suspect the driver does not implement Link state
> > change detection at all. Is this accurate?
Ah, perhaps that is why as long as network-mangler is running, my
.resume_reset() handler improvements (managing to keep an active interface
even directly after resume) actually do _not_ work (since it seems it simply
down:s the iface and that's it).
I know that there is link info functionality in other drivers yet not
as much in mcs7830.
Note that the mcs7830 driver still has a rather stubby appearance
(many more "advanced" features are either weak or not available at all).
I've got a patch series sitting here to improve several parts
(and waiting to cook a bit more), but I hadn't even identified the link issue.
It appears that this would need fixing, presto.
> > LSCD works in Windows, where it's apparently implemented through periodic
> > polling (judging by virtualbox's blinking USB icon).
> > How is this situation normally handled? Is it kernel's job to do the polling?
> > Or are userspace utilities expected to do this?
I'm afraid a painful solution would be to activate the .status callback
for periodic USB status descriptor polling. I've got a
half-implementation of that, however it's very painful in terms of
obscene amounts of CPU wakeups.
There _has_ to be a better solution...
Thank you for your (the OP's) report (and for my extra notification!),
this seems very helpful!
(I am determined to post related useful patches soon,
especially since this card is in active use here)
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* RE: [net-next-2.6 03/16] e1000e: do not wakeup Tx queue until ready
From: Allan, Bruce W @ 2011-02-08 20:52 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, bphilips@novell.com
In-Reply-To: <20110208.122115.183054158.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Tuesday, February 08, 2011 12:21 PM
>To: Kirsher, Jeffrey T
>Cc: Allan, Bruce W; netdev@vger.kernel.org; gospo@redhat.com;
>bphilips@novell.com
>Subject: Re: [net-next-2.6 03/16] e1000e: do not wakeup Tx queue until ready
>
>You should not control the TX queue based upon link status information.
>That's the job of netif_carrier_{on,off}().
>
>The TX queue state should be set based solely upon that state of the
>TX ring, whether it is full or not.
>
>When the netif carrier is off, the packet scheduler is blocked from
>sending packets to the driver.
>
>If that isn't happening, that's a bug which you need to track down.
>Maybe you're not doing netif_carrier_off() early enough.
That's what I understood, but the driver was still getting packets
scheduled, at least that's what appeared to happen. I'll dig deeper.
Thanks,
Bruce.
^ permalink raw reply
* Re: [PATCH] GRO: fix merging a paged skb after non-paged skbs
From: Herbert Xu @ 2011-02-08 20:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Michal Schmidt, David Miller, netdev, linux-net-drivers
In-Reply-To: <1297177484.3325.1.camel@bwh-desktop>
On Tue, Feb 08, 2011 at 03:04:44PM +0000, Ben Hutchings wrote:
>
> That would work, though it looks like Michal has managed to make it
> tolerate switches. (I haven't yet tested the result myself.)
Well the question is do we really want to still keep merging
in case of a switch? It could potentially get messy if it switches
back over and over again.
However, I suppose other merging criteria will stop the merging
in such cases so it's probably not a big deal.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: Andrew Morton @ 2011-02-08 21:34 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, hadmut
In-Reply-To: <bug-28282-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 5 Feb 2011 18:06:31 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=28282
>
> Summary: forwarding turns autoconfiguration off
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.35
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV6
> AssignedTo: yoshfuji@linux-ipv6.org
> ReportedBy: hadmut@danisch.de
> Regression: No
>
>
> Hi,
>
> Linux ethernet interfaces do not use autoconfiguration and do ignore router
> advertisings if the packet forwarding is turned on in the configuration (i.e.
> /proc/sys/net/ipv6/conf/eth0/forwarding set to 1)
>
>
> This might be wrong.
>
> IPv6 network devices can have multiple IPv6 addresses and server several
> purposes at the same time. A machine can have a statically assigned local IPv6
> address and act as a router (e.g. to a virtual machine or a VPN tunnel) and
> thus needs to turn forwarding on, while at the same time it needs to listen to
> router advertisements and autoconfigure, e.g. because a network is connected to
> the internet through a DSL router with dynamically assigned network adresses,
> either through direct IPv6 assignment or a 6to4 tunnel.
>
> So there are cases where you need to have autoconfiguration of an IP address
> and forwarding on the same interface at the same time. Therefore, it might be
> technically wrong to have this mutually exclusive.
>
^ permalink raw reply
* Re: Trouble Shooting ipsec
From: Neil Horman @ 2011-02-08 21:37 UTC (permalink / raw)
To: David Miller; +Cc: sclark46, netdev
In-Reply-To: <20110208.113708.226773767.davem@davemloft.net>
On Tue, Feb 08, 2011 at 11:37:08AM -0800, David Miller wrote:
> From: Stephen Clark <sclark46@earthlink.net>
> Date: Tue, 08 Feb 2011 14:33:17 -0500
>
> > I'll continue investigating. It just so frustrating when the ipsec
> > packets just get dropped and you have no idea why. I wish there were
> > some hooks in the kernel so you could at least get some debug
> > information about what is happening.
>
> There is a tracepoint (which you can monitor using perf) which tracks
> all packet drops.
>
+1, you can also use dropwatch to monitor that tracepoint if the drop volume is
high.
Neil
^ permalink raw reply
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: David Miller @ 2011-02-08 21:44 UTC (permalink / raw)
To: akpm; +Cc: netdev, bugzilla-daemon, bugme-daemon, hadmut
In-Reply-To: <20110208133408.7d447e6a.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 8 Feb 2011 13:34:08 -0800
>> Linux ethernet interfaces do not use autoconfiguration and do ignore router
>> advertisings if the packet forwarding is turned on in the configuration (i.e.
>> /proc/sys/net/ipv6/conf/eth0/forwarding set to 1)
>>
>>
>> This might be wrong.
>>
>> IPv6 network devices can have multiple IPv6 addresses and server several
>> purposes at the same time. A machine can have a statically assigned local IPv6
>> address and act as a router (e.g. to a virtual machine or a VPN tunnel) and
>> thus needs to turn forwarding on, while at the same time it needs to listen to
>> router advertisements and autoconfigure, e.g. because a network is connected to
>> the internet through a DSL router with dynamically assigned network adresses,
>> either through direct IPv6 assignment or a 6to4 tunnel.
>>
>> So there are cases where you need to have autoconfiguration of an IP address
>> and forwarding on the same interface at the same time. Therefore, it might be
>> technically wrong to have this mutually exclusive.
This is a case where we're probably just following what the RFC documents
state we should do, which means unless you can provide clear reference to
a specification that states we should behave otherwise this isn't changing.
^ permalink raw reply
* Re: [net-2.6][2.6.38-rc2] panic during stress testing
From: David Miller @ 2011-02-08 21:51 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: netdev, jeffrey.e.pieper
In-Reply-To: <1297189925.4087.8.camel@jbrandeb-mobl2>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Tue, 08 Feb 2011 10:32:05 -0800
> We are currently testing patches and ran into this panic, doesn't
> immediately seem related to the driver.
>
> During TCP/UDP ipv4/6 stress testing on 82574L, 2.6.38-rc2 x86_64
> (net-2.6 with e1000e patches under test) gets numerous OOM killer
> messages, followed by a bug/Oops and panic. could not reproduce the
> bug/panic on 2.6.37, but the OOM killer messages are still seen.
>
> Could well be related somehow to testing with DEBUG_PAGEALLOC enabled.
>
> panic dump and .config follows:
>
> BUG: unable to handle kernel paging request at ffffffff81089738
> IP: [<ffffffff812e2139>] dst_destroy+0x4b/0xf3
> PGD 1695067 PUD 1699063 PMD 10001e1
> Oops: 0003 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
> CPU 1
> Modules linked in: nfsd exportfs lockd sunrpc dca e1000e [last unloaded: igb]
So some piece of freed memory is being referenced in dst_destroy(), can you
match dst_destroy+0x4b to a line in that function for your build?
You should always do this when submitting a trace like this.
Thanks.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-02-08
From: David Miller @ 2011-02-08 21:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110208204139.GC6244@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 8 Feb 2011 15:41:39 -0500
> Here is the latest round of wireless bits intended for 2.6.39.
> This is mostly driver updates (as usual), including a flurry of
> wl1251 patches from David Gnedt. ath5k, ath9k, and iwlwifi are
> well represented, of course. Interestingly, this batch includes a
> number of mac80211 patches -- most of them _not_ from Johannes Berg!
> I doubt if that holds for long... :-) And, zd1211rw grows AP support.
> Also, this includes a wireless-2.6 pull to resolve some merge conflicts.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* Re: [PATCH 0/2] CDC NCM errata updates
From: David Miller @ 2011-02-08 21:53 UTC (permalink / raw)
To: alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-l3A5Bk7waGM, yauheni.kaliuta-xNZwKgViW5gAvxtiuMwx3w
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520153BB643596B-8ZTw5gFVCTjVH5byLeRTJxkTb7+GphCuwzqs5ZKRSiY@public.gmane.org>
From: Alexey ORISHKO <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Date: Tue, 8 Feb 2011 18:44:13 +0100
> Both patches can be applied to net-2.6 and net-next.
> [PATCH 1/2] CDC NCM errata updates for cdc.h
> [PATCH 2/2] USB CDC NCM errata updates for cdc_ncm host driver
>
> I don't know if the merge window is closed or not, but it would be
> *really* good to get this patches merged to 2.6.38-rc branch due to
> bug fixes included.
I'll apply them to net-2.6, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH] ipsec: allow to align IPv4 AH on 32 bits
From: David Miller @ 2011-02-08 22:00 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: herbert, netdev, christophe.gouault
In-Reply-To: <4D49864E.8020002@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 02 Feb 2011 17:29:02 +0100
> On 28/01/2011 20:46, David Miller wrote:
>> From: Nicolas Dichtel<nicolas.dichtel@6wind.com>
>> Date: Fri, 28 Jan 2011 09:51:40 +0100
>>
>>> On 28/01/2011 05:51, Herbert Xu wrote:
>>>> So perhaps an SA configuration flag is needed?
>>> I agree. If David is ok, I will update the patch.
>>
>> Sounds good to me.
>
> Here is the new patch.
I've applied this to net-next-2.6, thanks.
^ permalink raw reply
* Re: Oops in tcp_output.c, kernel 2.6.38-rc3
From: Brandeburg, Jesse @ 2011-02-08 22:07 UTC (permalink / raw)
To: David Miller
Cc: cebbert@redhat.com, netdev@vger.kernel.org,
ilpo.jarvinen@helsinki.fi, bruce.w.allan
In-Reply-To: <20110207.130234.112590109.davem@davemloft.net>
On Mon, 7 Feb 2011, David Miller wrote:
> From: Chuck Ebbert <cebbert@redhat.com>
> Date: Fri, 4 Feb 2011 15:32:54 -0500
>
> > Analysis is below. (From https://bugzilla.redhat.com/show_bug.cgi?id=674622)
> >
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> > IP: [<ffffffff81407b16>] tcp_write_xmit+0x694/0x7af
>
> I bet this is some kind of bug in the driver or similar, what device
> and also what kind of network config (netfilter, packet scheduler,
> interface, routes, etc.) is this?
glaring at the bug dump shows e1000e as the only network driver that i can
see, hardware seems to be the ICH10 chipset. Copied bruce in case he's
seen or heard anything.
appears to be this system:
http://www.asus.com/Product.aspx?P_ID=qH6ZSEJ8EPY6HoNU&content=specifications
^ permalink raw reply
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: Hadmut Danisch @ 2011-02-08 22:12 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20110208.134421.39185637.davem@davemloft.net>
On 08.02.2011 22:44, David Miller wrote:
>
> This is a case where we're probably just following what the RFC documents
> state we should do, which means unless you can provide clear reference to
> a specification that states we should behave otherwise this isn't changing.
Could you cite where exactly this is stated in the RFC documents? (Would
save me the time to dig through all the RFCs to find that particular
statement and help avoid misunderstanding.)
It appears to me to be a contradiction in terms. IPv6 interfaces must be
able to have several IP addresses, and IPv6 does not have a default
route (or 0::0/0). IPv6 interfaces are designed to participate in
multiple independend logical networks (and several address ranges have
been reserved for future extensions and uses). It therefore does not
make sense if autoconfiguration for one network and routing for another
are mutually exclusive. I'd like to check this (and maybe file a bug in
the RFC).
regards
Hadmut
^ permalink raw reply
* [PATCH] net: provide capability and group sets via SCM
From: Casey Schaufler @ 2011-02-08 22:28 UTC (permalink / raw)
To: LKLM, netdev
Cc: Casey Schaufler, Sakkinen Jarkko.2 (EXT-Tieto/Tampere),
Janne Karhunen, Reshetova Elena (Nokia-D/Helsinki)
In-Reply-To: <4D3466BD.10500@schaufler-ca.com>
Subject: [PATCH] net: provide group lists and capability set via CMSG
Provide the namespace converted group list of the peer
process using the SCM mechanism. Provide the capability
set of the peer process. The capability set is not
namespace converted on the assumption that there is no
such conversion available or required.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
include/asm-generic/socket.h | 4 ++
include/linux/net.h | 2 +
include/linux/socket.h | 18 +++++++++
include/net/scm.h | 33 +++++++++++++++++
net/core/sock.c | 82 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/socket.h b/include/asm-generic/socket.h
index 9a6115e..fc2d609 100644
--- a/include/asm-generic/socket.h
+++ b/include/asm-generic/socket.h
@@ -64,4 +64,8 @@
#define SO_DOMAIN 39
#define SO_RXQ_OVFL 40
+
+#define SO_PASSGROUPS 41
+#define SO_PASSCAPS 42
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/include/linux/net.h b/include/linux/net.h
index 16faa13..929e241 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -71,6 +71,8 @@ struct net;
#define SOCK_NOSPACE 2
#define SOCK_PASSCRED 3
#define SOCK_PASSSEC 4
+#define SOCK_PASSGROUPS 5
+#define SOCK_PASSCAPS 6
#ifndef ARCH_HAS_SOCKET_TYPES
/**
diff --git a/include/linux/socket.h b/include/linux/socket.h
index edbb1d0..63f64f0 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -23,6 +23,7 @@ struct __kernel_sockaddr_storage {
#include <linux/uio.h> /* iovec support */
#include <linux/types.h> /* pid_t */
#include <linux/compiler.h> /* __user */
+#include <linux/capability.h> /* _KERNEL_CAPABILITY_U32S */
struct pid;
struct cred;
@@ -145,6 +146,8 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr *__msg, struct cmsghdr
#define SCM_RIGHTS 0x01 /* rw: access rights (array of int) */
#define SCM_CREDENTIALS 0x02 /* rw: struct ucred */
#define SCM_SECURITY 0x03 /* rw: security label */
+#define SCM_GROUPS 0x04 /* rw: group list */
+#define SCM_CAPS 0x05 /* rw: capability set */
struct ucred {
__u32 pid;
@@ -152,6 +155,16 @@ struct ucred {
__u32 gid;
};
+struct scm_groups {
+ __u32 count;
+ __u32 gids[0];
+};
+
+struct scm_capabilities {
+ struct __user_cap_data_struct caps[_KERNEL_CAPABILITY_U32S];
+};
+
+
/* Supported address families. */
#define AF_UNSPEC 0
#define AF_UNIX 1 /* Unix domain sockets */
@@ -313,6 +326,11 @@ struct ucred {
#define IPX_TYPE 1
extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct ucred *ucred);
+extern void cred_to_scm_groups(const struct cred *cred,
+ struct scm_groups **sgp, int *size);
+extern void cred_to_scm_capabilities(const struct cred *cred,
+ struct scm_capabilities **scp,
+ int *size);
extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
diff --git a/include/net/scm.h b/include/net/scm.h
index 745460f..b263867 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -102,6 +102,36 @@ static inline void scm_passec(struct socket *sock, struct msghdr *msg, struct sc
{ }
#endif /* CONFIG_SECURITY_NETWORK */
+static inline void scm_passgroups(struct socket *sock, struct msghdr *msg,
+ struct scm_cookie *scm)
+{
+ struct scm_groups *data;
+ int size = 0;
+
+ if (test_bit(SOCK_PASSGROUPS, &sock->flags)) {
+ cred_to_scm_groups(scm->cred, &data, &size);
+ if (size) {
+ put_cmsg(msg, SOL_SOCKET, SCM_GROUPS, size, data);
+ kfree(data);
+ }
+ }
+}
+
+static inline void scm_passcaps(struct socket *sock, struct msghdr *msg,
+ struct scm_cookie *scm)
+{
+ struct scm_capabilities *data;
+ int size = 0;
+
+ if (test_bit(SOCK_PASSCAPS, &sock->flags)) {
+ cred_to_scm_capabilities(scm->cred, &data, &size);
+ if (size) {
+ put_cmsg(msg, SOL_SOCKET, SCM_CAPS, size, data);
+ kfree(data);
+ }
+ }
+}
+
static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
struct scm_cookie *scm, int flags)
{
@@ -115,6 +145,9 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
if (test_bit(SOCK_PASSCRED, &sock->flags))
put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(scm->creds), &scm->creds);
+ scm_passgroups(sock, msg, scm);
+ scm_passcaps(sock, msg, scm);
+
scm_destroy_cred(scm);
scm_passec(sock, msg, scm);
diff --git a/net/core/sock.c b/net/core/sock.c
index 7dfed79..80eb5d7 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -648,6 +648,20 @@ set_rcvbuf:
clear_bit(SOCK_PASSCRED, &sock->flags);
break;
+ case SO_PASSGROUPS:
+ if (valbool)
+ set_bit(SOCK_PASSGROUPS, &sock->flags);
+ else
+ clear_bit(SOCK_PASSGROUPS, &sock->flags);
+ break;
+
+ case SO_PASSCAPS:
+ if (valbool)
+ set_bit(SOCK_PASSCAPS, &sock->flags);
+ else
+ clear_bit(SOCK_PASSCAPS, &sock->flags);
+ break;
+
case SO_TIMESTAMP:
case SO_TIMESTAMPNS:
if (valbool) {
@@ -764,6 +778,66 @@ void cred_to_ucred(struct pid *pid, const struct cred *cred,
}
EXPORT_SYMBOL_GPL(cred_to_ucred);
+void cred_to_scm_groups(const struct cred *cred,
+ struct scm_groups **scm_groups, int *size)
+{
+ struct user_namespace *current_ns;
+ struct scm_groups *sgp;
+ struct group_info *gip;
+ int bytes;
+ int i;
+
+ if (!cred || !scm_groups)
+ return;
+
+ gip = cred->group_info;
+ if (gip == NULL)
+ return;
+
+ bytes = sizeof(struct scm_groups) + gip->ngroups * sizeof(__u32);
+ sgp = kmalloc(bytes, GFP_KERNEL);
+ if (sgp == NULL) {
+ *scm_groups = NULL;
+ *size = 0;
+ return;
+ }
+
+ current_ns = current_user_ns();
+
+ for (i = 0 ; i < gip->ngroups; i++)
+ sgp->gids[i] = user_ns_map_gid(current_ns, cred,
+ GROUP_AT(gip, i));
+ sgp->count = gip->ngroups;
+ *scm_groups = sgp;
+ *size = bytes;
+}
+EXPORT_SYMBOL_GPL(cred_to_scm_groups);
+
+void cred_to_scm_capabilities(const struct cred *cred,
+ struct scm_capabilities **scm_caps, int *size)
+{
+ struct scm_capabilities *scp;
+ int i;
+
+ if (!cred || !scm_caps)
+ return;
+
+ scp = kmalloc(sizeof(struct scm_capabilities), GFP_KERNEL);
+ if (!scp) {
+ *scm_caps = NULL;
+ *size = 0;
+ return;
+ }
+ for (i = 0; i < _LINUX_CAPABILITY_U32S_3; i++) {
+ scp->caps[i].permitted = cred->cap_permitted.cap[i];
+ scp->caps[i].effective = cred->cap_effective.cap[i];
+ scp->caps[i].inheritable = cred->cap_inheritable.cap[i];
+ }
+ *scm_caps = scp;
+ *size = sizeof(struct scm_capabilities);
+}
+EXPORT_SYMBOL_GPL(cred_to_scm_capabilities);
+
int sock_getsockopt(struct socket *sock, int level, int optname,
char __user *optval, int __user *optlen)
{
@@ -915,6 +989,14 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
v.val = test_bit(SOCK_PASSCRED, &sock->flags) ? 1 : 0;
break;
+ case SO_PASSGROUPS:
+ v.val = test_bit(SOCK_PASSGROUPS, &sock->flags) ? 1 : 0;
+ break;
+
+ case SO_PASSCAPS:
+ v.val = test_bit(SOCK_PASSCAPS, &sock->flags) ? 1 : 0;
+ break;
+
case SO_PEERCRED:
{
struct ucred peercred;
^ permalink raw reply related
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: David Miller @ 2011-02-08 22:30 UTC (permalink / raw)
To: hadmut; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4D51BFCE.2070405@msgid.danisch.de>
From: Hadmut Danisch <hadmut@danisch.de>
Date: Tue, 08 Feb 2011 23:12:30 +0100
> On 08.02.2011 22:44, David Miller wrote:
>>
>> This is a case where we're probably just following what the RFC documents
>> state we should do, which means unless you can provide clear reference to
>> a specification that states we should behave otherwise this isn't changing.
>
> Could you cite where exactly this is stated in the RFC documents?
I'm working on other bugs at the moment, so I am personally unable to
help you with this at this time. Perhaps someone else can.
^ permalink raw reply
* [PATCH] net/caif: Fix dangling list pointer in freed object on error.
From: David Miller @ 2011-02-08 22:33 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev
rtnl_link_ops->setup(), and the "setup" callback passed to alloc_netdev*(),
cannot make state changes which need to be undone on failure. There is
no cleanup mechanism available at this point.
So we have to add the caif private instance to the global list once we
are sure that register_netdev() has succedded in ->newlink().
Otherwise, if register_netdev() fails, the caller will invoke free_netdev()
and we will have a reference to freed up memory on the chnl_net_list.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Committed to net-2.6, I need this setup() invariant to be properly
followed tree-wide in order to fix another bug.
net/caif/chnl_net.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index fa9dab3..6008d6d 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -394,9 +394,7 @@ static void ipcaif_net_setup(struct net_device *dev)
priv->conn_req.sockaddr.u.dgm.connection_id = -1;
priv->flowenabled = false;
- ASSERT_RTNL();
init_waitqueue_head(&priv->netmgmt_wq);
- list_add(&priv->list_field, &chnl_net_list);
}
@@ -453,6 +451,8 @@ static int ipcaif_newlink(struct net *src_net, struct net_device *dev,
ret = register_netdevice(dev);
if (ret)
pr_warn("device rtml registration failed\n");
+ else
+ list_add(&caifdev->list_field, &chnl_net_list);
return ret;
}
--
1.7.4
^ permalink raw reply related
* RE: Oops in tcp_output.c, kernel 2.6.38-rc3
From: Allan, Bruce W @ 2011-02-08 22:46 UTC (permalink / raw)
To: Brandeburg, Jesse, David Miller
Cc: cebbert@redhat.com, netdev@vger.kernel.org,
ilpo.jarvinen@helsinki.fi
In-Reply-To: <alpine.WNT.2.00.1102081401480.5424@JBRANDEB-DESK2.amr.corp.intel.com>
>-----Original Message-----
>From: Brandeburg, Jesse
>Sent: Tuesday, February 08, 2011 2:07 PM
>To: David Miller
>Cc: cebbert@redhat.com; netdev@vger.kernel.org; ilpo.jarvinen@helsinki.fi;
>Allan, Bruce W
>Subject: Re: Oops in tcp_output.c, kernel 2.6.38-rc3
>
>glaring at the bug dump shows e1000e as the only network driver that i can
>see, hardware seems to be the ICH10 chipset. Copied bruce in case he's
>seen or heard anything.
>
>appears to be this system:
>http://www.asus.com/Product.aspx?P_ID=qH6ZSEJ8EPY6HoNU&content=specifications
Sorry, no, this is new to me. BTW, it's the ICH10R chipset which is
different from other ICH10* chipsets, just FYI.
^ permalink raw reply
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: Francois Romieu @ 2011-02-08 22:44 UTC (permalink / raw)
To: David Miller; +Cc: hadmut, akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20110208.143046.246534138.davem@davemloft.net>
David Miller <davem@davemloft.net> :
> From: Hadmut Danisch <hadmut@danisch.de>
> Date: Tue, 08 Feb 2011 23:12:30 +0100
>
> > On 08.02.2011 22:44, David Miller wrote:
> >>
> >> This is a case where we're probably just following what the RFC documents
> >> state we should do, which means unless you can provide clear reference to
> >> a specification that states we should behave otherwise this isn't changing.
> >
> > Could you cite where exactly this is stated in the RFC documents?
>
> I'm working on other bugs at the moment, so I am personally unable to
> help you with this at this time. Perhaps someone else can.
This one MAY^W may be relevant (see http://www.ietf.org/rfc/rfc4862.txt) :
Thomson, et al. Standards Track [Page 3]
RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
[...]
The autoconfiguration process specified in this document applies only
to hosts and not routers. Since host autoconfiguration uses
information advertised by routers, routers will need to be configured
by some other means. However, it is expected that routers will
generate link-local addresses using the mechanism described in this
document. In addition, routers are expected to successfully pass the
Duplicate Address Detection procedure described in this document on
all addresses prior to assigning them to an interface.
--
Ueimor
^ permalink raw reply
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: Hadmut Danisch @ 2011-02-08 22:59 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Miller, akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20110208224411.GA9674@electric-eye.fr.zoreil.com>
On 08.02.2011 23:44, Francois Romieu wrote:
>
> RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
> [...]
> The autoconfiguration process specified in this document applies only
> to hosts and not routers. Since host autoconfiguration uses
> information advertised by routers, routers will need to be configured
> by some other means. However, it is expected that routers will
> generate link-local addresses using the mechanism described in this
> document. In addition, routers are expected to successfully pass the
> Duplicate Address Detection procedure described in this document on
> all addresses prior to assigning them to an interface.
Thanks for the citation.
Since Linux machines can - in contrast to Windows desktops and cisco
routers - can be a host and a router at the same time, even on the same
interface (i.e. use a autoconf IPv6 address as a host and an fe80::
address as a router address).
So I'd consider this in a different way. From my point of view the
decision between host and router must be done per assigned IPv6 address
(or address range) and not per IPv6 interface.
(Maybe it would be a more correct implementation to assign a special IP
address pattern like xxxx::.../64 to tell the interface to accept
autoconfiguration for a particular network range, probably for 2::/3 in
most cases.)
regards
Hadmut
^ permalink raw reply
* [PATCH] net: Remove bogus barrier() in dst_allfrag().
From: David Miller @ 2011-02-08 23:34 UTC (permalink / raw)
To: netdev
I simply missed this one when modifying the other dst
metric interfaces earlier.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Committed to net-next-2.6
include/net/dst.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index e550195..e01855d 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -220,8 +220,6 @@ static inline u32
dst_allfrag(const struct dst_entry *dst)
{
int ret = dst_feature(dst, RTAX_FEATURE_ALLFRAG);
- /* Yes, _exactly_. This is paranoia. */
- barrier();
return ret;
}
--
1.7.4
^ permalink raw reply related
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: Francois Romieu @ 2011-02-08 23:49 UTC (permalink / raw)
To: Hadmut Danisch; +Cc: David Miller, akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4D51CAE8.6070706@msgid.danisch.de>
Hadmut Danisch <hadmut@danisch.de> :
[...]
> Since Linux machines can - in contrast to Windows desktops and cisco
> routers - can be a host and a router at the same time, even on the same
> interface (i.e. use a autoconf IPv6 address as a host and an fe80::
> address as a router address).
>
> So I'd consider this in a different way. From my point of view the
> decision between host and router must be done per assigned IPv6 address
> (or address range) and not per IPv6 interface.
o^O
Afaik networking does not operate this way in the kernel. Really.
May I suggest you to have some sleep and see how your (dhcpv6 enabled ?)
DSL router can be convinced to collaborate with the existing tools under
Linux _without_ modifications ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH v4 0/5] net: Unified offload configuration
From: Michał Mirosław @ 2011-02-08 23:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bhutchings
In-Reply-To: <20110208.114018.71120939.davem@davemloft.net>
On Tue, Feb 08, 2011 at 11:40:18AM -0800, David Miller wrote:
> BTW, none of your patch postings from today made it to the mailing
> lists because there were syntax errors in your email headers.
>
> Therefore, you'll need to resend them.
Hmm, that's weird. My mailer said:
mail.info: Feb 8 15:23:59 postfix/smtp[6076]: 7138813909: to=<netdev@vger.kernel.org>, relay=vger.kernel.org[209.132.180.67]:25, delay=3, delays=0.09/0.08/2.2/0.7, dsn=2.7.0, status=sent (250 2.7.0 nothing apparently wrong in the message. BF:<H 0>; S1754489Ab1BHOX7)
mail.info: Feb 8 15:23:59 postfix/smtp[6110]: BA99413A5F: to=<netdev@vger.kernel.org>, relay=vger.kernel.org[209.132.180.67]:25, delay=3, delays=0.2/0.45/1.5/0.84, dsn=2.7.1, status=sent (250 2.7.1 Looks like Linux source DIFF email.. BF:<H 0>; S1754575Ab1BHOX7)
[same for other patches in series]
And I got no bounces. What were the errors?
Best Regards,
Michał Mirosław
^ 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