There are netif_napi_add() and napi_enable() in for_each_possible_cpu
loop in function cvm_oct_rx_initialize(). So it's logical to add
napi_disable() in for_each_possible_cpu loop in function
cvm_oct_rx_shutdown().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Mari
On Sat, Jan 26, 2008 at 10:00:29PM -0800, Andrew Morton wrote:
> > On Thu, 24 Jan 2008 10:50:30 -0600 David Teigland <[EMAIL PROTECTED]> wrote:
> > void dlm_rcom_in(struct dlm_rcom *rc)
> > {
> > struct dlm_header *hd = (struct dlm_header *) rc;
>
> aww, c'mon guys, this is nonsense.
>
>
On Sat, Jan 26, 2008 at 10:00:29PM -0800, Andrew Morton wrote:
> > On Thu, 24 Jan 2008 10:50:30 -0600 David Teigland <[EMAIL PROTECTED]> wrote:
> > void dlm_rcom_in(struct dlm_rcom *rc)
> > {
> > struct dlm_header *hd = (struct dlm_header *) rc;
>
> aww, c'mon guys, this is nonsense.
>
>
> On Thu, 24 Jan 2008 10:50:30 -0600 David Teigland <[EMAIL PROTECTED]> wrote:
> void dlm_rcom_in(struct dlm_rcom *rc)
> {
> struct dlm_header *hd = (struct dlm_header *) rc;
aww, c'mon guys, this is nonsense.
struct dlm_header *hd = &rc->rc_header;
there seems to be rather a lot
From: Fabio M. Di Nitto <[EMAIL PROTECTED]>
DLM_RCOM_LOCK_REPLY messages need byte swapping.
Signed-off-by: Fabio M. Di Nitto <[EMAIL PROTECTED]>
Signed-off-by: David Teigland <[EMAIL PROTECTED]>
---
fs/dlm/util.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/f
From: "Jonas Danielsson" <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 17:28:22 +0100
> Fix arp reply when received arp probe with sender ip 0.
>
> Send arp reply with target ip address 0.0.0.0 and target hardware address
> set to hardware address of requester. Previ
Fix arp reply when received arp probe with sender ip 0.
Send arp reply with target ip address 0.0.0.0 and target hardware address
set to hardware address of requester. Previously sent reply with target
ip address and target hardware address set to same as source fields.
Signed-off-by: Jonas
From: Bill Fink <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 00:16:07 -0500
> On Mon, 19 Nov 2007, Alexey Kuznetsov wrote:
>
> > 2. What's about your suggestion, I thought about this and I am going to
> > agree.
> >
> >Arguments, which convinced me are:
> >
> >- arping still works.
> >
ck
> > that I use will compare the target hardware field of the arp-reply and
> > match it against its own mac, to verify the reply. And this fails with
> > the current implementation in the kernel.
>
> 1. Do not do this. Mainly, because you already know that this does
nd hardware
address of requestor.
But if you use zero protocol address as source, you really can use
any hw address.
> The dhcp clients I examined, and the implementation of the arpcheck
> that I use will compare the target hardware field of the arp-reply and
> match it against its own mac,
Bill Fink wrote, On 11/16/2007 08:26 PM:
...
> Regarding the Target IP, RFC 826 says:
>
> "The target protocol address is necessary in the request form
> of the packet so that a machine can determine whether or not
> to enter the sender information in a tabl
> advertise what is most likely to result in successful communication.
> > >
> > > This is likely why we are changing that target address to the one of
> > > the interface actually sending back the reply rather than the zero
> > > value you used.
> > &g
>>>>> "DM" == David Miller <[EMAIL PROTECTED]> writes:
>> Reply:
>> Opcode: reply (0x0002)
>> Sender HW: 00:AA.00:AA:00:AA
>> Sender IP: 192.168.0.1
>> Target HW: 00:AA:00:AA:00:AA
>> Target IP:192.168.0.1
DM> And thi
> This is likely why we are changing that target address to the one of
> > the interface actually sending back the reply rather than the zero
> > value you used.
> >
> > In fact I think this information can be useful to the sender of
> > the DAD request.
> >
&g
f this, in cases where a choice can be made Linux will
> advertise what is most likely to result in successful communication.
>
> This is likely why we are changing that target address to the one of
> the interface actually sending back the reply rather than the zero
> value you used
model. Both approaches
are valid by RFCs.
Because of this, in cases where a choice can be made Linux will
advertise what is most likely to result in successful communication.
This is likely why we are changing that target address to the one of
the interface actually sending back the reply rather t
target ip address in the reply, it is
the fact that the target hardware address is set to the hardware
address of the machines that is sending the reply.
The target hardware address should be the same as the destination
address in the ethernet frame.
The dhcp clients I examined, and the
Hello!
> Send a correct arp reply instead of one with sender ip and sender
> hardware adress in target fields.
I do not see anything more legal in setting target address to 0.
Actually, semantics of target address in ARP reply is ambiguous.
If it is a reply to some real request, it is
Fix arp reply when received arp probe with sender ip 0.
Can't find any ground in RFC2131 to send a non-valid arp-reply in
the special case of sender ip being set to 0.
- Bug fix for arp handling when sender ip is set to 0.
Send a correct arp reply instead of one with sender ip and s
ion I noticed that my linux
machines responded a bit odd to this arp-request.
The arp-reply had the sender-ip field set to the same as the target-ip
field and the target-hwaddr field the same as the sender-hwaddr field.
All the values where the addresses of the machine replying to the request.
This is
Now icmp_reply is only called by icmp_echo and icmp_timestamp
ip_send_reply is only called by tcp_v4_send_reset and tcp_v4_send_ack
I think in all situations the ip_hdr(skb)->saddr is set and should
be the destination of reply packets.
If using rt->rt_src as destination is correct i
I'm not sure why it's using rt_src here, but there are relevant cases that
your description doesn't cover. For example, what happens if the source
is not set in the original packet? Does NAT affect this?
You quote RFC text for ICMP echo and the case where the receiving machine
is the final desti
re is an example (NOTE: eth0 address is set to 10.10.10.1/24):
#tcpdump -n -i lo icmp &
[1] 3155
...
# hping3 --icmp --spoof 10.10.10.3 10.10.10.1
...
09:53:49.508449 IP 10.10.10.3 > 10.10.10.1: icmp 8: echo request seq 0
09:53:49.508482 IP 10.10.10.1 > 10.10.10.1: icmp 8
;rt_src in the current
code, if this is a wrong fix, please correct me.
Signed-off-by: Lepton Wu <[EMAIL PROTECTED]>
That the address is wrong is your opinion only :-)
Mine too, since an ICMP reply from an unexpected source IP is likely to
be logged as a probe and dropped.
Source address s
Hi,
Sorry for my error.
The problem is the current icmp_reply and ip_send_reply will
send out packets with wrong destination address. Not wrong source
address.
My point is that we should always use the source address of packets we
received as the destination address of our reply packets.
On
;
That the address is wrong is your opinion only :-)
Source address selection is a rather complex topic, and
here we are definitely purposefully using the source
address selected by the routing lookup for the reply.
And, if you do think something is "wrong", you need to describe it
in det
Hi,
sorry for my previous email.
What I mean is icmp_reply and ip_send_reply
in some situation will send out packets with wrong
DESTINATION address. the source address is always
correct.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
need we use a source address diffrent
from ip_hdr(skb)->s_addr?
My situaiton is:
I DNAT some tcp packet to my box. some times the box will
reply reset or ack packet with tcp_v4_send_ack and tcp_v4_reset,
when this happens, it will use the rt->s_addr instead of
ip_hdr(skb)->s_addr, the
off-by: Lepton Wu <[EMAIL PROTECTED]>
>
> That the address is wrong is your opinion only :-)
>
> Source address selection is a rather complex topic, and
> here we are definitely purposefully using the source
> address selected by the routing lookup for the reply.
And, if you do thi
urce
address selected by the routing lookup for the reply.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi,
In some situation, icmp_reply and ip_send_reply will send
out packet with the wrong source addr, the following patch
will fix this.
I don't understand why we must use rt->rt_src in the current
code, if this is a wrong fix, please correct me.
Signed-off-by: Lepton Wu <[EMAIL PROTECTE
iw_cxgb3: Don't abort after failures sending the mpa reply.
This bug results in an abort request being sent down _after_ the tid
has been released. If the tid happens to have been reused, then the
subsequent generation of the tid gets incorrectly aborted.
The thread running iwch_accec
Around a year ago, Chris Lalancette posted a patch to make it so that
when an EXCLUSIVE nfs4 create is done, that the mtime and atime get
properly updated in the following setattr call. At the time Trond
replied that that approach was incorrect and that we need to check the
bitmask in the reply to
How do you send a reply to an email you have deleted?
--
[EMAIL PROTECTED]
--
http://www.fastmail.fm - I mean, what is it about a decent email service?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Good afternoon.
I got your resume from SEEK Australia job-site and it
suites our company requirements.
My name is Roger Longbotham, I represent George Metway
Inc company located in Europe.
Our company is seekeing for a representatives in
Australia for full and part-time jobs.
No relocation is ne
When a lockspace on a remote node is not found for a recovery status
request, an error needs to be returned so the requesting node can
distinguish it from a normal reply with a zero status.
Signed-off-by: David Teigland <[EMAIL PROTECTED]>
Index: linux/drivers/dlm/
On Mon, Apr 04, 2005 at 10:07:30PM +0200, SuD (Alex) wrote:
>
> /* Check for an AC97 1.0 soft modem (ID1) */
> codec->codec_read(codec, AC97_RESET) returned 0xd3a
> ...
>
> /* Check for an AC97 2.x soft modem */ ...
> codec->codec_read(codec, AC97_EXTENDED_MODEM_ID) returned 0x1
Interesting. C
I already tried my own version of the patch with a few printk. I can
tell you that both probe functions in (ac97_codec.c:719) would report
the device as modem.
/* Check for an AC97 1.0 soft modem (ID1) */
codec->codec_read(codec, AC97_RESET) returned 0xd3a
...
/* Check for an AC97 2.x soft mod
Send audit repsonse to socket which request came from, rather than pid
that request came from.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
= kernel/audit.c 1.9 vs edited =
--- 1.9/kernel/audit.c 2005-01-30 22:33:47 -08:00
+++ edited/kernel/audit.c 2005-02-28 18:34:47 -08:00
@@
Thank you for your message. I will be away from Office until 17 January 2005.
For urgent matters, request touch base with my colleague, Ms Anjana Chellani
(Tel no: 24602101-2-3, extn 210; e-mail: [EMAIL PROTECTED]). Happy 2005!.
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
Okay, the sleep situation has not improved. I'll admit that right now.
But it's ABOUT to. G'night...
Rob
On Mon, 8 Jan 2001, Rob Landley wrote:
>
> So fork ramfs already. Copy the snapshot you like as an educational
> tool, call it skeletonfs.c or some such, and let the current code evol
He replied to my bad cc:, so forwarding this here should be okay...
Linus Torvalds wrote:
>
> On Mon, 8 Jan 2001, Rob Landley wrote:
> >
> > So fork ramfs already. Copy the snapshot you like as an educational
> > tool, call it skeletonfs.c or some such, and let the current code evolve
> > into
> Reply ALL also results in 2 mails being sent instead of one but of
> course this is usually not a problem since one is going direct and the
> other is going through vger, but still... it's kind of wasteful to
> resources and i dont see any harm in Reply-to being sen
safemode wrote:
> Reply ALL also results in 2 mails being sent instead of one but of course this is
>usually not a problem since one is going direct and the other is going through vger,
>but still... it's kind of wasteful to
> resources and i dont see any harm in Reply-to
In <[EMAIL PROTECTED]> safemode <[EMAIL PROTECTED]> writes:
[mega snip]
See http://www.unicom.com/pw/reply-to-harmful.html for all of the
good reasons why the vger lists behave just the way they should.
--
Henrik Storner | "Crackers thrive on code secrecy. Cockcroach
601 - 645 of 645 matches
Mail list logo
