Commit-ID: e9024d519d892b38176cafd46f68a7c77412
Gitweb: https://git.kernel.org/tip/e9024d519d892b38176cafd46f68a7c77412
Author: David S. Miller
AuthorDate: Tue, 30 Oct 2018 12:12:26 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 31 Oct 2018 09:57:51 -0300
perf
Commit-ID: e9024d519d892b38176cafd46f68a7c77412
Gitweb: https://git.kernel.org/tip/e9024d519d892b38176cafd46f68a7c77412
Author: David S. Miller
AuthorDate: Tue, 30 Oct 2018 12:12:26 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 31 Oct 2018 09:57:51 -0300
perf
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 8 Sep 2005 14:22:37 -0700 (PDT)
> On Thu, 8 Sep 2005, David S. Miller wrote:
> >
> > Ok, I'll revert the patch and fix the sunsab.c driver as
> > Russell indicated. So much for type checking...
>
> Actual
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 8 Sep 2005 13:39:35 -0700 (PDT)
> So it's certainly a valid optimization to know that the arguments aren't
> even evaluated, and thus it's sometimes really wrong to change a macro
> into an inline function.
Ok, I'll revert the patch and fix the
From: Russell King <[EMAIL PROTECTED]>
Date: Thu, 8 Sep 2005 21:22:36 +0100
> the "regs" argument may not exist in the parent context in the
> !SUPPORT_SYSRQ case.
Then pass in a NULL in the ARM serial drivers instead of this ugly
dependency upon the macro not using the argument.
-
To
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 8 Sep 2005 09:27:56 -0700 (PDT)
> Mistakes happen, and the way you fix them is not to pull a tantrum, but
> tell people that they are idiots and they broke something, and get them to
> fix it instead.
In all this noise I still haven't seen
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 8 Sep 2005 09:27:56 -0700 (PDT)
Mistakes happen, and the way you fix them is not to pull a tantrum, but
tell people that they are idiots and they broke something, and get them to
fix it instead.
In all this noise I still haven't seen what is
From: Russell King [EMAIL PROTECTED]
Date: Thu, 8 Sep 2005 21:22:36 +0100
the regs argument may not exist in the parent context in the
!SUPPORT_SYSRQ case.
Then pass in a NULL in the ARM serial drivers instead of this ugly
dependency upon the macro not using the argument.
-
To unsubscribe from
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 8 Sep 2005 13:39:35 -0700 (PDT)
So it's certainly a valid optimization to know that the arguments aren't
even evaluated, and thus it's sometimes really wrong to change a macro
into an inline function.
Ok, I'll revert the patch and fix the
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 8 Sep 2005 14:22:37 -0700 (PDT)
On Thu, 8 Sep 2005, David S. Miller wrote:
Ok, I'll revert the patch and fix the sunsab.c driver as
Russell indicated. So much for type checking...
Actually, I think there's a simpler fix. Instead
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Wed, 7 Sep 2005 15:39:08 +0200
> Jeff Garzik wrote:
> > I find them useful in my own drivers; they are definitely not pure noise.
>
> gcc -finstrument-functions
I was going to mention this as well, and also the idea to
enable CONFIG_MCOUNT on a
From: Ingo Oeser [EMAIL PROTECTED]
Date: Wed, 7 Sep 2005 15:39:08 +0200
Jeff Garzik wrote:
I find them useful in my own drivers; they are definitely not pure noise.
gcc -finstrument-functions
I was going to mention this as well, and also the idea to
enable CONFIG_MCOUNT on a per-file
From: Esben Nielsen <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 20:56:40 +0200 (METDST)
> Andrew and David: I CC'ed you guyes because you took care of it the last
> time :-)
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 07 Sep 2005 01:42:48 +0200
> The only other user of proto_list besides proto_register, which
> doesn't care, are the seqfs functions. They use the slab pointer,
> but in a harmless way:
>
> proto->slab == NULL ? "no" :
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 07 Sep 2005 01:02:01 +0200
> You're right, good catch. This patch fixes it by moving the lock
> down to the list-operation which it is supposed to protect.
I think we need to unlink from the list first if you're
going to do it this way.
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 22:23:50 +0200
> I don't think the functionality of having single copies in case
> an out of line version was needed was ever required by the Linux kernel.
Alpha does, exactly for the kind of case this gcc inlining feature was
designed
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 22:23:50 +0200
I don't think the functionality of having single copies in case
an out of line version was needed was ever required by the Linux kernel.
Alpha does, exactly for the kind of case this gcc inlining feature was
designed for.
From: Patrick McHardy [EMAIL PROTECTED]
Date: Wed, 07 Sep 2005 01:02:01 +0200
You're right, good catch. This patch fixes it by moving the lock
down to the list-operation which it is supposed to protect.
I think we need to unlink from the list first if you're
going to do it this way. Otherwise
From: Patrick McHardy [EMAIL PROTECTED]
Date: Wed, 07 Sep 2005 01:42:48 +0200
The only other user of proto_list besides proto_register, which
doesn't care, are the seqfs functions. They use the slab pointer,
but in a harmless way:
proto-slab == NULL ? no : yes,
From: Esben Nielsen [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 20:56:40 +0200 (METDST)
Andrew and David: I CC'ed you guyes because you took care of it the last
time :-)
Applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
TCP_OFF without setting TCP_PAGE. Since there is not much to be
gained from avoiding this situation, we might as well just zap the
offset. The following patch should fix it.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTE
From: [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 01:56:45 +0100
> Yet another architecture not coverd by GEN_RTC - sparc64 never
> picked it until now and it doesn't have asm/rtc.h to go with it, so
> it wouldn't compile anyway (or have these ioctls in the user-visible
> headers, for that
From: [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 01:56:45 +0100
Yet another architecture not coverd by GEN_RTC - sparc64 never
picked it until now and it doesn't have asm/rtc.h to go with it, so
it wouldn't compile anyway (or have these ioctls in the user-visible
headers, for that matter).
TCP_PAGE. Since there is not much to be
gained from avoiding this situation, we might as well just zap the
offset. The following patch should fix it.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp.c b/net/ipv4
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sun, 4 Sep 2005 14:42:18 -0700
> It seems a strange thing to check though. Do we really need it?
Other platforms already do, it's a very good sanity check.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
From: Dave Jones <[EMAIL PROTECTED]>
Subject: Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm
tree
Date: Sun, 4 Sep 2005 16:23:33 -0400
> On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote:
> > unsigned long __copy_to_user_ll(void __user *to, const void *from,
From: Dave Jones [EMAIL PROTECTED]
Subject: Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm
tree
Date: Sun, 4 Sep 2005 16:23:33 -0400
On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote:
unsigned long __copy_to_user_ll(void __user *to, const void *from,
From: Andrew Morton [EMAIL PROTECTED]
Date: Sun, 4 Sep 2005 14:42:18 -0700
It seems a strange thing to check though. Do we really need it?
Other platforms already do, it's a very good sanity check.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
From: "Brown, Len" <[EMAIL PROTECTED]>
Date: Sat, 3 Sep 2005 12:58:15 -0400
> CONFIG_AUDIT=y indeed did the trick.
>
> When will I be able to delete CONFIG_AUDIT from my kernel again?
It's a regression we accidently added to the netlink socket
family, we will fix it. But please use the
From: Brown, Len [EMAIL PROTECTED]
Date: Sat, 3 Sep 2005 12:58:15 -0400
CONFIG_AUDIT=y indeed did the trick.
When will I be able to delete CONFIG_AUDIT from my kernel again?
It's a regression we accidently added to the netlink socket
family, we will fix it. But please use the workaround of
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Sat, 03 Sep 2005 07:47:48 +1000
> So neither could currently supported atomic_t ops be shared with
> userland accesses?
Correct.
> Then I think it would not be breaking any interface rule to do an
> atomic_t atomic_cmpxchg either. Definitely for my
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Sat, 03 Sep 2005 07:22:18 +1000
> This atomic_cmpxchg, unlike a "regular" cmpxchg, has the advantage
> that the memory altered should always be going through the atomic_
> accessors, and thus should be implementable with spinlocks.
>
> See for example,
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 02 Sep 2005 22:41:31 +0200
> > Yeah quite a few. I suspect most MIPS also would have a problem in this
> > area.
>
> cmpxchg can be done with LL/SC can't it? Any MIPS should have that.
Right.
On PARISC, I don't see where they are emulating compare and
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Fri, 2 Sep 2005 22:24:44 +0200
> "extern inline" doesn't make much sense.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Patch does not apply to Linus's current tree, every change
in include/asm-sparc/spinlock.h was rejected.
-
To unsubscribe from
From: Alan Cox <[EMAIL PROTECTED]>
Subject: Re: [PATCH] more of sparc32 dependencies fallout
Date: Fri, 02 Sep 2005 21:24:08 +0100
> On Gwe, 2005-09-02 at 20:12 +0100, [EMAIL PROTECTED] wrote:
> > config MOXA_SMARTIO
> > tristate "Moxa SmartIO support"
> > - depends on SERIAL_NONSTANDARD
>
From: [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 20:12:01 +0100
> More stuff that got exposed to sparc32 build due to inclusion of
> drivers/char/Kconfig in arch/sparc/Kconfig needs to be excluded.
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Applied, thanks Al.
-
To unsubscribe from this list:
From: [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 19:46:42 +0100
> Fixing breakage from [NET]: Kill skb->list - original was
> assign vcc
> do a bunch of stuff using ZATM_VCC(vcc)->pool as common subexpression
> Now we do
> int pos = ZATM_VCC(vcc)->pool;
> assign vcc
>
From: John Heffner <[EMAIL PROTECTED]>
Date: Thu, 1 Sep 2005 22:51:48 -0400
> I have an idea why this is going on. Packets are pre-allocated by the
> driver to be a max packet size, so when you send small packets, it
> wastes a lot of memory. Currently Linux uses the packets at the
>
From: John Heffner [EMAIL PROTECTED]
Date: Thu, 1 Sep 2005 22:51:48 -0400
I have an idea why this is going on. Packets are pre-allocated by the
driver to be a max packet size, so when you send small packets, it
wastes a lot of memory. Currently Linux uses the packets at the
beginning of
From: [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 19:46:42 +0100
Fixing breakage from [NET]: Kill skb-list - original was
assign vcc
do a bunch of stuff using ZATM_VCC(vcc)-pool as common subexpression
Now we do
int pos = ZATM_VCC(vcc)-pool;
assign vcc
do a bunch
From: [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 20:12:01 +0100
More stuff that got exposed to sparc32 build due to inclusion of
drivers/char/Kconfig in arch/sparc/Kconfig needs to be excluded.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Applied, thanks Al.
-
To unsubscribe from this list: send
From: Alan Cox [EMAIL PROTECTED]
Subject: Re: [PATCH] more of sparc32 dependencies fallout
Date: Fri, 02 Sep 2005 21:24:08 +0100
On Gwe, 2005-09-02 at 20:12 +0100, [EMAIL PROTECTED] wrote:
config MOXA_SMARTIO
tristate Moxa SmartIO support
- depends on SERIAL_NONSTANDARD
+
From: Adrian Bunk [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 22:24:44 +0200
extern inline doesn't make much sense.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Patch does not apply to Linus's current tree, every change
in include/asm-sparc/spinlock.h was rejected.
-
To unsubscribe from this
From: Andi Kleen [EMAIL PROTECTED]
Date: 02 Sep 2005 22:41:31 +0200
Yeah quite a few. I suspect most MIPS also would have a problem in this
area.
cmpxchg can be done with LL/SC can't it? Any MIPS should have that.
Right.
On PARISC, I don't see where they are emulating compare and swap
as
From: Nick Piggin [EMAIL PROTECTED]
Date: Sat, 03 Sep 2005 07:22:18 +1000
This atomic_cmpxchg, unlike a regular cmpxchg, has the advantage
that the memory altered should always be going through the atomic_
accessors, and thus should be implementable with spinlocks.
See for example,
From: Nick Piggin [EMAIL PROTECTED]
Date: Sat, 03 Sep 2005 07:47:48 +1000
So neither could currently supported atomic_t ops be shared with
userland accesses?
Correct.
Then I think it would not be breaking any interface rule to do an
atomic_t atomic_cmpxchg either. Definitely for my usage it
From: Jesper Juhl <[EMAIL PROTECTED]>
Date: Fri, 2 Sep 2005 00:49:20 +0200
> Hmm, I see plenty of content in the post. Want me to farward you a
> copy off list ?
Please do, I didn't see anything.
It still needs to be reposted to netdev@vger.kernel.org
anyways :)
-
To unsubscribe from this list:
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Applied, thanks Jesper.
Can you avoid those "/./" things from showing up in the file paths of
the patches you post? They upset the GIT patch application scripts
and diff verifiers, so I had to edit them out by hand.
Thanks again.
-
To unsubscribe from this list: send the line "unsubscribe
From: Patrick Caulfield <[EMAIL PROTECTED]>
Date: Tue, 30 Aug 2005 09:47:36 +0100
> Patch from Steve which I've vetted and tested:
>
> "This patch is really intended has a move towards fixing the sendmsg/recvmsg
>
> functions in various ways so that we will finally have working nagle.
From: Geoff Levand <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 17:23:11 -0700
> This changes the Sun Gem Ether driver's tx ring buffer
> length to the proper constant. Currently TX_RING_SIZE
> and RX_RING_SIZE are equal, so no malfunction occurs.
>
> Signed-off-by: Geoff Levand <[EMAIL
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 17:58:06 +0200
> "extern inline" doesn't make much sense.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
From: Ed L Cashin <[EMAIL PROTECTED]>
Date: Thu, 01 Sep 2005 15:13:52 -0400
> The aoe driver looks OK, but it turns out there's a byte swapping bug
> in the vblade that could be related if he's running the vblade on a
> big endian host (even though he said it was an x86 host), but I
> haven't
From: Ed L Cashin <[EMAIL PROTECTED]>
Date: Wed, 31 Aug 2005 11:50:55 -0400
> Jim MacBaine <[EMAIL PROTECTED]> writes:
>
> > Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.<6>
> > etherd/e0.0: unknown partition table
> > Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000
From: Ed L Cashin [EMAIL PROTECTED]
Date: Wed, 31 Aug 2005 11:50:55 -0400
Jim MacBaine [EMAIL PROTECTED] writes:
Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.6
etherd/e0.0: unknown partition table
Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has
From: Ed L Cashin [EMAIL PROTECTED]
Date: Thu, 01 Sep 2005 15:13:52 -0400
The aoe driver looks OK, but it turns out there's a byte swapping bug
in the vblade that could be related if he's running the vblade on a
big endian host (even though he said it was an x86 host), but I
haven't heard
From: Geoff Levand [EMAIL PROTECTED]
Date: Wed, 24 Aug 2005 17:23:11 -0700
This changes the Sun Gem Ether driver's tx ring buffer
length to the proper constant. Currently TX_RING_SIZE
and RX_RING_SIZE are equal, so no malfunction occurs.
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
From: Patrick Caulfield [EMAIL PROTECTED]
Date: Tue, 30 Aug 2005 09:47:36 +0100
Patch from Steve which I've vetted and tested:
This patch is really intended has a move towards fixing the sendmsg/recvmsg
functions in various ways so that we will finally have working nagle. Also
From: Adrian Bunk [EMAIL PROTECTED]
Date: Wed, 24 Aug 2005 17:58:06 +0200
extern inline doesn't make much sense.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Applied, thanks Jesper.
Can you avoid those /./ things from showing up in the file paths of
the patches you post? They upset the GIT patch application scripts
and diff verifiers, so I had to edit them out by hand.
Thanks again.
-
To unsubscribe from this list: send the line unsubscribe
Thanks for the empty posting. Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
From: Jesper Juhl [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 00:49:20 +0200
Hmm, I see plenty of content in the post. Want me to farward you a
copy off list ?
Please do, I didn't see anything.
It still needs to be reposted to netdev@vger.kernel.org
anyways :)
-
To unsubscribe from this list:
From: Jim Keniston <[EMAIL PROTECTED]>
Date: 31 Aug 2005 14:53:37 -0700
> This bug doesn't exist on ppc64 and ia64, where a breakpoint
> instruction leaves the IP pointing to the beginning of the instruction.
> I don't know about sparc64. (Dave, could you please advise?)
On sparc64 instructions
From: Jim Keniston [EMAIL PROTECTED]
Date: 31 Aug 2005 14:53:37 -0700
This bug doesn't exist on ppc64 and ia64, where a breakpoint
instruction leaves the IP pointing to the beginning of the instruction.
I don't know about sparc64. (Dave, could you please advise?)
On sparc64 instructions are
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES
is configured.
Date: Wed, 31 Aug 2005 01:38:08 +0200
> On Wednesday 31 August 2005 01:05, Luck, Tony wrote:
> > >Please do not generate any code if the feature cannot ever be
> >
From: Andi Kleen [EMAIL PROTECTED]
Subject: Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES
is configured.
Date: Wed, 31 Aug 2005 01:38:08 +0200
On Wednesday 31 August 2005 01:05, Luck, Tony wrote:
Please do not generate any code if the feature cannot ever be
used
From: Jon Smirl <[EMAIL PROTECTED]>
Date: Tue, 30 Aug 2005 00:35:11 -0400
> As far as I can tell no one has built recent hardware this way. But I
> believe there are some old SCSI controllers that do this. I provided a
> ROM API for disabling sysfs access, if we identify one of these cards
> we
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT)
> So 2.6.13 is being "safe". It allocates the space for the ROM in the
> resource tables, but it neither enables it nor does it write the
> (disabled) address out to the device, since both of those actions have
>
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT)
So 2.6.13 is being safe. It allocates the space for the ROM in the
resource tables, but it neither enables it nor does it write the
(disabled) address out to the device, since both of those actions have
been
From: Jon Smirl [EMAIL PROTECTED]
Date: Tue, 30 Aug 2005 00:35:11 -0400
As far as I can tell no one has built recent hardware this way. But I
believe there are some old SCSI controllers that do this. I provided a
ROM API for disabling sysfs access, if we identify one of these cards
we should
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 27 Aug 2005 04:34:07 +0200
> "David S. Miller" <[EMAIL PROTECTED]> writes:
>
> > From: Alexey Dobriyan <[EMAIL PROTECTED]>
> > Date: Sat, 27 Aug 2005 02:58:48 +0400
> >
> > > Wha
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Sat, 27 Aug 2005 02:58:48 +0400
> What's the point of having unlikely() attached to every possible if ()?
If can result in smaller code, for one thing, even if it
isn't a performance critical path.
-
To unsubscribe from this list: send the line
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Sat, 27 Aug 2005 02:58:48 +0400
What's the point of having unlikely() attached to every possible if ()?
If can result in smaller code, for one thing, even if it
isn't a performance critical path.
-
To unsubscribe from this list: send the line
From: Andi Kleen [EMAIL PROTECTED]
Date: 27 Aug 2005 04:34:07 +0200
David S. Miller [EMAIL PROTECTED] writes:
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Sat, 27 Aug 2005 02:58:48 +0400
What's the point of having unlikely() attached to every possible if ()?
If can result
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: Re: some missing spin_unlocks
Date: Tue, 23 Aug 2005 19:40:06 +0200
> On Tue, 2005-08-23 at 10:30 -0700, David S. Miller wrote:
> > From: Arjan van de Ven <[EMAIL PROTECTED]>
> > Date: Tue, 23 Aug 2005 18:54:03 +020
b0864e7f34efcbb66e391)
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Tue Aug 23 09:42:38 2005 -0700
[ROSE]: Fix missing unlocks in rose_route_frame()
Noticed by Coverity checker.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/net/rose/ros
: David S. Miller [EMAIL PROTECTED]
Date: Tue Aug 23 09:42:38 2005 -0700
[ROSE]: Fix missing unlocks in rose_route_frame()
Noticed by Coverity checker.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
--- a/net/rose
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: Re: some missing spin_unlocks
Date: Tue, 23 Aug 2005 19:40:06 +0200
On Tue, 2005-08-23 at 10:30 -0700, David S. Miller wrote:
From: Arjan van de Ven [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 18:54:03 +0200
does it matter? can ANYTHING
From: Ted Unangst <[EMAIL PROTECTED]>
Subject: missing spin_unlock in tcp_v4_get_port
Date: Mon, 22 Aug 2005 14:17:36 -0700
> There appears to be a missing spin_unlock in tcp_v4_get_port.
>
> do {rover++;
> if (rover > high)
>
From: Jason Uhlenkott <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 13:33:06 -0700
> On Mon, Aug 22, 2005 at 01:20:52PM -0700, David S. Miller wrote:
> > Not really, when I'm debugging TCP events over gigabit
> > these timestamps are exceptionally handy.
>
> Yes, bu
From: Dave Jones <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 15:59:13 -0400
> This is still broken afaics in todays -git.
They are certainly there in Linus's current GIT tree.
...
#ifdef CONFIG_PM
static int skge_suspend(struct pci_dev *pdev, pm_message_t state)
...
static int
From: [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 10:42:22 -0700
> At the other extreme ... the current use of sched_clock() with
> potentially nano-second resolution is way over the top.
Not really, when I'm debugging TCP events over gigabit
these timestamps are exceptionally handy.
-
To
From: [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 10:42:22 -0700
At the other extreme ... the current use of sched_clock() with
potentially nano-second resolution is way over the top.
Not really, when I'm debugging TCP events over gigabit
these timestamps are exceptionally handy.
-
To unsubscribe
From: Dave Jones [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 15:59:13 -0400
This is still broken afaics in todays -git.
They are certainly there in Linus's current GIT tree.
...
#ifdef CONFIG_PM
static int skge_suspend(struct pci_dev *pdev, pm_message_t state)
...
static int skge_resume(struct
From: Jason Uhlenkott [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 13:33:06 -0700
On Mon, Aug 22, 2005 at 01:20:52PM -0700, David S. Miller wrote:
Not really, when I'm debugging TCP events over gigabit
these timestamps are exceptionally handy.
Yes, but how many of those figures are really
From: Ted Unangst [EMAIL PROTECTED]
Subject: missing spin_unlock in tcp_v4_get_port
Date: Mon, 22 Aug 2005 14:17:36 -0700
There appears to be a missing spin_unlock in tcp_v4_get_port.
do {rover++;
if (rover high)
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sat, 20 Aug 2005 21:03:09 +0200
> This breaks the compilation with CONFIG_PROC_FS=n:
..
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sat, 20 Aug 2005 21:03:09 +0200
This breaks the compilation with CONFIG_PROC_FS=n:
..
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
From: Sebastian Kuzminsky <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 16:07:32 -0600
> Linux provides 3 non-standard TCP socket options for tweaking the
> keepalive behavior of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT,
> and TCP_KEEPINTVL. The values set on a socket with these options should
From: Ollie Wild <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 12:05:31 -0700
> Patrick McHardy wrote:
>
> >Checking the return value of ip_append_data seems cleaner to me.
> >Patch attached.
> >
> >
> Works for me.
Applied, thanks everyone.
-
To unsubscribe from this list: send the line
From: Chris Wedgwood <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 09:33:58 -0700
> I thought the concensurs here was that because doing reliable atomic
> updates of 64-bit values isn't possible on some (most?) 32-bit
> architectures so we need additional locking to make this work which is
>
From: Anton Blanchard <[EMAIL PROTECTED]>
Date: Fri, 19 Aug 2005 04:29:55 +1000
> Calling itanium the "fastest 64bit processor at any given clock frequency"
> on lkml is likewise inflammatory :)
I totally agree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 09:14:47 +0200
> After reading your suggestions, I understand we still need two slabs.
> One (filp_cachep) without the readahead data, the other one
> (filp_ra_cachep) with it.
Correct.
> static inline struct file_ra_state
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 18 Aug 2005 09:14:47 +0200
After reading your suggestions, I understand we still need two slabs.
One (filp_cachep) without the readahead data, the other one
(filp_ra_cachep) with it.
Correct.
static inline struct file_ra_state
From: Ollie Wild [EMAIL PROTECTED]
Date: Thu, 18 Aug 2005 12:05:31 -0700
Patrick McHardy wrote:
Checking the return value of ip_append_data seems cleaner to me.
Patch attached.
Works for me.
Applied, thanks everyone.
-
To unsubscribe from this list: send the line unsubscribe
From: Chris Wedgwood [EMAIL PROTECTED]
Date: Thu, 18 Aug 2005 09:33:58 -0700
I thought the concensurs here was that because doing reliable atomic
updates of 64-bit values isn't possible on some (most?) 32-bit
architectures so we need additional locking to make this work which is
undesirable?
From: Anton Blanchard [EMAIL PROTECTED]
Date: Fri, 19 Aug 2005 04:29:55 +1000
Calling itanium the fastest 64bit processor at any given clock frequency
on lkml is likewise inflammatory :)
I totally agree.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
From: Sebastian Kuzminsky [EMAIL PROTECTED]
Date: Thu, 18 Aug 2005 16:07:32 -0600
Linux provides 3 non-standard TCP socket options for tweaking the
keepalive behavior of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT,
and TCP_KEEPINTVL. The values set on a socket with these options should
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 17 Aug 2005 21:05:32 -0700
> Perhaps by uprevving the compiler version?
Can't be, we definitely support gcc-2.95 and that compiler
definitely has the bug on sparc64.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 17 Aug 2005 17:38:18 -0700
> I'm prety sure we fixed that somehow. But I forget how.
I wish you could remember :-) I honestly don't think we did.
The DEFINE_PER_CPU() definition still looks the same, and the
way the .data.percpu section is
1 - 100 of 1880 matches
Mail list logo
