drivers/net/iseries_veth.c: In function 'veth_transmit_to_many':
drivers/net/iseries_veth.c:1174: warning: unused variable 'port'
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/iseries_veth.c |1 -
1 file changed, 1 deletion(-)
diff -ruNp a/dr
Of ethtool_ops->get_stats_count and ethtool_ops->get_ethtool_stats.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/mv643xx_eth.c |2 --
1 file changed, 2 deletions(-)
diff -ruNp a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
--- a/drivers/net/mv643x
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/pasemi_mac.c
[PATCH -mm] pasemi_mac: Build fix after recent netdev stats changes
Unbreak the following:
drivers/net
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_et
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the follow
On Mon, 17 Sep 2007, Denis V. Lunev wrote:
> Dhaval Giani wrote:
> > On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
> >> EIP: [] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec
As Vlad Yasevich mentioned, this one is already fixed in 23-rc6.
The forcedeth oops is unrelated, but m
nel.h, but
> > pr_err() was defined
> > multiple times in several other places
> >
> > Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
I think it's a useful cleanup, patch looks good to me ...
Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
[ Origi
On Thu, 6 Sep 2007, Johannes Berg wrote:
> On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
> > On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> > >
> > > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > > [
On Tue, 4 Sep 2007, Mark Hindley wrote:
> On Tue, Sep 04, 2007 at 02:09:47PM +0530, Satyam Sharma wrote:
> > Hi Steffen,
> >
> >
> > On Tue, 4 Sep 2007, Steffen Klassert wrote:
> >
> > > On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote
On Thu, 6 Sep 2007, Herbert Xu wrote:
> On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> >
> > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
>
> This is where the bug
Hi,
> On 02/09/07, Florian Lohoff <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > with current git i got this when "ifconfig eth1" down. eth1 had a mac
> > address which looked really like an eth1394 ethernet although the module
> > was not loaded. Something is really broken in 2.6.23-currentgit. I al
On Wed, 5 Sep 2007, Dale Farnsworth wrote:
> On Wed, Sep 05, 2007 at 08:24:52AM -0700, Andrew Morton wrote:
> > > On Mon, 20 Aug 2007 14:38:57 +0800 gshan <[EMAIL PROTECTED]> wrote:
> > > Hi All,
> > >
> > > After I started the NFS server, it crashed:
> > >
> > > <3>Badness in local_bh_enable
On Tue, 4 Sep 2007, Satyam Sharma wrote:
> Hi Micah,
>
>
> On Tue, 4 Sep 2007, Micah Gruber wrote:
>
> > This patch fixes a potential null dereference bug where we dereference
> > dev before a null check. This patch simply moves the dereferencing after
> > th
Hi Steffen,
On Tue, 4 Sep 2007, Steffen Klassert wrote:
> On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote:
> >
> > drivers/net/3c59x.c: In function 'vortex_up':
> > drivers/net/3c59x.c:1495: warning: 'err' may be used uninitialized in this
Hi Micah,
On Tue, 4 Sep 2007, Micah Gruber wrote:
> This patch fixes a potential null dereference bug where we dereference
> dev before a null check. This patch simply moves the dereferencing after
> the null check.
>
> Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
> ---
>
> --- a/drivers/ne
Remove duplicate entry for the same driver.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
MAINTAINERS |6 --
1 file changed, 6 deletions(-)
--- linux-2.6.23-rc4-mm1/MAINTAINERS~fix2007-09-04 03:49:16.0
+0530
+++ linux-2.6.23-rc4-mm1/MAINTAINERS2007-09
. Let's
fix this by explicitly initializing 'err' to zero.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/3c59x.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.23-rc4-mm1/drivers/net/3c59x.c~fix2007-09-04
03:29:40.0
lowed()
restore to happen only after the kernel_thread() is forked. Alas, we have
to use cpus_clear() to initialize oldmask instead to keep gcc happy.
Also add some comments to describe what's happening in the function.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
net/sun
On Sun, 2 Sep 2007, Mark Hindley wrote:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0025
> [...]
> Call Trace:
> [] tcp_rtt_estimator+0xba/0x100
> [...]
> EIP: [] tcp_rto_min+0x8/0x12 SS:ESP 0068:c0341dec
Third report of this oops within past
On Sun, 2 Sep 2007, [EMAIL PROTECTED] wrote:
>
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of disks),
> > > > 2.6.23-rc1-mm2 runs fine. 2.6.23-rc4-mm1 reproducably dies within
> > > > seconds of
> > > > starting
> > > > a rsync session
On Sun, 2 Sep 2007, Alexey Dobriyan wrote:
>
> Unable to handle kernel NULL pointer dereference at 0039 RIP:
> [] tcp_rto_min+0xc/0x20
tcp_rto_min() lacks a check-for-NULL. You want 5c127c58ae9bf196 from
the net-2.6.git tree -- so this will be gone in -rc6.
> P.S.: uh-oh, it's "[
net/sched/sch_cbq.c: In function 'cbq_enqueue':
net/sched/sch_cbq.c:383: warning: 'ret' may be used uninitialized in this
function
has been verified to be a bogus case. So let's shut it up.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
net/sched/sch_cbq
Hi Jurriaan,
> [EMAIL PROTECTED] wrote:
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Fri, Aug 31, 2007 at 09:58:22PM -0700
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
> > >
> > On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of d
On Fri, 31 Aug 2007, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
Got these on an i386 build with CONFIG_MODVERSIONS=y ...
WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] has no CRC!
WARNING: "div64_64" [net/ipv4/tcp_cubi
[ Adding relevant Cc:'s ]
On Thu, 30 Aug 2007, n wrote:
> I found a bug when using the Ethernet controller: Realtek Semiconductor Co.,
> Ltd. RTL-8169 Gigabit Ethernet (rev 10) ethernet card and kernel High
> Resolution Timers (menuconfig -> Processor type and features -> High
> Resolution Time
Hi Denys,
On Fri, 24 Aug 2007, Denys Vlasenko wrote:
> On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
> >
> > static inline void wait_for_init_deassert(atomic_t *deassert)
> > {
> > - while (!atomic_read(deassert));
> > + while (!atomic_read(dea
On Tue, 21 Aug 2007, Chris Snook wrote:
> David Miller wrote:
> > From: Linus Torvalds <[EMAIL PROTECTED]>
> > Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
> >
> > > Ie a "barrier()" is likely _cheaper_ than the code generation downside
> > > from using "volatile".
> >
> > Assuming GCC were eve
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > GCC manual, section 6.1, "When
^^
> > > is a Volatile Object Accessed?" doesn't say anything of the
^^^
> > > kind.
^
> > True, "impleme
On Fri, 17 Aug 2007, Linus Torvalds wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
> >
> > No code does (or would do, or should do):
> >
> > x.counter++;
> >
> > on an "atomic_t x;" anyway.
>
> That's just an example of
[ LOL, you _are_ shockingly petty! ]
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > The documentation simply doesn't say "+m" is allowed. The code to
> > > allow it was added for the benefit of people who do not read the
> > > documentation. Documentation for "+m" might get added later i
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > The "asm volatile" implementation does have exactly the same
> > > > > reordering guarantees as the "volatile cast" thing,
> > > >
> > > > I don't think so.
> > >
> > > "asm volatile" creates a side effect.
> >
> > Yeah.
> >
> > > Side
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > I didn't quite understand what you said here, so I'll tell what I think:
> >
> > * foo() is a compiler barrier if the definition of foo() is invisible to
> > the compiler at a calls
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > atomic_dec() writes
> > > > > to memory, so it _does_ have "volatile semantics", implicitly, as
> > > > > long as the compiler cannot optimise the atomic variable away
> > > > > completely -- any store counts as a side effect.
> > > >
> >
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Paul E. McKenney wrote:
>
> > On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> > > On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> > > >
> > > > gcc bugzilla bug #33102, for whatever that ends
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > No it does not have any volatile semantics. atomic_dec() can be
> > > > reordered
> > > > at will by the compiler within the current basic unit if you do not add
> > > > a
> > > > barrier.
> > >
> > > "volatile" has nothing to do with reord
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > #define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
> >
> > [ This is exactly equivalent to using "+m" in the constraints, as recently
> > explained on a GCC list somewhere, in response to the patch in my bitops
> > series a fe
On Fri, 17 Aug 2007, Segher Boessenkool wrote:
> > > atomic_dec() already has volatile behavior everywhere, so this is
> > > semantically
> > > okay, but this code (and any like it) should be calling cpu_relax() each
> > > iteration through the loop, unless there's a compelling reason not to.
>
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
> On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
> >
> > On Thu, 16 Aug 2007, Paul E. McKenney wrote:
> >
> > > On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> > > >
> >
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
> >
> > > Because they should be thinking about them in terms of barriers, over
> > > which the compiler / CPU is not to reorder accesses or cache
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> [...]
> > You think both these are equivalent in terms of "looks":
> >
> > |
> > while (!atomic_read(&v)) {
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
> > >
> > > It is very obvious. msleep calls schedule() (ie. sleeps), which is
> > > always a barrier.
> >
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > [...]
> > The point is about *author expecations*. If people do expect atomic_read()
> > (or a variant thereof) to have volatile semantics, why not give them such
> > a variant?
>
> Because they
On Fri, 17 Aug 2007, Paul Mackerras wrote:
> Satyam Sharma writes:
>
> > I wonder if this'll generate smaller and better code than _both_ the
> > other atomic_read_volatile() variants. Would need to build allyesconfig
> > on lots of diff arch's etc to test t
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> >
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> > > Also, why would you want to make these insane accessors for atomic_t
> > > types? Just make sure everybody knows the basics of bar
delay() and udelay() that often becomes __const_udelay() after some
macro-ing in various headers). So let's not mark it as "inline" either.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/i386/lib/delay.c |2 +-
arch/x86_64/lib/delay.c |2 +-
2 files changed
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> >
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> > > > Sure, now
> > > > that I learned of these properties I can start to audit code and insert
> > > > barriers where
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> [...]
> > Granted, the above IS buggy code. But, the stated objective is to avoid
> > heisenbugs.
^^
> Anyway, why are you making up code snippets that are buggy in other
> ways in order t
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Stefan Richter wrote:
> [...]
> Just use spinlocks if you're not absolutely clear about potential
> races and memory ordering issues -- they're pretty cheap and simple.
I fully agree with this. As Paul Mackerras mentioned elsewhere,
a lot of authors spr
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > #define atomic_read_volatile(v) \
> > ({ \
> > forget((v)->counter); \
&g
On Fri, 17 Aug 2007, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> > > Herbert Xu writes:
> > >
> > > > Can you find an actual atomic_read code snippet there that is
> > > > broken without the volatile modifier?
> > >
> > >
On Thu, 16 Aug 2007, Paul E. McKenney wrote:
> On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> > On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
> > >
> > > The compiler can also reorder non-volatile accesses. For an example
> > > patch that cares about this, ple
On Fri, 17 Aug 2007, Herbert Xu wrote:
> On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
> >
> > The cost of doing so seems to me to be well down in the noise - 44
> > bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> > the extra few cycles for the occasional
Hi Linus,
[ and others; I think there's a communication gap in a lot of this
thread, and a little summary would be useful. Hence this posting. ]
On Thu, 16 Aug 2007, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I tr
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Here, I should obviously admit that the semantics of *(volatile int *)&
> > aren't any neater or well-defined in the _language standard_ at all. The
> > standard does say (verbatim) "precisely what constitutes as access to
> > object of volatile
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Note that "volatile"
> > is a type-qualifier, not a type itself, so a cast of the _object_ itself
> > to a qualified-type i.e. (volatile int) would not make the access itself
> > volatile-qualified.
>
> There is no such thing as "volatile-quali
Hi Ilpo,
On Thu, 16 Aug 2007, Ilpo Järvinen wrote:
>
> ...I guess those guys hunting for broken busyloops in the other thread
> could also benefit from similar searching commands introduced in this
> thread... ...Ccing Satyam to caught their attention too.
>
>
> > On Wed, Aug 15, 2007 at 05
6 Aug 2007, Satyam Sharma wrote:
> On Thu, 16 Aug 2007, Satyam Sharma wrote:
> [...]
> > On Wed, 15 Aug 2007, Bill Fink wrote:
> > > [...]
> > > I'm curious about one minor tangential point. Why, instead of:
> > >
> > > b = *(vola
On Thu, 16 Aug 2007, Satyam Sharma wrote:
> Hi Bill,
>
>
> On Wed, 15 Aug 2007, Bill Fink wrote:
>
> > On Wed, 15 Aug 2007, Satyam Sharma wrote:
> >
> > > (C)
> > > $ cat tp3.c
> > > int a;
> > >
> > > void func(voi
Hi Bill,
On Wed, 15 Aug 2007, Bill Fink wrote:
> On Wed, 15 Aug 2007, Satyam Sharma wrote:
>
> > (C)
> > $ cat tp3.c
> > int a;
> >
> > void func(void)
> > {
> > *(volatile int *)&a = 10;
> > *(volatile int *)&a = 20;
On Thu, 16 Aug 2007, Satyam Sharma wrote:
> On Thu, 16 Aug 2007, Paul Mackerras wrote:
> > Herbert Xu writes:
> >
> > > See sk_stream_mem_schedule in net/core/stream.c:
> > >
> > > /* Under limit. */
> > > if (atomic_read(
On Thu, 16 Aug 2007, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > See sk_stream_mem_schedule in net/core/stream.c:
> >
> > /* Under limit. */
> > if (atomic_read(sk->sk_prot->memory_allocated) <
> > sk->sk_prot->sysctl_mem[0]) {
> > if (*sk->sk_prot->memory
On Wed, 15 Aug 2007, Christoph Lameter wrote:
> On Wed, 15 Aug 2007, Paul E. McKenney wrote:
>
> > Understood. My point is not that the impact is precisely zero, but
> > rather that the impact on optimization is much less hurtful than the
> > problems that could arise otherwise, particularly a
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> [...]
> > BTW:
> >
> > #define atomic_read(a) (*(volatile int *)&(a))
> > #define atomic_set(a,i) (*(volatile int *)&(a) = (i))
> >
> > int a;
> >
> > void func(void)
> > {
> > int b;
> >
> > b = atomic_read(a);
> > atomic
Hi Herbert,
On Thu, 16 Aug 2007, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 06:28:42AM +0530, Satyam Sharma wrote:
> >
> > > The udelay itself certainly should have some form of cpu_relax in it.
> >
> > Yes, a form of barrier() must be present in mdelay() or
[ Sorry for empty subject line in previous mail. I intended to make
a patch so cleared it to change it, but ultimately neither made
a patch nor restored subject line. Done that now. ]
On Thu, 16 Aug 2007, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 06:06:00AM +0530, Satyam Sharma wr
n the register only,
so these look like real bugs to me. With the fix below, this becomes:
0xc1019706 :pause
0xc1019708 :cmpl $0x0,0xc144c4c8
0xc101970f :je 0xc1019706
which looks nice and healthy. ]
Thanks to Heiko Carstens for noticing this.
Signed-off-by:
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > > > What you probably mean is that the compiler has to assume any code
> > > > it cannot currently see can do anything (insofar as allowed by the
> > > > relevant standards etc.)
> >
> > I think this was just terminology confusion here again. I
[ The Cc: list scares me. Should probably trim it. ]
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> > >>How does the compiler know that msleep() has got barrier()s?
> > >
> > >Because msleep_interruptible() is in a separate co
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > "Volatile behaviour" itself isn't consistently defined (at least
> > definitely not consistently implemented in various gcc versions across
> > platforms),
>
> It should be consistent across platforms; if not, file a bug please.
>
> > but it i
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 10:48:28PM +0530, Satyam Sharma wrote:
> > [...]
> > Not for i386 and x86_64 -- those have atomic ops without any "volatile"
> > semantics (currently as per existing definitions).
>
> I
Hi Paul,
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
> > [...]
> > No, I'd actually prefer something like what Christoph Lameter suggested,
> > i.e. users (such as above) who want "volatile"-li
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
> > On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
> > >
> > > Do we really need another set of APIs? Can you give even one example
> > > where the pre-existing volatil
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
> > Herbert Xu wrote:
> > > On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
> > >>> I don't know if this here is affected:
hen kthread_should_stop
is not true, on receiving a signal (might never happen in practice, as
it ignores signals). But considering kthread_stop() must not be mixed with
kthreads that can exit on their own, I think changing the code like this
is clearer. This change means the thread can cut its s
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > On Wed, 15 Aug 2007, Stefan Richter wrote:
> >> Doesn't "atomic WRT all processors" require volatility?
> >
> > No, it definitely doesn't. Why should it?
> >
> &
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> > the first place? Atomic ops guarantee atomicity, which has nothing
> > to do with "volatility" -- users that e
On Tue, 14 Aug 2007, Christoph Lameter wrote:
> On Thu, 9 Aug 2007, Chris Snook wrote:
>
> > This patchset makes the behavior of atomic_read uniform by removing the
> > volatile keyword from all atomic_t and atomic64_t definitions that currently
> > have it, and instead explicitly casts the var
On Mon, 13 Aug 2007, Satyam Sharma wrote:
> Hi David,
>
>
> On Fri, 10 Aug 2007, David Miller wrote:
> [...]
> > 1) The reiserfs definition is better, it is _type_ based.
> >Please use (~(__u16)0) and (~(__u32)0), respectively.
>
> Hmm, in that case ((__u
Hi David,
On Fri, 10 Aug 2007, David Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Fri, 10 Aug 2007 14:12:10 -0700
>
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > ... in kernel.h and clean up home-grown macros elsewhere in the tree.
> >
> >
On Thu, 2 Aug 2007, Jarek Poplawski wrote:
> On Thu, Aug 02, 2007 at 04:02:21PM +0530, Satyam Sharma wrote:
> [...]
> How often "common" developer has to make such decisions in Kconfig?
> Probably no more than once per year. So, it's fair to blame anybody
> for not
[ Read through the thread, looked at Kconfig files,
did some tests. Adding Kconfig experts to Cc: list. ]
> On Thu, 2 Aug 2007, Sam Ravnborg wrote:
>
> > > >
> > > > ...
> > > > endif # NETDEVICES
> > > >
> > > > config NETPOLL
> > > > depends on NETDEVICES
> > > > def_bool N
Hi,
On Thu, 2 Aug 2007, Sam Ravnborg wrote:
> > >
> > > ...
> > > endif # NETDEVICES
> > >
> > > config NETPOLL
> > > depends on NETDEVICES
> > > def_bool NETCONSOLE
> > >
> > > config NETPOLL_TRAP
> > > bool "Netpoll traffic trapping"
> > > default n
> > >
On Mon, 30 Jul 2007, Andrew Morton wrote:
> On Mon, 30 Jul 2007 08:19:10 +0530
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > +/*
> > + * Wrapper over simple_strtol (base 10) with sanity and range checking.
> > + * We return (signed) long only because we may
On Mon, 30 Jul 2007, Andrew Morton wrote:
> On Mon, 30 Jul 2007 08:17:41 +0530
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > [0/9] netconsole: Multiple targets and dynamic reconfigurability
> >
> > This is v3 of the patchset
>
> That all looks pre
emove it.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/pcmcia/nmclan_cs.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/pcmcia/nmclan_cs.c b/drivers/net/pcmcia/nmclan_cs.c
index 73da611..3446be9 100644
--- a/drivers/net/pcmc
Hi Jeff,
On Mon, 30 Jul 2007, Jeff Garzik wrote:
> Fix a potential NULL pointer dereference in mace_interrupt() in
> drivers/net/pcmcia/nmclan_cs.c
This oops is _programmatically_ impossible (the only way it can occur
is if the kernel has gone bazooka already anyway ...)
[ BTW even if i
On Mon, 30 Jul 2007, Petko Manolov wrote:
> On Sun, 29 Jul 2007, Oliver Neukum wrote:
>
> > [...]
> > pegasus == NULL there would be a kernel bug. Silently ignoring
> > it, like the code now wants to do is bad. As the oops has never been
> > reported, I figure turning it into an explicit debugg
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 chan
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]>
[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]>
[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-
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]>
[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(
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]>
[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]>
S
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
[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 2.6.23-rc1-
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.
>
s
In net_device->do_ioctl() of the sb1000 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 no
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,
1 - 100 of 176 matches
Mail list logo
