Re: [2.6 patch] rename hostap.c to hostap_main.c
On Sun, Nov 06, 2005 at 01:53:43AM +0100, Adrian Bunk wrote:
> I wanted to remove the #include "hostap_ioctl.c" from hostap.c and build
> hostap_ioctl.c separately, but this doesn't work since hostap.c has the
> same name as the module.
Is this patch changing anything in hostap.c or is it just a rename of
the file? Patch file is not exactly ideal for this kind of changes and I
hope git has a better way of storing this kind of rename.
I would rather not rename the file, but if this is the only way of
getting the module built in pieces, I'm okay with the change (assuming
nothing else changed in hostap.c in this changeset).
> +++ linux-2.6.14-rc5-mm1-full/drivers/net/wireless/hostap/Makefile
> 2005-11-06 00:14:57.0 +0100
> @@ -1,5 +1,7 @@
> -obj-$(CONFIG_HOSTAP_CS) += hostap_cs.o
> -obj-$(CONFIG_HOSTAP_PLX) += hostap_plx.o
> -obj-$(CONFIG_HOSTAP_PCI) += hostap_pci.o
> +obj-$(CONFIG_HOSTAP) += hostap.o
> +
> +obj-$(CONFIG_HOSTAP_CS) += hostap_cs.o
> +obj-$(CONFIG_HOSTAP_PLX) += hostap_plx.o
> +obj-$(CONFIG_HOSTAP_PCI) += hostap_pci.o
Why were the hostap_{cs,plx,pci} lines changed? I prefer the original
version of those lines (i.e., no extra padding).
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix ifenslave to not fail on lack of IP information
On Fri, Nov 04, 2005 at 11:08:32PM -0800, Jason R. Martin wrote:
> On 11/4/05, Neil Horman <[EMAIL PROTECTED]> wrote:
> > On Fri, Nov 04, 2005 at 12:25:49PM -0800, Jay Vosburgh wrote:
> > >
> > > [dropped linux-kernel; added netdev]
> > >
> > > Neil Horman <[EMAIL PROTECTED]> wrote:
> > >
> > > >The current version of ifenslave fails to attach slave interfaces to a
> > > >bond if
> > > >the masters doesn't have appropriate IP information. While its common
> > > >for
> > > >bonded interface to have IP information its not required (bond as part
> > > >of a
> > > >bridge for instance).
> > >
> > > As far as I know, attaching slaves to a bonding device without
> > > an IP address works just fine; the bonding master device must merely be
> > > up. Under what circumstances are you seeing a problem?
> > >
> > Try to run ifenslave on a bonded interface with no ip address, it will fail.
>
> Are you sure it fails or do you just get an error message?
> Traditionally it has spit out a (non-fatal) error message about not
> being able to get the address info, but then go ahead and enslave
> anyway.
>
> At least that's been my experience.
>
> Jason
Hey, I just checked the code on this, and it appears that the ensalve opperation
aborts in the event that the masters ip address info isn't present. This means
that any of the subsequent operations that ensalve preforms, wont happen, which
can break the bond. This include propogation of the MTU size, setting of the
master MAC address, and most importantly, setting of the IFF_SLAVE flag on the
slave interfaces. So having no IP address on a bond interface with an abi
version less than two definately will not be able to enslave any physical
interfaces, which is what I'm currently seeing. I'm still looking into the use
of an updated bonding driver in my specific situation, but I think in light of
this info, the right thing to do is probably to make the enslave function not
fail if set_if_addr fails, as the patch attached does
Thanks and Regards
Neil
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
ifenslave.c |1 -
1 files changed, 1 deletion(-)
diff --git a/Documentation/networking/ifenslave.c
b/Documentation/networking/ifenslave.c
--- a/Documentation/networking/ifenslave.c
+++ b/Documentation/networking/ifenslave.c
@@ -698,7 +698,6 @@ static int enslave(char *master_ifname,
fprintf(stderr,
"Slave '%s': Error: set address failed\n",
slave_ifname);
- return res;
}
} else {
res = clear_if_addr(slave_ifname);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for pull from netdev-jwl
John W. Linville wrote: The following changes since commit 70d9d825e0a5a78ec1dacaaaf5c72ff5b0206fab: Linus Torvalds: Merge branch 'upstream-linus' of master.kernel.org:/.../jgarzik/netdev-2.6 are found in the git repository at: git://git.tuxdriver.com/git/netdev-jwl.git Adrian Bunk: drivers/net/ixgb/: make some code static drivers/net/e1000/: possible cleanups drivers/net/hamradio/dmascc.c: remove dmascc_setup() airo.c/airo_cs.c: correct prototypes Daniel Drake: prism54: Remove redundant assignment Michael Chan: bnx2: add 5708 support bnx2: update firmware for 5708 bnx2: update nvram code for 5708 bnx2: update firmware handshake for 5708 bnx2: refine bnx2_poll bnx2: update version and minor fixes Pulled, thanks much for the help! Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.14] fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
Make CONFIG_FEC_8XX depend on CONFIG_8xx. This keeps allmodconfig from breaking on non-8xx (PPC) platforms. Signed-off-by: John W. Linville <[EMAIL PROTECTED]> --- drivers/net/fec_8xx/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig index 4560026..a84c232 100644 --- a/drivers/net/fec_8xx/Kconfig +++ b/drivers/net/fec_8xx/Kconfig @@ -1,6 +1,6 @@ config FEC_8XX tristate "Motorola 8xx FEC driver" - depends on NET_ETHERNET + depends on NET_ETHERNET && 8xx select MII config FEC_8XX_GENERIC_PHY -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for pull from netdev-jwl
On Sat, Nov 05, 2005 at 04:24:21PM -0500, Jeff Garzik wrote: > John W. Linville wrote: > >I thought you might appreciate a little offload of some of your netdev > >merging chores. I don't think there is anything controversial here. > > Thanks, appreciated. > > I already had some of this stuff in netdev-2.6.git, so, how to proceed > from here? I rebased on your latest netdev-2.6. I dropped the ones you had already merged, and the "natsemi: Option to use MII port with no PHY" patch. I merged the others, plus the airo.h one from Adrian since it seemed reasonable as well. The pull request follows, w/ the patch ommitted because of its size (due to bnx2 firmware update). I can provide that under separate cover if desired. Thanks, John --- The following changes since commit 70d9d825e0a5a78ec1dacaaaf5c72ff5b0206fab: Linus Torvalds: Merge branch 'upstream-linus' of master.kernel.org:/.../jgarzik/netdev-2.6 are found in the git repository at: git://git.tuxdriver.com/git/netdev-jwl.git Adrian Bunk: drivers/net/ixgb/: make some code static drivers/net/e1000/: possible cleanups drivers/net/hamradio/dmascc.c: remove dmascc_setup() airo.c/airo_cs.c: correct prototypes Daniel Drake: prism54: Remove redundant assignment Michael Chan: bnx2: add 5708 support bnx2: update firmware for 5708 bnx2: update nvram code for 5708 bnx2: update firmware handshake for 5708 bnx2: refine bnx2_poll bnx2: update version and minor fixes drivers/net/bnx2.c| 468 +++ drivers/net/bnx2.h| 119 + drivers/net/bnx2_fw.h | 4055 ++--- drivers/net/e1000/e1000_ethtool.c |2 drivers/net/e1000/e1000_hw.c | 101 + drivers/net/e1000/e1000_hw.h | 42 drivers/net/e1000/e1000_main.c| 31 drivers/net/hamradio/dmascc.c | 10 drivers/net/ixgb/ixgb_ethtool.c |2 drivers/net/ixgb/ixgb_hw.c| 31 drivers/net/ixgb/ixgb_hw.h| 17 drivers/net/ixgb/ixgb_main.c |2 drivers/net/wireless/airo.c |2 drivers/net/wireless/airo.h |9 drivers/net/wireless/airo_cs.c|6 drivers/net/wireless/prism54/islpci_eth.c |1 include/linux/ethtool.h |3 include/linux/pci_ids.h |2 18 files changed, 3160 insertions(+), 1743 deletions(-) create mode 100644 drivers/net/wireless/airo.h -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] (G)RED fixes and improvements
On 11/5/05, Thomas Graf <[EMAIL PROTECTED]> wrote: > Arnaldo, > > Please pull from 'red' branch of rsync://84.73.165.173/scm/net-2.6.git > to receive the following updates: > > include/linux/pkt_sched.h | 50 +- > include/net/inet_ecn.h| 28 + > include/net/red.h | 325 + > net/sched/sch_gred.c | 835 > ++ > net/sched/sch_red.c | 416 +- > 5 files changed, 887 insertions(+), 767 deletions(-) Thanks, pulled and I already asked Linus to pull. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] TSO problems with congestion updates
From: John Heffner <[EMAIL PROTECTED]> Date: Fri, 28 Oct 2005 20:39:24 -0400 > On Oct 28, 2005, at 6:10 PM, Stephen Hemminger wrote: > > > The following update cwnd for every ACK, but it ends up making Linux > > more aggressive > > (but still in compliance with existing RFC's). > > Since Linux now implements cwnd validation (rfc2861) I think this > especially makes sense. But this check Stephen is removing _is_ part of our congestion window validation implementation. Although not mentioned explicitly in that RFC, this check we are discussing is sort of implied by that text and I'm very sure this is why Alexey added it. It is the same test performed by tcp_cwnd_validate() except that it's done at ACK processing CWND update time. I kept revisiting this very same check while I was doing the Super TSO work but I resisted every temptation to remove it during that time. In fact I remember mentioning this issue to jheffner back then :-) Now, given that, I'm pretty much in support of removing the ACK time check as Stephen is proposing. But do realize that the rest of our cwnd validation implementation has some wrong cases during TSO for the same reason. Look at that check in tcp_cwnd_validate() in net/ipv4/tcp_output.c, it is the same check we're discussing and will not pass for some cases with TSO. Fortunately, during loss, it will work properly since TSO deferral is disabled during this time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] drivers/net/s2io.c: make functions static
This patch makes needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/s2io.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
--- linux-2.6.14-rc5-mm1-full/drivers/net/s2io.c.old2005-11-06
00:19:48.0 +0100
+++ linux-2.6.14-rc5-mm1-full/drivers/net/s2io.c2005-11-06
00:25:39.0 +0100
@@ -1515,7 +1515,7 @@
#define LINK_UP_DOWN_INTERRUPT 1
#define MAC_RMAC_ERR_TIMER 2
-int s2io_link_fault_indication(nic_t *nic)
+static int s2io_link_fault_indication(nic_t *nic)
{
if (nic->intr_type != INTA)
return MAC_RMAC_ERR_TIMER;
@@ -1847,7 +1847,7 @@
*
*/
-void fix_mac_address(nic_t * sp)
+static void fix_mac_address(nic_t * sp)
{
XENA_dev_config_t __iomem *bar0 = sp->bar0;
u64 val64;
@@ -2111,7 +2111,7 @@
* SUCCESS on success or an appropriate -ve value on failure.
*/
-int fill_rx_buffers(struct s2io_nic *nic, int ring_no)
+static int fill_rx_buffers(struct s2io_nic *nic, int ring_no)
{
struct net_device *dev = nic->dev;
struct sk_buff *skb;
@@ -2796,7 +2796,7 @@
* SUCCESS on success and FAILURE on failure.
*/
-int wait_for_cmd_complete(nic_t * sp)
+static int wait_for_cmd_complete(nic_t * sp)
{
XENA_dev_config_t __iomem *bar0 = sp->bar0;
int ret = FAILURE, cnt = 0;
@@ -3042,7 +3042,7 @@
return SUCCESS;
}
-int wait_for_msix_trans(nic_t *nic, int i)
+static int wait_for_msix_trans(nic_t *nic, int i)
{
XENA_dev_config_t *bar0 = (XENA_dev_config_t *) nic->bar0;
u64 val64;
@@ -3081,7 +3081,7 @@
}
}
-void store_xmsi_data(nic_t *nic)
+static void store_xmsi_data(nic_t *nic)
{
XENA_dev_config_t *bar0 = (XENA_dev_config_t *) nic->bar0;
u64 val64, addr, data;
@@ -3253,7 +3253,7 @@
* file on failure.
*/
-int s2io_open(struct net_device *dev)
+static int s2io_open(struct net_device *dev)
{
nic_t *sp = dev->priv;
int err = 0;
@@ -3383,7 +3383,7 @@
* file on failure.
*/
-int s2io_close(struct net_device *dev)
+static int s2io_close(struct net_device *dev)
{
nic_t *sp = dev->priv;
int i;
@@ -3432,7 +3432,7 @@
* 0 on success & 1 on failure.
*/
-int s2io_xmit(struct sk_buff *skb, struct net_device *dev)
+static int s2io_xmit(struct sk_buff *skb, struct net_device *dev)
{
nic_t *sp = dev->priv;
u16 frg_cnt, frg_len, i, queue, queue_len, put_off, get_off;
@@ -3878,7 +3878,7 @@
* pointer to the updated net_device_stats structure.
*/
-struct net_device_stats *s2io_get_stats(struct net_device *dev)
+static struct net_device_stats *s2io_get_stats(struct net_device *dev)
{
nic_t *sp = dev->priv;
mac_info_t *mac_control;
@@ -5071,19 +5071,20 @@
tmp_stats[i++] = stat_info->sw_stat.double_ecc_errs;
}
-int s2io_ethtool_get_regs_len(struct net_device *dev)
+static int s2io_ethtool_get_regs_len(struct net_device *dev)
{
return (XENA_REG_SPACE);
}
-u32 s2io_ethtool_get_rx_csum(struct net_device * dev)
+static u32 s2io_ethtool_get_rx_csum(struct net_device * dev)
{
nic_t *sp = dev->priv;
return (sp->rx_csum);
}
-int s2io_ethtool_set_rx_csum(struct net_device *dev, u32 data)
+
+static int s2io_ethtool_set_rx_csum(struct net_device *dev, u32 data)
{
nic_t *sp = dev->priv;
@@ -5094,17 +5095,19 @@
return 0;
}
-int s2io_get_eeprom_len(struct net_device *dev)
+
+static int s2io_get_eeprom_len(struct net_device *dev)
{
return (XENA_EEPROM_SPACE);
}
-int s2io_ethtool_self_test_count(struct net_device *dev)
+static int s2io_ethtool_self_test_count(struct net_device *dev)
{
return (S2IO_TEST_LEN);
}
-void s2io_ethtool_get_strings(struct net_device *dev,
- u32 stringset, u8 * data)
+
+static void s2io_ethtool_get_strings(struct net_device *dev,
+u32 stringset, u8 * data)
{
switch (stringset) {
case ETH_SS_TEST:
@@ -5120,7 +5123,7 @@
return (S2IO_STAT_LEN);
}
-int s2io_ethtool_op_set_tx_csum(struct net_device *dev, u32 data)
+static int s2io_ethtool_op_set_tx_csum(struct net_device *dev, u32 data)
{
if (data)
dev->features |= NETIF_F_IP_CSUM;
@@ -5173,7 +5176,7 @@
* function always return EOPNOTSUPPORTED
*/
-int s2io_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+static int s2io_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
return -EOPNOTSUPP;
}
@@ -5189,7 +5192,7 @@
* file on failure.
*/
-int s2io_change_mtu(struct net_device *dev, int new_mtu)
+static int s2io_change_mtu(struct net_device *dev, int new_mtu)
{
nic_t *sp = dev->priv;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
Re: [PATCH] tcp/dccp: randomize port selection
On 11/3/05, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > This patch randomizes the port selected on bind() for connections > to help with possible security attacks. It should also be faster > in most cases because there is no need for a global lock. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Thanks Stephen, I'll have to rework the generalisation of tcp_v6_get_port into inet6_csk_get_port (like was done in the v4 case) and the same for some other functions (hash_connect, etc) but its ok :-) Applied. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A bug in sk_stream_wait_connect()
On 11/3/05, Herbert Xu <[EMAIL PROTECTED]> wrote: > On Thu, Nov 03, 2005 at 03:39:08PM +, Alex Sidorenko wrote: > > > > I am not a kernel developer so I am not sure about the best way to fix this > > but just adding another finish_wait(sk->sk_sleep, &wait) to be called even > > when we 'break' fixes the problem - we were able to run the same test and do > > some other work on the instrumented host for several hours without any > > problems. > > Thank you very much for this most excellent and detailed bug report. > In fact, your conclusion here is absolutely correct. We should do Thanks everybody for fixing this one, it is special in the sense that it is now used by several protocols, so I guess that at least one problem reported about DCCP may well have been fixed by this one :-) Applied. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]eepro100: remove devices supported by e100
On 11/5/05, Lennert Buytenhek <[EMAIL PROTECTED]> wrote: > On Fri, Nov 04, 2005 at 08:34:05PM -0800, Scott Feldman wrote: > > > So there is nothing left. Why not just remove eepro100? > > This has been coming up every few months for a while now. e100 doesn't > work on a number of ARM platforms due to its (ab)use of the DMA API. > > http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1438.html > http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1481.html > > Apparently, Intel have shown no interest in fixing e100 for ARM, which > because Intel also manufactures ARM-based CPUs leads to the situation > where an Intel NIC is not supported in combination with an Intel CPU. Actually, I do have an interest, but the closest thing I have to an ARM cpu with a pro/100 network adapter is a pci plug in development board and I haven't had time to get the thing and its environment up and running. Thanks for posting these links, I had heard of them but hadn't seen them. These posts mention an interesting problem, where the e100 hardware (in the mode we're using it) requires the crazy dynamic chaining thing modifying the S(suspend) bit of a previous descriptor, basically racing with hardware, but there are multiple platforms like ARM that have some issues with this design. Coming up with a fix is not real simple but probably will entail something like the eepro100 driver does where it only replenishes the ring when it has to restart the receive unit. I'm pretty sure this will effect peformance, but i don't know how much. Anyone want to take a shot at it? I'd be glad to test and review patches that were submitted to fix the 'ARM' issue. Jesse - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for pull from netdev-jwl
John W. Linville wrote: I thought you might appreciate a little offload of some of your netdev merging chores. I don't think there is anything controversial here. Thanks, appreciated. I already had some of this stuff in netdev-2.6.git, so, how to proceed from here? The pull request is immediately below, followed by the omnibus patch for quick review. Thanks, John P.S. The tree is based upon the netdev-2.6.git from kernel.org. --- The following changes since commit e2f2e58e7968f8446b1078a20a18bf8ea12b4fbc: Paul Mackerras: powerpc: import a fix from arch/ppc/mm/pgtable.c are found in the git repository at: git://git.tuxdriver.com/git/netdev-jwl.git Adrian Bunk: drivers/net/ixgb/: make some code static drivers/net/e1000/: possible cleanups drivers/net/hamradio/dmascc.c: remove dmascc_setup() OK Daniel Drake: prism54: Remove redundant assignment OK Daniele Venzano: sis900: add Wake on LAN support already in netdev-2.6.git branch sis900-wol Mark Brown: natsemi: Option to use MII port with no PHY questionable Matt Porter: phy address mask support for generic phy layer OK, already merged Michael Chan: bnx2: add 5708 support bnx2: update firmware for 5708 bnx2: update nvram code for 5708 bnx2: update firmware handshake for 5708 bnx2: refine bnx2_poll bnx2: update version and minor fixes OK Ravinandan Arakali: S2io: Updated documentation OK, already merged - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.14] S2io: Updated documentation
applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.14-git4] pcnet32: Prevent hang with 79c976
applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phy address mask support for generic phy layer
applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.14-git4] pcnet32: AT2700/2701 and Bugzilla 2699 & 4551
applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.14-git4] pcnet32: show name of failing device
applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netem: support time based reordering
On 11/3/05, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > Change netem to support packets getting reordered because of > variations in delay. Introduce a special case version of FIFO that queues > packets > in order based on the netem delay. > > Since netem is classful, those users that don't want jitter based reordering > can just insert a pfifo instead of the default. > > This required changes to generic skbuff code to allow finer grain manipulation > of sk_buff_head. Insertion into the middle and reverse walk. Next time please consider breaking such a changeset in two, one for the new sk_buff stuff and the other for netem using it. Anyway, applied all three patches - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
> > Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_ > > any notification. > > Flushes do not generate notifications. The reason is technical: they > are usually massive, do overflow buffer, get lost and listeners have > to do painful resynchronization. The justification: they are useless > because these events are derived. I perfectly agree, still I'm not happy with deleting the local routes for the temporarly orphaned secondaries without notifications and just re-add them again later. I think we should either prevent the deletion of the local routes by rewriting their preferred source address during promotion or explicitely announce the temprary orphaned secondaries as down and up again in order to have the local routes deleted/re-added in a clean way. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] kill include/linux/eeprom.h
This patch kills include/linux/eeprom.h .
Rationale:
- it was only used by one single driver
- even this driver didn't do anything useful with it
- most of this file are non-inline and non-static functions (sic)
This removes include/linux/eeprom.h and cleans drivers/net/ns83820.c up.
If you think eeprom.h should be used more extensively, please consider:
- the code has to be moved from the header file to a .c file
- the currently empty write function has to be implemented
- ns83820.c or any other driver should actually use it
Noone did any of these during the more than 3 years eeprom.h already
exists...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/ns83820.c | 13 ---
include/linux/eeprom.h | 136 -
2 files changed, 2 insertions(+), 147 deletions(-)
--- linux-2.6.11-rc3-mm2-full/include/linux/eeprom.h2004-12-24
22:33:49.0 +0100
+++ /dev/null 2004-11-25 03:16:25.0 +0100
@@ -1,136 +0,0 @@
-/* credit winbond-840.c
- */
-#include
-struct eeprom_ops {
- void(*set_cs)(void *ee);
- void(*clear_cs)(void *ee);
-};
-
-#define EEPOL_EEDI 0x01
-#define EEPOL_EEDO 0x02
-#define EEPOL_EECLK0x04
-#define EEPOL_EESEL0x08
-
-struct eeprom {
- void *dev;
- struct eeprom_ops *ops;
-
- void __iomem * addr;
-
- unsignedee_addr_bits;
-
- unsignedeesel;
- unsignedeeclk;
- unsignedeedo;
- unsignedeedi;
- unsignedpolarity;
- unsignedee_state;
-
- spinlock_t *lock;
- u32 *cache;
-};
-
-
-u8 eeprom_readb(struct eeprom *ee, unsigned address);
-void eeprom_read(struct eeprom *ee, unsigned address, u8 *bytes,
- unsigned count);
-void eeprom_writeb(struct eeprom *ee, unsigned address, u8 data);
-void eeprom_write(struct eeprom *ee, unsigned address, u8 *bytes,
- unsigned count);
-
-/* The EEPROM commands include the alway-set leading bit. */
-enum EEPROM_Cmds {
-EE_WriteCmd=(5 << 6), EE_ReadCmd=(6 << 6), EE_EraseCmd=(7 << 6),
-};
-
-void setup_ee_mem_bitbanger(struct eeprom *ee, void __iomem *memaddr, int
eesel_bit, int eeclk_bit, int eedo_bit, int eedi_bit, unsigned polarity)
-{
- ee->addr = memaddr;
- ee->eesel = 1 << eesel_bit;
- ee->eeclk = 1 << eeclk_bit;
- ee->eedo = 1 << eedo_bit;
- ee->eedi = 1 << eedi_bit;
-
- ee->polarity = polarity;
-
- *ee->cache = readl(ee->addr);
-}
-
-/* foo. put this in a .c file */
-static inline void eeprom_update(struct eeprom *ee, u32 mask, int pol)
-{
- unsigned long flags;
- u32 data;
-
- spin_lock_irqsave(ee->lock, flags);
- data = *ee->cache;
-
- data &= ~mask;
- if (pol)
- data |= mask;
-
- *ee->cache = data;
-//printk("update: %08x\n", data);
- writel(data, ee->addr);
- spin_unlock_irqrestore(ee->lock, flags);
-}
-
-void eeprom_clk_lo(struct eeprom *ee)
-{
- int pol = !!(ee->polarity & EEPOL_EECLK);
-
- eeprom_update(ee, ee->eeclk, pol);
- udelay(2);
-}
-
-void eeprom_clk_hi(struct eeprom *ee)
-{
- int pol = !!(ee->polarity & EEPOL_EECLK);
-
- eeprom_update(ee, ee->eeclk, !pol);
- udelay(2);
-}
-
-void eeprom_send_addr(struct eeprom *ee, unsigned address)
-{
- int pol = !!(ee->polarity & EEPOL_EEDI);
- unsigned i;
- address |= 6 << 6;
-
-/* Shift the read command bits out. */
-for (i=0; i<11; i++) {
- eeprom_update(ee, ee->eedi, ((address >> 10) & 1) ^ pol);
- address <<= 1;
- eeprom_clk_hi(ee);
- eeprom_clk_lo(ee);
-}
- eeprom_update(ee, ee->eedi, pol);
-}
-
-u16 eeprom_readw(struct eeprom *ee, unsigned address)
-{
- unsigned i;
- u16 res = 0;
-
- eeprom_clk_lo(ee);
- eeprom_update(ee, ee->eesel, 1 ^ !!(ee->polarity & EEPOL_EESEL));
- eeprom_send_addr(ee, address);
-
- for (i=0; i<16; i++) {
- u32 data;
- eeprom_clk_hi(ee);
- res <<= 1;
- data = readl(ee->addr);
-//printk("eeprom_readw: %08x\n", data);
- res |= !!(data & ee->eedo) ^ !!(ee->polarity & EEPOL_EEDO);
- eeprom_clk_lo(ee);
- }
- eeprom_update(ee, ee->eesel, 0 ^ !!(ee->polarity & EEPOL_EESEL));
-
- return res;
-}
-
-
-void eeprom_writeb(struct eeprom *ee, unsigned address, u8 data)
-{
-}
--- linux-2.6.14-rc5-mm1-full/drivers/net/ns83820.c.old 2005-11-05
19:45:57.0 +0100
+++ linux-2.6.14-rc5-mm1-full/drivers/net/ns83820.c 2005-11-05
19:50:20.0 +0100
@@ -110,7 +110,6 @@
#include
#include /* for iph */
#include /* for IPPROTO_... */
-#include
#include
#include
#include
@@ -445,7 +444,6 @@
u32 MEAR_cache;
u32 IMR_cache;
- struct eeprom
[PATCH] [PRISM54] Fix leaking of kernel buffers into short frames
Josh Wright and I encountered this doing rawtx experiements some time ago. I bounced it to the prism54 guys but it must have gotten lost in the shuffle and we just noticed that it's still in the latest kernel so here we go again. PROBLEM: Prism54 assumes frames must be at least ETH_ZLEN in size, and grows the skb to that size if they are not. However, it doesn't clear the grown skb so anything left in kernel buffers gets throw into the packet and transmitted onto the air. SOLUTION: Don't grow the frame size. 802.11 doesn't have a minimum frame size constraint. This was addressed on the Orinoco drivers recently in a similar situation. After talking to the Prism54 team there appears to be no constraint in the prism54 firmware that would prevent sending short frames like this. Patch attached. Signed off by: Mike Kershaw <[EMAIL PROTECTED]> -- Mike Kershaw/Dragorn <[EMAIL PROTECTED]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 Bus Error at 008BE426 while reading byte from DEADBEEF in User data space diff --git a/drivers/net/wireless/prism54/islpci_eth.c b/drivers/net/wireless/prism54/islpci_eth.c index 5952e99..a2558c2 100644 --- a/drivers/net/wireless/prism54/islpci_eth.c +++ b/drivers/net/wireless/prism54/islpci_eth.c @@ -99,7 +99,9 @@ islpci_eth_transmit(struct sk_buff *skb, /* determine the amount of fragments needed to store the frame */ - frame_size = skb->len < ETH_ZLEN ? ETH_ZLEN : skb->len; + /* Previously this was calculated by enforcing that a frame had to be as +* large as ETH_ZLEN, however this should not be necessary on 802.11 frames */ + frame_size = skb->len; if (init_wds) frame_size += 6; pgp9Zx3BqWgBX.pgp Description: PGP signature
Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
Hello! > Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_ > any notification. Flushes do not generate notifications. The reason is technical: they are usually massive, do overflow buffer, get lost and listeners have to do painful resynchronization. The justification: they are useless because these events are derived. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
Richard Knutsson <[EMAIL PROTECTED]> wrote: > > Richard Knutsson wrote: > > > Andrew Morton wrote: > > > >> Richard Knutsson <[EMAIL PROTECTED]> wrote: > >> > >> > */ > > >>> > >>> > #ifdef CONFIG_EISA > >>> >-eisacount = eisa_driver_register(&dgrs_eisa_driver); > >>> >-if (eisacount < 0) > >>> >-return eisacount; > >>> >-#endif > >>> >-#ifdef CONFIG_PCI > >>> >-pcicount = pci_register_driver(&dgrs_pci_driver); > >>> >-if (pcicount) > >>> >-return pcicount; > >>> >+cardcount = eisa_driver_register(&dgrs_eisa_driver); > >>> >+if (cardcount < 0) > >>> >+return cardcount; > >>> > #endif > >>> >+cardcount = pci_register_driver(&dgrs_pci_driver); > >>> >+if (cardcount) > >>> >+return cardcount; > >>> > return 0; > >>> > } > >>> > > > >>> I do not know what to think about this one: > >>> * reduce one #ifdef: good > >>> * check for something clearly stated not to: not so good > >>> > >> > >> > >> Well a nicer fix would be to provide a stub implementation of > >> eisa_driver_register() if !CONFIG_EISA, just like > >> pci_register_driver(). Then all the ifdefs go away and the compiler > >> removes all the code for us, > >> after checking that we typed it correctly. > >> > >> > > Oh, sorry. Missed the stub implementation of the pci-driver. I "ack" > > your patch. > > > > BTW, can anyone ack or is that up to the maintainers? > > BTW #2, why not remove #ifdef CONFIG_PCI on dgrs_cleanup_module() at > > the same time? Or maybe that should be in a "remove config_pci"-patch... > > > > /Richard > > Just realized; what happens if CONFIG_EISA && !CONFIG_PCI and > eisa_driver_register() returns value > 0, then the if-statement for the > pci-driver is going to return the value, instead of 0. if !CONFIG_PCI, pci_register_driver() will return zero. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
Richard Knutsson <[EMAIL PROTECTED]> wrote: > > BTW, can anyone ack or is that up to the maintainers? It's useful info - it shows that someone else took the time to revie the code. > BTW #2, why not remove #ifdef CONFIG_PCI on dgrs_cleanup_module() at the > same time? Or maybe that should be in a "remove config_pci"-patch... yup. There are lots of opportunities for that, I bet. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/25] net: move atm ioctl32 to net/atm/ioctl.c
This moves all the ATM specific compat ioctls to net/atm.
The code is still the same as before, but it would probably
be a good idea to simplify this by getting rid of using
compat_alloc_user_space.
CC: [EMAIL PROTECTED]
CC: netdev@vger.kernel.org
CC: [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Index: linux-2.6.14-rc/net/atm/common.h
===
--- linux-2.6.14-rc.orig/net/atm/common.h 2005-11-05 02:41:10.0
+0100
+++ linux-2.6.14-rc/net/atm/common.h2005-11-05 02:41:28.0 +0100
@@ -19,6 +19,7 @@
size_t total_len);
unsigned int vcc_poll(struct file *file, struct socket *sock, poll_table
*wait);
int vcc_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg);
+int vcc_compat_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg);
int vcc_setsockopt(struct socket *sock, int level, int optname,
char __user *optval, int optlen);
int vcc_getsockopt(struct socket *sock, int level, int optname,
Index: linux-2.6.14-rc/net/atm/ioctl.c
===
--- linux-2.6.14-rc.orig/net/atm/ioctl.c2005-11-05 02:41:10.0
+0100
+++ linux-2.6.14-rc/net/atm/ioctl.c 2005-11-05 02:41:28.0 +0100
@@ -156,3 +156,170 @@
done:
return error;
}
+
+#ifdef CONFIG_COMPAT
+struct atmif_sioc32 {
+compat_int_t number;
+compat_int_t length;
+compat_caddr_t arg;
+};
+
+struct atm_iobuf32 {
+ compat_int_tlength;
+ compat_caddr_t buffer;
+};
+
+#define ATM_GETLINKRATE32 _IOW('a', ATMIOC_ITF+1, struct atmif_sioc32)
+#define ATM_GETNAMES32_IOW('a', ATMIOC_ITF+3, struct atm_iobuf32)
+#define ATM_GETTYPE32 _IOW('a', ATMIOC_ITF+4, struct atmif_sioc32)
+#define ATM_GETESI32 _IOW('a', ATMIOC_ITF+5, struct atmif_sioc32)
+#define ATM_GETADDR32_IOW('a', ATMIOC_ITF+6, struct atmif_sioc32)
+#define ATM_RSTADDR32_IOW('a', ATMIOC_ITF+7, struct atmif_sioc32)
+#define ATM_ADDADDR32_IOW('a', ATMIOC_ITF+8, struct atmif_sioc32)
+#define ATM_DELADDR32_IOW('a', ATMIOC_ITF+9, struct atmif_sioc32)
+#define ATM_GETCIRANGE32 _IOW('a', ATMIOC_ITF+10, struct atmif_sioc32)
+#define ATM_SETCIRANGE32 _IOW('a', ATMIOC_ITF+11, struct atmif_sioc32)
+#define ATM_SETESI32 _IOW('a', ATMIOC_ITF+12, struct atmif_sioc32)
+#define ATM_SETESIF32 _IOW('a', ATMIOC_ITF+13, struct atmif_sioc32)
+#define ATM_GETSTAT32 _IOW('a', ATMIOC_SARCOM+0, struct atmif_sioc32)
+#define ATM_GETSTATZ32_IOW('a', ATMIOC_SARCOM+1, struct atmif_sioc32)
+#define ATM_GETLOOP32_IOW('a', ATMIOC_SARCOM+2, struct atmif_sioc32)
+#define ATM_SETLOOP32_IOW('a', ATMIOC_SARCOM+3, struct atmif_sioc32)
+#define ATM_QUERYLOOP32 _IOW('a', ATMIOC_SARCOM+4, struct
atmif_sioc32)
+
+static struct {
+unsigned int cmd32;
+unsigned int cmd;
+} atm_ioctl_map[] = {
+ { ATM_GETLINKRATE32, ATM_GETLINKRATE },
+ { ATM_GETNAMES32,ATM_GETNAMES },
+ { ATM_GETTYPE32, ATM_GETTYPE },
+ { ATM_GETESI32, ATM_GETESI },
+ { ATM_GETADDR32, ATM_GETADDR },
+ { ATM_RSTADDR32, ATM_RSTADDR },
+ { ATM_ADDADDR32, ATM_ADDADDR },
+ { ATM_DELADDR32, ATM_DELADDR },
+ { ATM_GETCIRANGE32, ATM_GETCIRANGE },
+ { ATM_SETCIRANGE32, ATM_SETCIRANGE },
+ { ATM_SETESI32, ATM_SETESI },
+ { ATM_SETESIF32, ATM_SETESIF },
+ { ATM_GETSTAT32, ATM_GETSTAT },
+ { ATM_GETSTATZ32,ATM_GETSTATZ },
+ { ATM_GETLOOP32, ATM_GETLOOP },
+ { ATM_SETLOOP32, ATM_SETLOOP },
+ { ATM_QUERYLOOP32, ATM_QUERYLOOP }
+};
+
+#define NR_ATM_IOCTL (sizeof(atm_ioctl_map)/sizeof(atm_ioctl_map[0]))
+
+
+static int do_atm_iobuf(struct socket *sock, unsigned int cmd, unsigned long
arg)
+{
+ struct atm_iobuf __user *iobuf;
+ struct atm_iobuf32 __user *iobuf32;
+ u32 data;
+ void __user *datap;
+ int len, err;
+
+ iobuf = compat_alloc_user_space(sizeof(*iobuf));
+ iobuf32 = compat_ptr(arg);
+
+ if (get_user(len, &iobuf32->length) ||
+ get_user(data, &iobuf32->buffer))
+ return -EFAULT;
+ datap = compat_ptr(data);
+ if (put_user(len, &iobuf->length) ||
+ put_user(datap, &iobuf->buffer))
+ return -EFAULT;
+
+ err = vcc_ioctl(sock, cmd, (unsigned long)iobuf);
+
+ if (!err) {
+ if (copy_in_user(&iobuf32->length, &iobuf->length,
+sizeof(int)))
+ err = -EFAULT;
+ }
+
+ return err;
+}
+
+static int do_atmif_sioc(struct socket *sock, unsigned int cmd, unsigned long
arg)
+{
+ struct atmif_sioc __user *sioc;
+ struct atmif_sioc32 __user *sioc32;
+ u32 data;
+ void __user *datap;
+ int err;
+
+ sioc = compat_alloc_user_space(sizeof(*sioc));
+ si
[PATCH 05/25] net: move ppp specific ioctl32 handlers
This moves all ioctl32 code for ppp close to the
native ioctl implementation.
CC: linux-ppp@vger.kernel.org
CC: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Index: linux-2.6.14-rc/drivers/net/ppp_generic.c
===
--- linux-2.6.14-rc.orig/drivers/net/ppp_generic.c 2005-11-05
02:41:10.0 +0100
+++ linux-2.6.14-rc/drivers/net/ppp_generic.c 2005-11-05 02:41:29.0
+0100
@@ -46,6 +46,8 @@
#include
#include
#include
+#include
+
#include
#include
@@ -837,12 +839,189 @@
return err;
}
+#ifdef CONFIG_COMPAT
+/* FIXME: These could be better integrated into the driver */
+
+struct sock_fprog32 {
+ unsigned short len;
+ compat_caddr_t filter;
+};
+
+#define PPPIOCSPASS32 _IOW('t', 71, struct sock_fprog32)
+#define PPPIOCSACTIVE32_IOW('t', 70, struct sock_fprog32)
+
+static int ppp_sock_fprog_ioctl_trans(struct file *file, unsigned int cmd,
unsigned long arg)
+{
+ struct sock_fprog32 __user *u_fprog32 = compat_ptr(arg);
+ struct sock_fprog __user *u_fprog64 =
compat_alloc_user_space(sizeof(struct sock_fprog));
+ void __user *fptr64;
+ u32 fptr32;
+ u16 flen;
+
+ if (get_user(flen, &u_fprog32->len) ||
+ get_user(fptr32, &u_fprog32->filter))
+ return -EFAULT;
+
+ fptr64 = compat_ptr(fptr32);
+
+ if (put_user(flen, &u_fprog64->len) ||
+ put_user(fptr64, &u_fprog64->filter))
+ return -EFAULT;
+
+ if (cmd == PPPIOCSPASS32)
+ cmd = PPPIOCSPASS;
+ else
+ cmd = PPPIOCSACTIVE;
+
+ return ppp_ioctl(file->f_dentry->d_inode, file, cmd,
+(unsigned long) u_fprog64);
+}
+
+struct ppp_option_data32 {
+ compat_caddr_t ptr;
+ u32 length;
+ compat_int_ttransmit;
+};
+#define PPPIOCSCOMPRESS32 _IOW('t', 77, struct ppp_option_data32)
+
+struct ppp_idle32 {
+ compat_time_t xmit_idle;
+ compat_time_t recv_idle;
+};
+#define PPPIOCGIDLE32 _IOR('t', 63, struct ppp_idle32)
+
+static int ppp_gidle(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ struct ppp_idle __user *idle;
+ struct ppp_idle32 __user *idle32;
+ __kernel_time_t xmit, recv;
+ int err;
+
+ idle = compat_alloc_user_space(sizeof(*idle));
+ idle32 = compat_ptr(arg);
+
+ err = ppp_ioctl(file->f_dentry->d_inode, file, PPPIOCGIDLE, (unsigned
long) idle);
+
+ if (!err) {
+ if (get_user(xmit, &idle->xmit_idle) ||
+ get_user(recv, &idle->recv_idle) ||
+ put_user(xmit, &idle32->xmit_idle) ||
+ put_user(recv, &idle32->recv_idle))
+ err = -EFAULT;
+ }
+ return err;
+}
+
+static int ppp_scompress(struct file *file, unsigned int cmd, unsigned long
arg)
+{
+ struct ppp_option_data __user *odata;
+ struct ppp_option_data32 __user *odata32;
+ __u32 data;
+ void __user *datap;
+
+ odata = compat_alloc_user_space(sizeof(*odata));
+ odata32 = compat_ptr(arg);
+
+ if (get_user(data, &odata32->ptr))
+ return -EFAULT;
+
+ datap = compat_ptr(data);
+ if (put_user(datap, &odata->ptr))
+ return -EFAULT;
+
+ if (copy_in_user(&odata->length, &odata32->length,
+sizeof(__u32) + sizeof(int)))
+ return -EFAULT;
+
+ return ppp_ioctl(file->f_dentry->d_inode, file, PPPIOCSCOMPRESS,
(unsigned long) odata);
+}
+
+static int ppp_ioctl_trans(struct file *file, unsigned int cmd, unsigned long
arg)
+{
+ int err;
+
+ switch (cmd) {
+ case PPPIOCGIDLE32:
+ err = ppp_gidle(file, cmd, arg);
+ break;
+
+ case PPPIOCSCOMPRESS32:
+ err = ppp_scompress(file, cmd, arg);
+ break;
+
+ default:
+ do {
+ static int count;
+ if (++count <= 20)
+ printk("ppp_ioctl: Unknown cmd(%08x)
arg(%08x)\n",
+ (unsigned int)cmd, (unsigned int)arg);
+ } while(0);
+ err = -EINVAL;
+ break;
+ };
+
+ return err;
+}
+
+static long ppp_compat_ioctl(struct file *file, unsigned int cmd, unsigned
long arg)
+{
+ int ret;
+ ret = -ENOIOCTLCMD;
+
+ lock_kernel();
+ switch (cmd) {
+ case PPPIOCGIDLE32:
+ case PPPIOCSCOMPRESS32:
+ ret = ppp_ioctl_trans(file, cmd, arg);
+ break;
+
+ case PPPIOCSPASS32:
+ case PPPIOCSACTIVE32:
+ ret = ppp_sock_fprog_ioctl_trans(file, cmd, arg);
+ break;
+
+ case PPPIOCGFLAGS:
+ case PPPIOCSFLAGS:
+ case PPPIOCGASYNCMAP:
+ case PPPIOCSASYNCMAP:
+ case PPPIOCGUNIT:
+
[PATCH 03/25] net: improve ioctl32 dev_ioctl handling
This patch tries to be a bit smarter about net device ioctl
emulation. In particular, the wireless extensions are treated
as a group in order to make the switch list a little shorter.
CC: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Index: linux-cg/net/compat.c
===
--- linux-cg.orig/net/compat.c 2005-11-05 03:17:30.0 +0100
+++ linux-cg/net/compat.c 2005-11-05 03:24:16.0 +0100
@@ -854,7 +854,7 @@
if (__put_user(data64, &u_ifreq64->ifr_ifru.ifru_data))
return -EFAULT;
- return sock_ioctl(file, cmd, (unsigned long) u_ifreq64);
+ return dev_ioctl(cmd, u_ifreq64);
}
static int dev_ifsioc(struct file *file, unsigned int cmd, unsigned long arg)
@@ -1302,13 +1302,14 @@
return err;
}
+#ifdef WIRELESS_EXT
struct compat_iw_point {
compat_caddr_t pointer;
__u16 length;
__u16 flags;
};
-static int do_wireless_ioctl(struct file *file, unsigned int cmd, unsigned
long arg)
+static int do_wireless_ioctl(unsigned int cmd, unsigned long arg)
{
struct iwreq __user *iwr;
struct iwreq __user *iwr_u;
@@ -1343,8 +1344,9 @@
__put_user(flags, &iwp->flags))
return -EFAULT;
- return sock_ioctl(file, cmd, (unsigned long) iwr);
+ return dev_ioctl(cmd, iwr);
}
+#endif /* WIRELESS_EXT */
/* Since old style bridge ioctl's endup using SIOCDEVPRIVATE
* for some operations; this forces use of the newer bridge-utils that
@@ -1363,16 +1365,43 @@
long compat_sock_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
- if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15))
- return siocdevprivate_ioctl(file, cmd, arg);
+ struct socket *sock;
+ int ret = -ENOIOCTLCMD;
- switch (cmd) {
+ sock = file->private_data;
+ if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15))
+ ret = siocdevprivate_ioctl(file, cmd, arg);
+#ifdef WIRELESS_EXT
+ else if (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST)
+ ret = do_wireless_ioctl(cmd, arg);
+#endif
+ else switch (cmd) {
#define HANDLE_IOCTL(type, handler) \
- case type: return handler(file, cmd, arg);
+ case type: ret = handler(file, cmd, arg); break;
#define COMPATIBLE_IOCTL(type) \
- case type: return sock_ioctl(file, cmd, arg);
+ case type: ret = sock_ioctl(file, cmd, arg); break;
#define INVAL_IOCTL(type) \
- case type: return -EINVAL;
+ case type: ret = -EINVAL; break;
+/* these are handled in sock_ioctl */
+COMPATIBLE_IOCTL(FIOSETOWN)
+COMPATIBLE_IOCTL(SIOCSPGRP)
+COMPATIBLE_IOCTL(FIOGETOWN)
+COMPATIBLE_IOCTL(SIOCGPGRP)
+HANDLE_IOCTL(SIOCSIFBR, old_bridge_ioctl)
+HANDLE_IOCTL(SIOCGIFBR, old_bridge_ioctl)
+COMPATIBLE_IOCTL(SIOCBRADDBR)
+COMPATIBLE_IOCTL(SIOCBRDELBR)
+COMPATIBLE_IOCTL(SIOCGIFVLAN)
+COMPATIBLE_IOCTL(SIOCSIFVLAN)
+COMPATIBLE_IOCTL(SIOCADDDLCI)
+COMPATIBLE_IOCTL(SIOCDELDLCI)
+ default:
+ if (sock->ops->compat_ioctl)
+ ret = sock->ops->compat_ioctl(sock, cmd, arg);
+ }
+
+ if (ret == -ENOIOCTLCMD)
+ switch (cmd) {
HANDLE_IOCTL(SIOCGIFNAME, dev_ifname32)
HANDLE_IOCTL(SIOCGIFCONF, dev_ifconf)
HANDLE_IOCTL(SIOCGIFFLAGS, dev_ifsioc)
@@ -1393,10 +1422,6 @@
HANDLE_IOCTL(SIOCGIFADDR, dev_ifsioc)
HANDLE_IOCTL(SIOCSIFADDR, dev_ifsioc)
-/* ioctls used by appletalk ddp.c */
-HANDLE_IOCTL(SIOCATALKDIFADDR, dev_ifsioc)
-HANDLE_IOCTL(SIOCDIFADDR, dev_ifsioc)
-
HANDLE_IOCTL(SIOCSARP, dev_ifsioc)
HANDLE_IOCTL(SIOCDARP, dev_ifsioc)
@@ -1456,79 +1481,6 @@
HANDLE_IOCTL(PPPIOCSCOMPRESS32, ppp_ioctl_trans)
HANDLE_IOCTL(PPPIOCSPASS32, ppp_sock_fprog_ioctl_trans)
HANDLE_IOCTL(PPPIOCSACTIVE32, ppp_sock_fprog_ioctl_trans)
-/* wireless */
-HANDLE_IOCTL(SIOCGIWRANGE, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCSIWSPY, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCGIWSPY, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCSIWTHRSPY, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCGIWTHRSPY, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCGIWAPLIST, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCGIWSCAN, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCSIWESSID, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCGIWESSID, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCSIWNICKN, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCGIWNICKN, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCSIWENCODE, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCGIWENCODE, do_wireless_ioctl)
-HANDLE_IOCTL(SIOCSIFBR, old_bridge_ioctl)
-HANDLE_IOCTL(SIOCGIFBR, old_bridge_ioctl)
-
-COMPATIBLE_IOCTL(FIOSETOWN)
-COMPATIBLE_IOCTL(SIOCSPGRP)
-COMPATIBLE_IOCTL(FIOGETOWN)
-COMPATIBLE_IOCTL(SIOCGPGRP)
-COMPATIBLE_IOCTL(SIOCATMARK)
-COMPATIBLE_IOCTL(SIOCSIFLINK)
-COMPATIBLE_IOCTL(SIOCSIFENCAP)
-COMPATIBLE_IOCTL(SIOCGIFENCAP)
-COMPATIBLE_IOCTL(SIOCSIFNAME)
-//COMPATIBLE_IOCTL(SIOCSARP)
-COMPATIBLE_IOCTL(SIOCGARP)
-//COMPATIBLE_IOCTL(SIOCDARP)
-COMPATIBLE_IOCTL(SIOCSRARP)
-COMPATIBLE_IOCTL(SIOCGRARP)
-
[2.6 patch] airo.c/airo_cs.c: correct prototypes
This patch creates a file airo.h containing prototypes of the global
functions in airo.c used by airo_cs.c .
If you got strange problems with either airo_cs devices or in any other
completely unrelated part of the kernel shortly or long after a airo_cs
device was detected by the kernel, this might have been caused by the
fact that caller and callee disagreed regarding the size of the first
argument to init_airo_card()...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/wireless/airo.c|2 ++
drivers/net/wireless/airo.h|9 +
drivers/net/wireless/airo_cs.c |6 ++
3 files changed, 13 insertions(+), 4 deletions(-)
--- /dev/null 2005-04-28 03:52:17.0 +0200
+++ linux-2.6.14-rc5-mm1-full/drivers/net/wireless/airo.h 2005-11-05
16:57:14.0 +0100
@@ -0,0 +1,9 @@
+#ifndef _AIRO_H_
+#define _AIRO_H_
+
+struct net_device *init_airo_card(unsigned short irq, int port, int is_pcmcia,
+ struct device *dmdev);
+int reset_airo_card(struct net_device *dev);
+void stop_airo_card(struct net_device *dev, int freeres);
+
+#endif /* _AIRO_H_ */
--- linux-2.6.14-rc5-mm1-full/drivers/net/wireless/airo.c.old 2005-11-05
16:54:10.0 +0100
+++ linux-2.6.14-rc5-mm1-full/drivers/net/wireless/airo.c 2005-11-05
16:54:43.0 +0100
@@ -47,6 +47,8 @@
#include
#include
+#include "airo.h"
+
#ifdef CONFIG_PCI
static struct pci_device_id card_ids[] = {
{ 0x14b9, 1, PCI_ANY_ID, PCI_ANY_ID, },
--- linux-2.6.14-rc5-mm1-full/drivers/net/wireless/airo_cs.c.old
2005-11-05 16:57:27.0 +0100
+++ linux-2.6.14-rc5-mm1-full/drivers/net/wireless/airo_cs.c2005-11-05
16:57:58.0 +0100
@@ -42,6 +42,8 @@
#include
#include
+#include "airo.h"
+
/*
All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If
you do not define PCMCIA_DEBUG at all, all the debug code will be
@@ -78,10 +80,6 @@
event handler.
*/
-struct net_device *init_airo_card( int, int, int, struct device * );
-void stop_airo_card( struct net_device *, int );
-int reset_airo_card( struct net_device * );
-
static void airo_config(dev_link_t *link);
static void airo_release(dev_link_t *link);
static int airo_event(event_t event, int priority,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
Richard Knutsson wrote: Andrew Morton wrote: Richard Knutsson <[EMAIL PROTECTED]> wrote: */ > #ifdef CONFIG_EISA >-eisacount = eisa_driver_register(&dgrs_eisa_driver); >-if (eisacount < 0) >-return eisacount; >-#endif >-#ifdef CONFIG_PCI >-pcicount = pci_register_driver(&dgrs_pci_driver); >-if (pcicount) >-return pcicount; >+cardcount = eisa_driver_register(&dgrs_eisa_driver); >+if (cardcount < 0) >+return cardcount; > #endif >+cardcount = pci_register_driver(&dgrs_pci_driver); >+if (cardcount) >+return cardcount; > return 0; > } > > I do not know what to think about this one: * reduce one #ifdef: good * check for something clearly stated not to: not so good Well a nicer fix would be to provide a stub implementation of eisa_driver_register() if !CONFIG_EISA, just like pci_register_driver(). Then all the ifdefs go away and the compiler removes all the code for us, after checking that we typed it correctly. Oh, sorry. Missed the stub implementation of the pci-driver. I "ack" your patch. BTW, can anyone ack or is that up to the maintainers? BTW #2, why not remove #ifdef CONFIG_PCI on dgrs_cleanup_module() at the same time? Or maybe that should be in a "remove config_pci"-patch... /Richard Just realized; what happens if CONFIG_EISA && !CONFIG_PCI and eisa_driver_register() returns value > 0, then the if-statement for the pci-driver is going to return the value, instead of 0. /Richard - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
* Patrick McHardy <[EMAIL PROTECTED]> 2005-11-05 05:28 > The reason why all routes are deleted is because their prefered > source addresses is the primary address. fn_flush_list should > probably send the missing notifications for the deleted routes. > Changing address promotion to not delete the other routes at all > looks extremly complicated, I think just fixing it to behave > correctly is good enough (which my patch didn't do entirely, > I'll send a new one this weekend). Yes, fib_sync_down(), but even when I remove the code setting RTNH_F_DEAD I still see _some_ local routes disappearing which I cannot explain right now. I can only reproduce this with !CONFIG_IP_MULTIPLE_TABLES though. Assuming this is a separate bug, I'm not sure if this is the right way to fix it. I think it would be better to rewrite the preferred source address of all related local routes and only perform a remove-and-add on the secondary address being promoted. _If_ we let them die, we should announce it in fib_sync_down() rather then in the algorithm specific flush routines. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Request for pull from netdev-jwl
[Resend #2 -- I think it is getting dropped due to size, so I'm omitting the omnibus patch. I'll send it separately if need be...] Jeff, I thought you might appreciate a little offload of some of your netdev merging chores. I don't think there is anything controversial here. Thanks, John P.S. The tree is based upon the netdev-2.6.git from kernel.org. --- The following changes since commit e2f2e58e7968f8446b1078a20a18bf8ea12b4fbc: Paul Mackerras: powerpc: import a fix from arch/ppc/mm/pgtable.c are found in the git repository at: git://git.tuxdriver.com/git/netdev-jwl.git Adrian Bunk: drivers/net/ixgb/: make some code static drivers/net/e1000/: possible cleanups drivers/net/hamradio/dmascc.c: remove dmascc_setup() Daniel Drake: prism54: Remove redundant assignment Daniele Venzano: sis900: add Wake on LAN support Mark Brown: natsemi: Option to use MII port with no PHY Matt Porter: phy address mask support for generic phy layer Michael Chan: bnx2: add 5708 support bnx2: update firmware for 5708 bnx2: update nvram code for 5708 bnx2: update firmware handshake for 5708 bnx2: refine bnx2_poll bnx2: update version and minor fixes Ravinandan Arakali: S2io: Updated documentation Documentation/networking/s2io.txt | 197 + drivers/net/bnx2.c| 468 +++ drivers/net/bnx2.h| 119 + drivers/net/bnx2_fw.h | 4055 ++--- drivers/net/e1000/e1000_ethtool.c |2 drivers/net/e1000/e1000_hw.c | 101 + drivers/net/e1000/e1000_hw.h | 42 drivers/net/e1000/e1000_main.c| 31 drivers/net/hamradio/dmascc.c | 10 drivers/net/ixgb/ixgb_ethtool.c |2 drivers/net/ixgb/ixgb_hw.c| 31 drivers/net/ixgb/ixgb_hw.h| 17 drivers/net/ixgb/ixgb_main.c |2 drivers/net/natsemi.c | 97 - drivers/net/phy/mdio_bus.c|3 drivers/net/sis900.c | 73 + drivers/net/sis900.h | 45 drivers/net/wireless/prism54/islpci_eth.c |1 include/linux/ethtool.h |3 include/linux/pci_ids.h |2 include/linux/phy.h |3 21 files changed, 3478 insertions(+), 1826 deletions(-) -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix ifenslave to not fail on lack of IP information
On Fri, Nov 04, 2005 at 11:08:32PM -0800, Jason R. Martin wrote: > On 11/4/05, Neil Horman <[EMAIL PROTECTED]> wrote: > > On Fri, Nov 04, 2005 at 12:25:49PM -0800, Jay Vosburgh wrote: > > > > > > [dropped linux-kernel; added netdev] > > > > > > Neil Horman <[EMAIL PROTECTED]> wrote: > > > > > > >The current version of ifenslave fails to attach slave interfaces to a > > > >bond if > > > >the masters doesn't have appropriate IP information. While its common > > > >for > > > >bonded interface to have IP information its not required (bond as part > > > >of a > > > >bridge for instance). > > > > > > As far as I know, attaching slaves to a bonding device without > > > an IP address works just fine; the bonding master device must merely be > > > up. Under what circumstances are you seeing a problem? > > > > > Try to run ifenslave on a bonded interface with no ip address, it will fail. > > Are you sure it fails or do you just get an error message? > Traditionally it has spit out a (non-fatal) error message about not > being able to get the address info, but then go ahead and enslave > anyway. > > At least that's been my experience. > Definately exits prematurely for me. I'm not in front of the source at the moment, but I'll grab the backtrace first thing monday morning and post the call trace. Thanks and regards Neil > Jason -- /*** *Neil Horman *Software Engineer *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix ifenslave to not fail on lack of IP information
On Fri, Nov 04, 2005 at 07:44:16PM -0800, Jay Vosburgh wrote: > Neil Horman <[EMAIL PROTECTED]> wrote: > [...] > >Try to run ifenslave on a bonded interface with no ip address, it will fail. > > Works fine for me with the 2.6.14 kernel and ifenslave. > > [...] But it also modifies > >set_if_addr, which is used to propogate the masters ip info to the slave(s). > > Ah, I missed that bit. > > In any event, the set_if_addr() function is only for old > versions of bonding (it's called inside an "if (abi_ver < 2) block"), so > it shouldn't normally be called for the current bonding kernel driver; > what versions of bonding and ifenslave are you using? There was some > version control breakage in some of the 2.6.14-rc kernels, so if you're > running one of those, be sure to upgrade to the final 2.6.14. > I'm not sure that will be feasable for me (Its the RHEL 3 kernel series). But if it is I'll certainly give that a go. Thanks! Neil > -J > > --- > -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] -- /*** *Neil Horman *Software Engineer *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
Andrew Morton wrote: Richard Knutsson <[EMAIL PROTECTED]> wrote: */ > #ifdef CONFIG_EISA >- eisacount = eisa_driver_register(&dgrs_eisa_driver); >- if (eisacount < 0) >- return eisacount; >-#endif >-#ifdef CONFIG_PCI >- pcicount = pci_register_driver(&dgrs_pci_driver); >- if (pcicount) >- return pcicount; >+ cardcount = eisa_driver_register(&dgrs_eisa_driver); >+ if (cardcount < 0) >+ return cardcount; > #endif >+ cardcount = pci_register_driver(&dgrs_pci_driver); >+ if (cardcount) >+ return cardcount; >return 0; > } > > I do not know what to think about this one: * reduce one #ifdef: good * check for something clearly stated not to: not so good Well a nicer fix would be to provide a stub implementation of eisa_driver_register() if !CONFIG_EISA, just like pci_register_driver(). Then all the ifdefs go away and the compiler removes all the code for us, after checking that we typed it correctly. Oh, sorry. Missed the stub implementation of the pci-driver. I "ack" your patch. BTW, can anyone ack or is that up to the maintainers? BTW #2, why not remove #ifdef CONFIG_PCI on dgrs_cleanup_module() at the same time? Or maybe that should be in a "remove config_pci"-patch... /Richard - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]eepro100: remove devices supported by e100
On Sat, Nov 05, 2005 at 11:28:21AM +0100, Lennert Buytenhek wrote: > This has been coming up every few months for a while now. e100 doesn't > work on a number of ARM platforms due to its (ab)use of the DMA API. > > http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1438.html > http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1481.html eepro100 removal also came up in January of this year: http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/1330.html --L - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
Hi, Patrick, From: Patrick McHardy <[EMAIL PROTECTED]> Date: Sat, 05 Nov 2005 10:55:57 +0100 > > Also, I thought Yoshifuji-san's objection is not just about > > transport mode packets passing through netif_rx twice, but > > passing through netfilter twice as well? > > I think so, but he didn't mention a reason why he objects to it. > I also don't think it can be done otherwise while still keeping > netfilter "just working" for all cases, which IMO is highly > desirable. I try to comment based on discussion with Yoshifuji-san and Miyazawa-san. We think it's confusing for user to mix decrypted packets and pre-decrypted ones to same hook. For example, if user want to accept packets encrypted by transport mode ESP and drop others, he will do "iptables -A INPUT -p esp -j ACCEPT" and "iptables -P INPUT DROP". But decrypted packets will be dropped because of the 2nd command. Of cause the match module 'policy' will be helpful in such case, but it's simple if he can different name of hook with INPUT. And, in logical, the hook for decrypted packet and the one for pre-decrypted packet is different like the current LOCAL_IN and LOCAL_OUT. Their place and the packets they can see, are different. This can be said about output path. The hook for encrypted packet and the one for pre-encrypted packet is different. In the current, LOCAL_OUT see pre-encrypted packet. I've been assuming that LOCAL_OUT see the packets just before sending them from network device. This is the reason why I said "I support the way" - which means LOCAL_OUT doesn't see pre-encrypted packet. Meanwhile the hook to see pre-encrypted packet is necessary for NAT indeed as you pointed out. Then our suggestion is adding new hook with new name, and distinguishing cleary between the usage of new and current hook. BTW, tunnel mode is special case. We can avoid confusing by operation and so on. For example, using different address for inner and outer header. We agree to call netif_rx() twice for tunneled packets, as ever. Regards, -- Yasuyuki Kozakai - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]eepro100: remove devices supported by e100
On Fri, Nov 04, 2005 at 08:34:05PM -0800, Scott Feldman wrote: > So there is nothing left. Why not just remove eepro100? This has been coming up every few months for a while now. e100 doesn't work on a number of ARM platforms due to its (ab)use of the DMA API. http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1438.html http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1481.html Apparently, Intel have shown no interest in fixing e100 for ARM, which because Intel also manufactures ARM-based CPUs leads to the situation where an Intel NIC is not supported in combination with an Intel CPU. IMHO, this is an even weirder situation than if Intel were to not support the Intel NIC silicon on third-party NICs.. *ducks* :-) Can we put a comment in eepro100.c stating our reasons for keeping it for the time being? cheers, Lennert - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
Herbert Xu wrote: > On Sat, Nov 05, 2005 at 10:55:57AM +0100, Patrick McHardy wrote: > >>In my last patchset I did it by calling netif_rx at that point, >>now I want to add new hooks. > > The only problem I can see is that at some point we're probably > going to add an AF_PACKET hook there as well for the pure transport > mode packet so that people can diagnose their transport mode IPsec > problems. Yes, that would be useful. > However, I reckon that's still miles ahead of passing the packet > back through netif_rx when we already know that it's still the > same address family as what we started out with. Great. I'm moving to a new appartment right now and will be offline until monday. I'll try to get some patches ready until then. Regards Patrick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
On Sat, Nov 05, 2005 at 10:55:57AM +0100, Patrick McHardy wrote:
>
> > <[EMAIL PROTECTED]>
>
> Well, once encapsulated and once decapsulated.
>
> What I propose is actually exactly what you suggested in that mail:
You got me there :) I was confused. Yes this is OK with me.
> In my last patchset I did it by calling netif_rx at that point,
> now I want to add new hooks.
The only problem I can see is that at some point we're probably
going to add an AF_PACKET hook there as well for the pure transport
mode packet so that people can diagnose their transport mode IPsec
problems.
However, I reckon that's still miles ahead of passing the packet
back through netif_rx when we already know that it's still the
same address family as what we started out with.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
Herbert Xu wrote:
> On Sat, Nov 05, 2005 at 10:19:51AM +0100, Patrick McHardy wrote:
>
>>What I propose is to keep tunnel mode handling as it is, so
>>for each tunnel mode SA we hit PRE_ROUTING and LOCAL_IN in
>>the normal packet path. If the final SA is a transport mode
>>SA, we don't call netif_rx as in my first patchset, but pass
>>the packet through a new PRE_ROUTING hook in xfrm{4,6}_input
>>and LOCAL_IN afterwards. The packet won't be processed a second
>>time by the stack, just the netfilter hooks will be called.
>>NAT be will be handled manually for IPv4 by doing a new route
>>lookup and calling dst_input if NAT took place.
>
>
> In other words LOCAL_IN will still see the packet twice for
> pure transport mode packets? That's going to be a problem for
> me for the reasons that I outlined earlier:
>
> <[EMAIL PROTECTED]>
Well, once encapsulated and once decapsulated.
What I propose is actually exactly what you suggested in that mail:
> Would it be workable to try something like this? We invoke netfilter
> after each tunnel mode transform as we do now. In addition to that,
> we invoke netfilter at the very end of IPsec processing, that is,
> just before the point where the original xfrm*_rcv_encap would have
> returned.
In my last patchset I did it by calling netif_rx at that point,
now I want to add new hooks.
> Also, I thought Yoshifuji-san's objection is not just about
> transport mode packets passing through netif_rx twice, but
> passing through netfilter twice as well?
I think so, but he didn't mention a reason why he objects to it.
I also don't think it can be done otherwise while still keeping
netfilter "just working" for all cases, which IMO is highly
desirable.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
