* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-08-29 13:30 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46D56C60.3060702@bigtelecom.ru>
On Wed, Aug 29, 2007 at 04:53:52PM +0400, Badalian Vyacheslav wrote:
...
> we have this kernel panic (then delete HTB) at all 2.6.18-x versions.
> on older kernel (2.6.x) we have another panic (then delete tc filter)...
> summary we have TC panics 1 year ago ;) Sysctl option "reboot on panic"
I'm not sure: do you mean it was less often? Did you try to report it
here? (Delete HTB: qdisc or classes?)
> save us. Now we up 2 backup computers and may try any patches to fix
> this problem.
>
> Also on 2.6.22 have strange dead. Black screen, no response to keyboard,
> no info in netconsole, HardDisk led is stable red. "Black Dead"
>
Yes, with all black it could be harder... Maybe 'set -x' at the
beginning (after #!/bin/sh line) of a script could manage to save
something before reboot or send with netconsole (but there could be
a lot of this with a large script...). Netconsole could be troublesome
too. One HTB deadlock problem during similar deleting was fixed in
2.6.23-rc (HTB timer problem) but the log was different. Anyway,
we probably need some more information (and trying).
Jarek P.
^ permalink raw reply
* [PATCH] Use task_pid_nr() in ip_vs_sync.c
From: Pavel Emelyanov @ 2007-08-29 13:30 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Containers, Linux Netdev List, Oleg Nesterov,
Linux Kernel Mailing List
The sync_master_pid and sync_backup_pid are set in set_sync_pid()
and are used later for set/not-set checks and in printk. So it
is safe to use the global pid value in this case.
Signed-off-by: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
---
diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
index 959c08d..d0798a5 100644
--- a/net/ipv4/ipvs/ip_vs_sync.c
+++ b/net/ipv4/ipvs/ip_vs_sync.c
@@ -794,7 +794,7 @@ static int sync_thread(void *startup)
add_wait_queue(&sync_wait, &wait);
- set_sync_pid(state, current->pid);
+ set_sync_pid(state, task_pid_nr(current));
complete(tinfo->startup);
/*
^ permalink raw reply related
* Re: [ofa-general] Re: [PATCH V4 8/10] net/bonding: Handlle wrong assumptions that slave is always an Ethernet device
From: Moni Shoua @ 2007-08-29 13:37 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Moni Shoua, netdev, rdreier, davem, general
In-Reply-To: <416.1188343604@death>
Jay Vosburgh wrote:
> Moni Shoua <monis@voltaire.com> wrote:
>
>> bonding sometimes uses Ethernet constants (such as MTU and address length) which
>> are not good when it enslaves non Ethernet devices (such as InfiniBand).
>>
>> Signed-off-by: Moni Shoua <monis@voltaire.com>
>> ---
>> drivers/net/bonding/bond_main.c | 3 ++-
>> drivers/net/bonding/bond_sysfs.c | 19 +++++++++++++------
>> drivers/net/bonding/bonding.h | 1 +
>> 3 files changed, 16 insertions(+), 7 deletions(-)
>>
>> Index: net-2.6/drivers/net/bonding/bond_main.c
>> ===================================================================
>> --- net-2.6.orig/drivers/net/bonding/bond_main.c 2007-08-15 10:55:48.000000000 +0300
>> +++ net-2.6/drivers/net/bonding/bond_main.c 2007-08-20 14:29:11.911298577 +0300
>> @@ -1224,7 +1224,8 @@ static int bond_compute_features(struct
>> struct slave *slave;
>> struct net_device *bond_dev = bond->dev;
>> unsigned long features = bond_dev->features;
>> - unsigned short max_hard_header_len = ETH_HLEN;
>> + unsigned short max_hard_header_len = max((u16)ETH_HLEN,
>> + bond_dev->hard_header_len);
>
> Since non-IB bonding masters are run through ether_setup, which
> sets hard_header_len to ETH_HLEN, the max() is probably unnecessary, and
> I think this could just be bond_dev->hard_header_len.
>
This is true except for the case where there are no slaves left.
In that case max_hard_header_len has equals to the initialization value.
bond_for_each_slave(bond, slave, i) {
features = netdev_compute_features(features,
slave->dev->features);
if (slave->dev->hard_header_len > max_hard_header_len)
max_hard_header_len = slave->dev->hard_header_len;
}
features |= (bond_dev->features & BOND_VLAN_FEATURES);
bond_dev->features = features;
bond_dev->hard_header_len = max_hard_header_len;
^ permalink raw reply
* Re: pktgen terminating condition
From: jamal @ 2007-08-29 13:46 UTC (permalink / raw)
To: Mandeep Singh Baines
Cc: davem, rick.jones2, msb, netdev, grundler, robert.olsson, venza
In-Reply-To: <20070829044352.GA4133@ludhiana>
On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
> I interpret this to mean that the interrupt gets generates after a packet
> is transferred to the TFIFO on the NIC and the next packet in the ring is
> NULL.
iow, when tx transits to idle ..
> This interrupt gets generates less often then TxOK which gets generated
> after every completed packet transmit. So I'm thinking that maybe the
> driver was written to use this interrupt instead of TxOK for this reason.
> Really just my speculation.
It does make sense if you are trying to cut down on tx interupts. It's a
little extreme - and if you dont have much memory it may not be the best
scheme. OTOH, you have moved to the other extreme imo ;-> You are
generating an interupt per tx packet. This may not matter on modern
hardware because that NIC seems to be Fast Ethernet.
You may wanna heed Dave's advice and just always set the idle on a
per-descriptor basis as well as txcomplete on every Xth packet (4 was
suggested).
Looking at sis900_start_xmit() at the spot where OWN is set
on the descriptor, theres possibly another bit in tx_ring[entry].cmdsts
you may could set that will ask for tx complete; which makes me wonder:
is that "outl(TxENA | inl(ioaddr + cr), ioaddr + cr)" really needed on a
per-packet basis? Should it not be sufficient to turn it on once at
open()?
> Anyway, if I rewrite the driver to use TxOK instead of TxIdle, pktgen
> works fine.
I think its a good thing pktgen caught this; i am unsure however if it
is doing the right thing. Hoping Robert would respond.
One thing pktgen could do is restrict the amount of outstanding buffers
by using accounting the way sockets do - this at least wont stop
progress as it did in your case.
> I'm attaching the patch.
Looks good to me given the desire. I would bounce it by whoever the
maintainer is - they may have some insights on the lazy tx prune habit.
cheers,
jamal
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH V4 10/10] net/bonding: Destroy bonding master when last slave is gone
From: Moni Shoua @ 2007-08-29 14:06 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: rdreier, davem, general, netdev
In-Reply-To: <3403.1188343986@death>
Jay Vosburgh wrote:
> Moni Shoua <monis@voltaire.com> wrote:
>
>> When bonding enslaves non Ethernet devices it takes pointers to functions
>> in the module that owns the slaves. In this case it becomes unsafe
>> to keep the bonding master registered after last slave was unenslaved
>> because we don't know if the pointers are still valid. Destroying the bond when slave_cnt is zero
>> ensures that these functions be used anymore.
>
> Would it not be simpler to run the bonding master through
> ether_setup() again when the final slave is released (to reset all of
> the pointers to their "ethernet" values)? I'm presuming here the
> pointers of questionable validity are the ones set in the
> bond_setup_by_slave() copied from the slave_dev->hard_header, et al.
>
> Having the bonding master disappear (but only sometimes) after
> the last slave is removed is a semantic change I'd rather not introduce
> if it's not necessary.
Thanks for the comments.
Having the master disappear is one way I could think of to solve the problem of leaving
the bonding module with pointers to illegal addresses.
The other way is to increase the usage count, with try_module_get(), of the module which owns of the slave.
To do that I have to restore the field owner in structure net_device (it was removed in 2.6).
Do you prefer the second approach? I wasn't sure about that.
^ permalink raw reply
* Re: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero
From: Vlad Yasevich @ 2007-08-29 15:26 UTC (permalink / raw)
To: Wei Yongjun; +Cc: lksctp-developers, netdev
In-Reply-To: <46D51F91.90101@cn.fujitsu.com>
Wei Yongjun wrote:
> Vlad Yasevich wrote:
>>
>> NACK
>>
>> Section 8.4:
>>
>> An SCTP packet is called an "out of the blue" (OOTB) packet if it is
>> correctly formed (i.e., passed the receiver's CRC32c check; see
>> Section 6.8), but the receiver is not able to identify the
>> association to which this packet belongs.
>>
>>
>> I would argue that the packet is not correctly formed in this case
>> and deserves a protocol violation ABORT in return.
>>
>> -vlad
>>
> As your comment, patch has been changed.
> Patch has been split to two, one is resolve this dead loop problem in
> this mail.
> And the other is come in another mail to discard partial chunk which
> chunk length is set to zero.
I am starting to question the entire OOTB packet handling. There are way
too many function that do almost the same thing and all handle OOTB a little
different.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> --- a/net/sctp/sm_statefuns.c 2007-08-17 06:17:14.000000000 -0400
> +++ b/net/sctp/sm_statefuns.c 2007-08-17 09:57:17.000000000 -0400
> @@ -98,6 +98,7 @@ static sctp_disposition_t sctp_stop_t1_a
> struct sctp_transport *transport);
>
> static sctp_disposition_t sctp_sf_abort_violation(
> + const struct sctp_endpoint *ep,
> const struct sctp_association *asoc,
> void *arg,
> sctp_cmd_seq_t *commands,
> @@ -192,6 +193,11 @@ sctp_disposition_t sctp_sf_do_4_C(const if
> (!sctp_vtag_verify_either(chunk, asoc))
> return sctp_sf_pdiscard(ep, asoc, type, arg, commands);
>
> + /* Make sure that the SHUTDOWN_COMPLETE chunk has a valid length. */
> + if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
> + return sctp_sf_violation_chunklen(ep, asoc, type, arg,
> + commands);
> +
> /* RFC 2960 10.2 SCTP-to-ULP
> *
> * H) SHUTDOWN COMPLETE notification
> @@ -2495,6 +2501,11 @@ sctp_disposition_t sctp_sf_do_9_2_reshut
> struct sctp_chunk *chunk = (struct sctp_chunk *) arg;
> struct sctp_chunk *reply;
>
> + /* Make sure that the INIT chunk has a valid length */
> + if (!sctp_chunk_length_valid(chunk, sizeof(sctp_init_chunk_t)))
> + return sctp_sf_violation_chunklen(ep, asoc, type, arg,
> + commands);
> +
sctp_sf_do_9_2_reshutack() is also called during sctp_sf_do_dupcook_a()
processing, so checking for INIT chunk is wrong. Checking for just the
chunkhdr_t should be enough.
> /* Since we are not going to really process this INIT, there
> * is no point in verifying chunk boundries. Just generate
> * the SHUTDOWN ACK.
> @@ -2938,6 +2949,11 @@ sctp_disposition_t sctp_sf_tabort_8_4_8(
> struct sctp_chunk *chunk = arg;
> struct sctp_chunk *abort;
>
> + /* Make sure that the chunk has a valid length. */
> + if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
> + return sctp_sf_violation_chunklen(ep, asoc, type, arg,
> + commands);
> +
> packet = sctp_ootb_pkt_new(asoc, chunk);
sctp_sf_tabort_8_4_8 is used directly as well (not just through the state
machine). Not sure if the header verification is appropriate.
>
> if (packet) {
> @@ -3185,6 +3201,11 @@ static sctp_disposition_t sctp_sf_shut_8
> struct sctp_chunk *chunk = arg;
> struct sctp_chunk *shut;
>
> + /* Make sure that the SHUTDOWN_ACK chunk has a valid length. */
> + if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
> + return sctp_sf_violation_chunklen(ep, asoc, type, arg,
> + commands);
> +
> packet = sctp_ootb_pkt_new(asoc, chunk);
This is a static function, so any verifications should already have been
done.
>
> if (packet) {
> @@ -3240,6 +3261,13 @@ sctp_disposition_t sctp_sf_do_8_5_1_E_sa
> void *arg,
> sctp_cmd_seq_t *commands)
> {
> + struct sctp_chunk *chunk = arg;
> +
> + /* Make sure that the SHUTDOWN_ACK chunk has a valid length. */
> + if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
> + return sctp_sf_violation_chunklen(ep, asoc, type, arg,
> + commands);
> +
> /* Although we do have an association in this case, it corresponds
> * to a restarted association. So the packet is treated as an OOTB
> * packet and the state function that handles OOTB SHUTDOWN_ACK is
> @@ -3654,6 +3682,16 @@ sctp_disposition_t sctp_sf_discard_chunk
> void *arg,
> sctp_cmd_seq_t *commands)
> {
> + struct sctp_chunk *chunk = arg;
> +
> + /* Make sure that the chunk has a valid length.
> + * Since we don't know the chunk type, we use a general
> + * chunkhdr structure to make a comparison.
> + */
> + if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
> + return sctp_sf_violation_chunklen(ep, asoc, type, arg,
> + commands);
> +
> SCTP_DEBUG_PRINTK("Chunk %d is discarded\n", type.chunk);
> return SCTP_DISPOSITION_DISCARD;
> }
> @@ -3709,6 +3747,13 @@ sctp_disposition_t sctp_sf_violation(con
> void *arg,
> sctp_cmd_seq_t *commands)
> {
> + struct sctp_chunk *chunk = arg;
> +
> + /* Make sure that the chunk has a valid length. */
> + if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
> + return sctp_sf_violation_chunklen(ep, asoc, type, arg,
> + commands);
> +
> return SCTP_DISPOSITION_VIOLATION;
> }
>
> @@ -3716,12 +3761,14 @@ sctp_disposition_t sctp_sf_violation(con
> * Common function to handle a protocol violation.
> */
> static sctp_disposition_t sctp_sf_abort_violation(
> + const struct sctp_endpoint *ep,
> const struct sctp_association *asoc,
> void *arg,
> sctp_cmd_seq_t *commands,
> const __u8 *payload,
> const size_t paylen)
> {
> + struct sctp_packet *packet = NULL;
> struct sctp_chunk *chunk = arg;
> struct sctp_chunk *abort = NULL;
>
> @@ -3730,22 +3777,41 @@ static sctp_disposition_t sctp_sf_abort_
> if (!abort)
> goto nomem;
>
> - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
> - SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
> + if (asoc) {
> + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
> + SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
>
> - if (asoc->state <= SCTP_STATE_COOKIE_ECHOED) {
> - sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP,
> - SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
> - sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> - SCTP_ERROR(ECONNREFUSED));
> - sctp_add_cmd_sf(commands, SCTP_CMD_INIT_FAILED,
> - SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> + if (asoc->state <= SCTP_STATE_COOKIE_ECHOED) {
> + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP,
> + SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
> + sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> + SCTP_ERROR(ECONNREFUSED));
> + sctp_add_cmd_sf(commands, SCTP_CMD_INIT_FAILED,
> + SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> + } else {
> + sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> + SCTP_ERROR(ECONNABORTED));
> + sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
> + SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> + SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
> + }
> } else {
> - sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> - SCTP_ERROR(ECONNABORTED));
> - sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
> - SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> - SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
> + packet = sctp_ootb_pkt_new(asoc, chunk);
> +
> + if (!packet)
> + goto nomem;
> +
> + if (sctp_test_T_bit(abort))
> + packet->vtag = ntohl(chunk->sctp_hdr->vtag);
> +
> + abort->skb->sk = ep->base.sk;
> +
> + sctp_packet_append_chunk(packet, abort);
> +
> + sctp_add_cmd_sf(commands, SCTP_CMD_SEND_PKT, +
> SCTP_PACKET(packet));
> +
> + SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
> }
>
> sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET, SCTP_NULL());
> @@ -3786,7 +3852,7 @@ static sctp_disposition_t sctp_sf_violat
> {
> char err_str[]="The following chunk had invalid length:";
>
> - return sctp_sf_abort_violation(asoc, arg, commands, err_str,
> + return sctp_sf_abort_violation(ep, asoc, arg, commands, err_str,
> sizeof(err_str));
> }
>
> @@ -3805,7 +3871,7 @@ static sctp_disposition_t sctp_sf_violat
> {
> char err_str[]="The cumulative tsn ack beyond the max tsn currently
> sent:";
>
> - return sctp_sf_abort_violation(asoc, arg, commands, err_str,
> + return sctp_sf_abort_violation(ep, asoc, arg, commands, err_str,
> sizeof(err_str));
> }
>
>
>
^ permalink raw reply
* Re: [3/4] 2.6.23-rc4: known regressions
From: Michal Piotrowski @ 2007-08-29 15:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, LKML, linux-fsdevel, nfs, Trond Myklebust,
Andrew Clayton, kbuild-devel, Roman Zippel, Sam Ravnborg,
Hugh Dickins, Netdev, Shish, Karl Meyer, Francois Romieu,
linux-wireless, Christian Casteyde, Martin Langer, Stefano Brivio,
Michael Buesch, Danny van Dyk, Andreas Jaggi
In-Reply-To: <46D58CC6.4020605@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.23-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 9
Andi Kleen 5
Linus Torvalds 5
Andrew Morton 4
Hugh Dickins 4
Al Viro 3
Alan Stern 3
Cornelia Huck 3
Jens Axboe 3
Tejun Heo 3
FS
Subject : [NFSD OOPS] 2.6.23-rc1-git10
References : http://lkml.org/lkml/2007/8/2/462
Last known good : ?
Submitter : Andrew Clayton <andrew@digital-domain.net>
Caused-By : ?
Handled-By : ?
Status : unknown
Kconfig
Subject : CONFIG_HOTPLUG_CPU: kconfig bug?
References : http://lkml.org/lkml/2007/8/27/204
Last known good : ?
Submitter : Hugh Dickins <hugh@veritas.com>
Caused-By : ?
Handled-By : Sam Ravnborg <sam@ravnborg.org>
Status : problem is being debugged
Networking
Subject : System freeze when restarting network connection with Broadcom driver
References : http://bugzilla.kernel.org/show_bug.cgi?id=8934
Last known good : ?
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Caused-By : ?
Handled-By : ?
Status : problem is being debugged
Subject : NETDEV WATCHDOG: eth0: transmit timed out
References : http://lkml.org/lkml/2007/8/13/737
Last known good : ?
Submitter : Karl Meyer <adhocrocker@gmail.com>
Caused-By : ?
Handled-By : Francois Romieu <romieu@fr.zoreil.com>
Status : problem is being debugged
Subject : Weird network problems with 2.6.23-rc2
References : http://lkml.org/lkml/2007/8/11/40
Last known good : ?
Submitter : Shish <shish@shishnet.org>
Caused-By : ?
Handled-By : ?
Status : unknown
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: [2/2] 2.6.23-rc3: known regressions with patches
From: Michal Piotrowski @ 2007-08-29 15:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, LKML, linux-fsdevel, nfs, Trond Myklebust,
Florin Iucha, Bret Towe, Harry Edmon, Pierre Ossman,
Christian Casteyde, Alan Stern, linux-mtd, David Woodhouse,
Ingo Molnar, Netdev, Stephen Hemminger, Florian Lohoff, Daniel K.
In-Reply-To: <46D58F89.4010108@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.23-rc4
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 9
Andi Kleen 5
Linus Torvalds 5
Andrew Morton 4
Hugh Dickins 4
Al Viro 3
Alan Stern 3
Cornelia Huck 3
Jens Axboe 3
Tejun Heo 3
FS
Subject : NFSv4 client OOPS
References : http://lkml.org/lkml/2007/8/28/207
Last known good : ?
Submitter : Harry Edmon <harry@atmos.washington.edu>
Caused-By : ?
Handled-By : Trond Myklebust <Trond.Myklebust@netapp.com>
Patch : http://lkml.org/lkml/2007/8/28/204
Status : patch available
Subject : nfs4 hang/NFS woes again
(was USB-related oops in sysfs with linux v2.6.23-rc3-50-g28e8351)
References : http://lkml.org/lkml/2007/8/15/144
http://lkml.org/lkml/2007/8/22/484
http://lkml.org/lkml/2007/8/23/134
Last known good : ?
Submitter : Florin Iucha <florin@iucha.net>
Bret Towe <magnade@gmail.com>
Caused-By : Trond Myklebust <Trond.Myklebust@netapp.com>
commit 3d39c691ff486142dd9aaeac12f553f4476b7a62
Handled-By : Trond Myklebust <Trond.Myklebust@netapp.com>
Patch : http://lkml.org/lkml/2007/8/28/119
Status : patch available
MMC
Subject : Unable to access memory card reader anymore
References : http://bugzilla.kernel.org/show_bug.cgi?id=8885
Last known good : ?
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Caused-By : ?
Handled-By : Alan Stern <stern@rowland.harvard.edu>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=12438
Status : patch available
MTD
Subject : error: implicit declaration of function 'cfi_interleave'
References : http://lkml.org/lkml/2007/8/6/272
Last known good : ?
Submitter : Ingo Molnar <mingo@elte.hu>
Caused-By : ?
Handled-By : David Woodhouse <dwmw2@infradead.org>
Patch : http://lkml.org/lkml/2007/8/9/586
Status : patch available
Networking
Subject : BUG: when using 'brctl stp'
References : http://lkml.org/lkml/2007/8/10/441
Last known good : 2.6.23-rc1
Submitter : Daniel K. <daniel@cluded.net>
Caused-By : ?
Handled-By : Stephen Hemminger <shemminger@osdl.org>
Status : fix applied by David Miller
Subject : sky2 boot crash in sky2_mac_intr
References : http://lkml.org/lkml/2007/7/24/91
Last known good : ?
Submitter : Florian Lohoff <flo@rfc822.org>
Caused-By :
Handled-By : Stephen Hemminger <shemminger@osdl.org>
Patch : http://marc.info/?l=linux-netdev&m=118651402523966&w=2
Status : patch available
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: Linksys Gigabit USB2.0 adapter (asix) regression
From: Erik Slagter @ 2007-08-29 15:56 UTC (permalink / raw)
To: David Hollis; +Cc: netdev
In-Reply-To: <1187729323.2879.32.camel@dhollis-lnx.sunera.com>
Never mind, I plugged the adapter into a windows machine once more
(another one) and now it acts exactly like it's plugged into my linux
laptop, so I guess it's actually broken. I will send it back for repair.
Thanks for your effort and I apologise for being a pain ;-)
^ permalink raw reply
* Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
From: Rick Jones @ 2007-08-29 16:16 UTC (permalink / raw)
To: OBATA Noboru; +Cc: davem, shemminger, yoshfuji, netdev
In-Reply-To: <20070829.212613.65744831.noboru.obata.ar@hitachi.com>
OBATA Noboru wrote:
> What about another option to let TCP have a notification?
>
> Can it be a solution if it is standardized?
It would at best be a partial solution which would only work when the
link failover/whatnot happened on the same system/node as the TCP
endpoint. Then it can be some sort of call-back to TCP or the like.
If this failover is out in the middle of the cloud the only way to get a
notification back to TCP would be by sending it a packet of some sort
and I don't see that happening.
rick jones
^ permalink raw reply
* Re: malformed captured packets
From: Toralf Förster @ 2007-08-29 16:22 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <46D521BC.1050300@katalix.com>
[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]
Am Mittwoch, 29. August 2007 schrieb James Chapman:
> Can you provide more information about the problem, please? Are you
> using a simple DSL modem with PPPoE, such that the ppp0 interface is
> that of the pppd started by a local PPPoE server? Is this a problem only
> with packet capture or are you seeing actual data corruption? Did this
> work with previous kernels? What is the network topology related to the
> DSL interface?
>
I use a ThinkPad T41 with this Ethernet controller:
n22 ~ # lspci | grep Eth
02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
My DSL provider is Alice DSL (formerly Hansenet) in Hamburg. The T41 is connected
with an Ethernet cable to a Siemens DSL modem. The modem (just a modem, not a
router) itself is connected to the DSL splitter which itself is plugged into socket.
The current ppp version I'm using is net-dialup/ppp-2.4.4-r9
Here are my kernel config settings:
n22 ~ # zgrep PPP /proc/config.gz
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
# CONFIG_PPP_ASYNC is not set
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=m
I observed this problem since a long time with different kernel versions (Gentoo,
plain vanilla kernel, git sources) while playing with ethereal - currently known
as wireshark.
I'm wondering b/c for kscd eg. it is always the IP packet containing the content
information of a CD (or even a <CD is unknown> message) with is struggled.
This packets prevents me from using the "Follow TCP Strem" feature of wireshark
for an easy look into the plain text of all TCP packets of this HTTP stream
(which was in fact the trigger for me to have a deeper look into the sniffed
stream from ppp0 and eth0).
For other apps I observed similar things which cannot fully be explained by
terms like "TCP checksum offloading".
I didn't observed any malfunction at application level so it might be an issue
with the capturing itself.
Why is the ppp stream always ok in opposite to the eth0 stream ?
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pktgen terminating condition
From: Grant Grundler @ 2007-08-29 16:26 UTC (permalink / raw)
To: Mandeep Baines
Cc: David Miller, hadi, rick.jones2, msb, netdev, robert.olsson,
venza
In-Reply-To: <535ddc6b0708290914k21d0b71fs21ea3b96c6fd7f4d@mail.gmail.com>
On 8/29/07, Mandeep Baines <mandeep.baines@gmail.com> wrote:
...
> Unfortunately, the TxIdle interrupt would not free the last odd packet.
> However, if we want to quiet interrupts couldn't the driver just be
> converted NAPI. If this seems reasonable I could work on a patch.
It seems reasonable and that's what I was thinking when you
submitted the patch to use TXOk.
I think NAPI could be used with either TxOK or TxIdle interrupts.
For TxIdle to work, the driver would have to recognize one more
packet is still in flight and poll for completion of that packet - then
re-enable interrupts and switch back to interrupt mode of operation.
I just don't know if netperf TCP_RR perf numbers will suffer
(assuming TCP_RR is more important than CPU utilization/efficiency
on heavy TX loads like pktgen.)
grant
^ permalink raw reply
* Re: pktgen terminating condition
From: Robert Olsson @ 2007-08-29 16:32 UTC (permalink / raw)
To: hadi
Cc: Mandeep Singh Baines, davem, rick.jones2, msb, netdev, grundler,
robert.olsson, venza
In-Reply-To: <1188395183.4274.19.camel@localhost>
jamal writes:
> On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
> I think its a good thing pktgen caught this; i am unsure however if it
> is doing the right thing. Hoping Robert would respond.
> One thing pktgen could do is restrict the amount of outstanding buffers
> by using accounting the way sockets do - this at least wont stop
> progress as it did in your case.
Hello,
Yes it's synchronization issue... the test is over and we have sent
all pkts to the device but pktgen cannot free the skb for it still
has refcounts.
IMO must drivers have provisions to handle situation like. I'll
guess we can discuss last-resort timer if it should be us, ms
or possibly seconds but shouldn't need ping to make this happen.
If so we probably have a ICMP packet sitting there waiting instead.
Cheers
--ro
^ permalink raw reply
* RE: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
From: Waskiewicz Jr, Peter P @ 2007-08-29 16:43 UTC (permalink / raw)
To: David Miller, krkumar2
Cc: gaagaan, general, hadi, herbert, jagana, jeff, johnpol, kaber,
kumarkr, mcarlson, mchan, netdev, netdev-owner, rdreier,
rick.jones2, Robert.Olsson, shemminger, sri, tgraf, xma
In-Reply-To: <20070828.221448.123919361.davem@davemloft.net>
> From: Krishna Kumar2 <krkumar2@in.ibm.com>
> Date: Wed, 29 Aug 2007 10:43:23 +0530
>
> > The reason was to run parallel copies, not for buffer limitations.
>
> Oh, I see.
>
> I'll note in passing that current lmbench-3 has some
> parallelization features you could play with, you might want
> to check it out.
I've also used iperf for parallel connections successfully, and that
will allow you to mess with the buffer sizes as well along with other
variables of the data streams for both TCP and UDP.
Cheers,
-PJ
^ permalink raw reply
* [patch 1/1][RFC] add a private field to the sock structure
From: dlezcano @ 2007-08-29 16:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <20070829164114.868188182@f002726.toulouse-stg.fr.ibm.com>
[-- Attachment #1: sock-private-data.patch --]
[-- Type: text/plain, Size: 2443 bytes --]
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Store private information for a socket
This patch adds a field to the common socket structure. This field
is a anonymous pointer which allow to store an information about
the socket
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
include/net/inet_timewait_sock.h | 1 +
include/net/sock.h | 3 +++
net/ipv4/inet_timewait_sock.c | 1 +
3 files changed, 5 insertions(+)
Index: net-2.6.24-bf/include/net/sock.h
===================================================================
--- net-2.6.24-bf.orig/include/net/sock.h
+++ net-2.6.24-bf/include/net/sock.h
@@ -106,6 +106,7 @@
* @skc_refcnt: reference count
* @skc_hash: hash value used with various protocol lookup tables
* @skc_prot: protocol handlers inside a network family
+ * @skc_private: field used to store private data
*
* This is the minimal network layer representation of sockets, the header
* for struct sock and struct inet_timewait_sock.
@@ -120,6 +121,7 @@
atomic_t skc_refcnt;
unsigned int skc_hash;
struct proto *skc_prot;
+ void *skc_private;
};
/**
@@ -196,6 +198,7 @@
#define sk_refcnt __sk_common.skc_refcnt
#define sk_hash __sk_common.skc_hash
#define sk_prot __sk_common.skc_prot
+#define sk_private __sk_common.skc_private
unsigned char sk_shutdown : 2,
sk_no_check : 2,
sk_userlocks : 4;
Index: net-2.6.24-bf/net/ipv4/inet_timewait_sock.c
===================================================================
--- net-2.6.24-bf.orig/net/ipv4/inet_timewait_sock.c
+++ net-2.6.24-bf/net/ipv4/inet_timewait_sock.c
@@ -108,6 +108,7 @@
tw->tw_hash = sk->sk_hash;
tw->tw_ipv6only = 0;
tw->tw_prot = sk->sk_prot_creator;
+ tw->tw_private = sk->sk_private;
atomic_set(&tw->tw_refcnt, 1);
inet_twsk_dead_node_init(tw);
__module_get(tw->tw_prot->owner);
Index: net-2.6.24-bf/include/net/inet_timewait_sock.h
===================================================================
--- net-2.6.24-bf.orig/include/net/inet_timewait_sock.h
+++ net-2.6.24-bf/include/net/inet_timewait_sock.h
@@ -115,6 +115,7 @@
#define tw_refcnt __tw_common.skc_refcnt
#define tw_hash __tw_common.skc_hash
#define tw_prot __tw_common.skc_prot
+#define tw_private __tw_common.skc_private
volatile unsigned char tw_substate;
/* 3 bits hole, try to pack */
unsigned char tw_rcv_wscale;
--
^ permalink raw reply
* [patch 0/1][RFC] add a private field to the sock structure
From: dlezcano @ 2007-08-29 16:41 UTC (permalink / raw)
To: netdev
When a socket is created it is sometime useful to store a specific information
for this socket.
This information can be for examples:
* a creation time
* a pid
* a uid/gid
* a container identifier
* a pointer to a more specific structure
* ...
The following patch is a proposition to add a private anonymous pointer
field to the common part of the sock structure.
--
^ permalink raw reply
* Re: pktgen terminating condition
From: Mandeep Baines @ 2007-08-29 16:59 UTC (permalink / raw)
To: hadi
Cc: davem, rick.jones2, msb, netdev, grundler, robert.olsson, venza,
jeff, nhorman
In-Reply-To: <1188395183.4274.19.camel@localhost>
On 8/29/07, jamal <hadi@cyberus.ca> wrote:
> On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
>
> > I interpret this to mean that the interrupt gets generates after a packet
> > is transferred to the TFIFO on the NIC and the next packet in the ring is
> > NULL.
>
> iow, when tx transits to idle ..
>
> > This interrupt gets generates less often then TxOK which gets generated
> > after every completed packet transmit. So I'm thinking that maybe the
> > driver was written to use this interrupt instead of TxOK for this reason.
> > Really just my speculation.
>
> It does make sense if you are trying to cut down on tx interupts. It's a
> little extreme - and if you dont have much memory it may not be the best
> scheme. OTOH, you have moved to the other extreme imo ;-> You are
> generating an interupt per tx packet. This may not matter on modern
> hardware because that NIC seems to be Fast Ethernet.
> You may wanna heed Dave's advice and just always set the idle on a
> per-descriptor basis as well as txcomplete on every Xth packet (4 was
> suggested).
My hardware at home is not so modern:( I'm running a AMD Geode NX1750.
I like to punish myself:) Actually, it does the job and is very power
efficient.
Agreed, interrupting every packet is inefficient. A better solution is
probably NAPI. I'll work on a new patch.
> Looking at sis900_start_xmit() at the spot where OWN is set
> on the descriptor, theres possibly another bit in tx_ring[entry].cmdsts
> you may could set that will ask for tx complete; which makes me wonder:
> is that "outl(TxENA | inl(ioaddr + cr), ioaddr + cr)" really needed on a
> per-packet basis? Should it not be sufficient to turn it on once at
> open()?
>
You have to set this bit to restart the Tx State Machine. You could
optimize this if you use the TxIdle interrupt to tell you when you
really need to set this bit.
> > Anyway, if I rewrite the driver to use TxOK instead of TxIdle, pktgen
> > works fine.
>
> I think its a good thing pktgen caught this; i am unsure however if it
> is doing the right thing. Hoping Robert would respond.
> One thing pktgen could do is restrict the amount of outstanding buffers
> by using accounting the way sockets do - this at least wont stop
> progress as it did in your case.
>
> > I'm attaching the patch.
>
> Looks good to me given the desire. I would bounce it by whoever the
> maintainer is - they may have some insights on the lazy tx prune habit.
>
+ nhorman@tuxdriver.com
+ jeff@garzik.org
I'll work on a NAPI patch.
Regards,
Mandeep
^ permalink raw reply
* Re: [PATCH 4/5] Net: ath5k, license is GPLv2
From: Valdis.Kletnieks @ 2007-08-29 17:29 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jiri Slaby, linville, linux-kernel, linux-wireless, netdev
In-Reply-To: <20070828171155.GC29343@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
On Tue, 28 Aug 2007 18:11:55 BST, Christoph Hellwig said:
> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
> > ath5k, license is GPLv2
> >
> > The files are available only under GPLv2 since now.
>
> Is this really a good idea? Most of the reverse-engineering was
> done by the OpenBSD folks, and it would certainly be helpful to
> work together with them on new hardware revisions, etc..
The heck with "good idea" - it's unclear to me if Jiri is even *allowed*
to remove the BSD/other license. Jiri can release *his* code as GPLv2
only, but I suspect the files as a whole really should be dual BSD/GPLv2,
due to the numerous other stakeholders in those files.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
From: Michael Buesch @ 2007-08-29 17:46 UTC (permalink / raw)
To: David Miller; +Cc: joe, johannes, netdev
In-Reply-To: <20070828.155419.74563234.davem@davemloft.net>
On Wednesday 29 August 2007 00:54:19 David Miller wrote:
> From: Michael Buesch <mb@bu3sch.de>
> Date: Tue, 28 Aug 2007 16:48:44 +0200
>
> > On Monday 27 August 2007 23:11:50 David Miller wrote:
> > > From: Joe Perches <joe@perches.com>
> > > Date: Mon, 27 Aug 2007 13:57:42 -0700
> > >
> > > > On Mon, 2007-08-27 at 13:41 -0700, David Miller wrote:
> > > > > From: Johannes Berg <johannes@sipsolutions.net>
> > > > > Date: Mon, 27 Aug 2007 12:54:09 +0200
> > > > > > #define MAC_FMT "%s"
> > > > > > #define MAC_ARG(a) ({char __buf[18]; print_mac(a, __buf); __buf;})
> > > >
> > > > > I don't think this works.
> > > >
> > > > $ cat test_fmt.c
> > > > #include <stdio.h>
> > > > #include <stdlib.h>
> > >
> > > You're just getting lucky in this test case.
> > >
> > > The language does not allow what you are doing, so you're
> > > playing with fire.
> >
> > What exactly to you think it invalid in this code?
> > I think it's fine (except that I'd chose an u8* for the mac
> > address (first arg in print_mac()).
>
> The __buf[] is used out of scope, therefore it's stack space is
> fair game for the compiler to reuse.
>
> When the compiler sees:
>
> printk(FMT, ({ char __buf[x]; print_mac(a, __buf); __buf;}));
>
> It first all of the printk() argument expressions, first FMT and
> then it evaluates the ({ ... }) argument.
>
> Now that the ({ ... }) expression is done, __buf[] is out of
> scope and illegal to reference.
>
> printk() is now called, with a pointer to an out-of-scope buffer.
> This is illegal.
>
> I don't know how else to explain this to you, I can learn how to
> describe the issue in German if this would help :-)
Oh, not needed. I see the bug and indeed, this is a ticking
timebomb.
I don't use the ({}) notation a lot, so I didn't see this here.
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH 2.6.23 0/2] cxgb3 - Fix dev->priv usage
From: Divy Le Ray @ 2007-08-29 17:53 UTC (permalink / raw)
To: Roland Dreier; +Cc: Jeff Garzik, netdev, linux-kernel, Steve Wise
In-Reply-To: <ada3ay26gys.fsf@cisco.com>
Roland Dreier wrote:
>
> Looks OK to me but I would just roll up the second patch into the
> first patch and let Jeff merge it as one commit. There's no point in
> creating an intermediate tree that doesn't build -- it just breaks git
> bisect for no useful purpose.
>
Okay, Jeff agrees too, I'll do so.
> Also as a side note, when trying to test this I got the message
>
> could not load TP SRAM: unable to load t3a_protocol_sram-1.0.44.bin
>
> and you guys seem to only have t3b protocol sram images on your web
> site. Could you send me the t3a file (or swap out my T3A boards for
> T3B boards ;)?
>
I'd rather fix the driver then:
First, HW folks tell me that there is no need for engine
microcode update for T3A.
Moreover, there is a bug when the file name is constructed.
We have T3B and T3B2 board revs, the driver looks for
t3b_protocol_sram-1.0.44.bin for T3B2 boards and defaults to
t3a_protocol_sram-1.0.44.bin even for T3B boards.
I submitted a patch fixing this in netdev#upstream.
I should propose the fix for 2.6.23 instead.
Cheers,
Divy
^ permalink raw reply
* Re: [PATCH 4/5] Net: ath5k, license is GPLv2
From: Jon Smirl @ 2007-08-29 18:01 UTC (permalink / raw)
To: Valdis.Kletnieks@vt.edu
Cc: Christoph Hellwig, Jiri Slaby, linville, linux-kernel,
linux-wireless, netdev
In-Reply-To: <3208.1188408545@turing-police.cc.vt.edu>
On 8/29/07, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> The heck with "good idea" - it's unclear to me if Jiri is even *allowed*
> to remove the BSD/other license. Jiri can release *his* code as GPLv2
> only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> due to the numerous other stakeholders in those files.
This mess has been occurring in the kernel for years. The DRM graphics
drivers are used in both BSD and Linux. It is quite easy to contribute
something to this code via LKML and think you are doing it under the
GPL. Doesn't a patch against the kernel have to be GPL? When these
patches get pulled back into BSD and distributed with it, did BSD get
infected with the GPL? AFAIK this has never been legally sorted out.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [patch 1/1][RFC] add a private field to the sock structure
From: Christoph Hellwig @ 2007-08-29 18:09 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <20070829164714.637053362@f002726.toulouse-stg.fr.ibm.com>
On Wed, Aug 29, 2007 at 06:41:15PM +0200, dlezcano@fr.ibm.com wrote:
> From: Daniel Lezcano <dlezcano@fr.ibm.com>
>
> Store private information for a socket
>
> This patch adds a field to the common socket structure. This field
> is a anonymous pointer which allow to store an information about
> the socket
If you have orivtae information it should have a typed pointer to it.
Please also post the patches actually using this field.
^ permalink raw reply
* Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
From: David Miller @ 2007-08-29 18:15 UTC (permalink / raw)
To: noboru.obata.ar; +Cc: shemminger, yoshfuji, netdev
In-Reply-To: <20070829.212613.65744831.noboru.obata.ar@hitachi.com>
From: OBATA Noboru <noboru.obata.ar@hitachi.com>
Date: Wed, 29 Aug 2007 21:26:13 +0900 (JST)
> From: David Miller <davem@davemloft.net>
> Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
> Date: Tue, 28 Aug 2007 13:30:57 -0700 (PDT)
>
> > From: OBATA Noboru <noboru.obata.ar@hitachi.com>
> > Date: Tue, 28 Aug 2007 22:04:47 +0900 (JST)
> >
> > > (1) Make the application timeouts longer. (Steve has shown that
> > > making an application timeouts twice the failover detection
> > > timeout would be a solution.)
> >
> > This is the only feasible solution to your problem.
>
> What about another option to let TCP have a notification?
No.
^ permalink raw reply
* Re: [PATCH 4/5] Net: ath5k, license is GPLv2
From: Alan Cox @ 2007-08-29 18:28 UTC (permalink / raw)
To: Jon Smirl
Cc: Valdis.Kletnieks@vt.edu, Christoph Hellwig, Jiri Slaby, linville,
linux-kernel, linux-wireless, netdev
In-Reply-To: <9e4733910708291101i3783a8b1l38f0d5cfb0c2863d@mail.gmail.com>
> > to remove the BSD/other license. Jiri can release *his* code as GPLv2
> > only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> > due to the numerous other stakeholders in those files.
>
> This mess has been occurring in the kernel for years. The DRM graphics
> drivers are used in both BSD and Linux. It is quite easy to contribute
> something to this code via LKML and think you are doing it under the
> GPL. Doesn't a patch against the kernel have to be GPL? When these
> patches get pulled back into BSD and distributed with it, did BSD get
> infected with the GPL? AFAIK this has never been legally sorted out.
I'm not aware anyone has felt it needed "sorting out". Its not exactly
complicated.
BSD non advertising is compatible with GPL
The GPL says:
"when you distribute the same sections as part of a whole which
is a work based on the Program, the distribution of the whole
must be on the terms of this License, "
The BSD license doesn't conflict with that
The GPL (and copyright law also say)
"If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to ..."
All a bit irrelevant anyway as Ath5K code (not the .h file) say:
* Alternatively, this software may be distributed under the terms of the
* GNU General Public License ("GPL") version 2 as published by the Free
* Software Foundation.
So Jiri is choosing to distribute it under the GPL, and with his changes
GPL only.
So whats the problem ?
^ permalink raw reply
* Re: [patch 0/1][RFC] add a private field to the sock structure
From: David Miller @ 2007-08-29 18:23 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <20070829164114.868188182@f002726.toulouse-stg.fr.ibm.com>
From: dlezcano@fr.ibm.com
Date: Wed, 29 Aug 2007 18:41:14 +0200
> When a socket is created it is sometime useful to store a specific information
> for this socket.
>
> This information can be for examples:
> * a creation time
> * a pid
> * a uid/gid
> * a container identifier
> * a pointer to a more specific structure
> * ...
>
> The following patch is a proposition to add a private anonymous pointer
> field to the common part of the sock structure.
We got rid of the private field a long time ago because not only
is it not needed, it tends to get abused.
Find another way to implement your feature.
^ 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