* Re: OOM Killer firing when plenty of memory left and no swap used
From: Mike Galbraith @ 2006-05-11 4:44 UTC (permalink / raw)
To: Bron Gondwana; +Cc: linux-kernel
In-Reply-To: <20060511020808.GA6126@brong.net>
On Thu, 2006-05-11 at 12:08 +1000, Bron Gondwana wrote:
>
> I hope someone can shed some light on what could possibly
> have caused the oom-killer to engage with so much free
> memory.
> Log messages from the first failure:
> May 10 19:57:00 heartbeat1 kernel: oom-killer: gfp_mask=0xd0, order=1
A two page GFP_KERNEL allocation fails...
> May 10 19:57:00 heartbeat1 kernel: [out_of_memory+180/209] out_of_memory+0xb4/0xd1
> May 10 19:57:00 heartbeat1 kernel: [__alloc_pages+623/795] __alloc_pages+0x26f/0x31boom-killer: gfp_mask=0xd0, order=1
> May 10 19:57:00 heartbeat1 kernel: [out_of_memory+180/209] out_of_memory+0xb4/0xd1
> May 10 19:57:00 heartbeat1 kernel: [__alloc_pages+623/795] __alloc_pages+0x26f/0x31b
> May 10 19:57:00 heartbeat1 kernel: [kmem_getpages+52/155] kmem_getpages+0x34/0x9b
> May 10 19:57:00 heartbeat1 kernel: [cache_grow+190/375] cache_grow+0xbe/0x177
> May 10 19:57:00 heartbeat1 kernel: [cache_alloc_refill+354/523] cache_alloc_refill+0x162/0x20b
> May 10 19:57:00 heartbeat1 kernel: [kmem_cache_alloc+103/127] kmem_cache_alloc+0x67/0x7f
> May 10 19:57:00 heartbeat1 kernel: [dup_task_struct+69/153] dup_task_struct+0x45/0x99
> May 10 19:57:00 heartbeat1 kernel: [copy_process+94/3348] copy_process+0x5e/0xd14
> May 10 19:57:00 heartbeat1 kernel: [do_fork+105/395] do_fork+0x69/0x18b
> May 10 19:57:00 heartbeat1 kernel: [sys_rt_sigprocmask+161/256] sys_rt_sigprocmask+0xa1/0x100
> May 10 19:57:00 heartbeat1 kernel: [sys_clone+62/66] sys_clone+0x3e/0x42
> May 10 19:57:00 heartbeat1 kernel: [syscall_call+7/11] syscall_call+0x7/0xb
...for the slab allocator as it tries to expand it's cache to create
space for a new task.
> May 10 19:57:00 heartbeat1 kernel: Normal free:24276kB min:26732kB low:33412kB high:40096kB active:2256kB inactive:1940kB present:901120kB pages_scanned:6457 all_unreclaimable? yes
Zone normal is below min watermark, and GFP_HIGH isn't set, so no
digging down into reserves is allowed. Most of Zone Normal memory isn't
on the LRU, and what is there is all unreclaimable, so swap can't help
with the shortage. Genuine oom situation.
Question is, where are all your Zone Normal pages hanging out? If it
happens again, take a look at /proc/slabinfo to see if it's there, and
if so, in which cache[s].
If it's not there, somebody is leaking pages. If that's the case, I'd
take a close look at those out-of-tree patches.
-Mike
^ permalink raw reply
* RE: [Xen-users] Xen 3.0 User Manual revision
From: Anthony Wood @ 2006-05-11 4:43 UTC (permalink / raw)
To: xen-users, xen-devel
In-Reply-To: <002b01c673a9$3fac46c0$03c8a8c0@PAPA>
[-- Attachment #1.1: Type: text/plain, Size: 2702 bytes --]
Hi Alan,
I support the HVM requests others have made. Particularly confusing for me
was that I started with Xen 3.0.2 which seemed to have changed all
references to vmx to hvm including files, this meant I rebuilt xen numerous
times trying to get vmx files (e.g. vmx-builder) when I already had hvm
files (e.g. hvm-builder) and didn't need anything else.
Some ways of telling whether your computer supports hvm, e.g. a simple test
program.
How to move real partitions to file backed partitions.
Using VNC/RDP/SDL.
I think heaps of examples in both networking and HVM would be excellent.
Also some notes about various operating system restrictions about changing
the hardware between reboots and how to avoid those problems.
Links to the Wiki for each section of the manual would be excellent, meaning
you would:
a) hopefully have a more up to date manual just a click away
b) have a handy reference for when you are actually updating the manual
c) harness the community to collect bits for the manual in a place handy for
you
cheers,
Woody
(sorry about top-posting - just going with the flow)
_____
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Mito
Sent: Wednesday, 10 May 2006 06:44
To: 'Alan C. Oehler'; xen-users@lists.xensource.com;
xen-devel@lists.xensource.com
Subject: RE: [Xen-users] Xen 3.0 User Manual revision
I would like to see the addition of how to use customized networking. I
finally got NAT networking working, but all documentation that I ran across
was from other sources, the Xen manual doesn't even mention NAT other than
in the sentence that says "other options are available".
Thanks for all your work!
Mito
_____
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Alan C. Oehler
Sent: Tuesday, May 09, 2006 12:46 PM
To: xen-users@lists.xensource.com; xen-devel@lists.xensource.com
Subject: [Xen-users] Xen 3.0 User Manual revision
I'm the tech writer at XenSource and I'm planning to devote some energies to
improving the Xen User Manual. To that end, I'm eliciting feedback from the
community.
Please respond here on the list if you have any notions about how the manual
might be improved, and I'll collect and review the feedback, prioritize it,
and do all I can to move it forward.
* Is anything glaringly omitted from the manual that should be there?
* Are there any sections that are notably incomplete or lacking in clarity?
* Is the current organization of the material reasonable? If not, how would
you like to see it changed?
Thanks very much!
Regards,
Alan C. Oehler
Sr. Technical Writer
XenSource, Inc.
[-- Attachment #1.2: Type: text/html, Size: 11662 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* + x86_64-move-ondemand-timer-into-own-work-queue.patch added to -mm tree
From: akpm @ 2006-05-11 4:18 UTC (permalink / raw)
To: ak, cpufreq, davej, venkatesh.pallipadi, mm-commits
The patch titled
x86_64: Move ondemand timer into own work queue
has been added to the -mm tree. Its filename is
x86_64-move-ondemand-timer-into-own-work-queue.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
From: Andi Kleen <ak@suse.de>
Taking the cpu hotplug semaphore in a normal events workqueue is unsafe
because other tasks can wait for any workqueues with it hold. This results in
a deadlock.
Move the DBS timer into its own work queue which is not affected by other work
queue flushes to avoid this.
Cc: <venkatesh.pallipadi@intel.com>
Cc: <cpufreq@lists.linux.org.uk>
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/cpufreq/cpufreq_ondemand.c | 28 +++++++++++++++++++--------
1 files changed, 20 insertions(+), 8 deletions(-)
diff -puN drivers/cpufreq/cpufreq_ondemand.c~x86_64-move-ondemand-timer-into-own-work-queue drivers/cpufreq/cpufreq_ondemand.c
--- devel/drivers/cpufreq/cpufreq_ondemand.c~x86_64-move-ondemand-timer-into-own-work-queue 2006-05-10 21:18:15.000000000 -0700
+++ devel-akpm/drivers/cpufreq/cpufreq_ondemand.c 2006-05-10 21:18:15.000000000 -0700
@@ -74,6 +74,8 @@ static unsigned int dbs_enable; /* numbe
static DEFINE_MUTEX (dbs_mutex);
static DECLARE_WORK (dbs_work, do_dbs_timer, NULL);
+static struct workqueue_struct *dbs_workq;
+
struct dbs_tuners {
unsigned int sampling_rate;
unsigned int sampling_down_factor;
@@ -364,23 +366,29 @@ static void do_dbs_timer(void *data)
mutex_lock(&dbs_mutex);
for_each_online_cpu(i)
dbs_check_cpu(i);
- schedule_delayed_work(&dbs_work,
- usecs_to_jiffies(dbs_tuners_ins.sampling_rate));
+ queue_delayed_work(dbs_workq, &dbs_work,
+ usecs_to_jiffies(dbs_tuners_ins.sampling_rate));
mutex_unlock(&dbs_mutex);
}
static inline void dbs_timer_init(void)
{
INIT_WORK(&dbs_work, do_dbs_timer, NULL);
- schedule_delayed_work(&dbs_work,
- usecs_to_jiffies(dbs_tuners_ins.sampling_rate));
+ if (!dbs_workq)
+ dbs_workq = create_singlethread_workqueue("ondemand");
+ if (!dbs_workq) {
+ printk(KERN_ERR "ondemand: Cannot initialize kernel thread\n");
+ return;
+ }
+ queue_delayed_work(dbs_workq, &dbs_work,
+ usecs_to_jiffies(dbs_tuners_ins.sampling_rate));
return;
}
static inline void dbs_timer_exit(void)
{
- cancel_delayed_work(&dbs_work);
- return;
+ if (dbs_workq)
+ cancel_rearming_delayed_workqueue(dbs_workq, &dbs_work);
}
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
@@ -489,8 +497,12 @@ static int __init cpufreq_gov_dbs_init(v
static void __exit cpufreq_gov_dbs_exit(void)
{
- /* Make sure that the scheduled work is indeed not running */
- flush_scheduled_work();
+ /* Make sure that the scheduled work is indeed not running.
+ Assumes the timer has been cancelled first. */
+ if (dbs_workq) {
+ flush_workqueue(dbs_workq);
+ destroy_workqueue(dbs_workq);
+ }
cpufreq_unregister_governor(&cpufreq_gov_dbs);
}
_
Patches currently in -mm which might be from ak@suse.de are
origin.patch
x86_64-disable-aperture-pci-region-check-in-amd64.patch
x86_64-avoid-irq0-ioapic-pin-collision.patch
x86_64-check-for-too-many-northbridges-in-iommu.patch
x86_64-fix-die_lock-nesting.patch
x86_64-add-nmi_exit-to-die_nmi.patch
x86_64-avoid-ebda-area-in-early-boot-allocator.patch
x86_64-move-ondemand-timer-into-own-work-queue.patch
git-acpi.patch
git-agpgart.patch
x86_64-mm-serialize-assign_irq_vector-use-of-static-variables-fix.patch
^ permalink raw reply
* Re: [Bugme-new] [Bug 6530] New: MAINLINE
From: Andrew Morton @ 2006-05-11 4:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: bugme-daemon, netdev, xeb
In-Reply-To: <17506.46898.503580.4994@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> Andrew Morton writes:
>
> > xeb has said:
> >
> > in this construction:
> >
> > if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
> > test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
> > ppp_output_wakeup(&ap->chan);
> >
> > if ppp_async_push() doesn't send any data i.e. XMIT_FULL is set then all
> > (transfer) hangs up while somebody push again, for instance lcp-echo.
>
> If XMIT_FULL and ppp_async_push doesn't send any data, that means the
> serial driver's output buffer was full. If that's the case, *and* we
> don't see a call to ppp_output_wakeup, then the finger points squarely
> at the serial driver as the source of the bug.
>
OK, thanks. So the next question is: which driver is being used?
^ permalink raw reply
* Ad:¡ºÎÒÊÇÍæ¼Ò¡»£¬ÓÎÏ·Íæ¼ÒµÄÍøÉϼÒÔ°£¡
From: q9PkTm2V6oUsKt3 @ 2006-05-11 4:04 UTC (permalink / raw)
To: yPCv5lJhWFRcK
¡ºÎÒÊÇÍæ¼Ò¡»ÍøÕ¾ http://iamwanjia.oicp.net/ ÊÇΪÓÎÏ·Íæ¼ÒÌṩһ¸ö»¥ÏàÈÏʶ£¬½»Á÷£¬¹µÍ¨µÄÒ»¸öÉçÇøƽ̨¡£
ÔÚÕâ¸öƽ̨ÖУ¬Ä¿Ç°ÓС°Íæ¼Ò¶Ô¶ÔÅö¡±£¬¡°ÒµÄÚ×îÐÂÏûÏ¢¡±£¬¡°×°±¸µã¿¨½»Ò×½»»»Çø¡±£¬
¡°ÓÎÏ·ÈËÉú¡±£¬ ¡°ÓéÀÖÐÝÏÐÇø¡± µÈ¶ÔÍæ¼Ò¿ª·ÅµÄÖ÷Ìâ¡£
Èç¹ûÄã¶ÔÓÎÏ·ÓÐÐËȤ£¬Çë¼ÓÈëÎÒÃÇ£¬ÎÒÃÇһͬ½¨ÉèÎÒÃÇ×Ô¼ºµÄÍøÉϼÒÔ°¡£
±¾Õ¾³¤ÆÚÕÐƸ°æÖ÷¡£»¶ÓÄã¼ÓÃË¡£
^ permalink raw reply
* Re: [RFC] [PATCH] Execute PCI quirks on resume from suspend-to-RAM
From: Carl-Daniel Hailfinger @ 2006-05-11 4:01 UTC (permalink / raw)
To: Dave Jones
Cc: Greg KH, Pavel Machek, Linux Kernel Mailing List, trenn, thoenig
In-Reply-To: <20060511023109.GB11693@redhat.com>
Dave Jones wrote:
> On Wed, May 10, 2006 at 11:36:41PM +0200, Carl-Daniel Hailfinger wrote:
> > Greg KH wrote:
> > > On Wed, May 10, 2006 at 12:30:34PM +0200, Carl-Daniel Hailfinger wrote:
> > >> Thinking about it again, if we restored the full pci config space
> > >> on resume, this quirk handling would be completely unnecessary.
> > >> Any reasons why we don't do that?
> > >
> > > We do do that. Look at pci_restore_state().
> > >
> > > Actually, look at it in the latest -mm tree, that version works better
> > > than mainline does right now :)
> >
> > Sorry. Even the version in -mm does not restore all 256 bytes, so it
> > will not change anything.
>
> You can't generically look at a PCI device past the first 32 bytes.
> *anything* could be there, including registers which cause the machine
> to lock up when they get read.
>
> This is exactly the reason that lspci by default only shows 32 bytes,
> and you need to be root to see past that limit.
You mean 64 bytes?
> > So either we really restore the full config space (probably a good idea
> > by itself)
>
> No, *really* *really* bad idea :)
I had hoped the warnings in the lspci man page would be obsolete now.
Wishful thinking, it appears. Thanks for the hint.
Unfortunately, that means we either have to introduce a new PCI_FIXUP_
type or we execute PCI_FIXUP_HEADER also on resume. Which is better?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* Re: [Bugme-new] [Bug 6530] New: MAINLINE
From: Paul Mackerras @ 2006-05-11 4:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev, xeb
In-Reply-To: <20060510202943.35f548db.akpm@osdl.org>
Andrew Morton writes:
> xeb has said:
>
> in this construction:
>
> if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
> test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
> ppp_output_wakeup(&ap->chan);
>
> if ppp_async_push() doesn't send any data i.e. XMIT_FULL is set then all
> (transfer) hangs up while somebody push again, for instance lcp-echo.
If XMIT_FULL and ppp_async_push doesn't send any data, that means the
serial driver's output buffer was full. If that's the case, *and* we
don't see a call to ppp_output_wakeup, then the finger points squarely
at the serial driver as the source of the bug.
Paul.
^ permalink raw reply
* [U-Boot-Users] questions booting Linux on a mpc8247
From: Jim Fridlund @ 2006-05-11 3:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060511034600.62949.qmail@web15901.mail.cnb.yahoo.com>
Hi Sam,
Ultimately, I would like to load a multi-boot image
kernel + ram disk in a single file off the compact
flash (IDE) drive. At the moment, I just got the IDE
driver working. I had some problems with endian issue
as my IDE interface is basically implemented as a CPLD.
Even though I'm a big endian system, the IDE registers
are little endian so I had to add special CFG arguments
to get the IDE to recognize the drive. I'm also having
problems trying to access the DOS file system. This is
something I can pursue once I get linux bootstrapped
though.
When I started with u-boot, I looked at the various
boards in the list. I used IDS8247 as a reference since
it was the same PPC8247. I realize I probably don't
have the boot parameters set up correctly (I don't
have NVRAM environment), but I figure I should still
be allowed to boot.
Here is my hardcoded info in the board specific header:
#define CONFIG_EXTRA_ENV_SETTINGS \
"netdev=eth0\0" \
"nfsargs=setenv bootargs root=/dev/nfs rw " \
"nfsroot=${serverip}:${rootpath}\0" \
"ramargs=setenv bootargs root=/dev/ram rw " \
"console=ttyS0,57600\0" \
"addip=setenv bootargs ${bootargs} " \
"ip=172.16.86.177:172.16.86.50:172.16.86.254:255.255.255.0"
\
":jim-r100:eth0:off panic=1\0" \
"flash_nfs=run nfsargs addip;" \
"bootm ${kernel_addr}\0" \
"flash_self=run ramargs addip;" \
"bootm ${kernel_addr} ${ramdisk_addr}\0" \
"net_nfs=tftp 200000 ${bootfile};run nfsargs addip;bootm\0" \
"rootpath=/opt/eldk/ppc_82xx\0" \
"bootfile=jim/uImage\0" \
"kernel_addr=ff800000\0" \
"ramdisk_addr=ffa00000\0" \
"ethaddr=00:01:47:01:02:03\0" \
"ipaddr=172.16.86.177\0" \
"serverip=172.16.86.50\0" \
"verify=y\0" \
""
#define CONFIG_BOOTCOMMAND "run flash_self"
Thanks.
--
Jim
Sam Song wrote:
> Jim Fridlund <jim@code4fun.us> wrote:
> [snip]
>> I can load the image via TFTP, but it hangs when I
>> try to run bootm. I searched in Google, but I
>
> If you can boot kernel via NFS, the problem must be
> your bootargs settings in u-boot. Try to type
> the cmdline to here for check.
>
> Regards,
>
> Sam
^ permalink raw reply
* [Bluez-users] blocking or non-blocking?
From: Sowmya Gattupalli @ 2006-05-11 3:47 UTC (permalink / raw)
To: bluez-users
[-- Attachment #1: Type: text/plain, Size: 83 bytes --]
Hi all,
Are rfcomm sockets "blocking" sockets by default???
regards
Soumya
[-- Attachment #2: Type: text/html, Size: 107 bytes --]
^ permalink raw reply
* [U-Boot-Users] questions booting Linux on a mpc8247
From: Sam Song @ 2006-05-11 3:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4462ACC9.8060206@code4fun.us>
Jim Fridlund <jim@code4fun.us> wrote:
[snip]
> I can load the image via TFTP, but it hangs when I
> try to run bootm. I searched in Google, but I
If you can boot kernel via NFS, the problem must be
your bootargs settings in u-boot. Try to type
the cmdline to here for check.
Regards,
Sam
___________________________________________________________
????????-3.5G???20M???
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] bonding: fix sparse warnings
From: Stephen Hemminger @ 2006-05-11 3:45 UTC (permalink / raw)
To: Al Viro; +Cc: ctindel, Jay Vosburgh, bonding-devel, netdev
In-Reply-To: <20060510232203.GK27946@ftp.linux.org.uk>
On Thu, 11 May 2006 00:22:03 +0100
Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, May 10, 2006 at 04:14:05PM -0700, Stephen Hemminger wrote:
> > Fix warning from sparse in bonding code about "incorrect type in assignment"
>
> *snerk*
>
> Only if you are building without -Wcast-to-as. It _is_ incorrect type in
> assignment. And the real fix is to expand the call, killing set_fs()
> in there.
More like this (in br_if.c)?
struct ethtool_cmd ecmd = { ETHTOOL_GSET };
struct ifreq ifr;
mm_segment_t old_fs;
int err;
strncpy(ifr.ifr_name, dev->name, IFNAMSIZ);
ifr.ifr_data = (void __user *) &ecmd;
old_fs = get_fs();
set_fs(KERNEL_DS);
err = dev_ethtool(&ifr);
set_fs(old_fs);
if (!err)
...
^ permalink raw reply
* Re: [PATCH] bcm43xx: Fix array overrun in bcm43xx_geo_init
From: Andrew Morton @ 2006-05-11 3:42 UTC (permalink / raw)
To: Michael Buesch; +Cc: linville, st3, bcm43xx-dev, netdev, Stephen Hemminger
In-Reply-To: <200605051723.51609.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> wrote:
>
> The problem here is that the bcm34xx driver and the ieee80211
> stack do not agree on what channels are possible for 802.11a.
> The ieee80211 stack only wants channels between 34 and 165, while
> the bcm43xx driver accepts anything from 0 to 200. I made the
> bcm43xx driver comply with the ieee80211 stack expectations, by
> using the proper constants.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
>
> [mb]: Reduce stack usage by kzalloc-ing ieee80211_geo
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
I find this changelog confusing. We seem to have two patches, one written
by Jean and one by yourself, perhaps? And the fact that the changlog
didn't start with
From: Jean Delvare <jdelvare@suse.de>
indicates that you are to be considered the primary author?
btw, we seem to have a number of bcm43xx patches banking up. I don't know
if John has merged them because we're back in the situation where some of
John's tree has been merged into Jeff's tree but hasn't gone upstream - so
my git-wireless.patch generates a massive reject storm against git-netdev.patch
So I suspect that all these bcm43xx might not be making it into 2.6.17.
^ permalink raw reply
* Re: [Bluez-devel] A2DP and VDP for BlueZ
From: Mayank Batra @ 2006-05-11 3:37 UTC (permalink / raw)
To: bluez-devel
In-Reply-To: <20060510151310.29728.qmail@web26907.mail.ukl.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
Javier,
> >Thank you very much for your comments. I was wrong. I've already seen the
> A2DP's implementation over ACL channels in the page >bluetooth-alsa.sf.net<http://bluetooth-alsa.sf.net/>
> .
>
> >On the other hand, I'd like to know if you had studied the Video
> Distribution Profile (VDP). At first, my objetives were to develop the
>
>A2DP or, if it was already implemented, the VDP. Therefore, I'm
> interested in knowing if you have implemented something similar to >a2play
> for A2DP.
>
>
VDP also makes use of AVDTP, thus it is pretty much the same, protocol wise.
So connection establishment in case of 'vplay' / 'vrecv' should be more or
less the same as in a2play/a2recv.
Only difference might be the sink capabilities.
So you'll only have to read stuff about the H.263 codec.
To begin with you can directly send the encoded file and later on try
encoding video taken from a webcam to h.263 and then stream.
Mayank
[-- Attachment #2: Type: text/html, Size: 1562 bytes --]
^ permalink raw reply
* Re: [Bugme-new] [Bug 6530] New: MAINLINE
From: Andrew Morton @ 2006-05-11 3:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: bugme-daemon, netdev, xeb
In-Reply-To: <17505.49174.848331.686297@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> Andrew Morton writes:
>
> > hm, a PPP fix. We seem to need some of those lately.
> >
> > Paul, does this look sane?
>
> /me pages in 7 year old code...
>
> > @@ -516,6 +516,8 @@ static void ppp_async_process(unsigned l
> > /* try to push more stuff out */
> > if (test_bit(XMIT_WAKEUP, &ap->xmit_flags) && ppp_async_push(ap))
> > ppp_output_wakeup(&ap->chan);
> > + else if (test_bit(XMIT_FULL, &ap->xmit_flags))
> > + ppp_asynctty_wakeup(ap->tty);
>
> ppp_asynctty_wakeup is supposed to be called by the serial driver when
> it can take more output. It's slightly bogus having ppp_async call it
> itself whether or not the serial driver can take more output at the
> moment, but I suppose it won't hurt. I would really like to know the
> precise circumstances where we need this fake wakeup though. Is the
> serial driver failing to give us a wakeup call where it should, or is
> ppp_async ignoring a wakeup for some reason?
>
> I think the same effect could be achieved without an extra trip
> through tasklet_schedule et al. by making those lines look like this
> (untested):
>
> if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
> test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
> ppp_output_wakeup(&ap->chan);
>
> so that ppp_async_push gets called if either XMIT_WAKEUP or XMIT_FULL
> is set.
>
> This is all relying on getting some input to kick off more output when
> the wakeup gets missed, though. That's a reasonable workaround in most
> situations, I guess, but I'd really like to know why the wakeup is
> getting missed.
>
(xeb, on this bug please respond via email using reply-to-all rather than
via the bugzilla web form).
xeb has said:
in this construction:
if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
ppp_output_wakeup(&ap->chan);
if ppp_async_push() doesn't send any data i.e. XMIT_FULL is set then all
(transfer) hangs up while somebody push again, for instance lcp-echo.
^ permalink raw reply
* Re: [ANNOUNCE] libata EH/NCQ/hotplug/PM git tree
From: zhao, forrest @ 2006-05-11 3:09 UTC (permalink / raw)
To: Tejun Heo
Cc: Jeff Garzik, Alan Cox, Albert Lee, Jens Axboe, Edward Falk,
Carlos Pardo, Raymond Liu, linux-ide@vger.kernel.org
In-Reply-To: <44614592.7080301@gmail.com>
On Wed, 2006-05-10 at 10:44 +0900, Tejun Heo wrote:
> Hello, all.
Tejun,
I have comments about definition of macro ata_link_for_each_dev(dev,
link) and struct ata_port{};.
In the definition of struct ata_port{}, there's
......
struct ata_link link;
struct ata_device __dev1;
......
Then macro ata_link_for_each_dev() assumes that the field 'device' in
struct ata_link is adjacent to field '__dev1' in struct ata_port.
I think this assumption is not correct in theory. Because the alignment
may make these two fields not adjacent in memory.
Although we haven't found the problem so far, it's very dangerous to
have such assumption in the code.
Does this make sense to you?
Thanks,
Forrest
^ permalink raw reply
* Re: [PATCH] smbfs: Fix slab corruption in samba error path
From: Andrew Morton @ 2006-05-11 3:16 UTC (permalink / raw)
To: Jan Niehusmann; +Cc: urban, linux-kernel, samba
In-Reply-To: <20060510103202.GA5913@knautsch.gondor.com>
Jan Niehusmann <jan@gondor.com> wrote:
>
> On Wed, May 10, 2006 at 02:25:29AM -0700, Andrew Morton wrote:
> > I think the bug is actually that this code is accessing *req after having
> > doen the smb_rput(). I worry that your patch "fixes" this by accidentally
> > leaking the request.
> >
> > We can fairly simply restructure this code so that it doesn't touch the
> > request after that possible smb_rput().
> >
> > How does this look? If "OK", are you able to test it?
>
> No, it doesn't look ok: The callers of smb_add_request (which are all in
> fs/smbfs/proc.c) do touch the req structure after calling
> smb_add_request, even if an error is returned. So your code would still
> cause access after release and double frees on the req object.
OK.
> As I understand the code smb_add_request is not allowed to completely
> release the req structure at all.
yup.
> What smb_add_request should do is
> - increase the req usage counter by one (by calling smb_rget), and add
> the req to one of the work queues
> - or leave the usage counter alone, and don't add the req to one of the
> work queues
>
> On error, one has to be careful: If we actively remove the req from the
> work queues again, we have to decrease the usage counter (otherwise we
> leak requests). But if some other function already removed the req from
> the queue, that function already did decrease the counter, so we are not
> allowed to do it again.
>
> The original code did get the latter case partly wrong. It assumed that
> the only way a req could be removed from the work queue would be in
> smb_request_recv, where the SMB_REQ_RECEIVED flag gets set. But it did
> miss the error cases in smbiod.c, eg. smbiod_flush(), where the req gets
> removed from the queues (and the usage counter decreased), without the
> SMB_REQ_RECEIVED flag being set.
>
> Therefore I changed the code to not check SMB_REQ_RECEIVED, but test if
> the req is still on one of the work queue linked lists.
>
> After that change, smb_add_request never releases the req, so reordering
> is not necessary.
yup, makes sense. It'd be nice if we knew who was doing the smb_rput()
without setting SMB_REQ_RECEIVED.
> Unfortunately it's not easy to test the patch: Of course I did check
> that it properly compiles, but the bug is not easily reproducible.
btw, is there any particular reason why you're using smbfs rather than
cifs?
I'll queue up an smbfs patch to inform people that the fs is deprecated and
I'll schedule its removal.
I tweaked your patch a bit:
diff -puN fs/smbfs/request.c~smbfs-fix-slab-corruption-in-samba-error-path fs/smbfs/request.c
--- devel/fs/smbfs/request.c~smbfs-fix-slab-corruption-in-samba-error-path 2006-05-10 20:11:53.000000000 -0700
+++ devel-akpm/fs/smbfs/request.c 2006-05-10 20:12:25.000000000 -0700
@@ -339,9 +339,11 @@ int smb_add_request(struct smb_request *
/*
* On timeout or on interrupt we want to try and remove the
* request from the recvq/xmitq.
+ * First check if the request is still part of a queue. (May
+ * have been removed by some error condition)
*/
smb_lock_server(server);
- if (!(req->rq_flags & SMB_REQ_RECEIVED)) {
+ if (!list_empty(&req->rq_queue)) {
list_del_init(&req->rq_queue);
smb_rput(req);
}
_
^ permalink raw reply
* [U-Boot-Users] questions booting Linux on a mpc8247
From: Jim Fridlund @ 2006-05-11 3:17 UTC (permalink / raw)
To: u-boot
Hi all. I am trying to load Linux on a board with a mpc8247
processor using u-boot-1.1.4 and I'm running into a problems
booting a multi-boot image (Linux kernel + ram disk).
I can load the image via TFTP, but it hangs when I try to
run bootm. I searched in Google, but I couldn't find anything
related to what I'm seeing so I'm hoping I can get some help
from the u-boot community. What I see here is that u-boot gets
a 0x200 exception because it is trying to load the ram disk
image to memory out of range. My board has 128M of memory. Here
is a snippet:
U-Boot 1.1.4 (May 10 2006 - 11:38:41)
MPC8247 Reset Status: Check Stop, External Soft, External Hard
MPC8247 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300
- dfbrg 1, corecnf 0x1a, busdf 5, cpmdf 1, plldf 0, pllmf 5
- vco_out 399999996, scc_clk 99999999, brg_clk 24999999
- cpu_clk 266666664, cpm_clk 199999998, bus_clk 66666666
- pci_clk 66666666
CPU: MPC8247 (HiP7 Rev 14, Mask 1.0 1K50M) at 266.666 MHz
Board: MPC 8247
I2C: ready
DRAM: 128 MB
FLASH: 512 kB
Using default environment
In: serial
Out: serial
Err: serial
Net: FCC1 ETHERNET
IDE: Bus 0: OK
Device 0: Model: TOSHIBA THNCF256MMA Firm: 3.10 Ser#: STCB52M6300ZC49843C5
Type: Removable Hard Disk
Capacity: 244.5 MB = 0.2 GB (500736 x 512)
Type "run flash_nfs" to mount root filesystem over NFS
=> tftp
Using FCC1 ETHERNET device
TFTP from server 172.16.86.50; our IP address is 172.16.86.177
Filename 'jim/uImage'.
Load address: 0x100000
Loading: #################################################################
...
done
Bytes transferred = 7326900 (6fccb4 hex)
=> bootm
## Booting image at 00100000 ...
Image Name: Linux with ramdisk
Created: 2006-05-10 22:01:21 UTC
Image Type: PowerPC Linux Multi-File Image (uncompressed)
Data Size: 7326836 Bytes = 7 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 2559077 Bytes = 2.4 MB
Image 1: 4767744 Bytes = 4.5 MB
Verifying Checksum ... OK
OK
Loading Ramdisk to 84344000, end 07f74064 ...
It verifies the image correctly, but the board hangs with a
0x200 exception trying to load the ram disk at 0x84344000
which is out of range. I don't know how u-boot calculates
where it stores the kernel and ram disk at the moment (this
is all magic to me). If I create an image where I specify the
load address, say 16M (0x01000000), it is able to load the ram
disk ok but hangs shortly with exception 0x200.
I generate the multi-boot image by running the following mkimage
command:
$ ./u-boot-1.1.4/tools/mkimage -A ppc -O Linux -T multi -C none -n
'Linux with ramdisk' -d vmlinux:rootfs.powerpc.ext2 uImage.img
Unfortunately, I haven't figured out how to debug u-boot after
it copies the code from rom to memory so progress has slowed.
I am using Vision Probe to debug. I can debug the code prior to
copying itself into memory, but I lose symbols once it relocates
to memory. Does anyone have any advice on how to tackle this? I
saw the GDB serial debug tutorial, but I don't have another serial
port unfortunately.
I also have a question regarding tool chain. I am using uClibC's
buildroot to build a compiler toolchain. At the moment, I am using
gcc 3.4.2 and Linux 2.4.31. I tried using gcc 4.0.2 initially, but
I had a problem with it trying to generate the proper code for
building u-boot. It appears that u-boot is using register r29 as
a global pointer and we had the following code in
./cpu/mpc8260/cpu_init.c:
void cpu_init_f (volatile immap_t * immr)
{
DECLARE_GLOBAL_DATA_PTR;
...
/* Pointer is writable since we allocated a register for it */
gd = (gd_t *) (CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET);
}
For the PPC, DECLARE_GLOBAL_DATA_PTR is defined as:
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r29")
As far as I can tell, the above statement is trying to assign
r29 the value of CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET which
is basically an offset in the PPC's internal memory for storing
global data structure. However, gcc 4.0.2 would not generate code
that sets r29 correctly. I temporarily worked around it by adding
a couple of lines in start.S:
/* Hack to initialize R29 since cpu_init_f code isn't working. */
lis r29,(CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET)@h
ori r29, r29, (CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET)@l
Is anyone using gcc 4.x to build? I reverted to gcc 3.4.2 just to
be on the safe side. Also, I noticed that Linux 2.6.x kernel doesn't
have much support for embedded mpc82xx so I ended up using Linux 2.4.31
which is the most current version that works with uClibC's buildroot.
Is there anyone doing embedded PPC development based on 2.6 kernel and
gcc 4.x? I sure would like to hear your inputs.
Lastly, is there anyone working on a TIPC implementation in u-boot?
I read the white paper on TIPC and it would seem like a nice solution
to have on a distributed/embedded cluster environment such as a
chassis where there is a single control card with multiple dummy
line cards (flashless) on a custom backplane.
Any help or pointers would be greatly appreciated. Thanks in advance.
--
Jim
^ permalink raw reply
* Re: [PATCH] add slab_is_available() routine for boot code
From: Benjamin Herrenschmidt @ 2006-05-11 3:07 UTC (permalink / raw)
To: Mike Kravetz
Cc: Andrew Morton, Arnd Bergmann, penberg, clameter, haveblue,
linux-kernel
In-Reply-To: <20060510230054.GA11214@w-mikek2.ibm.com>
> I'll let Arnd answer. He ran into this when doing some Cell work. Not
> sure where in the development cycle the code is that exposes this bug.
I want that too for some other unrelated patches :) I want request_irq()
to use alloc_bootmem when slab is not available so that some low level
arch irqs can be requested at init_IRQ() time.
(Typically IRQs for cascaded controllers). We currently define
statically irqaction structures for them and call setup_irq() on them,
this is gross :)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix
From: Mike Galbraith @ 2006-05-11 2:58 UTC (permalink / raw)
To: David S. Miller; +Cc: akpm, viro, dwalker, alan, linux-kernel
In-Reply-To: <20060510.153007.19037157.davem@davemloft.net>
On Wed, 2006-05-10 at 15:30 -0700, David S. Miller wrote:
> Even a huge tree like gcc can build itself %100 fine with -Werror, for
What's the emoticon for coffee going down your windpipe?
-Mike
^ permalink raw reply
* [KJ] [PATCH] Make function static in drivers/telephony/ixj.c
From: Matthew Martin @ 2006-05-11 2:54 UTC (permalink / raw)
To: kernel-janitors
Hello,
This makes a function in drivers/telephony/ixj.c static. The
function that was
made static is int ixj_set_tone_off.
Signed-off-by: Matthew Martin <lihnucks@gmail.com>
---
--- vanilla-linux-2.6.16/drivers/telephony/ixj.c 2006-03-19
23:53:29.000000000 -0600
+++ linux-2.6.16/drivers/telephony/ixj.c 2006-05-10
10:08:38.000000000 -0500
@@ -5712,7 +5712,7 @@ static int ixj_daa_write(IXJ *j)
return 1;
}
-int ixj_set_tone_off(unsigned short arg, IXJ *j)
+static int ixj_set_tone_off(unsigned short arg, IXJ *j)
{
j->tone_off_time = arg;
if (ixj_WriteDSPCommand(0x6E05, j)) /* Set Tone Off Period */
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* RE: [Qemu-devel] patch for ne2000.c
From: Han, Zhu @ 2006-05-11 2:51 UTC (permalink / raw)
To: qemu-devel
Any comments for this patch?
Best Regards,
hanzhu
-----Original Message-----
From: qemu-devel-bounces+zhu.han=intel.com@nongnu.org [mailto:qemu-devel-bounces+zhu.han=intel.com@nongnu.org] On Behalf Of Han, Zhu
Sent: 2006年5月9日 12:27
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] patch for ne2000.c
Hi, All!
I'm a developer working on xen project! It's well known that xen has
adopted a lot of codes and features from QEMU, especially the Device
Mode Part!
I fix a bug for ne2000 device emulation code in XEN and I expect it to
be a potential bug for QEMU, either! Because you are all device mode
experts, I submit this patch to you at first in order to ask you to
review my patch.
Several notes:
1) Because XEN use event driven mechanism in the main_loop(), irq may be
missed due to the rather high speed and large file! For example, the
ne2000_receive will filled up with the buffer and set up the ENISR_RX
signal, however, the driver could ack and clear the ENISR_RX signal due
to it could only handle a certain amount of packets once in it's
interrupt handling routine! The consequence for this specific steps is
the netcard buffer is full but it never resend the ENISR_RX signal, at
the last, the netcard will be halted! This problem could be rather rare
for QEMU. Anyway, it's a potential bug.
2) Many of the ne2000 spec said we should set boundary register should
be set to indicate the last receive buffer page the host has read, and
the driver in linux follows this guideline. So, we boundary == index,
the buffer for the netcard is full and we can't write any packets into
this buffer. This minor fix could prevent the ne2000 emulated card from
overflow and destroying the previous received packet page! This problem
could also be rare for QEMU since it could happen only under extreme
circumstance!
Any feedbacks and comments will be appreciated!
--- qemu-snapshot-2006-05-07_23\hw\ne2000.c Mon May 08 16:13:49 2006
+++ ./ne2000.c Mon May 08 16:57:33 2006
@@ -159,9 +159,19 @@
}
}
+static int ne2000_buffer_full(NE2000State *s);
static void ne2000_update_irq(NE2000State *s)
{
int isr;
+
+ if(ne2000_buffer_full(s)
+ && !(s->isr & ENISR_RX)){
+ /* The freeing space is not enough, tell the ne2k driver
+ * to fetch these packets!
+ */
+ s->isr |= ENISR_RX;
+ }
+
isr = (s->isr & s->imr) & 0x7f;
#if defined(DEBUG_NE2000)
printf("NE2000: Set IRQ line %d to %d (%02x %02x)\n",
@@ -206,7 +216,10 @@
index = s->curpag << 8;
boundary = s->boundary << 8;
- if (index < boundary)
+ if (index <= boundary)
+ /* when index == boundary, we should assume
+ * the buffer is full instead of empty!
+ */
avail = boundary - index;
else
avail = (s->stop - s->start) - (index - boundary);
Best Regards,
hanzhu
^ permalink raw reply
* Re: [PATCH] [MIPS] create consistency in "system type" selection
From: Kumba @ 2006-05-11 2:48 UTC (permalink / raw)
To: Linux/MIPS Development
In-Reply-To: <20060510102852.GA3193@linux-mips.org>
Ralf Baechle wrote:
> You still can but they need to be lumped together into a single group
> in the "System type" menu. In reality it's not terribly interesting
> and rarely tested.
>
> Ralf
Isn't the real blocker for a multi-system kernel the Load Address? I know w/
the different SGI system most of the kernels load at a different address. Is it
possible to encode all of these in a way that each system could detect them, or
would we need some kind of stub loader ala arcload that'd have to be pre-pended
onto the image to handle that for us?
--Kumba
--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees
"Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere." --Elrond
^ permalink raw reply
* Re: [RFC] [PATCH] Execute PCI quirks on resume from suspend-to-RAM
From: Dave Jones @ 2006-05-11 2:31 UTC (permalink / raw)
To: Carl-Daniel Hailfinger
Cc: Greg KH, Pavel Machek, Linux Kernel Mailing List, trenn, thoenig
In-Reply-To: <44625CE9.2060204@gmx.net>
On Wed, May 10, 2006 at 11:36:41PM +0200, Carl-Daniel Hailfinger wrote:
> Greg KH wrote:
> > On Wed, May 10, 2006 at 12:30:34PM +0200, Carl-Daniel Hailfinger wrote:
> >> Thinking about it again, if we restored the full pci config space
> >> on resume, this quirk handling would be completely unnecessary.
> >> Any reasons why we don't do that?
> >
> > We do do that. Look at pci_restore_state().
> >
> > Actually, look at it in the latest -mm tree, that version works better
> > than mainline does right now :)
>
> Sorry. Even the version in -mm does not restore all 256 bytes, so it
> will not change anything.
You can't generically look at a PCI device past the first 32 bytes.
*anything* could be there, including registers which cause the machine
to lock up when they get read.
This is exactly the reason that lspci by default only shows 32 bytes,
and you need to be root to see past that limit.
> So either we really restore the full config space (probably a good idea
> by itself)
No, *really* *really* bad idea :)
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Linux kernel 2.6.16.16 released
From: Linux Kernel Distribution System @ 2006-05-11 2:27 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 2.6.16.16 has been released. It is available from:
Patch: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/patch-2.6.16.16.bz2
Full source: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.16.tar.bz2
Sizes in bytes Compressed Uncompressed
------------------------------------------------------------
Patch 44544 164835
Full source 40837107 233953280
-----------------------------------------------------------------------------
This is an automatically generated message. To unsubscribe from this list,
please send a message to majordomo@vger.kernel.org containing
the line:
unsubscribe linux-kernel-announce <your_email_address>
... where <your_email_address> is the email address you are receiving
this message at.
-----------------------------------------------------------------------------
The following files were changed in this release:
arch/m32r/lib/getuser.S | 88 -------
arch/m32r/lib/putuser.S | 84 -------
b/Documentation/dvb/get_dvb_firmware | 8
b/Makefile | 2
b/arch/alpha/kernel/setup.c | 17 +
b/arch/alpha/kernel/smp.c | 8
b/arch/alpha/lib/strncpy.S | 8
b/arch/i386/kernel/apm.c | 2
b/arch/i386/kernel/cpu/amd.c | 2
b/arch/i386/kernel/cpu/cpufreq/Kconfig | 1
b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c | 2
b/arch/i386/kernel/cpu/cpufreq/speedstep-smi.c | 4
b/arch/i386/kernel/dmi_scan.c | 2
b/arch/i386/kernel/vm86.c | 12 -
b/arch/m32r/kernel/m32r_ksyms.c | 4
b/arch/m32r/kernel/setup.c | 12 -
b/arch/m32r/kernel/smpboot.c | 19 -
b/arch/m32r/lib/Makefile | 4
b/arch/mips/kernel/branch.c | 2
b/arch/mips/mm/c-r4k.c | 3
b/arch/powerpc/kernel/pci_64.c | 1
b/arch/powerpc/kernel/setup_64.c | 10
b/arch/powerpc/kernel/signal_64.c | 2
b/arch/x86_64/ia32/Makefile | 4
b/arch/x86_64/kernel/entry.S | 28 --
b/arch/x86_64/kernel/pci-gart.c | 4
b/arch/x86_64/kernel/process.c | 8
b/arch/x86_64/kernel/setup.c | 4
b/block/genhd.c | 103 ---------
b/drivers/base/cpu.c | 2
b/drivers/base/firmware_class.c | 6
b/drivers/base/node.c | 2
b/drivers/block/cciss.c | 98 ++++----
b/drivers/char/Kconfig | 1
b/drivers/char/agp/efficeon-agp.c | 8
b/drivers/char/cs5535_gpio.c | 5
b/drivers/char/ipmi/ipmi_bt_sm.c | 2
b/drivers/char/snsc.c | 3
b/drivers/char/sonypi.c | 3
b/drivers/char/tipar.c | 2
b/drivers/char/tlclk.c | 37 +--
b/drivers/char/tty_io.c | 8
b/drivers/edac/Kconfig | 2
b/drivers/i2c/busses/i2c-i801.c | 5
b/drivers/i2c/chips/m41t00.c | 8
b/drivers/ide/pci/alim15x3.c | 2
b/drivers/ieee1394/sbp2.c | 32 +-
b/drivers/macintosh/therm_adt746x.c | 4
b/drivers/md/dm-snap.c | 6
b/drivers/md/dm.c | 48 ++--
b/drivers/md/kcopyd.c | 17 +
b/drivers/media/dvb/dvb-usb/cxusb.c | 17 +
b/drivers/media/video/Kconfig | 1
b/drivers/media/video/saa7127.c | 1
b/drivers/media/video/tuner-types.c | 4
b/drivers/mtd/nand/Kconfig | 17 -
b/drivers/net/e1000/e1000_main.c | 1
b/drivers/net/irda/irda-usb.c | 5
b/drivers/net/sky2.c | 4
b/drivers/net/sky2.h | 1
b/drivers/net/wireless/Kconfig | 5
b/drivers/net/wireless/hostap/hostap_80211_tx.c | 2
b/drivers/net/wireless/ipw2200.c | 5
b/drivers/pcmcia/ds.c | 2
b/drivers/scsi/3w-9xxx.c | 8
b/drivers/scsi/3w-xxxx.c | 3
b/drivers/scsi/sata_mv.c | 7
b/drivers/usb/core/message.c | 12 -
b/drivers/usb/host/ehci-sched.c | 11
b/drivers/usb/serial/console.c | 2
b/drivers/usb/serial/option.c | 4
b/drivers/usb/storage/Kconfig | 3
b/drivers/video/cfbimgblt.c | 2
b/drivers/video/fbmem.c | 14 -
b/drivers/video/i810/i810_main.c | 2
b/fs/9p/vfs_inode.c | 3
b/fs/char_dev.c | 87 -------
b/fs/cifs/cifsencrypt.c | 36 ++-
b/fs/cifs/dir.c | 14 +
b/fs/compat.c | 4
b/fs/ext3/resize.c | 1
b/fs/fuse/file.c | 8
b/fs/locks.c | 30 +-
b/fs/nfsd/nfs3proc.c | 2
b/fs/nfsd/nfs4proc.c | 2
b/fs/nfsd/nfsproc.c | 2
b/fs/open.c | 24 +-
b/fs/partitions/check.c | 5
b/fs/proc/base.c | 21 +
b/fs/proc/proc_misc.c | 163 +++-----------
b/fs/proc/vmcore.c | 4
b/fs/reiserfs/xattr_acl.c | 5
b/fs/smbfs/dir.c | 5
b/fs/sysfs/dir.c | 1
b/fs/sysfs/file.c | 2
b/fs/sysfs/inode.c | 6
b/fs/sysfs/symlink.c | 1
b/fs/xfs/linux-2.6/xfs_aops.c | 2
b/fs/xfs/linux-2.6/xfs_iops.c | 3
b/include/asm-i386/cpufeature.h | 1
b/include/asm-i386/i387.h | 30 ++
b/include/asm-i386/pgtable-2level.h | 3
b/include/asm-i386/pgtable-3level.h | 20 +
b/include/asm-i386/pgtable.h | 4
b/include/asm-m32r/smp.h | 3
b/include/asm-m32r/uaccess.h | 266 ++++++++++--------------
b/include/asm-mips/bitops.h | 14 +
b/include/asm-mips/byteorder.h | 4
b/include/asm-mips/interrupt.h | 8
b/include/asm-mips/r4kcache.h | 2
b/include/asm-powerpc/floppy.h | 5
b/include/asm-x86_64/cpufeature.h | 1
b/include/asm-x86_64/i387.h | 20 +
b/include/linux/cpu.h | 2
b/include/linux/cpumask.h | 1
b/include/linux/fb.h | 2
b/include/linux/fs.h | 15 -
b/include/linux/mm.h | 5
b/include/linux/page-flags.h | 8
b/include/linux/proc_fs.h | 2
b/include/linux/raid/raid1.h | 2
b/include/linux/rtc.h | 4
b/include/net/ip.h | 1
b/include/net/sctp/structs.h | 1
b/ipc/shm.c | 2
b/ipc/util.c | 3
b/kernel/auditsc.c | 5
b/kernel/exec_domain.c | 1
b/kernel/fork.c | 2
b/kernel/power/process.c | 3
b/kernel/ptrace.c | 7
b/kernel/sched.c | 9
b/kernel/signal.c | 6
b/kernel/sys.c | 14 +
b/kernel/uid16.c | 59 ++++-
b/mm/madvise.c | 3
b/mm/page_alloc.c | 31 +-
b/net/atm/clip.c | 42 ++-
b/net/bridge/br_netfilter.c | 13 -
b/net/core/dev.c | 2
b/net/core/sock.c | 5
b/net/ipv4/fib_trie.c | 12 -
b/net/ipv4/ip_output.c | 12 -
b/net/ipv4/netfilter/ip_conntrack_netlink.c | 2
b/net/ipv4/netfilter/ip_conntrack_proto_sctp.c | 11
b/net/ipv4/route.c | 5
b/net/ipv4/tcp_output.c | 4
b/net/ipv6/exthdrs.c | 12 +
b/net/ipv6/xfrm6_policy.c | 8
b/net/netfilter/nf_conntrack_netlink.c | 2
b/net/netfilter/nf_conntrack_proto_sctp.c | 11
b/net/sctp/inqueue.c | 1
b/net/sctp/sm_statefuns.c | 59 +++--
b/net/sctp/sm_statetable.c | 10
b/net/sctp/ulpqueue.c | 27 ++
b/security/keys/key.c | 4
b/security/keys/keyring.c | 1
b/security/selinux/ss/mls.c | 2
b/sound/isa/opti9xx/opti92x-ad1848.c | 6
b/sound/oss/dmasound/tas_common.c | 4
b/sound/pci/hda/patch_realtek.c | 2
b/sound/ppc/daca.c | 2
b/sound/ppc/tumbler.c | 2
163 files changed, 1066 insertions(+), 1077 deletions(-)
^ permalink raw reply
* Re: Linux 2.6.16.16
From: Chris Wright @ 2006-05-11 2:29 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds
In-Reply-To: <20060511022547.GE25010@moss.sous-sol.org>
diff --git a/Makefile b/Makefile
index cdd3ce7..b93f75f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 16
-EXTRAVERSION = .15
+EXTRAVERSION = .16
NAME=Sliding Snow Leopard
# *DOCUMENTATION*
diff --git a/fs/locks.c b/fs/locks.c
index e75ac39..aa7f660 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -432,15 +432,14 @@ static struct lock_manager_operations le
*/
static int lease_init(struct file *filp, int type, struct file_lock *fl)
{
+ if (assign_type(fl, type) != 0)
+ return -EINVAL;
+
fl->fl_owner = current->files;
fl->fl_pid = current->tgid;
fl->fl_file = filp;
fl->fl_flags = FL_LEASE;
- if (assign_type(fl, type) != 0) {
- locks_free_lock(fl);
- return -EINVAL;
- }
fl->fl_start = 0;
fl->fl_end = OFFSET_MAX;
fl->fl_ops = NULL;
@@ -452,16 +451,19 @@ static int lease_init(struct file *filp,
static int lease_alloc(struct file *filp, int type, struct file_lock **flp)
{
struct file_lock *fl = locks_alloc_lock();
- int error;
+ int error = -ENOMEM;
if (fl == NULL)
- return -ENOMEM;
+ goto out;
error = lease_init(filp, type, fl);
- if (error)
- return error;
+ if (error) {
+ locks_free_lock(fl);
+ fl = NULL;
+ }
+out:
*flp = fl;
- return 0;
+ return error;
}
/* Check if two locks overlap each other.
@@ -1337,6 +1339,7 @@ static int __setlease(struct file *filp,
goto out;
if (my_before != NULL) {
+ *flp = *my_before;
error = lease->fl_lmops->fl_change(my_before, arg);
goto out;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.