On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:
> The SCSI Tape driver uses a semaphore as mutex. Use the mutex API
> instead of the (binary) semaphore.
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
-
To unsubscr
ck))
> + if (mutex_lock_interruptible(>lock))
> return (-ERESTARTSYS);
Same here.
Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
On Mon, 30 Jul 2007, Michael Buesch wrote:
> On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote:
> > The Host AP driver uses a semaphore as mutex. Use the mutex API
> > instead of the (binary) semaphore.
> >
> > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
[ Something seems to have
[PATCH] Fix a typo in Documentation/keys.txt
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Acked-by: David Howells <[EMAIL PROTECTED]>
---
[ Previously sent on: June 9, 2007 ]
Documentation/keys.txt |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff -ruNp a/D
From: Satyam Sharma <[EMAIL PROTECTED]>
[9/9] netconsole: Support dynamic reconfiguration using configfs
This patch introduces support for dynamic reconfiguration (adding, removing
and/or modifying parameters of netconsole targets at runtime) using a
userspace interface exported via co
From: Satyam Sharma <[EMAIL PROTECTED]>
[6/9] netconsole: Introduce netconsole_target
Introduce a wrapper structure over netpoll to represent logging targets
configured in netconsole. This will get extended with other members in
further patches.
This is done independent of the (to-be-intr
From: Satyam Sharma <[EMAIL PROTECTED]>
[7/9] netconsole: Introduce netconsole_netdev_notifier
To update fields of underlying netpoll structure at runtime on
corresponding NETDEV_CHANGEADDR or NETDEV_CHANGENAME notifications.
ioctl(SIOCSIFHWADDR or SIOCSIFNAME) could be used to
From: Satyam Sharma <[EMAIL PROTECTED]>
[8/9] netconsole: Support multiple logging targets
This patch introduces support for multiple targets, independent of
CONFIG_NETCONSOLE_DYNAMIC -- this is useful even in the default case and
(including the infrastructure introduced in previous p
From: Satyam Sharma <[EMAIL PROTECTED]>
[3/9] netconsole: Simplify boot/module option setup logic
Presently, boot/module parameters are set up quite differently for the
case of built-in netconsole (__setup() -> obsolete_checksetup() ->
netpoll_parse_options() -> strl
From: Satyam Sharma <[EMAIL PROTECTED]>
[4/9] netconsole: Use netif_running() in write_msg()
Avoid unnecessarily disabling interrupts and calling netpoll_send_udp()
if the corresponding local interface is not up.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Acked-by: Keiichi
From: Satyam Sharma <[EMAIL PROTECTED]>
[5/9] netconsole: Add some useful tips to documentation
Add some useful general-purpose tips. Also suggest solution for the frequent
problem of console loglevel set too low numerically (i.e. for high priority
messages only) on the sender.
Sign
From: Satyam Sharma <[EMAIL PROTECTED]>
[2/9] netconsole: Remove bogus check
The (!np.dev) check in write_msg() is bogus (always false), because:
np.dev is set by netpoll_setup(), which is called by init_netconsole()
before register_console(), so write_msg() cannot be triggered
From: Satyam Sharma <[EMAIL PROTECTED]>
[1/9] netconsole: Cleanups, codingstyle, prettyfication
(1) Remove unwanted headers.
(2) Mark __init and __exit as appropriate.
(3) Various trivial codingstyle and prettification stuff.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
[0/9] netconsole: Multiple targets and dynamic reconfigurability
This is v3 of the patchset, the previous versions are available at:
http://lkml.org/lkml/2007/7/4/107
http://lkml.org/lkml/2007/7/10/78
Diffed against 2.6.23-rc1-git6 (6c8dca5d as of writing), but applies
successfully to
On 7/30/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> [...]
> Gabriel C reports lguest doesn't compile with CONFIG_BLOCK=n. Fix
> this by introducing a config var for the block device, which depends
> on LGUEST && BLOCK. Do the same for the net driver, rather then
> depending gratuitously on
Hi Michael,
On Sun, 29 Jul 2007, Michael Buesch wrote:
> On Sunday 29 July 2007 20:34:46 Satyam Sharma wrote:
> > (2) !(dev->flags & IFF_UP) is bogus because the functions of this ioctl
> > can (and should) be allowed even when the interface is not up and runnin
Hi Martin,
On Sun, 29 Jul 2007, Martin Steigerwald wrote:
> Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote:
> > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > > > > I
> > > > > actually also think that the communication
driver (sb1000_dev_ioctl):
(1) !dev condition is always false -- this function cannot be called with
NULL net_device.
(2) !(dev->flags & IFF_UP) is bogus because the functions of this ioctl
can (and should) be allowed even when the interface is not up and running.
So let's remove these checks.
On Sun, 29 Jul 2007, Oliver Neukum wrote:
> Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
> > On 29/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > > > Hello
On Sun, 29 Jul 2007, Oliver Neukum wrote:
Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
On 29/07/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi,
On 7/29/07, Jesper Juhl [EMAIL PROTECTED] wrote:
Hello,
This patch makes sure we don't dereference a NULL pointer in
drivers
condition is always false -- this function cannot be called with
NULL net_device.
(2) !(dev-flags IFF_UP) is bogus because the functions of this ioctl
can (and should) be allowed even when the interface is not up and running.
So let's remove these checks.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Cc
Hi Martin,
On Sun, 29 Jul 2007, Martin Steigerwald wrote:
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote:
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
I
actually also think that the communication between Ingo and
Hi Michael,
On Sun, 29 Jul 2007, Michael Buesch wrote:
On Sunday 29 July 2007 20:34:46 Satyam Sharma wrote:
(2) !(dev-flags IFF_UP) is bogus because the functions of this ioctl
can (and should) be allowed even when the interface is not up and running.
Are you _sure_? This function does
On 7/30/07, Rusty Russell [EMAIL PROTECTED] wrote:
[...]
Gabriel C reports lguest doesn't compile with CONFIG_BLOCK=n. Fix
this by introducing a config var for the block device, which depends
on LGUEST BLOCK. Do the same for the net driver, rather then
depending gratuitously on CONFIG_NET.
[0/9] netconsole: Multiple targets and dynamic reconfigurability
This is v3 of the patchset, the previous versions are available at:
http://lkml.org/lkml/2007/7/4/107
http://lkml.org/lkml/2007/7/10/78
Diffed against 2.6.23-rc1-git6 (6c8dca5d as of writing), but applies
successfully to
From: Satyam Sharma [EMAIL PROTECTED]
[1/9] netconsole: Cleanups, codingstyle, prettyfication
(1) Remove unwanted headers.
(2) Mark __init and __exit as appropriate.
(3) Various trivial codingstyle and prettification stuff.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Signed-off-by: Keiichi
From: Satyam Sharma [EMAIL PROTECTED]
[2/9] netconsole: Remove bogus check
The (!np.dev) check in write_msg() is bogus (always false), because:
np.dev is set by netpoll_setup(), which is called by init_netconsole()
before register_console(), so write_msg() cannot be triggered unless
From: Satyam Sharma [EMAIL PROTECTED]
[3/9] netconsole: Simplify boot/module option setup logic
Presently, boot/module parameters are set up quite differently for the
case of built-in netconsole (__setup() - obsolete_checksetup() -
netpoll_parse_options() - strlen(config) == 0 in init_netconsole
From: Satyam Sharma [EMAIL PROTECTED]
[4/9] netconsole: Use netif_running() in write_msg()
Avoid unnecessarily disabling interrupts and calling netpoll_send_udp()
if the corresponding local interface is not up.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Acked-by: Keiichi Kii [EMAIL
From: Satyam Sharma [EMAIL PROTECTED]
[5/9] netconsole: Add some useful tips to documentation
Add some useful general-purpose tips. Also suggest solution for the frequent
problem of console loglevel set too low numerically (i.e. for high priority
messages only) on the sender.
Signed-off
From: Satyam Sharma [EMAIL PROTECTED]
[6/9] netconsole: Introduce netconsole_target
Introduce a wrapper structure over netpoll to represent logging targets
configured in netconsole. This will get extended with other members in
further patches.
This is done independent of the (to-be-introduced
From: Satyam Sharma [EMAIL PROTECTED]
[7/9] netconsole: Introduce netconsole_netdev_notifier
To update fields of underlying netpoll structure at runtime on
corresponding NETDEV_CHANGEADDR or NETDEV_CHANGENAME notifications.
ioctl(SIOCSIFHWADDR or SIOCSIFNAME) could be used to change
From: Satyam Sharma [EMAIL PROTECTED]
[8/9] netconsole: Support multiple logging targets
This patch introduces support for multiple targets, independent of
CONFIG_NETCONSOLE_DYNAMIC -- this is useful even in the default case and
(including the infrastructure introduced in previous patches
From: Satyam Sharma [EMAIL PROTECTED]
[9/9] netconsole: Support dynamic reconfiguration using configfs
This patch introduces support for dynamic reconfiguration (adding, removing
and/or modifying parameters of netconsole targets at runtime) using a
userspace interface exported via configfs
[PATCH] Fix a typo in Documentation/keys.txt
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Acked-by: David Howells [EMAIL PROTECTED]
---
[ Previously sent on: June 9, 2007 ]
Documentation/keys.txt |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff -ruNp a/Documentation
On Mon, 30 Jul 2007, Michael Buesch wrote:
On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote:
The Host AP driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
[ Something seems to have gone wrong
(-ERESTARTSYS);
Same here.
Reviewed-by: Satyam Sharma [EMAIL PROTECTED]
-
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/
On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:
The SCSI Tape driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
Reviewed-by: Satyam Sharma [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
Whoops ...
On Mon, 30 Jul 2007, Satyam Sharma wrote:
On Mon, 30 Jul 2007, Michael Buesch wrote:
On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote:
The Host AP driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.
Signed-off-by: Matthias
On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:
The ISDN subsystem common functions use a semaphore as mutex. Use the
mutex API instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
Reviewed-by: Satyam Sharma [EMAIL PROTECTED]
-
To unsubscribe from this list
On Sun, 29 Jul 2007, Matthias Kaehlcke wrote:
The DVB frontend tuning interface uses a semaphore as mutex. Use the
mutex API instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
Reviewed-by: Satyam Sharma [EMAIL PROTECTED]
-
To unsubscribe from this list
Hi Rodolfo,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
I only glanced through the code, so could be wrong, but I noticed that
the only global / shared data you have in there is a global pps_source
array of pps_s structs
Hi,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
[ Also, have you considered making pps_source a list and not an array?
It'll help you lose a whole lot of MAX_SOURCES, pps_is_allocated, etc
kind of gymnastics
Hi Rodolfo,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Take the race between the time_pps_setparams() syscall and a concurrent
pps_event() from an interrupt for instance. From sys_time_pps_setparams,
the parameters
On Sun, 29 Jul 2007, Domen Puncer wrote:
> On 29/07/07 00:02 +0200, Jesper Juhl wrote:
> > Hi,
> >
> > Here's a small patch, prompted by a find by the Coverity checker,
> > that removes a potential NULL pointer dereference from
> > drivers/net/sb1000.c::sb1000_dev_ioctl().
> > The checker
Hi,
On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This patch makes sure we don't dereference a NULL pointer in
> drivers/net/usb/pegasus.c::write_bulk_callback() in the initial
> struct net_device *net = pegasus->net; assignment.
> The existing code checks if 'pegasus' is NULL
Hi,
On 7/29/07, Jesper Juhl [EMAIL PROTECTED] wrote:
Hello,
This patch makes sure we don't dereference a NULL pointer in
drivers/net/usb/pegasus.c::write_bulk_callback() in the initial
struct net_device *net = pegasus-net; assignment.
The existing code checks if 'pegasus' is NULL and bails
On Sun, 29 Jul 2007, Domen Puncer wrote:
On 29/07/07 00:02 +0200, Jesper Juhl wrote:
Hi,
Here's a small patch, prompted by a find by the Coverity checker,
that removes a potential NULL pointer dereference from
drivers/net/sb1000.c::sb1000_dev_ioctl().
The checker spotted that we
Hi,
On 7/28/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi Rodolfo,
>
> On 7/28/07, Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
> > >
> > > My point is that the lock
Hi Rodolfo,
On 7/28/07, Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
> >
> > My point is that the lock should be used to protect specific data. Thus, it
> > would be more correct to say, "spinlock foo is taken because
> >
On 7/27/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Maybe I should resurrect it & send it out...
Hmm, something that hooks in not only at do_IRQ time (as the present
in-mainline stackoverflow check thing)?
> > (FWIW I think I recall that the warning itself sometimes tipped the
> > scales enough
On 7/27/07, Marc Dietrich <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Am Friday 27 July 2007 14:53 schrieben Sie:
> > Background:
> >
> > Server: x86-64 dual core Intel, kernel 2.6.23-rc1 (my home fileserver)
> > Exporting NFS/NFSv4 mounts. Client count: 1 Uptime: 4 days
> >
> > Client: x86-64
On 7/27/07, Marc Dietrich [EMAIL PROTECTED] wrote:
Hi,
Am Friday 27 July 2007 14:53 schrieben Sie:
Background:
Server: x86-64 dual core Intel, kernel 2.6.23-rc1 (my home fileserver)
Exporting NFS/NFSv4 mounts. Client count: 1 Uptime: 4 days
Client: x86-64 dual core Intel,
On 7/27/07, Alan Cox [EMAIL PROTECTED] wrote:
Maybe I should resurrect it send it out...
Hmm, something that hooks in not only at do_IRQ time (as the present
in-mainline stackoverflow check thing)?
(FWIW I think I recall that the warning itself sometimes tipped the
scales enough on 4k
Hi Rodolfo,
On 7/28/07, Rodolfo Giometti [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
My point is that the lock should be used to protect specific data. Thus, it
would be more correct to say, spinlock foo is taken because
pps_register_source()
Hi,
On 7/28/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi Rodolfo,
On 7/28/07, Rodolfo Giometti [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
My point is that the lock should be used to protect specific data. Thus,
it
would be more
Trivial nits ...
On 7/26/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
[...]
+/**
+ * ecryptfs_global_auth_tok structs refer to authentication token keys
+ * in the user keyring that apply to newly created files. A list of
+ * these objects hangs off of the mount_crypt_stat struct for any
+ *
ko] undefined!
ERROR: "unregister_dca_provider" [drivers/dma/ioatdma.ko] undefined!
ERROR: "free_dca_provider" [drivers/dma/ioatdma.ko] undefined!
make[1]: *** [__modpost] Error 1
"select" seems ok because CONFIG_DCA looks library-like and doesn't itself
depend upon anything els
Hi Ingo,
[ Going off-topic, nothing related to swap/prefetch/etc. Just getting
a hang of how development goes on here ... ]
On 7/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Rene Herman <[EMAIL PROTECTED]> wrote:
> Nick Piggin is the person to convince it seems and if I've read things
>
On 7/25/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Thu, 5 Jul 2007 18:52:27 -0700 (PDT) Joshua Wise <[EMAIL PROTECTED]> wrote:
> Background:
> This patch is a follow-on to "Info dump on Oops or panic()" [1].
>
> On some architectures, the kernel printed some information on the running
>
On 7/25/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
> [...]
>
> But where does the "send" come into the picture over here -- a send
> won't block forever, so I don't foresee any issues whatsoever
On 7/25/07, Lars Ellenberg [EMAIL PROTECTED] wrote:
On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
[...]
But where does the send come into the picture over here -- a send
won't block forever, so I don't foresee any issues whatsoever w.r.t.
kthreads conversion for that. [ BTW
On 7/25/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 5 Jul 2007 18:52:27 -0700 (PDT) Joshua Wise [EMAIL PROTECTED] wrote:
Background:
This patch is a follow-on to Info dump on Oops or panic() [1].
On some architectures, the kernel printed some information on the running
kernel,
Hi Ingo,
[ Going off-topic, nothing related to swap/prefetch/etc. Just getting
a hang of how development goes on here ... ]
On 7/25/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
Nick Piggin is the person to convince it seems and if I've read things
right
Trivial nits ...
On 7/26/07, Michael Halcrow [EMAIL PROTECTED] wrote:
[...]
+/**
+ * ecryptfs_global_auth_tok structs refer to authentication token keys
+ * in the user keyring that apply to newly created files. A list of
+ * these objects hangs off of the mount_crypt_stat struct for any
+ *
: unregister_dca_provider [drivers/dma/ioatdma.ko] undefined!
ERROR: free_dca_provider [drivers/dma/ioatdma.ko] undefined!
make[1]: *** [__modpost] Error 1
select seems ok because CONFIG_DCA looks library-like and doesn't itself
depend upon anything else.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers
On 7/23/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22 2007, Satyam Sharma wrote:
> Hi Walter,
>
> Thanks for reporting this.
>
> On 7/22/07, walter harms <[EMAIL PROTECTED]> wrote:
>> hello all,
>> on my asus notebook tm620 there is a crash wit
Hi Lars,
On 7/24/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
> On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> >[...]
> >&
On Tue, 24 Jul 2007, Linus Torvalds wrote:
> On Tue, 24 Jul 2007, Satyam Sharma wrote:
> >
> > Looks like when you said "CPU memory barrier extends to all memory
> > references" you were probably referring to a _given_ CPU ... yes,
> > that statement is corr
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > For the purpose of this discussion (Linux memory
> > > barrier semantics, on WB memory), it is true of CPU
> > > and compiler barriers.
> >
> > On later Intel processors, if the memory address range being referenced
> > (and say written to) by the
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
>
> > > > Consider this (the above two functions exist
> > only for clear_bit(),
> > > > the atomic variant, as you already know), the
> > _only_ memory reference
> > > >
Hi David,
On Tue, 24 Jul 2007, David Howells wrote:
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > OTOH, as per Linus' review it seems we can drop the "memory" clobber
> > and specify the output operand for the extended asm as "+m". But I
> >
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
> > > [...]
> > > > So let's make these proper no-ops, because that's exactly what we
> > > &g
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > [...]
> > >
> > > __test_and_change_bit is one that you could remove the memory clobber
> > > from.
> >
> > Yes, for the atomic versions we don't care if we're asking gcc to
> > generate trashy code (even though I'd have wanted to only disallow
> >
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
> >
> > > From Documentation/atomic_ops.txt, those archs that r
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
> >
> > The goal is to let gcc generate good, beautiful, optimi
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Linus Torvalds wrote:
> >
> > On Mon, 23 Jul 2007, Satyam Sharma wrote:
> >
> >
> > > [4/8] i386: bitops: Kill volatile-casting of memory addresses
> >
> >
> > This is wrong.
> >
> >
On Tue, 24 Jul 2007, Nick Piggin wrote:
Linus Torvalds wrote:
On Mon, 23 Jul 2007, Satyam Sharma wrote:
[4/8] i386: bitops: Kill volatile-casting of memory addresses
This is wrong.
The const volatile is so that you can pass an arbitrary pointer. The only
kind
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
The goal is to let gcc generate good, beautiful, optimized code.
But test_and_set_bit, test_and_clear_bit
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also
On Tue, 24 Jul 2007, Nick Piggin wrote:
[...]
__test_and_change_bit is one that you could remove the memory clobber
from.
Yes, for the atomic versions we don't care if we're asking gcc to
generate trashy code (even though I'd have wanted to only disallow
problematic
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
[...]
So let's make these proper no-ops, because that's exactly what we
require
these to be on the i386 platform.
No. clear_bit is not a compiler
Hi David,
On Tue, 24 Jul 2007, David Howells wrote:
Satyam Sharma [EMAIL PROTECTED] wrote:
OTOH, as per Linus' review it seems we can drop the memory clobber
and specify the output operand for the extended asm as +m. But I
must admit I didn't quite understand that at all.
As I
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
Consider this (the above two functions exist
only for clear_bit(),
the atomic variant, as you already know), the
_only_ memory reference
we care about is that of the address of the
passed bit-string
On Tue, 24 Jul 2007, Nick Piggin wrote:
For the purpose of this discussion (Linux memory
barrier semantics, on WB memory), it is true of CPU
and compiler barriers.
On later Intel processors, if the memory address range being referenced
(and say written to) by the (locked)
On Tue, 24 Jul 2007, Linus Torvalds wrote:
On Tue, 24 Jul 2007, Satyam Sharma wrote:
Looks like when you said CPU memory barrier extends to all memory
references you were probably referring to a _given_ CPU ... yes,
that statement is correct in that case.
No. CPU memory barriers
Hi Lars,
On 7/24/07, Lars Ellenberg [EMAIL PROTECTED] wrote:
On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
On 7/23/07, Lars Ellenberg [EMAIL PROTECTED] wrote:
On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
[...]
Don't use signals between kernel threads, use
On 7/23/07, Jens Axboe [EMAIL PROTECTED] wrote:
On Sun, Jul 22 2007, Satyam Sharma wrote:
Hi Walter,
Thanks for reporting this.
On 7/22/07, walter harms [EMAIL PROTECTED] wrote:
hello all,
on my asus notebook tm620 there is a crash with 2.6.22 and 2.6.21
Did this happen when you were
On Mon, 23 Jul 2007, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > On Mon, 23 Jul 2007, Satyam Sharma wrote:
> >> * The "I" constraint modifier is applicable only to immediate-value
> >> operands,
> >> and combining it with "r&
On Mon, 23 Jul 2007, Linus Torvalds wrote:
> On Mon, 23 Jul 2007, Satyam Sharma wrote:
> >
> > * The "I" constraint modifier is applicable only to immediate-value
> > operands,
> > and combining it with "r" is bogus.
>
> This is wrong t
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> I'm not quite sure what your point is.
Could be a case of terminology confusion ...
> The paragraph you quoted is
> pretty explicit in saying that volatile doesn't prevent an "asm
> volatile" from being interspersed with other code, and the
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:05:43 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [3/8] i386: bitops: Rectify bogus "+m" constraints
> >
> > From the gcc manual:
> >
> >
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
>
> > Yes, but _that_ address (of the bit-string) is protected already -- by the
> > implicit memory barrier due to the LOCK prefix.
>
> Compiler barrier != CPU barrier.
Exactly, but the actual _synchronization_ in all users of the bitops API
should
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in this file. The
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in t
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:05:58 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
> >
> > The goal is to let gcc g
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [2/8] i386: bitops: Rectify bogus "Ir" constraints
> >
> > The "I" cons
From: Satyam Sharma <[EMAIL PROTECTED]>
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) interspers
From: Satyam Sharma <[EMAIL PROTECTED]>
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
>From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also implement these two interfaces.
However, for i386,
From: Satyam Sharma <[EMAIL PROTECTED]>
[5/8] i386: bitops: Contain warnings fallout from the death of volatiles
The wrappers below included from all over tree re-used "volatile" just
because the bitops used them. With them killed, almost every file ends
up crying about:
601 - 700 of 1619 matches
Mail list logo
