Re: [RFC] Per-thread getrusage
Andrew Morton wrote: > On Thu, 17 Jan 2008 13:57:05 +0530 Vinay Sridhar <[EMAIL PROTECTED]> > wrote: > >> Hi All, >> >> Last year, there was discussion about per-thread getrusage by adding >> RUSAGE_THREAD flag to getrusage(). Please refer to the thread >> http://lkml.org/lkml/2007/4/4/308. Ulrich had suggested that we should >> design a better user-space API. Specifically, we need a >> pthread_getrusage interface in the thread library, which accepts >> pthread_t, converts pthread_t into the corresponding tid and passes it >> down to the syscall. >> >> There are two ways to implement this in the kernel: >> 1) Introduce an additional parameter 'tid' to sys_getrusage() and put >> code in glibc to handle getrusage() and pthread_getrusage() calls >> correctly. >> 2) Introduce a new system call to handle pthread_getrusage() and leave >> sys_getrusage() untouched. >> >> We implemented the second idea above, simply because it avoids touching >> any existing code. We have implemented a new syscall, thread_getrusage() >> and we have exposed pthread_getrusage() API to applications. >> >> Could you please share your thoughts on this? Does the approach look >> alright? The code is hardly complete. It is just a prototype that works >> on IA32 at the moment. >> >> ... >> >> +asmlinkage long sys_thread_getrusage(int tid, struct rusage __user *ru); > > What happens if `tid' refers to a thread in a different pid namespace? > That's impossible. I explicitly deny namespace creation in case the CLONE_THREAD is specified. So all threads of a single process always live in one pid namespace. Thanks, Pavel -- 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/
Re: [PATCH v2 8/9] bfs: remove multiple assignments
-inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME_SEC; +inode->i_mtime = CURRENT_TIME_SEC; +inode->i_atime = CURRENT_TIME_SEC; +inode->i_ctime = CURRENT_TIME_SEC; multiple assignments like "x = y = z = value;" can potentially (depending on the compiler and arch) be faster than "x = value; y = value; z=value;" I am surprized that this script complains about them as it is a perfectly valid thing to do in C. I think it seems wise to ask the maintainers of checkpatch.pl to comment on that. I'm Cc:ing them now. There are plenty of things that are valid to do in C that don't make for maintainable code. These scripts are designed to make your code easier for real people to review and maintain. As for if this can be faster we don't deal in the realm of "can". Please show a concrete example of gcc making Linux kernel code faster with multiple assignments per line. If you can do that I'm willing to change my mind and I'll lead the charge for mutliple assignments per line. -- 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/
Re: [PATCH] remove duplicating priority setting in try_to_free_p
On Jan 28, 2008 2:33 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Sat, 26 Jan 2008 02:29:23 -0500 "minchan kim" <[EMAIL PROTECTED]> wrote:
>
> > shrink_zones in try_to_free_pages already set zone through
> > note_zone_scanning_priority.
> > So, setting prev_priority in try_to_free_pages is needless.
> >
> > This patch is made by 2.6.24-rc8.
> >
> > Signed-off-by: barrios <[EMAIL PROTECTED]>
> > ---
> > mm/vmscan.c | 17 -
> > 1 files changed, 0 insertions(+), 17 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index e5a9597..fc55c23 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1273,23 +1273,6 @@ unsigned long try_to_free_pages(struct z
> > if (!sc.all_unreclaimable)
> > ret = 1;
> > out:
> > - /*
> > -* Now that we've scanned all the zones at this priority level, note
> > -* that level within the zone so that the next thread which performs
> > -* scanning of this zone will immediately start out at this priority
> > -* level. This affects only the decision whether or not to bring
> > -* mapped pages onto the inactive list.
> > -*/
> > - if (priority < 0)
> > - priority = 0;
> > - for (i = 0; zones[i] != NULL; i++) {
> > - struct zone *zone = zones[i];
> > -
> > - if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
> > - continue;
> > -
> > - zone->prev_priority = priority;
> > - }
> > return ret;
> > }
>
> (your mail client is replacing tabs with spaces)
Thank for your kindness.
> I think this is actually a bugfix. The code you're removing doesn't do the
>
> if (priority < zone->prev_priority)
>
> thing.
>
shrink_zones() in try_to_free_pages() already called
note_zone_scanning_priority().
So, it have done it.
> otoh with this change, the only thing which will cause prev_priority to
> increase (ie: lower priority) is kswapd, which seems odd.
>
So, There is not only kswapd but also direct page reclaim.
> So:
>
> a) this is a functional change and needs more thought and lots of runtime
>testing. I'll duck it for now.
>
> b) the prev_priority stuff is still screwed up.
>
--
Kinds regards,
barrios
--
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/
Re: [PATCH] Only print kernel debug information for OOMs caused by kernel allocations
On Monday 28 January 2008 06:52, Andrew Morton wrote:
> On Wed, 16 Jan 2008 23:24:21 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > I recently suffered an 20+ minutes oom thrash disk to death and computer
> > completely unresponsive situation on my desktop when some user program
> > decided to grab all memory. It eventually recovered, but left lots
> > of ugly and imho misleading messages in the kernel log. here's a minor
> > improvement
As a followup this was with swap over dm crypt. I've recently heard
about other people having trouble with this too so this setup seems to trigger
something bad in the VM.
> That information is useful for working out why a userspace allocation
> attempt failed. If we don't print it, and the application gets killed and
> thus frees a lot of memory, we will just never know why the allocation
> failed.
But it's basically only either page fault (direct or indirect) or write et.al.
who do these page cache allocations. Do you really think it is that important
to distingush these cases individually? In 95+% of all cases it should
be a standard user page fault which always has the same backtrace.
To figure out why the application really oom'ed for those you would
need a user level backtrace, but the message doesn't supply that one anyways.
All other cases will still print the full backtrace so if some kernel
subsystem runs amok it should be still possible to diagnose it.
Please reconsider.
>
> > struct page *__page_cache_alloc(gfp_t gfp)
> > {
> > + struct task_struct *me = current;
> > + unsigned old = (~me->flags) & PF_USER_ALLOC;
> > + struct page *p;
> > +
> > + me->flags |= PF_USER_ALLOC;
> > if (cpuset_do_page_mem_spread()) {
> > int n = cpuset_mem_spread_node();
> > - return alloc_pages_node(n, gfp, 0);
> > - }
> > - return alloc_pages(gfp, 0);
> > + p = alloc_pages_node(n, gfp, 0);
> > + } else
> > + p = alloc_pages(gfp, 0);
> > + /* Clear USER_ALLOC if it wasn't set originally */
> > + me->flags ^= old;
> > + return p;
> > }
>
> That's appreciable amount of new overhead for at best a fairly marginal
> benefit. Perhaps __GFP_USER could be [re|ab]used.
It's a few non atomic bit operations. You really think that is considerable
overhead? Also all should be cache hot already. My guess is that even with the
additional function call it's < 10 cycles more.
> Alternatively: if we've printed the diagnostic on behalf of this process
> and then decided to kill it, set some flag to prevent us from printing it
> again.
Do you really think that would help? I thought these messages came usually
from different processes.
-Andi
--
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/
Re: [patch 24/26] mount options: fix tmpfs
On Thu, 24 Jan 2008, Miklos Szeredi wrote:
>
Thanks Miklos, that's a welcome enhancement, nicely done. I've only
noticed one thing wrong (MPOL_PREFERRED shown as "default"); but thought
shmem_config didn't add much value - I'd rather avoid those syntactic
changes to unchanged code; and several tmpfs defaults being relative
(e.g. to totalram_pages, or to mounter's fsuid), I ended up preferring
to do real tests in shmem_show_options.
Thus, for example, if memory is hotplugged in or out later, what started
out as an unspecified size option will then get shown as explicit size.
(I did think for a while that I wanted to show explicit size in all
cases; but it looked pretty silly on udev.) I think that's the correct
behaviour, that otherwise would be misleading; but I may be looking at
this the wrong way round, what's your view?
If you agree with the version below, please take it into your collection
and insert your Signed-off-by. I should admit, I've not yet tested how
the NUMA policies look: you'll hear from me again tomorrow morning if
those turn out to wrong.
Hugh
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add .show_options super operation to tmpfs.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---
include/linux/shmem_fs.h |5
mm/shmem.c | 189 -
2 files changed, 129 insertions(+), 65 deletions(-)
--- 2.6.24-rc8-mm1/include/linux/shmem_fs.h 2006-11-29 21:57:37.0
+
+++ linux/include/linux/shmem_fs.h 2008-01-27 22:42:52.0 +
@@ -30,9 +30,12 @@ struct shmem_sb_info {
unsigned long free_blocks; /* How many are left for allocation */
unsigned long max_inodes; /* How many inodes are allowed */
unsigned long free_inodes; /* How many are left for allocation */
+ spinlock_t stat_lock; /* Serialize shmem_sb_info changes */
+ uid_t uid; /* Mount uid for root directory */
+ gid_t gid; /* Mount gid for root directory */
+ mode_t mode;/* Mount mode for root directory */
int policy; /* Default NUMA memory alloc policy */
nodemask_t policy_nodes;/* nodemask for preferred and bind */
- spinlock_tstat_lock;
};
static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
--- 2.6.24-rc8-mm1/mm/shmem.c 2008-01-17 16:51:21.0 +
+++ linux/mm/shmem.c2008-01-27 23:41:31.0 +
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1068,7 +1069,8 @@ redirty:
}
#ifdef CONFIG_NUMA
-static inline int shmem_parse_mpol(char *value, int *policy, nodemask_t
*policy_nodes)
+#ifdef CONFIG_TMPFS
+static int shmem_parse_mpol(char *value, int *policy, nodemask_t *policy_nodes)
{
char *nodelist = strchr(value, ':');
int err = 1;
@@ -1117,6 +1119,42 @@ out:
return err;
}
+static void shmem_show_mpol(struct seq_file *seq, int policy,
+ const nodemask_t policy_nodes)
+{
+ char *policy_string;
+
+ switch (policy) {
+ case MPOL_PREFERRED:
+ policy_string = "prefer";
+ break;
+ case MPOL_BIND:
+ policy_string = "bind";
+ break;
+ case MPOL_INTERLEAVE:
+ policy_string = "interleave";
+ break;
+ default:
+ /* MPOL_DEFAULT */
+ return;
+ }
+
+ seq_printf(seq, ",mpol=%s", policy_string);
+
+ if (policy != MPOL_INTERLEAVE ||
+ !nodes_equal(policy_nodes, node_states[N_HIGH_MEMORY])) {
+ char buffer[64];
+ int len;
+
+ len = nodelist_scnprintf(buffer, sizeof(buffer), policy_nodes);
+ if (len < sizeof(buffer))
+ seq_printf(seq, ":%s", buffer);
+ else
+ seq_printf(seq, ":?");
+ }
+}
+#endif /* CONFIG_TMPFS */
+
static struct page *shmem_swapin(swp_entry_t entry, gfp_t gfp,
struct shmem_inode_info *info, unsigned long idx)
{
@@ -1148,13 +1186,20 @@ static struct page *shmem_alloc_page(gfp
mpol_free(pvma.vm_policy);
return page;
}
-#else
+#else /* !CONFIG_NUMA */
+#ifdef CONFIG_TMPFS
static inline int shmem_parse_mpol(char *value, int *policy,
nodemask_t *policy_nodes)
{
return 1;
}
+static inline void shmem_show_mpol(struct seq_file *seq, int policy,
+ const nodemask_t policy_nodes)
+{
+}
+#endif /* CONFIG_TMPFS */
+
static inline struct page *shmem_swapin(swp_entry_t entry, gfp_t gfp,
struct shmem_inode_info *info, unsigned long idx)
{
@@ -1166,7 +1211,7 @@ static inline struct page *shmem_alloc_p
{
return alloc_page(gfp);
}
-#endif
+#endif /* CONFIG_NUMA */
/*
* shmem_getpage - either get the page from swap or allocate a n
Re: [PATCH] [3/18] BKL-removal: Convert ext3 to use unlocked_ioctl
On Monday 28 January 2008 06:33, Andrew Morton wrote: > On Sun, 27 Jan 2008 03:17:09 +0100 (CET) Andi Kleen <[EMAIL PROTECTED]> wrote: > > I checked ext3_ioctl and it looked largely safe to not be used > > without BKL. So convert it over to unlocked_ioctl. > > > > The only case where I wasn't quite sure was for the > > dynamic fs grow ioctls versus umounting -- I kept the BKL for those. > > Please cpoy linux-ext4 on ext2/3/4 material. Ok I'll resubmit those to tytso/ext4-devel (or perhaps he has already seen them) > > I skippped a lot of these patches because I just got bored of fixing > rejects. Now is a very optimistic time to be raising patches against > mainline. JFS and CIFS are already taken care of by the maintainers. This leaves remote_llseek which touches a couple of file systems. Could you perhaps take that one only please? And perhaps Nick's minix patchkit which looks safe to me and is unlikely to cause conflicts. > > + /* AK: not sure the BKL is needed, but this might prevent > > +* races against umount */ > > + lock_kernel(); > > err = ext3_group_add(sb, &input); > > journal_lock_updates(EXT3_SB(sb)->s_journal); > > journal_flush(EXT3_SB(sb)->s_journal); > > journal_unlock_updates(EXT3_SB(sb)->s_journal); > > + unlock_kernel(); > > The ext3_ioctl() caller has an open fd against the fs - should be > sufficient to keep unmount away? True. I am still conservative because group_add is a lot of code which I didn't fully check. But with the open fd it's likely safe to not take the BKL because there is nothing else (except readdir?) in ext* that takes it. > It's all reached the stage of stupid. I'll resubmit ->fasync_unlocked against -mm. Also I wanted to recheck the ->f_flags locking. I found one bug in those already and I can extract the bug fix for that one. -Andi -- 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/
Re: [PATCH] SH/Dreamcast - add support for GD-Rom CDROM drive on SEGA Dreamcast
On Sun, Jan 27, 2008 at 09:33:23PM -0800, Andrew Morton wrote: > On Fri, 18 Jan 2008 09:56:33 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote: > > > On Thu, Jan 17, 2008 at 10:30:06PM +, Adrian McMenamin wrote: > > > From: Adrian McMenamin <[EMAIL PROTECTED]> > > > > > > This patch adds support for the GD-Rom drive, SEGA's proprietary > > > implementation of an IDE CD Rom for the SEGA Dreamcast. This driver > > > implements Sega's Packet Interface (SPI) - at least partially. It will > > > also read disks in SEGA's propreitary GD format. > > > > > > Unlike previous drivers (which were never in mainline) this uses DMA and > > > not PIO to read disks. It is a new driver, not a refactoring of old > > > drivers. > > > > > > I hope I've fixed all the white space and other issues now! > > > > > > Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]> > > > > > Looks good to me. I'll add it to my queue unless Andrew has any glaring > > objections. > > Looks like a driver to me, but Jens is mostly-cdrom-maintainer. Indeed, his Acked-by was already collected, so I've added it to my tree. -- 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/
Re: [RFC] Per-thread getrusage
On Thu, 17 Jan 2008 13:57:05 +0530 Vinay Sridhar <[EMAIL PROTECTED]> wrote: > Hi All, > > Last year, there was discussion about per-thread getrusage by adding > RUSAGE_THREAD flag to getrusage(). Please refer to the thread > http://lkml.org/lkml/2007/4/4/308. Ulrich had suggested that we should > design a better user-space API. Specifically, we need a > pthread_getrusage interface in the thread library, which accepts > pthread_t, converts pthread_t into the corresponding tid and passes it > down to the syscall. > > There are two ways to implement this in the kernel: > 1) Introduce an additional parameter 'tid' to sys_getrusage() and put > code in glibc to handle getrusage() and pthread_getrusage() calls > correctly. > 2) Introduce a new system call to handle pthread_getrusage() and leave > sys_getrusage() untouched. > > We implemented the second idea above, simply because it avoids touching > any existing code. We have implemented a new syscall, thread_getrusage() > and we have exposed pthread_getrusage() API to applications. > > Could you please share your thoughts on this? Does the approach look > alright? The code is hardly complete. It is just a prototype that works > on IA32 at the moment. > > ... > > +asmlinkage long sys_thread_getrusage(int tid, struct rusage __user *ru); What happens if `tid' refers to a thread in a different pid namespace? -- 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/
Re: [PATCH] Convert reiserfs_ioctl() to an unlocked_ioctl
I get a massive reject when applying this. As usual. I'm afraid that the days when one could prepare 2.6.x patches against the 2.6.x-1 tree are long past us. Please resend after 2.6.25-rc1 or, better, redo against the most-recently-released -mm kernel or, better, redo against http://userweb.kernel.org/~akpm/mmotm/ -- 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/
Re: [PATCH] Only print kernel debug information for OOMs caused by kernel allocations
On Wed, 16 Jan 2008 23:24:21 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> I recently suffered an 20+ minutes oom thrash disk to death and computer
> completely unresponsive situation on my desktop when some user program
> decided to grab all memory. It eventually recovered, but left lots
> of ugly and imho misleading messages in the kernel log. here's a minor
> improvement
>
> -Andi
>
> ---
>
> Only print kernel debug information for OOMs caused by kernel allocations
>
> For any page cache allocation don't print the backtrace and the detailed
> zone debugging information. This makes the problem look less like
> a kernel bug because it typically isn't.
>
> I needed a new task flag for that. Since the bits are running low
> I reused an unused one (PF_STARTING)
>
> Also clarify the error message (OOM means nothing to a normal user)
>
That information is useful for working out why a userspace allocation
attempt failed. If we don't print it, and the application gets killed and
thus frees a lot of memory, we will just never know why the allocation
failed.
> struct page *__page_cache_alloc(gfp_t gfp)
> {
> + struct task_struct *me = current;
> + unsigned old = (~me->flags) & PF_USER_ALLOC;
> + struct page *p;
> +
> + me->flags |= PF_USER_ALLOC;
> if (cpuset_do_page_mem_spread()) {
> int n = cpuset_mem_spread_node();
> - return alloc_pages_node(n, gfp, 0);
> - }
> - return alloc_pages(gfp, 0);
> + p = alloc_pages_node(n, gfp, 0);
> + } else
> + p = alloc_pages(gfp, 0);
> + /* Clear USER_ALLOC if it wasn't set originally */
> + me->flags ^= old;
> + return p;
> }
That's appreciable amount of new overhead for at best a fairly marginal
benefit. Perhaps __GFP_USER could be [re|ab]used.
Alternatively: if we've printed the diagnostic on behalf of this process
and then decided to kill it, set some flag to prevent us from printing it
again.
--
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/
(Try#3) [Patch] Shut up warnings from files under drivers/
On Sun, Jan 27, 2008 at 10:21:00AM +0100, Sam Ravnborg wrote:
>Hi WANG.
>
>Thanks for chasing these annoying warnings - it is
>good to keep the warning level low so we keep
>attention when new warnings happens!
>
>> index d775eb6..eec1624 100644
>> --- a/drivers/video/aty/atyfb_base.c
>> +++ b/drivers/video/aty/atyfb_base.c
>> @@ -244,7 +244,9 @@ static int atyfb_sync(struct fb_info *info);
>> */
>>
>> static int aty_init(struct fb_info *info);
>> +#if defined(CONFIG_PM) && defined(CONFIG_PCI)
>> static void aty_resume_chip(struct fb_info *info);
>> +#endif
>
>It is preferable to have the forward declaration unconditional
>to keep the #if/#endif count low.
>
>
>> #endif
>> @@ -2709,6 +2711,7 @@ aty_init_exit:
>> return -1;
>> }
>>
>> +#if defined(CONFIG_PM) && defined(CONFIG_PCI)
>> static void aty_resume_chip(struct fb_info *info)
>> {
>> struct atyfb_par *par = info->par;
>> @@ -2721,6 +2724,7 @@ static void aty_resume_chip(struct fb_info *info)
>> if (par->aux_start)
>> aty_st_le32(BUS_CNTL, aty_ld_le32(BUS_CNTL, par) |
>> BUS_APER_REG_DIS, par);
>> }
>> +#endif
>
>Moving the aty_resume_chip() function down just above
>atyfb_pci_resume() would put in in the same #if/#endif
>block and you can kill the forward declaration too.
>Did you try that out?
Yes, it works.
Here's the updated patch, and I dropped the drivers/char/applicom.c
part as Jiri Slaby has better fix.
--->
Fix defined-but-not-used warnings from files under drivers/,
such as:
drivers/video/aty/atyfb_base.c:2713: warning: ‘aty_resume_chip’ defined but not
used
Compile tests passed.
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Jiri Slaby <[EMAIL PROTECTED]>
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
index 905d1f5..ae1f565 100644
--- a/drivers/char/synclink.c
+++ b/drivers/char/synclink.c
@@ -897,7 +897,6 @@ static char *driver_version = "$Revision: 4.38 $";
static int synclink_init_one (struct pci_dev *dev,
const struct pci_device_id *ent);
-static void synclink_remove_one (struct pci_dev *dev);
static struct pci_device_id synclink_pci_tbl[] = {
{ PCI_VENDOR_ID_MICROGATE, PCI_DEVICE_ID_MICROGATE_USC, PCI_ANY_ID,
PCI_ANY_ID, },
@@ -908,6 +907,10 @@ MODULE_DEVICE_TABLE(pci, synclink_pci_tbl);
MODULE_LICENSE("GPL");
+static void __devexit synclink_remove_one (struct pci_dev *dev)
+{
+}
+
static struct pci_driver synclink_pci_driver = {
.name = "synclink",
.id_table = synclink_pci_tbl,
@@ -8166,7 +8169,3 @@ static int __devinit synclink_init_one (struct pci_dev
*dev,
return 0;
}
-static void __devexit synclink_remove_one (struct pci_dev *dev)
-{
-}
-
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index dfbf24c..f33f82a 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2730,7 +2730,7 @@ err_out_disable_pci_device:
return err;
}
-static void hifn_remove(struct pci_dev *pdev)
+static void __devexit hifn_remove(struct pci_dev *pdev)
{
int i;
struct hifn_device *dev;
diff --git a/drivers/telephony/ixj.c b/drivers/telephony/ixj.c
index 49cd979..1549c0b 100644
--- a/drivers/telephony/ixj.c
+++ b/drivers/telephony/ixj.c
@@ -284,7 +284,7 @@ static int samplerate = 100;
module_param(ixjdebug, int, 0);
-static struct pci_device_id ixj_pci_tbl[] __devinitdata = {
+static struct pci_device_id ixj_pci_tbl[] __used __devinitdata = {
{ PCI_VENDOR_ID_QUICKNET, PCI_DEVICE_ID_QUICKNET_XJ,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{ }
diff --git a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
index cbd3308..4e57fcf 100644
--- a/drivers/video/aty/aty128fb.c
+++ b/drivers/video/aty/aty128fb.c
@@ -165,7 +165,7 @@ static const char *r128_family[] __devinitdata = {
*/
static int aty128_probe(struct pci_dev *pdev,
const struct pci_device_id *ent);
-static void aty128_remove(struct pci_dev *pdev);
+static void __devexit aty128_remove(struct pci_dev *pdev);
static int aty128_pci_suspend(struct pci_dev *pdev, pm_message_t state);
static int aty128_pci_resume(struct pci_dev *pdev);
static int aty128_do_resume(struct pci_dev *pdev);
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index d775eb6..3829f3e 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -244,7 +244,6 @@ static int atyfb_sync(struct fb_info *info);
*/
static int aty_init(struct fb_info *info);
-static void aty_resume_chip(struct fb_info *info);
#ifdef CONFIG_ATARI
static int store_video_par(char *videopar, unsigned char m64_num);
#endif
@@ -2076,6 +2075,20 @@ static int atyfb_pci_suspend(struct pci_dev *pdev,
pm_message_t state)
return 0;
}
+static void aty_resume_chip(struct fb_info *info)
Re: [patch] drop linux/ufs_fs.h from userspace export
On Sat, 26 Jan 2008 04:09:52 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > Per previous discussions about cleaning up ufs_fs.h, people just want this > straight up dropped from userspace export. The only remaining consumer (silo) > has been fixed a while ago to not rely on this header. > This patch is incompatible with your "Relocate linux/ufs_fs.h to fs/ufs/ufs_fs.h". I'll drop both. -- 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/
Re: [PATCH] [3/18] BKL-removal: Convert ext3 to use unlocked_ioctl
On Sun, 27 Jan 2008 03:17:09 +0100 (CET) Andi Kleen <[EMAIL PROTECTED]> wrote: > > I checked ext3_ioctl and it looked largely safe to not be used > without BKL. So convert it over to unlocked_ioctl. > > The only case where I wasn't quite sure was for the > dynamic fs grow ioctls versus umounting -- I kept the BKL for those. > Please cpoy linux-ext4 on ext2/3/4 material. I skippped a lot of these patches because I just got bored of fixing rejects. Now is a very optimistic time to be raising patches against mainline. I'm going to work on getting a unified devel tree operating: one which contains everyone's latest stuff and is updated daily. Basically it'll be -mm without a couple of the quilt trees. People can then prepare patches against that, as it seems that most can't be bothered patching against -mm, let alone building and testing it. More later. > + /* AK: not sure the BKL is needed, but this might prevent > + * races against umount */ > + lock_kernel(); > err = ext3_group_extend(sb, EXT3_SB(sb)->s_es, n_blocks_count); > journal_lock_updates(EXT3_SB(sb)->s_journal); > journal_flush(EXT3_SB(sb)->s_journal); > journal_unlock_updates(EXT3_SB(sb)->s_journal); > + unlock_kernel(); > > return err; > } > @@ -245,11 +249,14 @@ flags_err: > if (copy_from_user(&input, (struct ext3_new_group_input __user > *)arg, > sizeof(input))) > return -EFAULT; > - > + /* AK: not sure the BKL is needed, but this might prevent > + * races against umount */ > + lock_kernel(); > err = ext3_group_add(sb, &input); > journal_lock_updates(EXT3_SB(sb)->s_journal); > journal_flush(EXT3_SB(sb)->s_journal); > journal_unlock_updates(EXT3_SB(sb)->s_journal); > + unlock_kernel(); > The ext3_ioctl() caller has an open fd against the fs - should be sufficient to keep unmount away? (gets even more rejects, drops all the fasync patches too) It's all reached the stage of stupid. -- 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/
Re: [PATCH] SH/Dreamcast - add support for GD-Rom CDROM drive on SEGA Dreamcast
On Fri, 18 Jan 2008 09:56:33 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote: > On Thu, Jan 17, 2008 at 10:30:06PM +, Adrian McMenamin wrote: > > From: Adrian McMenamin <[EMAIL PROTECTED]> > > > > This patch adds support for the GD-Rom drive, SEGA's proprietary > > implementation of an IDE CD Rom for the SEGA Dreamcast. This driver > > implements Sega's Packet Interface (SPI) - at least partially. It will > > also read disks in SEGA's propreitary GD format. > > > > Unlike previous drivers (which were never in mainline) this uses DMA and > > not PIO to read disks. It is a new driver, not a refactoring of old > > drivers. > > > > I hope I've fixed all the white space and other issues now! > > > > Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]> > > > Looks good to me. I'll add it to my queue unless Andrew has any glaring > objections. Looks like a driver to me, but Jens is mostly-cdrom-maintainer. -- 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/
Re: [PATCH 1/1] Net: e100, fix iomap mem accesses
On Fri, 18 Jan 2008 14:38:51 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jiri Slaby wrote:
> > readX functions are not permitted on iomap-ped space change to ioreadX,
> > also pci_unmap pci_map-ped space on exit (instead of iounmap).
> >
> > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> > ---
> > drivers/net/e100.c |8
> > 1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> > index 51cf577..47548ef 100644
> > --- a/drivers/net/e100.c
> > +++ b/drivers/net/e100.c
> > @@ -1836,7 +1836,7 @@ static int e100_rx_indicate(struct nic *nic, struct
> > rx *rx,
> > if ((le16_to_cpu(rfd->command) & cb_el) &&
> > (RU_RUNNING == nic->ru_running))
> >
> > - if (readb(&nic->csr->scb.status) & rus_no_res)
> > + if (ioread8(&nic->csr->scb.status) & rus_no_res)
> > nic->ru_running = RU_SUSPENDED;
> > return -ENODATA;
> > }
> > @@ -1859,7 +1859,7 @@ static int e100_rx_indicate(struct nic *nic, struct
> > rx *rx,
> > if ((le16_to_cpu(rfd->command) & cb_el) &&
> > (RU_RUNNING == nic->ru_running)) {
> >
> > - if (readb(&nic->csr->scb.status) & rus_no_res)
> > + if (ioread8(&nic->csr->scb.status) & rus_no_res)
> > nic->ru_running = RU_SUSPENDED;
> > }
> >
> > @@ -1958,7 +1958,7 @@ static void e100_rx_clean(struct nic *nic, unsigned
> > int *work_done,
> >
> > if(restart_required) {
> > // ack the rnr?
> > - writeb(stat_ack_rnr, &nic->csr->scb.stat_ack);
> > + iowrite8(stat_ack_rnr, &nic->csr->scb.stat_ack);
> > e100_start_receiver(nic, nic->rx_to_clean);
> > if(work_done)
> > (*work_done)++;
> > @@ -2774,7 +2774,7 @@ static void __devexit e100_remove(struct pci_dev
> > *pdev)
> > struct nic *nic = netdev_priv(netdev);
> > unregister_netdev(netdev);
> > e100_free(nic);
> > - iounmap(nic->csr);
> > + pci_iounmap(pdev, nic->csr);
> > free_netdev(netdev);
> > pci_release_regions(pdev);
>
> ACK, but patch doesn't seem to apply...
It's been a week, nothing seems to have happened and the e100 maintainers
are asleep.
Please resend when convenient. Maybe more luodly or something, I dunno.
--
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/
Re: [PATCH] linux/types.h: always export 64bit aligned defines
On Sat, 26 Jan 2008 04:23:21 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > Some kernel headers exported to userspace rely on these 64bit aligned defines. > However, they are hidden behind __KERNEL_STRICT_NAMES at the moment which > means most of the time, they're never actually available. These these defines > dont actually conflict with normal userspace / C library types, there's no > reason to hide them behind the __KERNEL_STRICT_NAMES define. > Maybe we shouldn't be using these helper macros in exported-to-userspace headers. Do you know which headers are affected? Did you consider jsut expanding the macros in situ for thse cases? > --- > include/linux/types.h | 10 +- > 1 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/include/linux/types.h b/include/linux/types.h > index f4f8d19..b80a263 100644 > --- a/include/linux/types.h > +++ b/include/linux/types.h > @@ -125,11 +125,6 @@ typedef __u64 u_int64_t; > typedef __s64 int64_t; > #endif > > -/* this is a special 64bit data type that is 8-byte aligned */ > -#define aligned_u64 unsigned long long __attribute__((aligned(8))) > -#define aligned_be64 __be64 __attribute__((aligned(8))) > -#define aligned_le64 __le64 __attribute__((aligned(8))) > - > /** > * The type used for indexing onto a disc or disc partition. > * > @@ -161,6 +156,11 @@ typedef unsigned long blkcnt_t; > > #endif /* __KERNEL_STRICT_NAMES */ > > +/* this is a special 64bit data type that is 8-byte aligned */ > +#define aligned_u64 unsigned long long __attribute__((aligned(8))) > +#define aligned_be64 __be64 __attribute__((aligned(8))) > +#define aligned_le64 __le64 __attribute__((aligned(8))) > + > /* > * Below are truly Linux-specific types that should never collide with > * any application/library that wants linux/types.h. Seems relatively harmless. But I'd have thought that if we're going to do this, we should create a standard naming convention for types which the kernel exports to userspace. Say, kern_*. In which case the change becomes: #define kern_aligned_u64 unsigned long long __attribute__((aligned(8))) #define kern_aligned_be64 __be64 __attribute__((aligned(8))) #define kern_aligned_le64 __le64 __attribute__((aligned(8))) (exported to userspace) and, inside __KERNEL__: #define aligned_u64 kern_aligned_u64 etc. And, of course, all those bit of kernel headers which are presently using aligned_u64 in exposed-to-userspace places should be switched to kern_aligned_u4. What thinkest thou? If _that_ is all sane then we should do it all in a singe header file, say kern_types_for_userspace.h. include/linux/types.h would then do: #include #ifdef __KERNEL__ #define aligned_u64 kern_aligned_u64 etc... (all approximate, you-get-what-I-mean) Duno if it'd be worth the effort, but it is The Right Thing To Do. -- 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/
Re: [PATCH -mm 2/2] PWM LED driver
On Thu, 24 Jan 2008 15:33:45 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> + if (i > 0) {
> + for (i = i - 1; i >= 0; i--) {
> + led_classdev_unregister(&leds[i].cdev);
> + pwm_channel_free(&leds[i].pwmc);
> + }
> + }
Could be:
while (--i > 0) {
led_classdev_unregister(&leds[i].cdev);
pwm_channel_free(&leds[i].pwmc);
}
or thereabouts.
--
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/
Re: [PATCH] remove duplicating priority setting in try_to_free_p
On Sat, 26 Jan 2008 02:29:23 -0500 "minchan kim" <[EMAIL PROTECTED]> wrote:
> shrink_zones in try_to_free_pages already set zone through
> note_zone_scanning_priority.
> So, setting prev_priority in try_to_free_pages is needless.
>
> This patch is made by 2.6.24-rc8.
>
> Signed-off-by: barrios <[EMAIL PROTECTED]>
> ---
> mm/vmscan.c | 17 -
> 1 files changed, 0 insertions(+), 17 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index e5a9597..fc55c23 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1273,23 +1273,6 @@ unsigned long try_to_free_pages(struct z
> if (!sc.all_unreclaimable)
> ret = 1;
> out:
> - /*
> -* Now that we've scanned all the zones at this priority level, note
> -* that level within the zone so that the next thread which performs
> -* scanning of this zone will immediately start out at this priority
> -* level. This affects only the decision whether or not to bring
> -* mapped pages onto the inactive list.
> -*/
> - if (priority < 0)
> - priority = 0;
> - for (i = 0; zones[i] != NULL; i++) {
> - struct zone *zone = zones[i];
> -
> - if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
> - continue;
> -
> - zone->prev_priority = priority;
> - }
> return ret;
> }
(your mail client is replacing tabs with spaces)
I think this is actually a bugfix. The code you're removing doesn't do the
if (priority < zone->prev_priority)
thing.
otoh with this change, the only thing which will cause prev_priority to
increase (ie: lower priority) is kswapd, which seems odd.
So:
a) this is a functional change and needs more thought and lots of runtime
testing. I'll duck it for now.
b) the prev_priority stuff is still screwed up.
--
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/
Re: [PATCH -mm] kprobes: kretprobe user entry-handler (updated)
On Sat, 26 Jan 2008 23:52:48 +0530 Abhishek Sagar <[EMAIL PROTECTED]> wrote:
> This is a repost of a patch which was reviewed earlier at:
> http://lkml.org/lkml/2007/11/13/58 (thanks to Jim Keniston and Srinivasa for
> their review comments). This provides support to add an optional user defined
> callback to be run at function entry of a kretprobe'd function. It also
> modifies the kprobe smoke tests to include an entry-handler during the
> kretprobe sanity test.
>
Neither the changelog nor the newly-added documentation explain why Linux
needs this feature. What will it be used for??
> +1.3.2 Kretprobe entry-handler
> +
> +Kretprobes also provides an optional user-specified handler which runs
I think "caller-specified" would be a better term here. Generally "user"
refers to Aunt Tillie sitting at the keyboard.
> +/* Timestamp function entry. */
> +static int entry_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
> +{
> + struct my_data *data;
> +
> + if(!current->mm)
> + return 1; /* skip kernel threads */
gargh, what's happened to checkpatch lately? It failed to notice the
missing space.
--
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/
Re: [patch 00/14] M68k patches for 2.6.25
On Sun, 27 Jan 2008 13:32:16 +0100 Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > Hi Linus, Andrew, > > Here are the m68k patches I had queued up for 2.6.25: > [1] m68k: Use cc-cross-prefix > [2] m68k: ARRAY_SIZE() cleanup > [3] dio: ARRAY_SIZE() cleanup > [4] m68k: Balance ioremap and iounmap in m68k/atari/hades-pci.c > [5] nubus: kill drivers/nubus/nubus_syms.c > [6] m68k: kill arch/m68k/mac/mac_ksyms.c > [7] m68k: kill arch/m68k/hp300/ksyms.c > [8] m68k: kill arch/m68k/amiga/amiga_ksyms.c > [9] m68k: kill arch/m68k/atari/atari_ksyms.c > [10] m68k: kill arch/m68k/mvme16x/mvme16x_ksyms.c > [11] mac68k: macii adb comment correction > [12] mac68k: remove dead code > [13] mac68k: add nubus card definitions and a typo fix > [14] mac68k: remove dead MAC_ADBKEYCODES > I already have these merged and queued. Hopefully none of them have changed. -- 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/
Re: [PATCH] Rationalise ACPI backlight implementation
On Sun, Jan 27, 2008 at 09:10:13PM -0800, Andrew Morton wrote: > You cannot seriously tell me that if we are to change this range from 0-8 > up to 0-100 then this is not a backwards-incompatible change in > semantics. We're talking about changing 0-100 to 0-something sane, because the current driver is quite clearly broken. And yes, I'm perfectly happy to say that - the reason that max_brightness is exported is to allow userspace to determine what range of values is acceptable, and if userspace ignores that then things are going to break for it at some point. -- Matthew Garrett | [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/
Re: (Updated) [Patch] Shut up warnings from files under drivers/
On Sun, Jan 27, 2008 at 10:21:12AM +0100, Jiri Slaby wrote:
>On 01/27/2008 10:08 AM, Jiri Slaby wrote:
>>On 01/27/2008 05:15 AM, WANG Cong wrote:
>>>Fix defined-but-not-used warnings from files under drivers/,
>>>such as:
>>>
>>>drivers/char/applicom.c:68: warning: ‘applicom_pci_tbl’ defined but
>>>not used
>>>
>>>Compile tests passed.
>>>
>>>Cc: Jeff Garzik <[EMAIL PROTECTED]>
>>>Cc: Greg KH <[EMAIL PROTECTED]>
>>>Cc: Sam Ravnborg <[EMAIL PROTECTED]>
>>>Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>>>
>>>---
>>>
>>>diff --git a/drivers/char/applicom.c b/drivers/char/applicom.c
>>>index 1f0b752..97171ad 100644
>>>--- a/drivers/char/applicom.c
>>>+++ b/drivers/char/applicom.c
>>>@@ -65,7 +65,7 @@ static char *applicom_pci_devnames[] = {
>>> "PCI2000PFB"
>>> };
>>>
>>>-static struct pci_device_id applicom_pci_tbl[] = {
>>>+static struct pci_device_id applicom_pci_tbl[] __used = {
>>> { PCI_VENDOR_ID_APPLICOM, PCI_DEVICE_ID_APPLICOM_PCIGENERIC,
>>> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
>>> { PCI_VENDOR_ID_APPLICOM, PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN,
>>
>>I have probably a better fix with pci_match_id() referencing this array.
>
>Hmm, checking it one more time persuades me that the best fix ever is to
>convert it to probing. David, do you have the card?
OK. I will drop this part.
--
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/
Re: [Patch] drivers/base/core.c: fix a compile error
> >No, that will fix the build error, but die when linking :( > >I'll work on a real fix for this now... > Sorry. I just compiled it since the building process was stopped by another error. -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Mon, 28 Jan 2008 05:38:25 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > On Monday 28 January 2008 05:13:09 Trond Myklebust wrote: > > > > On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote: > > > The problem is that it's not a race in who gets to do its thing first, > > > but a > > > parallel reader can actually see a corrupted value from the two > > > independent > > > words on 32bit (e.g. during a 4GB). And this could actually completely > > > corrupt > > > f_pos when it happens with two racing relative seeks or read/write()s > > > > > > I would consider that a bug. > > > > I disagree. The corruption occurs because this isn't a situation that is > > allowed by either POSIX or SUSv2/v3. Exactly what spec are you referring > > to here? > > No specific spec, just general quality of implementation. I completely agree. If one thread writes A and another writes B then the kernel should record either A or B, not ((A & 0x) | (B & 0x)) -- 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/
Re: [PATCH] Rationalise ACPI backlight implementation
On Mon, 28 Jan 2008 01:25:50 + Matthew Garrett <[EMAIL PROTECTED]> wrote: > On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote: > > - Create a new /sys node with a new name which has the new semantics. > > The semantics are the same as they always have been - values between 0 > and max_brightness are valid values. If you've made assumptions about > what max_brightness is, then that's a bug in the userspace application > rather than a change in the semantics of the interface. > WTH? My (utterly comedic chase-crap-around-the-tree) brightness script was: ( 0 sh -c "echo $1 > /proc/acpi/sony/brightness" 0 sh -c "echo $1 > /proc/acpi/sony/brightness_default" 0 sh -c "echo $1 > /sys/class/backlight/sony/brightness" 0 sh -c "echo $1 > /sys/class/backlight/thinkpad_screen/brightness" ) 2>/dev/null And yes, I had an rc.local command which assumed that 7 (later 8) is max brightness. You cannot seriously tell me that if we are to change this range from 0-8 up to 0-100 then this is not a backwards-incompatible change in semantics. My /sys/class/backlight/ directory is presently empty. Rather than trying to find out why, I think I'll just collapse in laughter. Guys, sort it out, please. -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote: > On Monday 28 January 2008 05:13:09 Trond Myklebust wrote: > > > > On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote: > > > The problem is that it's not a race in who gets to do its thing first, > > > but a > > > parallel reader can actually see a corrupted value from the two > > > independent > > > words on 32bit (e.g. during a 4GB). And this could actually completely > > > corrupt > > > f_pos when it happens with two racing relative seeks or read/write()s > > > > > > I would consider that a bug. > > > > I disagree. The corruption occurs because this isn't a situation that is > > allowed by either POSIX or SUSv2/v3. Exactly what spec are you referring > > to here? > > No specific spec, just general quality of implementation. We normally don't > have > non thread safe system calls even if it was in theory allowed by some > specification. We've had the existing implementation for quite some time. The arguments against changing it have been the same all along: if your application wants to share files between threads, the portability argument implies that you should either use pread/pwrite or use a mutex or some other form of synchronisation primitive in order to ensure that lseek()/read()/write() do not overlap. Cheers Trond -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote: > > On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote: > > The problem is that it's not a race in who gets to do its thing first, but > > a > > parallel reader can actually see a corrupted value from the two independent > > words on 32bit (e.g. during a 4GB). And this could actually completely > > corrupt > > f_pos when it happens with two racing relative seeks or read/write()s > > > > I would consider that a bug. > > I disagree. The corruption occurs because this isn't a situation that is > allowed by either POSIX or SUSv2/v3. Exactly what spec are you referring > to here? No specific spec, just general quality of implementation. We normally don't have non thread safe system calls even if it was in theory allowed by some specification. -Andi -- 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/
[PATCH] [CPUISOL] Support for workqueue isolation
From: Max Krasnyansky <[EMAIL PROTECTED]>
I'm sure this one is going to be controversial for a lot of folks here.
So let me explain :).
What this patch is trying to address is the case when a high priority
realtime (FIFO, RR) user-space thread is using 100% CPU for extended periods
of time. In which case kernel workqueue threads do not get a chance to run and
entire machine essentially hangs because other CPUs are waiting for scheduled
workqueues to flush.
This use case is perfectly valid if one is using a CPU as a dedicated engine
(crunching numbers, hard realtime, etc). Think of it as an SPE in the Cell
processor.
Which is what CPU isolation enables in first place.
Most kernel subsystems do not rely on the per CPU workqueues. In fact we already
have support for single threaded workqueues, this patch just makes it automatic.
Some subsystems namely OProfile do rely on per CPU workqueues and do not work
when
this feature is enabled. It does not result in crashes or anything OProfile is
just
unable to collect stats from isolated CPUs. Hence this feature is marked as
experimental.
There is zero overhead if CPU workqueue isolation is disabled.
Better ideas/suggestions on how to handle use case described above are welcome
of course.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
kernel/workqueue.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 52db48e..ed2f09b 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -35,6 +35,16 @@
#include
/*
+ * Stub out cpu_isolated() if isolated CPUs are allowed to
+ * run workqueues.
+ */
+#ifdef CONFIG_CPUISOL_WORKQUEUE
+#define cpu_unusable(cpu) cpu_isolated(cpu)
+#else
+#define cpu_unusable(cpu) (0)
+#endif
+
+/*
* The per-CPU workqueue (if single thread, we always use the first
* possible cpu).
*/
@@ -97,7 +107,7 @@ static const cpumask_t *wq_cpu_map(struct workqueue_struct
*wq)
static
struct cpu_workqueue_struct *wq_per_cpu(struct workqueue_struct *wq, int cpu)
{
- if (unlikely(is_single_threaded(wq)))
+ if (unlikely(is_single_threaded(wq)) || cpu_unusable(cpu))
cpu = singlethread_cpu;
return per_cpu_ptr(wq->cpu_wq, cpu);
}
@@ -229,9 +239,11 @@ int queue_delayed_work_on(int cpu, struct workqueue_struct
*wq,
timer->data = (unsigned long)dwork;
timer->function = delayed_work_timer_fn;
- if (unlikely(cpu >= 0))
+ if (unlikely(cpu >= 0)) {
+ if (cpu_unusable(cpu))
+ cpu = singlethread_cpu;
add_timer_on(timer, cpu);
- else
+ } else
add_timer(timer);
ret = 1;
}
@@ -605,7 +617,8 @@ int schedule_on_each_cpu(work_func_t func)
get_online_cpus();
for_each_online_cpu(cpu) {
struct work_struct *work = per_cpu_ptr(works, cpu);
-
+ if (cpu_unusable(cpu))
+ continue;
INIT_WORK(work, func);
set_bit(WORK_STRUCT_PENDING, work_data_bits(work));
__queue_work(per_cpu_ptr(keventd_wq->cpu_wq, cpu), work);
@@ -754,7 +767,7 @@ struct workqueue_struct *__create_workqueue_key(const char
*name,
for_each_possible_cpu(cpu) {
cwq = init_cpu_workqueue(wq, cpu);
- if (err || !cpu_online(cpu))
+ if (err || !cpu_online(cpu) || cpu_unusable(cpu))
continue;
err = create_workqueue_thread(cwq, cpu);
start_workqueue_thread(cwq, cpu);
@@ -833,8 +846,11 @@ static int __devinit workqueue_cpu_callback(struct
notifier_block *nfb,
struct cpu_workqueue_struct *cwq;
struct workqueue_struct *wq;
- action &= ~CPU_TASKS_FROZEN;
+ if (cpu_unusable(cpu))
+ return NOTIFY_OK;
+ action &= ~CPU_TASKS_FROZEN;
+
switch (action) {
case CPU_UP_PREPARE:
@@ -869,7 +885,7 @@ static int __devinit workqueue_cpu_callback(struct
notifier_block *nfb,
void __init init_workqueues(void)
{
- cpu_populated_map = cpu_online_map;
+ cpus_andnot(cpu_populated_map, cpu_online_map, cpu_isolated_map);
singlethread_cpu = first_cpu(cpu_possible_map);
cpu_singlethread_map = cpumask_of_cpu(singlethread_cpu);
hotcpu_notifier(workqueue_cpu_callback, 0);
--
1.5.3.7
--
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/
[PATCH] [CPUISOL] Export CPU isolation bits
From: Max Krasnyansky <[EMAIL PROTECTED]>
Here we're just exporting CPU isolation bitmap so that it can
be used outside the scheduler code.
Helper functions like cpu_isolated() are provided for easy access.
This is very similar to cpu_online() and friends.
The patch also exports 'isolated' bit via sysfs in very much the
same way 'online' bit is exposed today.
CPUs can be isolated either via command line isolcpu= option or
by doing something like this:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu1/isolated
echo 1 > /sys/devices/system/cpu/cpu1/online
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
drivers/base/cpu.c | 47 +++
include/linux/cpumask.h |3 +++
kernel/sched.c | 12
3 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index c5885f5..f59c719 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -55,10 +55,57 @@ static ssize_t store_online(struct sys_device *dev, const
char *buf,
}
static SYSDEV_ATTR(online, 0644, show_online, store_online);
+#ifdef CONFIG_CPUISOL
+/*
+ * This is under config hotplug is because in order to
+ * dynamically isolate a CPU it needs to be brought down.
+ * In other words the sequence should be
+ * echo 0 > /sys/device/system/cpuN/online
+ * echo 1 > /sys/device/system/cpuN/isolated
+ */
+static ssize_t show_isol(struct sys_device *dev, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+
+ return sprintf(buf, "%u\n", !!cpu_isolated(cpu->sysdev.id));
+}
+
+static ssize_t store_isol(struct sys_device *dev, const char *buf,
+ size_t count)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ ssize_t ret = 0;
+
+ if (cpu_online(cpu->sysdev.id))
+ return -EBUSY;
+
+ switch (buf[0]) {
+ case '0':
+ cpu_clear(cpu->sysdev.id, cpu_isolated_map);
+ break;
+ case '1':
+ cpu_set(cpu->sysdev.id, cpu_isolated_map);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ if (ret >= 0)
+ ret = count;
+ return ret;
+}
+static SYSDEV_ATTR(isolated, 0600, show_isol, store_isol);
+#endif /* CONFIG_CPUISOL */
+
static void __devinit register_cpu_control(struct cpu *cpu)
{
sysdev_create_file(&cpu->sysdev, &attr_online);
+
+#ifdef CONFIG_CPUISOL
+ sysdev_create_file(&cpu->sysdev, &attr_isolated);
+#endif
}
+
void unregister_cpu(struct cpu *cpu)
{
int logical_cpu = cpu->sysdev.id;
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 85bd790..84d1561 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -380,6 +380,7 @@ static inline void __cpus_remap(cpumask_t *dstp, const
cpumask_t *srcp,
extern cpumask_t cpu_possible_map;
extern cpumask_t cpu_online_map;
extern cpumask_t cpu_present_map;
+extern cpumask_t cpu_isolated_map;
#if NR_CPUS > 1
#define num_online_cpus() cpus_weight(cpu_online_map)
@@ -388,6 +389,7 @@ extern cpumask_t cpu_present_map;
#define cpu_online(cpu)cpu_isset((cpu), cpu_online_map)
#define cpu_possible(cpu) cpu_isset((cpu), cpu_possible_map)
#define cpu_present(cpu) cpu_isset((cpu), cpu_present_map)
+#define cpu_isolated(cpu) cpu_isset((cpu), cpu_isolated_map)
#else
#define num_online_cpus() 1
#define num_possible_cpus()1
@@ -395,6 +397,7 @@ extern cpumask_t cpu_present_map;
#define cpu_online(cpu)((cpu) == 0)
#define cpu_possible(cpu) ((cpu) == 0)
#define cpu_present(cpu) ((cpu) == 0)
+#define cpu_isolated(cpu) (0)
#endif
#define cpu_is_offline(cpu)unlikely(!cpu_online(cpu))
diff --git a/kernel/sched.c b/kernel/sched.c
index 524285e..2fc942e 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4815,10 +4815,17 @@ asmlinkage long sys_sched_setaffinity(pid_t pid,
unsigned int len,
* as new cpu's are detected in the system via any platform specific
* method, such as ACPI for e.g.
*/
-
cpumask_t cpu_present_map __read_mostly;
EXPORT_SYMBOL(cpu_present_map);
+/*
+ * Represents isolated cpu's.
+ * These cpu's have isolated scheduling domains. In general any
+ * kernel activity should be avoided as much as possible on them.
+ */
+cpumask_t cpu_isolated_map __read_mostly = CPU_MASK_NONE;
+EXPORT_SYMBOL(cpu_isolated_map);
+
#ifndef CONFIG_SMP
cpumask_t cpu_online_map __read_mostly = CPU_MASK_ALL;
EXPORT_SYMBOL(cpu_online_map);
@@ -6186,9 +6193,6 @@ cpu_attach_domain(struct sched_domain *sd, struct
root_domain *rd, int cpu)
rcu_assign_pointer(rq->sd, sd);
}
-/* cpus with isolated domains */
-static cpumask_t cpu_isolated_map = CPU_MASK_NONE;
-
/* Setup the mask of cpus configured for isolated domains */
static int __init isolated_cpu_setup(char *str)
{
--
1.5.3.7
--
To unsubscr
[CPUISOL] CPU isolation extensions
Following patch series extends CPU isolation support. Yes, most people want to virtuallize CPUs these days and I want to isolate them :). The primary idea here is to be able to use some CPU cores as dedicated engines for running user-space code with minimal kernel overhead/intervention, think of it as an SPE in the Cell processor. We've had scheduler support for CPU isolation ever since O(1) scheduler went it. I'd like to extend it further to avoid kernel activity on those CPUs as much as possible. In fact that the primary distinction that I'm making between say "CPU sets" and "CPU isolation". "CPU sets" let you manage user-space load while "CPU isolation" provides a way to isolate a CPU as much as possible (including kernel activities). I'm personally using this for hard realtime purposes. With CPU isolation it's very easy to achieve single digit usec worst case and around 200 nsec average response times on off-the-shelf multi- processor/core systems under exteme system load. I'm working with legal folks on releasing hard RT user-space framework for that. I can also see other application like simulators and stuff that can benefit from this. I've been maintaining this stuff since around 2.6.18 and it's been running in production environment for a couple of years now. It's been tested on all kinds of machines, from NUMA boxes like HP xw9300/9400 to tiny uTCA boards like Mercury AXA110. The messiest part used to be SLAB garbage collector changes. With the new SLUB all that mess goes away (ie no changes necessary). Also CFS seems to handle CPU hotplug much better than O(1) did (ie domains are recomputed dynamically) so that isolation can be done at any time (via sysfs). So this seems like a good time to merge. Anyway. The patchset consist of 5 patches. First three are very simple and non-controversial. They simply make "CPU isolation" a configurable feature, export cpu_isolated_map and provide some helper functions to access it (just like cpu_online() and friends). Last two patches add support for isolating CPUs from running workqueus and stop machine. More details in the individual patch descriptions. Ideally I'd like all of this to go in during this merge window. If people think it's acceptable Linus or Andrew (or whoever is more appropriate Ingo maybe) can pull this patch set from git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git That tree is rebased against latest (as of yesterday) Linus' tree. Thanx Max arch/x86/Kconfig |1 arch/x86/kernel/genapic_flat_64.c |5 ++-- drivers/base/cpu.c| 47 ++ include/linux/cpumask.h |3 ++ kernel/Kconfig.cpuisol| 25 +++- kernel/sched.c| 13 ++ kernel/stop_machine.c |3 -- kernel/workqueue.c| 31 ++--- 8 files changed, 110 insertions(+), 18 deletions(-) -- 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/
[PATCH] [CPUISOL] Add config options for CPU isolation
From: Max Krasnyansky <[EMAIL PROTECTED]> This simply adds a couple of new kconfig options for configuring CPU isolation features. Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]> --- arch/x86/Kconfig |1 + kernel/Kconfig.cpuisol | 24 2 files changed, 25 insertions(+), 0 deletions(-) create mode 100644 kernel/Kconfig.cpuisol diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 80b7ba4..b8f986e 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -495,6 +495,7 @@ config SCHED_MC increased overhead in some places. If unsure say N here. source "kernel/Kconfig.preempt" +source "kernel/Kconfig.cpuisol" config X86_UP_APIC bool "Local APIC support on uniprocessors" diff --git a/kernel/Kconfig.cpuisol b/kernel/Kconfig.cpuisol new file mode 100644 index 000..6e099a4 --- /dev/null +++ b/kernel/Kconfig.cpuisol @@ -0,0 +1,24 @@ +config CPUISOL + depends on SMP + bool "CPU isolation" + help + This option enables support for CPU isolation. + If enabled the kernel will try to avoid kernel activity on the isolated CPUs. + By default user-space threads are not scheduled on the isolated CPUs unless + they explicitly request it (via sched_ and pthread_ affinity calls). Isolated + CPUs are not subject to the scheduler load-balancing algorithms. + + CPUs can be marked as isolated using 'cpuisol=' command line option or by + writing '1' into /sys/devices/system/cpu/cpuN/isolated. + + This feature is useful for hard realtime and high performance applications. + If unsure say 'N'. + +config CPUISOL_WORKQUEUE + bool "Do not schedule workqueues on isolated CPUs (EXPERIMENTAL)" + depends on CPUISOL && EXPERIMENTAL + help + In this option is enabled kernel will not schedule workqueues on the + isolated CPUs. + Please note that at this point this feature is experimental. It brakes + certain things like OProfile that heavily rely on per cpu workqueues. -- 1.5.3.7 -- 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/
[PATCH] [CPUISOL] Isolated CPUs should be ignored by the "stop machine"
From: Max Krasnyansky <[EMAIL PROTECTED]>
This patch is trying to address the same use case I explained in the previous
workqueue
isolation patch. Which is when a high priority realtime (FIFO, RR) user-space
thread
is using 100% CPU for extended periods of time. In which case stopmachine
threads do not
get a chance to run and entire machine essentially hangs because other CPUs are
waiting
for the all stopmachine threads to run.
This use case is perfectly valid if one is using a CPU as a dedicated engine
(crunching numbers, hard realtime, etc). Think of it as an SPE in the Cell
processor.
Which is what CPU isolation enables in first place.
Stopmachine is particularly bad when it comes to latencies. It's currently used
for
module insertion and removal only. Given that threads running on the isolated
CPUs
are unlikely to use kernel services anyway I'd consider this patch pretty safe.
The patch adds no overhead and/or side effects when CPU isolation is disabled.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
kernel/stop_machine.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 51b5ee5..0f4cc3f 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -99,7 +99,7 @@ static int stop_machine(void)
stopmachine_state = STOPMACHINE_WAIT;
for_each_online_cpu(i) {
- if (i == raw_smp_processor_id())
+ if (i == raw_smp_processor_id() || cpu_isolated(i))
continue;
ret = kernel_thread(stopmachine, (void *)(long)i,CLONE_KERNEL);
if (ret < 0)
--
1.5.3.7
--
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/
[PATCH] [CPUISOL] Do not route IRQs to the CPUs isolated at boot
From: Max Krasnyansky <[EMAIL PROTECTED]>
Most people would expect isolated CPUs to not get any
IRQs by default. This happens naturally if CPU is brought
off-line, marked isolated and then brought back online.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
arch/x86/kernel/genapic_flat_64.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/genapic_flat_64.c
b/arch/x86/kernel/genapic_flat_64.c
index 07352b7..e02e58c 100644
--- a/arch/x86/kernel/genapic_flat_64.c
+++ b/arch/x86/kernel/genapic_flat_64.c
@@ -21,7 +21,9 @@
static cpumask_t flat_target_cpus(void)
{
- return cpu_online_map;
+ cpumask_t target;
+ cpus_andnot(target, cpu_online_map, cpu_isolated_map);
+ return target;
}
static cpumask_t flat_vector_allocation_domain(int cpu)
--
1.5.3.7
--
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/
Re: [PATCH] Moving spinlock to struct usb_hcd
On Mon, Jan 28, 2008 at 09:50:36AM +0530, Romit Dasgupta wrote: > Hi, > Should I go ahead and submit the patch with the usual > "signed-off" thingie? Or is it totally useless patch that is going to > be ignored? Let's see some proof that it actually helps, and then we can evaluate if it is needed or not :) thanks, greg k-h -- 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/
Re: [PATCH] Moving spinlock to struct usb_hcd
Hi, Should I go ahead and submit the patch with the usual "signed-off" thingie? Or is it totally useless patch that is going to be ignored? Thanks, -Romit On Jan 26, 2008 9:06 PM, Romit Dasgupta <[EMAIL PROTECTED]> wrote: > > > > > > Looking at how this lock is used, contention doesn't look likely > > to be an issue. It's never held for long ... > yes in the general case but in usb_hcd_flush_endpoint routine it seems > to be held for longer than other routines. I agree that > usb_hcd_flush_endpoint is an infrequently called routine. Normal > systems dont have too many HCs. My computer shows 1 EHCI and 3 OHCIs > so I guess when I connect high speed devices there are less chances of > contention. With more HC this lock might be contended for. > Nevertheless, the right place for the lock seems to be inside usb_hcd. > What do you think? > > > > > > > Do you have any proof that contention is an actual problem? > > Because otherwise I see no benefit to such a change. > > > > I will try to see what I can find with /proc/lock_stat. > > Thanks, > -Romit > -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote: > The problem is that it's not a race in who gets to do its thing first, but a > parallel reader can actually see a corrupted value from the two independent > words on 32bit (e.g. during a 4GB). And this could actually completely > corrupt > f_pos when it happens with two racing relative seeks or read/write()s > > I would consider that a bug. I disagree. The corruption occurs because this isn't a situation that is allowed by either POSIX or SUSv2/v3. Exactly what spec are you referring to here? Trond -- 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/
[PATCH] writeback: speed up writeback of big dirty files
Andrew, I'd suggest it for 2.6.25.
It's a safer version of the reverted patch in .24-rc8. It was tested
on ext2/ext3/jfs/xfs/reiserfs and won't 100% iowait even without the
other bug fixing patches.
Fengguang
---
writeback: speed up writeback of big dirty files
After making dirty a 100M file, the normal behavior is to
start the writeback for all data after 30s delays. But
sometimes the following happens instead:
- after 30s:~4M
- after 5s: ~4M
- after 5s: all remaining 92M
Some analyze shows that the internal io dispatch queues goes like this:
s_ios_more_io
-
1) 100M,1K 0
2) 1K 96M
3) 0 96M
1) initial state with a 100M file and a 1K file
2) 4M written, nr_to_write <= 0, so write more
3) 1K written, nr_to_write > 0, no more writes(BUG)
nr_to_write > 0 in (3) fools the upper layer to think that data have all been
written out. The big dirty file is actually still sitting in s_more_io. We
cannot simply splice s_more_io back to s_io as soon as s_io becomes empty, and
let the loop in generic_sync_sb_inodes() continue: this may starve newly
expired inodes in s_dirty. It is also not an option to draw inodes from both
s_more_io and s_dirty, an let the loop go on: this might lead to live locks,
and might also starve other superblocks in sync time(well kupdate may still
starve some superblocks, that's another bug).
We have to return when a full scan of s_io completes. So nr_to_write > 0 does
not necessarily mean that "all data are written". This patch introduces a flag
writeback_control.more_io to indicate that more io should be done. With it the
big dirty file no longer has to wait for the next kupdate invocation 5s later.
In sync_sb_inodes() we only set more_io on super_blocks we actually visited.
This aviods the interaction between two pdflush deamons.
Also in __sync_single_inode() we don't blindly keep requeuing the io if the
filesystem cannot progress. Failing to do so may lead to 100% iowait.
Tested-by: Mike Snitzer <[EMAIL PROTECTED]>
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
fs/fs-writeback.c | 18 --
include/linux/writeback.h |1 +
mm/page-writeback.c |9 ++---
3 files changed, 23 insertions(+), 5 deletions(-)
--- linux-mm.orig/fs/fs-writeback.c
+++ linux-mm/fs/fs-writeback.c
@@ -284,7 +284,17 @@ __sync_single_inode(struct inode *inode,
* soon as the queue becomes uncongested.
*/
inode->i_state |= I_DIRTY_PAGES;
- requeue_io(inode);
+ if (wbc->nr_to_write <= 0) {
+ /*
+* slice used up: queue for next turn
+*/
+ requeue_io(inode);
+ } else {
+ /*
+* somehow blocked: retry later
+*/
+ redirty_tail(inode);
+ }
} else {
/*
* Otherwise fully redirty the inode so that
@@ -468,8 +478,12 @@ void generic_sync_sb_inodes(struct super
iput(inode);
cond_resched();
spin_lock(&inode_lock);
- if (wbc->nr_to_write <= 0)
+ if (wbc->nr_to_write <= 0) {
+ wbc->more_io = 1;
break;
+ }
+ if (!list_empty(&sb->s_more_io))
+ wbc->more_io = 1;
}
spin_unlock(&inode_lock);
return; /* Leave any unwritten inodes on s_io */
--- linux-mm.orig/include/linux/writeback.h
+++ linux-mm/include/linux/writeback.h
@@ -62,6 +62,7 @@ struct writeback_control {
unsigned for_reclaim:1; /* Invoked from the page allocator */
unsigned for_writepages:1; /* This is a writepages() call */
unsigned range_cyclic:1;/* range_start is cyclic */
+ unsigned more_io:1; /* more io to be dispatched */
};
/*
--- linux-mm.orig/mm/page-writeback.c
+++ linux-mm/mm/page-writeback.c
@@ -567,6 +567,7 @@ static void background_writeout(unsigned
global_page_state(NR_UNSTABLE_NFS) < background_thresh
&& min_pages <= 0)
break;
+ wbc.more_io = 0;
wbc.encountered_congestion = 0;
wbc.nr_to_write = MAX_WRITEBACK_PAGES;
wbc.pages_skipped = 0;
@@ -574,8 +575,9 @@ static void background_writeout(unsigned
min_pages -=
Re: [kvm-devel] [PATCH][RFC] SVM: Add Support for Nested Paging in AMD Fam16 CPUs
Avi Kivity wrote: I find it non-descriptive, and it reminds me of another hypervisor. I suggest 'tlp' for two-level paging. That has its own ambiguity; without other context it reads like "two-level pagetable". Anyway, using the same term for the same thing is not a bad idea. J -- 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/
Re: Problem with ata layer in 2.6.24
On Sun, 2008-01-27 at 21:22 -0500, Gene Heskett wrote: > Greeting; > > None were logged during the time I was running an -rc7 or -rc8. > > The previous hits on this resulted in the udma speed being downgraded > till it was actually running in pio just before the freeze that > required the hardware reset button. > > I'll reboot to -rc8 right now and resume. If its the drive, I should see it. > If not, then 2.6.24 is where I'll point the finger. > > Idea's anyone? I believe there is some sort of bug in libata, not just for this kernel version. i run a fileserver with .20, and i get these resets a few times a day.. no freezes though... except when its in progress, then all IO freezes and locks up applications using it.. but it passes after ~30sec. i know that since ubuntu started shipping with libata by default for IDE, a large number of people are seeing these intermittant freezes aswell(which passes after half a minute or less). i reported this before, however as far as i know, no reason, and much less a fix, has been found. it would be great to get this solved though. > > -- > Cheers, Gene > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Yow! Am I in Milwaukee? > -- > 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/ -- 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/
Re: [PATCH] [0/18] Implement some low hanging BKL removal fruit in fs/*
> BTW. here is a patch I did a while back for minix. I know it isn't > a big deal, but the work is done so I guess I should send it along. Looks safe, although I'm surprised it actually gets around with such little locking in general. -Andi -- 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/
Re: Many processes stuck in blk_congestion_wait
On Wed, Jan 23, 2008 at 05:19:14PM -0500, Sev Binello wrote: > We are experiencing numerous hangs/slow downs on our WS4 U5 nfs client > machines (not seen on WS3). > Many processes end up in a D state for long periods of time > and are in blk_congestion_wait(). > > Time in this state can vary, > not sure what triggers them to come out, some don't > But time in this state can be quite lengthy. > Machines are running 2.6.9-55.0.9.ELsmp It's a pretty old kernel. If possible, a kernel upgrade may well fix your problem. -- 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/
Re: nfs server patches for 2.6.25
On Sun, Jan 27, 2008 at 05:10:17PM -0500, bfields wrote: > OK. I've got a machine running > > for c in $(git rev-list origin..linux-nfs/nfs-server-stable^); do > git checkout $c > make -s -j4 > done > > now just to make sure Thanks again! Pfft, that should have been: for c in $(git rev-list --reverse origin..linux-nfs/nfs-server-stable^); do git checkout $c make -s -j4 done The results are a lot easier to understand if you do the compiles in chronological order! Anyway, that found one more compile failure, now fixed. Hopefully that's the last. (Probably I did an incomplete job of reordering one of the patches the other week) --b. -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Monday 28 January 2008 00:08:56 Trond Myklebust wrote: > > On Sun, 2008-01-27 at 16:18 -0600, Steve French wrote: > > If two seeks overlap, can't you end up with an f_pos value that is > > different than what either thread seeked to? or if you have a seek and > > a read overlap can't you end up with the read occurring in the midst > > of an update of f_pos (which takes more than one instruction on > > various architectures), e.g. reading an f_pos, which has only the > > lower half of a 64 bit field updated? I agree that you shouldn't > > have seeks racing in parallel but I think it is preferable to get > > either the updated f_pos or the earlier f_pos not something 1/2 > > updated. > > Why? The threads are doing something inherently liable to corrupt data > anyway. If they can race over the seek, why wouldn't they race over the > read or write too? > The race in lseek() should probably be the least of your worries in this > case. The problem is that it's not a race in who gets to do its thing first, but a parallel reader can actually see a corrupted value from the two independent words on 32bit (e.g. during a 4GB). And this could actually completely corrupt f_pos when it happens with two racing relative seeks or read/write()s I would consider that a bug. Fixes would be either to always take a spinlock to update this (nasty on platforms where spinlocks are expensive like P4) or define some architecture specific way to read/write 64bit values consistently. In theory also some lazy locking seqlock like mechanism could be used, but that had the disadvantage of being theoretically starvable. -Andi -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Sunday 27 January 2008 23:18:26 Steve French wrote: > If two seeks overlap, can't you end up with an f_pos value that is > different than what either thread seeked to? Yes you can on 32bit. Especially during the 4GB wrap -Andi -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Sunday 27 January 2008 17:57:14 Steve French wrote: > Don't you need to a spinlock/spinunlock(i_lock) or something similar > (there isn't a spinlock in the file struct unfortunately) around the > reads and writes from f_pos in fs/read_write.c in remote_llseek with > your patch since the reads/writes from that field are not necessarily > atomic and threads could be racing in seek on the same file struct? Funny that you mention it. I actually noticed this too while working on this, but noticed that it is wrong everywhere (as in even plain sys_write/read gets it wrong). So I decided to not address it because it is already broken. I did actually send email to a few people about this, but no answer yet. I agree it's probably all broken on 32bit platforms, but I'm not sure how to best address this. When it is comprehensively addressed remote_llseek can use that new method too. -Andi -- 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/
Re: Troubles waking up from suspend (S3) - how to debug?
On Sunday, 27 of January 2008, Bruno Prémont wrote: > I'm currently trying out suspend (S3) on a few machines but none of them > wakes > up completely/properly (I have a few more hosts I'm planning to try suspend > on once I can get useful information out of those not waking up properly). > > Tested kernels: 2.6.24(-rc8), on one 2.6.23.8 > > To suspend I enter the following from console: > echo -n mem > /sys/power/state > Please try s2ram (http://suspend.sf.net/s2ram-support.html). > Fujitsu-Siemens S7020 laptop (i915GM based): > Works fine except backlight that remains asleep and Xorg vesa driver > crashing Xorg. > It looks like a suspend cycle discards the VideoBIOS shadow copy. > Adjusting brightness using hotkeys or acpi-fujitsusiemens does not help > waking up the backlight. > At best backlight comes back when suspending from Xorg with > xf86-video-intel-2.2.x but then mode is distorded. Any attempt to fix this > using xrandr or switch to/from console puts backlight asleep. This one is on the s2ram whitelist, should work. > Acer Travelmate 660 laptop (i855GM based): > Laptop suspends as expected but hangs while waking up. This might work with "s2ram -f --vbe_post --vbe_save", please try. > Desktop with MSI nforce based mainboard with Athlon CPU, onboard graphics What kind? > and hdd on HighPoint RR1640 PCI card (USB mouse & keyboard): > Suspends as expected but hangs while waking up. > During wakeup I can ping the computer but userspace does not respond (e.g. > no answer when trying to connect via ssh) > The display remains off if using vga text console, display comes back with > garbadge when using nvidiafb (no Xorg running), USB is powered but triggers > no reactions on keyboard/mouse input > > > I tried using netconsole on the desktop computer to capture eventual printks > during resume but I got not a line during wakup. (only suspend progress > messages before actual suspend) > > What can I do to get more information out of those two last machines and find > out why they don't wake-up properly? Please apply the patches 01-11 from: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24/patches/ on top of 2.6.24, compile the kernel and install it. After booting, please do: # echo core > /sys/power/pm_test # echo mem > /sys/power/state and see if the boxes survive it (this causes the suspend/resume sequence to be executed without acutally suspending, but busy-waiting for 5 sec. instead). Greetings, Rafael -- 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/
Re: 2.6.24-rc7-rt2
> For me, on the other hand, it is against the spirit of free software to > actively make a block for people to do what ever they want with the code > when they are only doing it to themselves. That includes loading non-GPL > software into the kernel. The only thing they are not allowed to do is to > distribute it and in that way "hurt" other people. Since the GPL only applies to the people to whom you distribute your code, if you do not distribute the code, licensing it under the GPL is 100% harmless to you. So the requirement to only load GPL'd code does not prevent people from loading code that they do not intend to distribute. They just have to label it as GPL and then not distribute it. Stefan -- 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/
[PATCH] x86_64: not set boot cpu in cpu_online_map at smp_prepare_boot_cpu
[PATCH] x86_64: not set boot cpu in cpu_online_map at smp_prepare_boot_cpu
in init/main.c boot_cpu_init() does that before
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/smpboot_64.c
===
--- linux-2.6.orig/arch/x86/kernel/smpboot_64.c
+++ linux-2.6/arch/x86/kernel/smpboot_64.c
@@ -921,7 +921,7 @@ void __init smp_prepare_cpus(unsigned in
void __init smp_prepare_boot_cpu(void)
{
int me = smp_processor_id();
- cpu_set(me, cpu_online_map);
+ /* already set me in cpu_online_map in boot_cpu_init() */
cpu_set(me, cpu_callout_map);
per_cpu(cpu_state, me) = CPU_ONLINE;
}
--
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/
Problem with ata layer in 2.6.24
Greeting;
I had to reboot early this morning due to a freezeup, and I had a
bunch of these in the messages log:
==
Jan 27 19:42:11 coyote kernel: [42461.915961] ata1.00: exception Emask 0x0 SAct
0x0 SErr 0x0 action 0x2 frozen
Jan 27 19:42:11 coyote kernel: [42461.915973] ata1.00: cmd
ca/00:08:b1:66:46/00:00:00:00:00/e8 tag 0 dma 4096 out
Jan 27 19:42:11 coyote kernel: [42461.915974] res
40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 27 19:42:11 coyote kernel: [42461.915978] ata1.00: status: { DRDY }
Jan 27 19:42:11 coyote kernel: [42461.916005] ata1: soft resetting link
Jan 27 19:42:12 coyote kernel: [42462.078216] ata1.00: configured for UDMA/100
Jan 27 19:42:12 coyote kernel: [42462.078232] ata1: EH complete
Jan 27 19:42:12 coyote kernel: [42462.090700] sd 0:0:0:0: [sda] 390721968
512-byte hardware sectors (200050 MB)
Jan 27 19:42:12 coyote kernel: [42462.114230] sd 0:0:0:0: [sda] Write Protect
is off
Jan 27 19:42:12 coyote kernel: [42462.115079] sd 0:0:0:0: [sda] Write cache:
enabled, read cache: enabled, doesn't
support DPO or FUA
===
That one showed up about 2 hours ago, so I expect I'll be locked
up again before I've managed a 24 hour uptime. This drive passed
a 'smartctl -t long /dev/sda' with flying colors after the reboot
this morning.
Two instances were logged after I had rebooted to 2.6.24 from 2.6.24-rc8:
Jan 24 20:46:33 coyote kernel: [0.00] Linux version 2.6.24 ([EMAIL
PROTECTED]) (gcc version 4.1.2 20070925
(Red Hat 4.1.2-33)) #1 SMP Thu Jan 24 20:17:55 EST 2008
Jan 27 02:28:29 coyote kernel: [193207.445158] ata1.00: exception Emask 0x0
SAct 0x0 SErr 0x0 action 0x2 frozen
Jan 27 02:28:29 coyote kernel: [193207.445170] ata1.00: cmd
35/00:08:f9:24:0a/00:00:17:00:00/e0 tag 0 dma 4096 out
Jan 27 02:28:29 coyote kernel: [193207.445172] res
40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 27 02:28:29 coyote kernel: [193207.445175] ata1.00: status: { DRDY }
Jan 27 02:28:29 coyote kernel: [193207.445202] ata1: soft resetting link
Jan 27 02:28:29 coyote kernel: [193207.607384] ata1.00: configured for UDMA/100
Jan 27 02:28:29 coyote kernel: [193207.607399] ata1: EH complete
Jan 27 02:28:29 coyote kernel: [193207.609681] sd 0:0:0:0: [sda] 390721968
512-byte hardware sectors (200050 MB)
Jan 27 02:28:29 coyote kernel: [193207.619277] sd 0:0:0:0: [sda] Write Protect
is off
Jan 27 02:28:29 coyote kernel: [193207.649041] sd 0:0:0:0: [sda] Write cache:
enabled, read cache: enabled, doesn't
support DPO or FUA
Jan 27 02:30:06 coyote kernel: [193304.336929] ata1.00: exception Emask 0x0
SAct 0x0 SErr 0x0 action 0x2 frozen
Jan 27 02:30:06 coyote kernel: [193304.336940] ata1.00: cmd
ca/00:20:69:22:a6/00:00:00:00:00/e7 tag 0 dma 16384 out
Jan 27 02:30:06 coyote kernel: [193304.336942] res
40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 27 02:30:06 coyote kernel: [193304.336945] ata1.00: status: { DRDY }
Jan 27 02:30:06 coyote kernel: [193304.336972] ata1: soft resetting link
Jan 27 02:30:06 coyote kernel: [193304.499210] ata1.00: configured for UDMA/100
Jan 27 02:30:06 coyote kernel: [193304.499226] ata1: EH complete
Jan 27 02:30:06 coyote kernel: [193304.499714] sd 0:0:0:0: [sda] 390721968
512-byte hardware sectors (200050 MB)
Jan 27 02:30:06 coyote kernel: [193304.499857] sd 0:0:0:0: [sda] Write Protect
is off
Jan 27 02:30:06 coyote kernel: [193304.502315] sd 0:0:0:0: [sda] Write cache:
enabled, read cache: enabled, doesn't
support DPO or FUA
None were logged during the time I was running an -rc7 or -rc8.
The previous hits on this resulted in the udma speed being downgraded
till it was actually running in pio just before the freeze that
required the hardware reset button.
I'll reboot to -rc8 right now and resume. If its the drive, I should see it.
If not, then 2.6.24 is where I'll point the finger.
Idea's anyone?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yow! Am I in Milwaukee?
--
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/
[PATCH] x86_64: not set boot cpu in cpu_present_map again
[PATCH] x86_64: not set boot cpu in cpu_present_map again in init/main.c boot_cpu_init() already does that before setup_arch Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> Index: linux-2.6/arch/x86/kernel/setup_64.c === --- linux-2.6.orig/arch/x86/kernel/setup_64.c +++ linux-2.6/arch/x86/kernel/setup_64.c @@ -446,12 +446,6 @@ void __init setup_arch(char **cmdline_p) early_quirks(); - /* -* set this early, so we dont allocate cpu0 -* if MADT list doesnt list BSP first -* mpparse.c/MP_processor_info() allocates logical cpu numbers. -*/ - cpu_set(0, cpu_present_map); #ifdef CONFIG_ACPI /* * Read APIC and some other early information from ACPI tables. -- 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/
Re: High wake up latencies with FAIR_USER_SCHED
On Sun, Jan 27, 2008 at 09:01:15PM +0100, Guillaume Chazarain wrote:
> I noticed some strangely high wake up latencies with FAIR_USER_SCHED
> using this script:
> We have two busy loops with UID=1.
> And UID=2 maintains the running median of its wake up latency.
> I get these latencies:
>
> # ./sched.py
> 4.300022 ms
> 4.801178 ms
> 4.604006 ms
Given that sysctl_sched_wakeup_granularity is set to 10ms by default,
this doesn't sound abnormal.
> Disabling FAIR_USER_SCHED restores wake up latencies in the noise:
>
> # ./sched.py
> -0.156975 ms
> -0.067091 ms
> -0.022984 ms
The reason why we are getting better wakeup latencies for !FAIR_USER_SCHED is
because of this snippet of code in place_entity():
if (!initial) {
/* sleeps upto a single latency don't count. */
if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se))
^^
vruntime -= sysctl_sched_latency;
/* ensure we never gain time by being placed backwards. */
vruntime = max_vruntime(se->vruntime, vruntime);
}
NEW_FAIR_SLEEPERS feature gives credit for sleeping only to tasks and
not group-level entities. With the patch attached, I could see that wakeup
latencies with FAIR_USER_SCHED are restored to the same level as
!FAIR_USER_SCHED.
However I am not sure whether that is the way to go. We want to let one group of
tasks running as much as possible until the fairness/wakeup-latency threshold is
exceeded. If someone does want better wakeup latencies between groups too, they
can always tune sysctl_sched_wakeup_granularity.
> Strangely enough, another way to restore normal latencies is to change
> setuid(2) to setuid(1), that is, putting the latency measurement in
> the same group as the two busy loops.
--
Regards,
vatsa
---
kernel/sched_fair.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: current/kernel/sched_fair.c
===
--- current.orig/kernel/sched_fair.c
+++ current/kernel/sched_fair.c
@@ -511,7 +511,7 @@
if (!initial) {
/* sleeps upto a single latency don't count. */
- if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se))
+ if (sched_feat(NEW_FAIR_SLEEPERS))
vruntime -= sysctl_sched_latency;
/* ensure we never gain time by being placed backwards. */
Re: [PATCH] [0/18] Implement some low hanging BKL removal fruit in fs/*
On Sunday 27 January 2008 13:17, Andi Kleen wrote:
> [Andrew: I believe this is -mm material for .25]
>
> - Convert some more file systems (generally those who don't use the BKL
> for anything except mount) to use unlocked_bkl.
> - Implement BKL less fasync (see patch for the rationale)
> This is currently a separate entry point, but since the number of fasync
> users in the tree is relatively small I hope the older entry point can
> be removed then in the not too far future
> [help from other people converting more fasync users to unlocked_fasync
> would be appreciated]
> - Implement BKL less remote_llseek
> - While I was at it I also added a few missing compat ioctl handlers
> - Fix a few comments
>
> This fixes a lot of relatively trivial BKL users in fs/*. The main
> remaining non legacy offenders are now locks.c, nfs/nfsd and reiserfs.
> I believe BKL removal for all of those is being worked on by other people.
> Also a lot of "legacy" file systems still use it, but converting those
> does not seem to be very pressing.
BTW. here is a patch I did a while back for minix. I know it isn't
a big deal, but the work is done so I guess I should send it along.
The minix filesystem uses bkl to protect access to metadata. Switch
to a per-superblock mutex.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/minix/bitmap.c
===
--- linux-2.6.orig/fs/minix/bitmap.c
+++ linux-2.6/fs/minix/bitmap.c
@@ -69,11 +69,11 @@ void minix_free_block(struct inode *inod
return;
}
bh = sbi->s_zmap[zone];
- lock_kernel();
+ mutex_lock(&sbi->s_mutex);
if (!minix_test_and_clear_bit(bit, bh->b_data))
printk("minix_free_block (%s:%lu): bit already cleared\n",
sb->s_id, block);
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
mark_buffer_dirty(bh);
return;
}
@@ -88,18 +88,18 @@ int minix_new_block(struct inode * inode
struct buffer_head *bh = sbi->s_zmap[i];
int j;
- lock_kernel();
+ mutex_lock(&sbi->s_mutex);
j = minix_find_first_zero_bit(bh->b_data, bits_per_zone);
if (j < bits_per_zone) {
minix_set_bit(j, bh->b_data);
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
mark_buffer_dirty(bh);
j += i * bits_per_zone + sbi->s_firstdatazone-1;
if (j < sbi->s_firstdatazone || j >= sbi->s_nzones)
break;
return j;
}
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
}
return 0;
}
@@ -211,10 +211,10 @@ void minix_free_inode(struct inode * ino
minix_clear_inode(inode); /* clear on-disk copy */
bh = sbi->s_imap[ino];
- lock_kernel();
+ mutex_lock(&sbi->s_mutex);
if (!minix_test_and_clear_bit(bit, bh->b_data))
printk("minix_free_inode: bit %lu already cleared\n", bit);
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
mark_buffer_dirty(bh);
out:
clear_inode(inode); /* clear in-memory copy */
@@ -237,7 +237,7 @@ struct inode * minix_new_inode(const str
j = bits_per_zone;
bh = NULL;
*error = -ENOSPC;
- lock_kernel();
+ mutex_lock(&sbi->s_mutex);
for (i = 0; i < sbi->s_imap_blocks; i++) {
bh = sbi->s_imap[i];
j = minix_find_first_zero_bit(bh->b_data, bits_per_zone);
@@ -245,17 +245,17 @@ struct inode * minix_new_inode(const str
break;
}
if (!bh || j >= bits_per_zone) {
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
iput(inode);
return NULL;
}
if (minix_test_and_set_bit(j, bh->b_data)) { /* shouldn't happen */
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
printk("minix_new_inode: bit already set\n");
iput(inode);
return NULL;
}
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
mark_buffer_dirty(bh);
j += i * bits_per_zone;
if (!j || j > sbi->s_ninodes) {
Index: linux-2.6/fs/minix/dir.c
===
--- linux-2.6.orig/fs/minix/dir.c
+++ linux-2.6/fs/minix/dir.c
@@ -102,7 +102,7 @@ static int minix_readdir(struct file * f
char *name;
__u32 inumber;
- lock_kernel();
+ mutex_lock(&sbi->s_mutex);
pos = (pos + chunk_size-1) & ~(chunk_size-1);
if (pos >= inode->i_size)
@@ -146,7 +146,7 @@ static int minix_readdir(struct file * f
done:
filp->f_pos = (n << PAGE_CACHE_SHIFT) | offset;
- unlock_kernel();
+ mutex_unlock(&sbi->s_mutex);
return 0;
}
Index: linux-2.6/fs/minix/inode.c
===
--- linux-2.6.orig/fs/minix/inode.c
+++ linux-2.6/fs/minix/inode.c
@@ -174,6 +174,7 @@ static int minix_fill_super(struct super
sbi->s_firstdatazone = ms->s_firstdatazone;
sbi->s_log_zone_size = ms->s_log_zone_size;
sbi->s_max_size = ms->s_max_size;
+ mutex_init(&sbi->s_mutex);
s->s_magic = ms->s_magic;
if (s->s_magic == MINIX_SUPER_MAGIC) {
sbi->s_version = MINIX_V1;
Index: linux-2.6/fs/minix/minix.h
===
--- linux-2.6.orig/fs/minix/minix.h
+++ linux-2.6/fs/minix/minix.h
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
NFS EINVAL with O_TRUNC
hoi :) I bisected the kernel to find out why cfs stopped working. (open with O_TRUNC returning EINVAL when file already exists on an cfs file system.) First I tried to debug cfs itself, and after reading Gianlucas thread on lkml I then looked at the kernel itself. 1c710c896eb461895d3c399e15bb5f20b39c9073 is first bad commit commit 1c710c896eb461895d3c399e15bb5f20b39c9073 Author: Ulrich Drepper <[EMAIL PROTECTED]> Date: Tue May 8 00:33:25 2007 -0700 utimensat implementation Implement utimensat(2) which is an extension to futimesat(2) in that it a) supports nano-second resolution for the timestamps b) allows to selectively ignore the atime/mtime value c) allows to selectively use the current time for either atime or mtime d) supports changing the atime/mtime of a symlink itself along the lines of the BSD lutimes(3) functions [...] I don't have any clue how this commit can break cfs, but it definitely does. At least it uncovers some bug either in the Linux NFS client or in the cvs server code. So, and now I will happily go to sleep... Thanks to everybody who can figure out why above commit breaks stuff... -- Martin signature.asc Description: Digital signature
Re: [PATCH 3/9] x86_64: Switch to .data.compressed in arch/x86/boot/compressed/vmlinux_64.scr
Yinghai Lu wrote: payload.compressed ? We can call it .payload, or just .rodata.compressed. -hpa -- 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/
Re: 2.6.24 regression: pan hanging unkilleable and un-straceable
On Sunday 27 January 2008 01:27, Pascal Terjan wrote: > Nick Piggin yahoo.com.au> writes: > > On Sunday 27 January 2008 00:29, Frederik Himpe wrote: > > > I just succeeded to reproduce the problem with this patch. Does this > > > smell like an XFS problem? > > I got the same issue using ext3 > > > Possible. Though I think it is more likely to be a bug in the > > new deadlock avoidance code in the generic buffered write path. > > Dang... I wonder why this hasn't come up earlier. It looks like > > pan's use of writev might be tickling it. > > > > How quickly can you reproduce this? > > When I was using pan daily one month ago, I got it twice over a week > > > Can you use strace to see what the hanging syscall looks like? > > I tried last week during 5 hours without luck, I can try again Dang, I didn't see any reports of this earlier :( Anyway, I sent a patch to fix it in the original thread (can you reply-to-all please? just it a bit easier to keep threads together) Thanks, Nick -- 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/
Re: [PATCH 3/9] x86_64: Switch to .data.compressed in arch/x86/boot/compressed/vmlinux_64.scr
On Jan 27, 2008 4:33 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > > Yinghai Lu wrote: > > On Jan 27, 2008 2:04 PM, Ian Campbell <[EMAIL PROTECTED]> wrote: > >> On Sat, 2008-01-26 at 16:59 -0800, Yinghai Lu wrote: > >> > >>> can you make 32 bit use .text.compressed instead ? > >> Any reason to prefer .text? It is data at this stage after all. > >> > > it is comressed text insead of compressed data. > > > > No it's not. It's both. payload.compressed ? YH -- 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/
Re: [RFC] some page can't be migrated
On Mon, 2008-01-28 at 12:43 +1100, Nick Piggin wrote:
> On Sunday 27 January 2008 17:03, Andrew Morton wrote:
> > > On Fri, 25 Jan 2008 14:03:25 +0800 Shaohua Li <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > - if (!page->mapping)
> > > + if (!page->mapping) {
> > > + if (!PageAnon(page) && PagePrivate(page))
> > > + try_to_release_page(page, GFP_KERNEL);
> > > goto rcu_unlock;
> > > + }
> >
> > We call something(GFP_KERNEL) under rcu_read_lock()? I've lost track of
> > the myriad flavours of rcu which we purport to support, but I don't think
> > they'll all like us blocking under rcu_read_lock().
> >
> > We _won't_ block, because try_to_release_page() will see the NULL ->mapping
> > and will call the non-blocking try_to_free_buffers(). But still, it looks
> > bad, and will cause problems if someone decides to add a might_sleep_if()
> > to try_to_release_page().
> >
> > So... I'd suggest that it would be better to add an apologetic comment and
> > call direct into try_to_free_buffers().
>
> You're right, but can't we just rcu_read_unlock() before try_to_release_page?
or we could move the code above before doing rcu_read_lock()?
--
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/
Re: 2.6.24 regression: pan hanging unkilleable and un-straceable
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
> > > > On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
> > > > > With Linux 2.6.24-rc8 I often have the problem that the pan usenet
> > > > > reader starts using 100% of CPU time after some time. When this
> > > > > happens, kill -9 does not work, and strace just hangs when trying
> > > > > to attach to the process. The same with gdb. ps shows the process
> > > > > as being in the R state.
> > > > >
> > > > > I pressed Ctrl-Alt-SysRq-T, and this was shown for pan:
> > > > > Jan 21 21:45:01 Anastacia kernel: pan R running task
> > > > > 0
> >
> > Nasty. The attached patch is something really simple that can sometimes
> > help. sysrq+p is also an option, if you're on a UP system.
> >
> > Any luck getting traces?
>
> I just succeeded to reproduce the problem with this patch. Does this
> smell like an XFS problem?
>
> Jan 26 14:17:43 Anastacia kernel: pan R running task0
> 7564 1 Jan 26 14:17:43 Anastacia kernel: 3f5b3248
> 1000 880c28b0 Jan 26 14:17:43
> Anastacia kernel: 81003f5b3248 81002d1ed900 2d1ed900
> Jan 26 14:17:43 Anastacia kernel: 810016050dd0
> f000f000 81002d1eda10 Jan 26 14:17:43
> Anastacia kernel: Call Trace:
> Jan 26 14:17:43 Anastacia kernel: [_end+127964408/2129947720]
> :xfs:xfs_get_blocks+0x0/0x10 Jan 26 14:17:43 Anastacia kernel:
> [unix_poll+0/176] unix_poll+0x0/0xb0 Jan 26 14:17:43 Anastacia kernel:
> [_end+127964408/2129947720] :xfs:xfs_get_blocks+0x0/0x10 Jan 26 14:17:43
> Anastacia kernel: [iov_iter_copy_from_user_atomic+65/160]
> iov_iter_copy_from_user_atomic+0x41/0xa0 Jan 26 14:17:43 Anastacia kernel:
> [iov_iter_copy_from_user_atomic+46/160]
> iov_iter_copy_from_user_atomic+0x2e/0xa0 Jan 26 14:17:43 Anastacia kernel:
> [generic_file_buffered_write+383/1728]
Well after trying a lot of writev combinations, I've reproduced a hang
*hangs head*.
Does this help?
Zero length iovecs can go into an infinite loop in writev, because the
iovec iterator does not always advance over them.
The sequence required to trigger this is not trivial. I think it requires
that a zero-length iovec be followed by a non-zero-length iovec which causes
a pagefault in the atomic usercopy. This causes the writev code to drop back
into single-segment copy mode, which then tries to copy the 0 bytes of the
zero-length iovec; a zero length copy looks like a failure though, so it
loops.
Put a test into iov_iter_advance to catch zero-length iovecs. We could just
put the test in the fallback path, but I feel it is more robust to skip
over zero-length iovecs throughout the code (iovec iterator may be used in
filesystems too, so it should be robust).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -1733,7 +1733,11 @@ static void __iov_iter_advance_iov(struc
const struct iovec *iov = i->iov;
size_t base = i->iov_offset;
- while (bytes) {
+ /*
+ * The !iov->iov_len check ensures we skip over unlikely
+ * zero-length segments.
+ */
+ while (bytes || !iov->iov_len) {
int copy = min(bytes, iov->iov_len - base);
bytes -= copy;
@@ -2251,6 +2255,7 @@ again:
cond_resched();
+ iov_iter_advance(i, copied);
if (unlikely(copied == 0)) {
/*
* If we were unable to copy any data at all, we must
@@ -2264,7 +2269,6 @@ again:
iov_iter_single_seg_count(i));
goto again;
}
- iov_iter_advance(i, copied);
pos += copied;
written += copied;
Re: [RFC] some page can't be migrated
On Sunday 27 January 2008 17:03, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 14:03:25 +0800 Shaohua Li <[EMAIL PROTECTED]>
> > wrote:
> >
> > - if (!page->mapping)
> > + if (!page->mapping) {
> > + if (!PageAnon(page) && PagePrivate(page))
> > + try_to_release_page(page, GFP_KERNEL);
> > goto rcu_unlock;
> > + }
>
> We call something(GFP_KERNEL) under rcu_read_lock()? I've lost track of
> the myriad flavours of rcu which we purport to support, but I don't think
> they'll all like us blocking under rcu_read_lock().
>
> We _won't_ block, because try_to_release_page() will see the NULL ->mapping
> and will call the non-blocking try_to_free_buffers(). But still, it looks
> bad, and will cause problems if someone decides to add a might_sleep_if()
> to try_to_release_page().
>
> So... I'd suggest that it would be better to add an apologetic comment and
> call direct into try_to_free_buffers().
You're right, but can't we just rcu_read_unlock() before try_to_release_page?
--
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/
Re: [Regression] 2.6.24-git3: Major annoyance during suspend/hibernation on x86-64 (bisected)
Rafael J. Wysocki wrote: No, this isn't the WARN_ON(). this does have the feel of being scheduling related, but are you absolutely sure about the precise identity of the patch? Actually, not quite. That's why I have verified it and found that another patch is really responsible for the issue, namely: commit 82a1fcb90287052aabfa235e7ffc693ea003fe69 Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Fri Jan 25 21:08:02 2008 +0100 softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks Are you getting a bunch of prints from the softlockup detector in dmesg? I wonder if the detector can detect a long timeout caused by suspend and resume and if not is triggering false positives? -- Steve Reverting this commit (it reverts with some minor modifications) fixes the problem for me. -- 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/
Re: [Regression] 2.6.24-git3: Major annoyance during suspend/hibernation on x86-64 (bisected)
On Sunday, 27 of January 2008, Ingo Molnar wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > 2.6.24-git3 adds a 5 - 10 sec delay to the suspend and hibernation > > code paths (probably related to the disabling of nonboot CPUs), which > > is [EMAIL PROTECTED]&*() annoying. > > > > It's 100% reproducible on my HP nx6325 and bisection idendified the > > following commit as the first bad one: > > > > commit 764a9d6fe4b52995c8aba277e3634385699354f4 > > Author: Steven Rostedt <[EMAIL PROTECTED]> > > Date: Fri Jan 25 21:08:04 2008 +0100 > > > > sched: track highest prio task queued > > hm, this patch is a NOP, so it's weird that it has an effect. > > Do you have serial logging enabled perhaps? If the following WARN_ON() > triggers: > > + WARN_ON(p->prio < rq->rt.highest_prio); > > then perhaps that can cause a 5-10 seconds delay. (that's how much time > it takes to printk a warning on the slowest serial settings) > > but if you use suspend, then any such printks would be preserved in the > dmesg, right? If the WARN_ON() triggers, and if you remove it, do things > get faster? No, this isn't the WARN_ON(). > this does have the feel of being scheduling related, but are you > absolutely sure about the precise identity of the patch? Actually, not quite. That's why I have verified it and found that another patch is really responsible for the issue, namely: commit 82a1fcb90287052aabfa235e7ffc693ea003fe69 Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Fri Jan 25 21:08:02 2008 +0100 softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks Reverting this commit (it reverts with some minor modifications) fixes the problem for me. Thanks, Rafael -- 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/
Re: [PATCH] Rationalise ACPI backlight implementation
On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote: > - Create a new /sys node with a new name which has the new semantics. The semantics are the same as they always have been - values between 0 and max_brightness are valid values. If you've made assumptions about what max_brightness is, then that's a bug in the userspace application rather than a change in the semantics of the interface. -- Matthew Garrett | [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/
Re: a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
On Mon, 2008-01-28 at 08:50 +1100, Linus Torvalds wrote: > > On Sun, 27 Jan 2008, Avuton Olrich wrote: > > > > With v2.6.24 my second ALSA sound device stopped working. > > Hmm. Why is PnP ACPI called before PCI probing? That seems to be the > problem here - we should *never* have any firmware allocation block known > hardware BARs, they should only be blocking new dynamic allocations. > > Hmm. I wonder if the problem is that ACPIPnP marks the regions busy. That > would be wrong. They shouldn't be busy, they should just "exist". > > A busy region will stop a "request_region()" (incorrect for this case - > thats' not what the PnP resurce allocation should be all about), but an > *existing* resource will just stop a new resource being dynamically > assigned to that address (not not stop a known resource from using it). > > So maybe the ACPIPnP allocation is doen at the right moment, just doing > the wrong thing.. This is because the region is declaimed in motherboard device. That is BIOS thinks the region is reserved for motherboard. Maybe we should blacklist the system too. -- 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/
[PATCH 2/2] aio: -EINVAL on negative read/write offset
An AIO read or write should return -EINVAL if the offset is negative.
This check matches the one in pread and pwrite.
This was found by the libaio test suite.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
fs/aio.c |4
1 file changed, 4 insertions(+)
diff -r 18802689361a fs/aio.c
--- a/fs/aio.c Thu Jan 03 15:22:24 2008 +1100
+++ b/fs/aio.c Thu Jan 03 18:05:25 2008 +1100
@@ -1330,6 +1330,10 @@ static ssize_t aio_rw_vect_retry(struct
opcode = IOCB_CMD_PWRITEV;
}
+ /* This matches the pread()/pwrite() logic */
+ if (iocb->ki_pos < 0)
+ return -EINVAL;
+
do {
ret = rw_op(iocb, &iocb->ki_iovec[iocb->ki_cur_seg],
iocb->ki_nr_segs - iocb->ki_cur_seg,
--
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/
[PATCH 1/2] aio: partial write return
When an AIO write gets a non-retry error after writing some data (eg. ENOSPC), it should return the amount written already, not the error. Just like write() is supposed to. This was found by the libaio test suite. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> Acked-By: Zach Brown <[EMAIL PROTECTED]> --- fs/aio.c |7 +++ 1 file changed, 7 insertions(+) diff -r 18802689361a fs/aio.c --- a/fs/aio.c Thu Jan 03 15:22:24 2008 +1100 +++ b/fs/aio.c Thu Jan 03 18:05:25 2008 +1100 @@ -1346,6 +1350,13 @@ static ssize_t aio_rw_vect_retry(struct /* This means we must have transferred all that we could */ /* No need to retry anymore */ if ((ret == 0) || (iocb->ki_left == 0)) + ret = iocb->ki_nbytes - iocb->ki_left; + + /* If we managed to write some out we return that, rather than +* the eventual error. */ + if (opcode == IOCB_CMD_PWRITEV + && ret < 0 && ret != -EIOCBQUEUED && ret != -EIOCBRETRY + && iocb->ki_nbytes - iocb->ki_left) ret = iocb->ki_nbytes - iocb->ki_left; return ret; -- 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/
Re: [PATCH] CRAMFS: Uncompressed files support
> > This patch enables the uncompressed files support in cramfs.
> >
> > The word 'uncompressed file' is from linear cramfs (aka Application XIP).
> > In linear cramfs, it is used to suport XIP on NOR. However it is also
> > helpful on OneNAND. It makes a filesystem faster by removing compression
> > overhead.
> > In XIP mode it runs XIP, But non-XIP mode. It copies data to ram and runs.
> >
> > In my simple test, copy busybox (compressed or uncompressed).
> > It reduces the about 50% time saving from 0.40s to 0.19s.
> > Yes, it incrases the file system size, but nowadays flash has big capacity.
> > It's trade-off between size and performance.
> >
> > Also this patch uses the page cache directly.
> > In previous implementation, it used the local buffer. why?
> > It's already uncompressed and fits to page size. So It uses the page
> > directly to remove useless memory copy.
> >
> > It's compatible the existing linear cramfs image and original one.
> >
> > Any comments are welcome.
> >
> > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > index 3d194a2..edba28f 100644
> > --- a/fs/cramfs/inode.c
> > +++ b/fs/cramfs/inode.c
>
> I don't know what kernel this is against but it generates a lot of rejects
> against present mainline.
>
Sorry, it used another tree instead of mainline. Following patch will
be against mainline.
>
> Are you sure about the kmap/kunmap handling in this patch? It looks like
> it might be unbalanced.
>
Yes, It's matching. Because cramfs_read returns virtual address, it
returns the kmap-ped address if it had page, then caller kunmap-ed and
release it. Otherwise pg doesn't have page pointer.
Anyway, here's more simple method using get_block sytle.
With this patch, it can also use multi page read, cramfs_readpages.
However, it has no big improvement in my environment.
The goal is same it uses the requested page directly instead of
useless memory copy.
Any comments are welcome.
Thank you,
Kyungmin Park
Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 350680f..2d6736d 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,7 @@ static DEFINE_MUTEX(read_mutex);
#define CRAMINO(x) (((x)->offset && (x)->size)?(x)->offset<<2:1)
#define OFFSET(x) ((x)->i_ino)
+#define CRAMFS_INODE_IS_XIP(x) ((x)->i_mode & S_ISVTX)
static int cramfs_iget5_test(struct inode *inode, void *opaque)
{
@@ -468,16 +470,32 @@ static struct dentry * cramfs_lookup(struct
inode *dir, struct dentry *dentry, s
return NULL;
}
+static int cramfs_get_block(struct inode *inode, sector_t iblock,
+ struct buffer_head *bh_result, int create)
+{
+ /* A write? */
+ BUG_ON(unlikely(create));
+
+ iblock += (PAGE_ALIGN(OFFSET(inode)) >> PAGE_CACHE_SHIFT);
+ map_bh(bh_result, inode->i_sb, iblock);
+
+ return 0;
+}
+
static int cramfs_readpage(struct file *file, struct page * page)
{
struct inode *inode = page->mapping->host;
+ struct super_block *sb = inode->i_sb;
u32 maxblock, bytes_filled;
void *pgdata;
maxblock = (inode->i_size + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
bytes_filled = 0;
- if (page->index < maxblock) {
- struct super_block *sb = inode->i_sb;
+
+ /* Handle uncompressed files */
+ if (CRAMFS_INODE_IS_XIP(inode) && page->index < maxblock) {
+ return mpage_readpage(page, cramfs_get_block);
+ } else if (page->index < maxblock) {
u32 blkptr_offset = OFFSET(inode) + page->index*4;
u32 start_offset, compr_len;
--
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/
Re: Troubles waking up from suspend (S3) - how to debug?
On Sun, Jan 27, 2008 at 18:42:37 +0100, Bruno Prémont wrote: > I'm currently trying out suspend (S3) on a few machines but none of them > wakes > up completely/properly (I have a few more hosts I'm planning to try suspend > on once I can get useful information out of those not waking up properly). [...] > Acer Travelmate 660 laptop (i855GM based): > Laptop suspends as expected but hangs while waking up. You might try this: http://tikei.de/suspend-to-ram-debug Regards, Tino -- 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/
Re: 2.6.25 regression: VIDEO_DEV=y/m, I2C=n compile error
Hi Adrian and Marcin,
On Sun, 27 Jan 2008 20:52:16 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Commit 8ffbc6559493c64d6194c92d856196fdaeb8a5fb causes the following
> compile error with CONFIG_VIDEO_DEV=y/m, CONFIG_I2C=n:
>
> <-- snip -->
>
> ...
> MODPOST 26 modules
> ERROR: "i2c_attach_client" [drivers/media/video/v4l2-common.ko] undefined!
> make[2]: *** [__modpost] Error 1
>
> <-- snip -->
Thanks for getting this regression. Please test the enclosed patch.
Cheers,
Mauro
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
diff -r b0815101889d linux/drivers/media/video/v4l2-common.c
--- a/linux/drivers/media/video/v4l2-common.c Sun Jan 27 20:39:00 2008
-0200 +++ b/linux/drivers/media/video/v4l2-common.c Sun Jan 27 22:23:25
2008 -0200 @@ -1585,6 +1585,7 @@ u32 v4l2_ctrl_next(const u32 * const * c
return **ctrl_classes;
}
+#ifdef CONFIG_I2C
int v4l2_chip_match_i2c_client(struct i2c_client *c, u32 match_type, u32
match_chip) {
switch (match_type) {
@@ -1596,6 +1597,7 @@ int v4l2_chip_match_i2c_client(struct i2
return 0;
}
}
+EXPORT_SYMBOL(v4l2_chip_match_i2c_client);
int v4l2_chip_ident_i2c_client(struct i2c_client *c, struct v4l2_chip_ident
*chip, u32 ident, u32 revision)
@@ -1612,6 +1614,7 @@ int v4l2_chip_ident_i2c_client(struct i2
}
return 0;
}
+EXPORT_SYMBOL(v4l2_chip_ident_i2c_client);
int v4l2_chip_match_host(u32 match_type, u32 match_chip)
{
@@ -1622,6 +1625,7 @@ int v4l2_chip_match_host(u32 match_type,
return 0;
}
}
+EXPORT_SYMBOL(v4l2_chip_match_host);
/* - */
@@ -1656,6 +1660,8 @@ int v4l2_i2c_attach(struct i2c_adapter *
}
return err != -ENOMEM ? 0 : err;
}
+EXPORT_SYMBOL(v4l2_i2c_attach);
+#endif
/* - */
@@ -1679,15 +1685,3 @@ EXPORT_SYMBOL(v4l2_ctrl_query_menu);
EXPORT_SYMBOL(v4l2_ctrl_query_menu);
EXPORT_SYMBOL(v4l2_ctrl_query_fill);
EXPORT_SYMBOL(v4l2_ctrl_query_fill_std);
-
-EXPORT_SYMBOL(v4l2_chip_match_i2c_client);
-EXPORT_SYMBOL(v4l2_chip_ident_i2c_client);
-EXPORT_SYMBOL(v4l2_chip_match_host);
-
-EXPORT_SYMBOL(v4l2_i2c_attach);
-
-/*
- * Local variables:
- * c-basic-offset: 8
- * End:
- */
--
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/
Re: [PATCH 3/9] x86_64: Switch to .data.compressed in arch/x86/boot/compressed/vmlinux_64.scr
Yinghai Lu wrote: On Jan 27, 2008 2:04 PM, Ian Campbell <[EMAIL PROTECTED]> wrote: On Sat, 2008-01-26 at 16:59 -0800, Yinghai Lu wrote: can you make 32 bit use .text.compressed instead ? Any reason to prefer .text? It is data at this stage after all. it is comressed text insead of compressed data. No it's not. It's both. -hpa -- 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/
2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
Hi folks, with 2.6.24-rc8, Wake On LAN doesn't work anymore as it used to with 2.6.23 on my Mac mini Core Duo. I saw that this was reported in http://bugzilla.kernel.org/show_bug.cgi?id=9721 and on netdev a patch for the sky2 driver was sent by Stephen Hemminger. This patch fixed WOL for me after applying it to 2.6.24-rc8. However, it seems as the patch never made it into the kernel. Instead, the commit that was suspected to break WOL (84cd2dfb04d23a961c5f537baa243fa54d0987ac) was reverted (be63a21c9573fbf88106ff0f030da5974551257b). Now I tried the 2.6.24 release and noticed that WOL is still broken. I'll be happy to test any patches that can make it into 2.6.24.1. Regards, Tino -- 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/
Re: [PATCH] X86: coding style fixes to arch/x86/math-errors.c - take 2
Paolo Ciarrocchi пишет: > On Jan 27, 2008 11:48 PM, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote: >> On Jan 27, 2008 11:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: ... > > How should I compare the .o file? > Simply doing a md5sum or should I do a objdump -d before? > Or a strip? > Comparing the vmlinux images shoudls suffice. But you'll have to make sure that the object file resulting from the C source that you're changing gets linked into vmlinux. Dmitri > Ciao, -- 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/
Re: [PATCH] X86: coding style fixes to arch/x86/math-errors.c - take 2
On Jan 27, 2008 11:48 PM, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote: > > On Jan 27, 2008 11:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > * Dmitri Vorobiev <[EMAIL PROTECTED]> wrote: > > > > > Looks like it would be better to proceed in the following manner: > > > > > > 1) remove dead code (no md5 change); > > > 2) reformat the lines to use tabs, not spaces (no md5 change); > > > 3) address the "else-braces" and "single statement block" errors > > >(no md5 change); > > > 4) remove all unnecessary spaces (no md5 change); > > > 5) add the KERN_ macros (md5 will change). > > > 6) address remaining checkpatch complaints (no md5 change wrt #5 > > >above). > > > > > > Each item above might get into a separate patch. > > > > agreed, that looks like a sensible splitup for such larger cleanup > > patches. > > > > (also, a debug switch that disabled the FPU on modern CPUs and which > > forced math-emu would be nice as well.) > > OK, I'll do what you both suggested. Mmh... I wonder why if I strip the files I get the same md5sum: [EMAIL PROTECTED]:~/linux-2.6/kernel$ strip /home/paolo/Desktop/File\ punto\ o/* [EMAIL PROTECTED]:~/linux-2.6/kernel$ md5sum /home/paolo/Desktop/File\ punto\ o/* 2bf404e247edf33cf6fb99c37321cdb9 /home/paolo/Desktop/File punto o/error.o.after 2bf404e247edf33cf6fb99c37321cdb9 /home/paolo/Desktop/File punto o/error.o.before How should I compare the .o file? Simply doing a md5sum or should I do a objdump -d before? Or a strip? Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.com/ -- 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/
Re: preemptible RCU bug (was Re: [git pull] scheduler changes for v2.6.25)
On Sun, Jan 27, 2008 at 01:26:02PM +0100, Ingo Molnar wrote: > > * Paul E. McKenney <[EMAIL PROTECTED]> wrote: > > > > Sorry, no help available for this option yet. > > > > Good catch!!! > > > > This patch supplies help text for the "RCU implementation type" kernel > > configuration choice. > > thanks applied to sched.git. (see the patch below - the config option is > in init/Kconfig in mainline, not in kernel/Kconfig.preempt) Ah missed that -- thank you for retargeting the patch. Thanx, Paul > Ingo > > -> > Subject: RCU: add help text for "RCU implementation type" > From: "Paul E. McKenney" <[EMAIL PROTECTED]> > > This patch supplies help text for the "RCU implementation type" > kernel configuration choice. > > Reported-by: Stefan Richter <[EMAIL PROTECTED]> > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > --- > > init/Kconfig |8 > 1 file changed, 8 insertions(+) > > Index: linux/init/Kconfig > === > --- linux.orig/init/Kconfig > +++ linux/init/Kconfig > @@ -779,6 +779,14 @@ config PREEMPT_NOTIFIERS > choice > prompt "RCU implementation type:" > default CLASSIC_RCU > + help > + This allows you to choose either the classic RCU implementation > + that is designed for best read-side performance on non-realtime > + systems, or the preemptible RCU implementation for best latency > + on realtime systems. Note that some kernel preemption modes > + will restrict your choice. > + > + Select the default if you are unsure. > > config CLASSIC_RCU > bool "Classic RCU" -- 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/
[PATCH 5/5] PPC: Fix powerpc vio_find_name to not use devices_subsys
From: Paul Mackerras <[EMAIL PROTECTED]>
This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
currently broken because it tries to use devices_subsys. That is bad
for two reasons: (1) it's doing (or trying to do) a scan of all
devices when it should only be scanning those on the vio bus, and
(2) devices_subsys was an internal symbol of the device system code
which was never meant for external use and has now gone away, and
thus the kernel fails to compile on pSeries.
The new version uses bus_find_device_by_name() on the vio bus
(vio_bus_type).
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/vio.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 19a5656..f0bad70 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -37,8 +37,6 @@
#include
#include
-extern struct kset devices_subsys; /* needed for vio_find_name() */
-
static struct bus_type vio_bus_type;
static struct vio_dev vio_bus_device = { /* fake "parent" device */
@@ -361,19 +359,16 @@ EXPORT_SYMBOL(vio_get_attribute);
#ifdef CONFIG_PPC_PSERIES
/* vio_find_name() - internal because only vio.c knows how we formatted the
* kobject name
- * XXX once vio_bus_type.devices is actually used as a kset in
- * drivers/base/bus.c, this function should be removed in favor of
- * "device_find(kobj_name, &vio_bus_type)"
*/
-static struct vio_dev *vio_find_name(const char *kobj_name)
+static struct vio_dev *vio_find_name(const char *name)
{
- struct kobject *found;
+ struct device *found;
- found = kset_find_obj(&devices_subsys, kobj_name);
+ found = bus_find_device_by_name(&vio_bus_type, NULL, name);
if (!found)
return NULL;
- return to_vio_dev(container_of(found, struct device, kobj));
+ return to_vio_dev(found);
}
/**
--
1.5.3.8
--
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/
[PATCH 3/5] Module: check to see if we have a built in module with the same name
When trying to load a module with the same name as a built-in one, a
scary kobject backtrace comes up. Prevent that from checking for this
condition and warning the user as to what exactly is going on.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/module.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 1bb4c5e..76ddc85 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1214,6 +1214,7 @@ void module_remove_modinfo_attrs(struct module *mod)
int mod_sysfs_init(struct module *mod)
{
int err;
+ struct kobject *kobj;
if (!module_sysfs_initialized) {
printk(KERN_ERR "%s: module sysfs not initialized\n",
@@ -1221,6 +1222,15 @@ int mod_sysfs_init(struct module *mod)
err = -EINVAL;
goto out;
}
+
+ kobj = kset_find_obj(module_kset, mod->name);
+ if (kobj) {
+ printk(KERN_ERR "%s: module is already loaded\n", mod->name);
+ kobject_put(kobj);
+ err = -EINVAL;
+ goto out;
+ }
+
mod->mkobj.mod = mod;
memset(&mod->mkobj.kobj, 0, sizeof(mod->mkobj.kobj));
--
1.5.3.8
--
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/
[PATCH 4/5] Driver core: add bus_find_device_by_name function
The driver core, and some other parts of the kernel just want to find a
device based on a name for a specific bus. Give them a simple wrapper
to prevent them from having to always roll their own.
This will be used in the PPC patch later in this series.
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/base/bus.c | 41 +
include/linux/device.h |3 +++
2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index f484495..055989e 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -163,15 +163,6 @@ static struct kset *bus_kset;
#ifdef CONFIG_HOTPLUG
/* Manually detach a device from its associated driver. */
-static int driver_helper(struct device *dev, void *data)
-{
- const char *name = data;
-
- if (strcmp(name, dev->bus_id) == 0)
- return 1;
- return 0;
-}
-
static ssize_t driver_unbind(struct device_driver *drv,
const char *buf, size_t count)
{
@@ -179,7 +170,7 @@ static ssize_t driver_unbind(struct device_driver *drv,
struct device *dev;
int err = -ENODEV;
- dev = bus_find_device(bus, NULL, (void *)buf, driver_helper);
+ dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == drv) {
if (dev->parent)/* Needed for USB */
down(&dev->parent->sem);
@@ -206,7 +197,7 @@ static ssize_t driver_bind(struct device_driver *drv,
struct device *dev;
int err = -ENODEV;
- dev = bus_find_device(bus, NULL, (void *)buf, driver_helper);
+ dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == NULL) {
if (dev->parent)/* Needed for USB */
down(&dev->parent->sem);
@@ -250,7 +241,7 @@ static ssize_t store_drivers_probe(struct bus_type *bus,
{
struct device *dev;
- dev = bus_find_device(bus, NULL, (void *)buf, driver_helper);
+ dev = bus_find_device_by_name(bus, NULL, buf);
if (!dev)
return -ENODEV;
if (bus_rescan_devices_helper(dev, NULL) != 0)
@@ -338,6 +329,32 @@ struct device *bus_find_device(struct bus_type *bus,
}
EXPORT_SYMBOL_GPL(bus_find_device);
+static int match_name(struct device *dev, void *data)
+{
+ const char *name = data;
+
+ if (strcmp(name, dev->bus_id) == 0)
+ return 1;
+ return 0;
+}
+
+/**
+ * bus_find_device_by_name - device iterator for locating a particular device
of a specific name
+ * @bus: bus type
+ * @start: Device to begin with
+ * @name: name of the device to match
+ *
+ * This is similar to the bus_find_device() function above, but it handles
+ * searching by a name automatically, no need to write another strcmp matching
+ * function.
+ */
+struct device *bus_find_device_by_name(struct bus_type *bus,
+ struct device *start, const char *name)
+{
+ return bus_find_device(bus, start, (void *)name, match_name);
+}
+EXPORT_SYMBOL_GPL(bus_find_device_by_name);
+
static struct device_driver *next_driver(struct klist_iter *i)
{
struct klist_node *n = klist_next(i);
diff --git a/include/linux/device.h b/include/linux/device.h
index 1880208..db375be 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -84,6 +84,9 @@ int bus_for_each_dev(struct bus_type *bus, struct device
*start, void *data,
struct device *bus_find_device(struct bus_type *bus, struct device *start,
void *data,
int (*match)(struct device *dev, void *data));
+struct device *bus_find_device_by_name(struct bus_type *bus,
+ struct device *start,
+ const char *name);
int __must_check bus_for_each_drv(struct bus_type *bus,
struct device_driver *start, void *data,
--
1.5.3.8
--
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/
[PATCH 2/5] x86: fix runtime error in arch/x86/kernel/cpu/mcheck/mce_amd_64.c
This problem is due to the kobject rework recently done in this file. The mce_amd_64.c code uses some wierd forward calls to back out of the recursive way the code creates kobjects. Because of this, we need to verify that we have really created a kobject before calling kobject_uevent(). Many thanks to Yinghai Lu <[EMAIL PROTECTED]> for reporting the problem and testing. Cc: Yinghai Lu <[EMAIL PROTECTED]> Cc: Jacob Shin <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- arch/x86/kernel/cpu/mcheck/mce_amd_64.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd_64.c b/arch/x86/kernel/cpu/mcheck/mce_amd_64.c index 7535887..073afa7 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd_64.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd_64.c @@ -450,7 +450,8 @@ recurse: if (err) goto out_free; - kobject_uevent(&b->kobj, KOBJ_ADD); + if (b) + kobject_uevent(&b->kobj, KOBJ_ADD); return err; -- 1.5.3.8 -- 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/
[GIT PATCH] driver core fixes against 2.6.24
Here's 5 patches against your current git tree that fix all of the reported breakages due to the driver core patch merge. They fix the following issues: - build breakage with CONFIG_BLOCK=n - strange traceback messages when loading a module that is already built into the kernel. - ppc vio code build warning and link error fix. - oops fix for mce_amd_64 when running on some variants of multi-core AMD boxes. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h arch/powerpc/kernel/vio.c | 13 +++--- arch/x86/kernel/cpu/mcheck/mce_amd_64.c |3 +- drivers/base/bus.c | 41 ++- drivers/base/class.c|2 +- drivers/base/core.c | 30 ++ include/linux/device.h |3 ++ kernel/module.c | 10 +++ 7 files changed, 68 insertions(+), 34 deletions(-) --- Greg Kroah-Hartman (4): Driver core: Fix up build when CONFIG_BLOCK=N x86: fix runtime error in arch/x86/kernel/cpu/mcheck/mce_amd_64.c Module: check to see if we have a built in module with the same name Driver core: add bus_find_device_by_name function Paul Mackerras (1): PPC: Fix powerpc vio_find_name to not use devices_subsys -- 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/
[PATCH 1/5] Driver core: Fix up build when CONFIG_BLOCK=N
This fixes up the driver core build errors when CONFIG_BLOCK=N
Thanks to Alexander van Heukelum <[EMAIL PROTECTED]> for the basis
of this patch, and to Jeremy Fitzhardinge <[EMAIL PROTECTED]> for
reporting the problem.
Cc: Alexander van Heukelum <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Kay Sievers <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/base/class.c |2 +-
drivers/base/core.c | 30 +++---
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/base/class.c b/drivers/base/class.c
index 59cf358..d916bbf 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -149,7 +149,7 @@ int class_register(struct class *cls)
if (error)
return error;
-#ifdef CONFIG_SYSFS_DEPRECATED
+#if defined(CONFIG_SYSFS_DEPRECATED) && defined(CONFIG_BLOCK)
/* let the block class directory show up in the root of sysfs */
if (cls != &block_class)
cls->subsys.kobj.kset = class_kset;
diff --git a/drivers/base/core.c b/drivers/base/core.c
index edf3bbe..b172787 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -27,9 +27,17 @@
int (*platform_notify)(struct device *dev) = NULL;
int (*platform_notify_remove)(struct device *dev) = NULL;
-/*
- * sysfs bindings for devices.
- */
+#ifdef CONFIG_BLOCK
+static inline int device_is_not_partition(struct device *dev)
+{
+ return !(dev->type == &part_type);
+}
+#else
+static inline int device_is_not_partition(struct device *dev)
+{
+ return 1;
+}
+#endif
/**
* dev_driver_string - Return a device's driver name, if at all possible
@@ -652,14 +660,14 @@ static int device_add_class_symlinks(struct device *dev)
#ifdef CONFIG_SYSFS_DEPRECATED
/* stacked class devices need a symlink in the class directory */
if (dev->kobj.parent != &dev->class->subsys.kobj &&
- dev->type != &part_type) {
+ device_is_not_partition(dev)) {
error = sysfs_create_link(&dev->class->subsys.kobj, &dev->kobj,
dev->bus_id);
if (error)
goto out_subsys;
}
- if (dev->parent && dev->type != &part_type) {
+ if (dev->parent && device_is_not_partition(dev)) {
struct device *parent = dev->parent;
char *class_name;
@@ -688,11 +696,11 @@ static int device_add_class_symlinks(struct device *dev)
return 0;
out_device:
- if (dev->parent && dev->type != &part_type)
+ if (dev->parent && device_is_not_partition(dev))
sysfs_remove_link(&dev->kobj, "device");
out_busid:
if (dev->kobj.parent != &dev->class->subsys.kobj &&
- dev->type != &part_type)
+ device_is_not_partition(dev))
sysfs_remove_link(&dev->class->subsys.kobj, dev->bus_id);
#else
/* link in the class directory pointing to the device */
@@ -701,7 +709,7 @@ out_busid:
if (error)
goto out_subsys;
- if (dev->parent && dev->type != &part_type) {
+ if (dev->parent && device_is_not_partition(dev)) {
error = sysfs_create_link(&dev->kobj, &dev->parent->kobj,
"device");
if (error)
@@ -725,7 +733,7 @@ static void device_remove_class_symlinks(struct device *dev)
return;
#ifdef CONFIG_SYSFS_DEPRECATED
- if (dev->parent && dev->type != &part_type) {
+ if (dev->parent && device_is_not_partition(dev)) {
char *class_name;
class_name = make_class_name(dev->class->name, &dev->kobj);
@@ -737,10 +745,10 @@ static void device_remove_class_symlinks(struct device
*dev)
}
if (dev->kobj.parent != &dev->class->subsys.kobj &&
- dev->type != &part_type)
+ device_is_not_partition(dev))
sysfs_remove_link(&dev->class->subsys.kobj, dev->bus_id);
#else
- if (dev->parent && dev->type != &part_type)
+ if (dev->parent && device_is_not_partition(dev))
sysfs_remove_link(&dev->kobj, "device");
sysfs_remove_link(&dev->class->subsys.kobj, dev->bus_id);
--
1.5.3.8
--
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/
Re: [PATCH 3/9] x86_64: Switch to .data.compressed in arch/x86/boot/compressed/vmlinux_64.scr
On Jan 27, 2008 2:04 PM, Ian Campbell <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-01-26 at 16:59 -0800, Yinghai Lu wrote: > > > can you make 32 bit use .text.compressed instead ? > > Any reason to prefer .text? It is data at this stage after all. > it is comressed text insead of compressed data. YH -- 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/
Re: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:42:44 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > hm, perhaps it's due to the xtime lock dependency:
> >
> > do {
> > seq = read_seqbegin(&xtime_lock);
> > getnstimeofday(ts);
> > tomono = wall_to_monotonic;
> >
> > } while (read_seqretry(&xtime_lock, seq));
> >
> > perhaps your system somehow generates a printk from within an
> > xtime_lock locked section?
>
> i _bet_ it's these printks that cause your lockup:
>
> [ 10.313437] Marking TSC unstable due to: cpufreq changes.
> [ 10.313437] Time: hpet clocksource has been installed.
> [ 10.424431] Clocksource tsc unstable (delta = -121609771 ns)
>
> as these are done with the xtime lock held.
>
Yes, disabling cpufreq (in my .config since, sadly, there is no command
line option to disable it) fixes the problem.
--
Kevin Winchester <[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/
cups slow on linux-2.6.24
I'm sending printing jobs to a network printer (it's actually printing to the localhost simply creating a file), and running this on Linux-2.6.24 will cause the printing to slow down to 1 print every 3 seconds after printing 500 times. No such symptoms on 2.6.23.12, or 2.6.20.21. It's repeatable. I'm just check if this is already reported/resolved before bisecting the kernel. Thanks, Jeff. -- 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/
Re: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:42:44 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > hm, perhaps it's due to the xtime lock dependency:
> >
> > do {
> > seq = read_seqbegin(&xtime_lock);
> > getnstimeofday(ts);
> > tomono = wall_to_monotonic;
> >
> > } while (read_seqretry(&xtime_lock, seq));
> >
> > perhaps your system somehow generates a printk from within an
> > xtime_lock locked section?
>
> i _bet_ it's these printks that cause your lockup:
>
> [ 10.313437] Marking TSC unstable due to: cpufreq changes.
> [ 10.313437] Time: hpet clocksource has been installed.
> [ 10.424431] Clocksource tsc unstable (delta = -121609771 ns)
>
> as these are done with the xtime lock held.
>
Ok, I'll try disabling cpufreq to see if that prevents the lockup. If
that is the problem, what is the fix? Just to keep the path reverted?
--
Kevin Winchester <[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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Sun, 2008-01-27 at 16:18 -0600, Steve French wrote: > If two seeks overlap, can't you end up with an f_pos value that is > different than what either thread seeked to? or if you have a seek and > a read overlap can't you end up with the read occurring in the midst > of an update of f_pos (which takes more than one instruction on > various architectures), e.g. reading an f_pos, which has only the > lower half of a 64 bit field updated? I agree that you shouldn't > have seeks racing in parallel but I think it is preferable to get > either the updated f_pos or the earlier f_pos not something 1/2 > updated. Why? The threads are doing something inherently liable to corrupt data anyway. If they can race over the seek, why wouldn't they race over the read or write too? The race in lseek() should probably be the least of your worries in this case. Trond -- 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/
Re: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:37:02 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Kevin Winchester <[EMAIL PROTECTED]> wrote: > > > Sure, the result of the script is at > > > > http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.01.27-08.13.28 > > it seems you've got hpet active by default: > > /sys/devices/system/clocksource/clocksource0/current_clocksource: > hpet > /sys/devices/system/clocksource/clocksource0/available_clocksource: > hpet acpi_pm pit jiffies tsc > > do you get a similar lockup if you use acpi_pm? You can do that either > by disabling the HPET options in your .config, or by doing this prior > starting up X: > > echo acpi_pm > > /sys/devices/system/clocksource/clocksource0/current_clocksource > Since X was being autostarted when the computer booted, I just removed "hpet=force" from my command line instead. The result was that the lockup happened earlier, so that it was before X was being started. So I guess X is not the culprit. -- Kevin Winchester <[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/
Re: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:35:14 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Kevin Winchester <[EMAIL PROTECTED]> wrote: > > > although it is not complete. For some reason (xubuntu, probably) dash > > is my default shell and it does not like the for loop at line 69 of > > that script: > > > > for ((i=0; i<5; i++)); do > > echo "-- sched_debug #$i: --" >> $FILE > > date>> $FILE > > cat /proc/sched_debug >> $FILE 2>/dev/null > > sleep 1 > > done > > > > Not being a shell scripter, I have no idea how to port that to dash. > > oops, stick this to the top of the script: > > #!/bin/bash > > as that loop is a bashism. (I've updated the script on my site as well.) > > Ingo Here is the updated script run without the missing info: http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.01.27-19.04.50 -- Kevin Winchester <[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/
Re: [PATCH] [10/18] BKL-removal: Implement a compat_ioctl handler for JFS
On Sun, 2008-01-27 at 03:17 +0100, Andi Kleen wrote: > The ioctls were already compatible except for the actual values so this > was fairly easy to do. > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Added to the jfs git tree. Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center -- 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/
Re: [PATCH] [9/18] BKL-removal: Use unlocked_ioctl for jfs
On Sun, 2008-01-27 at 03:17 +0100, Andi Kleen wrote: > Convert jfs_ioctl over to not use the BKL. The only potential race > I could see was with two ioctls in parallel changing the flags > and losing the updates. Use the i_mutex to protect against this. > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Added to the jfs git tree. Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center -- 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/
Re: [PATCH 3/9] x86_64: Switch to .data.compressed in arch/x86/boot/compressed/vmlinux_64.scr
Ian Campbell wrote: On Sat, 2008-01-26 at 16:59 -0800, Yinghai Lu wrote: can you make 32 bit use .text.compressed instead ? Any reason to prefer .text? It is data at this stage after all. Technically, it's .rodata... -hpa -- 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/
Re: [PATCH] X86: coding style fixes to arch/x86/math-errors.c - take 2
On Jan 27, 2008 11:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Dmitri Vorobiev <[EMAIL PROTECTED]> wrote: > > > Looks like it would be better to proceed in the following manner: > > > > 1) remove dead code (no md5 change); > > 2) reformat the lines to use tabs, not spaces (no md5 change); > > 3) address the "else-braces" and "single statement block" errors > >(no md5 change); > > 4) remove all unnecessary spaces (no md5 change); > > 5) add the KERN_ macros (md5 will change). > > 6) address remaining checkpatch complaints (no md5 change wrt #5 > >above). > > > > Each item above might get into a separate patch. > > agreed, that looks like a sensible splitup for such larger cleanup > patches. > > (also, a debug switch that disabled the FPU on modern CPUs and which > forced math-emu would be nice as well.) OK, I'll do what you both suggested. Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.com/ -- 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/
Re: [PATCH] X86: coding style fixes to arch/x86/math-errors.c - take 2
* Dmitri Vorobiev <[EMAIL PROTECTED]> wrote: > Looks like it would be better to proceed in the following manner: > > 1) remove dead code (no md5 change); > 2) reformat the lines to use tabs, not spaces (no md5 change); > 3) address the "else-braces" and "single statement block" errors >(no md5 change); > 4) remove all unnecessary spaces (no md5 change); > 5) add the KERN_ macros (md5 will change). > 6) address remaining checkpatch complaints (no md5 change wrt #5 >above). > > Each item above might get into a separate patch. agreed, that looks like a sensible splitup for such larger cleanup patches. (also, a debug switch that disabled the FPU on modern CPUs and which forced math-emu would be nice as well.) Ingo -- 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/
Re: [PATCH] X86: coding style fixes to arch/x86/math-errors.c - take 2
On Jan 27, 2008 11:32 PM, Dmitri Vorobiev <[EMAIL PROTECTED]> wrote:
[..]
>
> Is there any point in changing code inside the #if 0/#endif block?
Just to avoid checkpatch complaints :-)
> > @@ -76,10 +74,10 @@ void Un_impl(void)
> > /*
> > Called for opcodes which are illegal and which are known to result in a
> > SIGILL with a real 80486.
> > - */
> > +*/
> > void FPU_illegal(void)
> > {
> > - math_abort(FPU_info,SIGILL);
> > + math_abort(FPU_info, SIGILL);
> > }
> >
> >
> > @@ -88,61 +86,69 @@ void FPU_printall(void)
> > {
> >int i;
> >static const char *tag_desc[] = { "Valid", "Zero", "ERROR", "Empty",
> > - "DeNorm", "Inf", "NaN" };
> > + "DeNorm", "Inf", "NaN" };
>
> Umm... Why?
I'll remove it.
Thanks.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
--
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/
Re: Question about DMA
On 01/27/2008 09:51 PM, Francis Moreau wrote: Hello, I have 2 questions regarding set_dma_addr(unsigned int channel, unsigned int addr) helper. 1/ Why does the function take only one address ? I would expect it to take both a source and a destination address for the dma controller to transfer data. since your device is responsible for sending data from/to local memory. ISA dma controller has only 2 registers -- 16-bit address to put incoming data to (get outcoming from) + 8-bit nonincrementing page and 16-bit counter. 2/ The type of address parameter is an unsigned int. Why isn't it a dma_addr_t type ? since isa dma controller can address up to 2^24 (16-bit address + 8-bit page) bytes of memory, i.e. 16M. Are you sure, you want use this API? -- 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/
Re: [PATCH] X86: coding style fixes to arch/x86/math-errors.c - take 2
Paolo Ciarrocchi пишет:
> This file has not been modified since October so should be
> easy to integrate the following patch.
>
> Before:
> total: 214 errors, 28 warnings, 739 lines checked
>
> After:
> total: 4 errors, 28 warnings, 708 lines checked
>
> Compile tested:
>
> [EMAIL PROTECTED]:/tmp$ size error.o.*
>textdata bss dec hex filename
>3476 0 03476 d94 error.o.after
>3476 0 03476 d94 error.o.before
>
>
> [EMAIL PROTECTED]:/tmp$ md5sum error.o.*
> f0b89bbbc0e24b74b0d78270bd3a4dd1 error.o.after
> a1e8d0723421256a1a21b2fc2add9031 error.o.before
>
> Should I be worried about the md5sum difference?
>
Looks like it would be better to proceed in the following manner:
1) remove dead code (no md5 change);
2) reformat the lines to use tabs, not spaces (no md5 change);
3) address the "else-braces" and "single statement block" errors
(no md5 change);
4) remove all unnecessary spaces (no md5 change);
5) add the KERN_ macros (md5 will change).
6) address remaining checkpatch complaints (no md5 change wrt #5
above).
Each item above might get into a separate patch.
See more comments below.
> Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
> ---
>
> The only remaining errors are like the following:
>
> ERROR: need consistent spacing around '*' (ctx:WxB)
> #110: FILE: errors.c:110:
> + FPU_get_user(FPU_modrm, 1 + (u_char __user *) address);
> ^
> Any hint on how to fix them?
>
> arch/x86/math-emu/errors.c | 405
>
> 1 files changed, 187 insertions(+), 218 deletions(-)
>
> diff --git a/arch/x86/math-emu/errors.c b/arch/x86/math-emu/errors.c
> index a1b0d22..fa23366 100644
> --- a/arch/x86/math-emu/errors.c
> +++ b/arch/x86/math-emu/errors.c
> @@ -43,25 +43,23 @@ void Un_impl(void)
>RE_ENTRANT_CHECK_OFF;
>/* No need to check access_ok(), we have previously fetched these bytes. */
>printk("Unimplemented FPU Opcode at eip=%p : ", (void __user *) address);
> - if ( FPU_CS == __USER_CS )
> -{
> - while ( 1 )
> - {
> + if (FPU_CS == __USER_CS) {
> + while (1) {
> FPU_get_user(byte1, (u_char __user *) address);
> - if ( (byte1 & 0xf8) == 0xd8 ) break;
> + if ((byte1 & 0xf8) == 0xd8)
> + break;
> printk("[%02x]", byte1);
> address++;
> }
>printk("%02x ", byte1);
>FPU_get_user(FPU_modrm, 1 + (u_char __user *) address);
> -
> +
>if (FPU_modrm >= 0300)
> printk("%02x (%02x+%d)\n", FPU_modrm, FPU_modrm & 0xf8, FPU_modrm & 7);
>else
> printk("/%d\n", (FPU_modrm >> 3) & 7);
> }
> - else
> -{
> + else {
>printk("cs selector = %04x\n", FPU_CS);
> }
>
Is there any point in changing code inside the #if 0/#endif block?
> @@ -76,10 +74,10 @@ void Un_impl(void)
> /*
> Called for opcodes which are illegal and which are known to result in a
> SIGILL with a real 80486.
> - */
> +*/
> void FPU_illegal(void)
> {
> - math_abort(FPU_info,SIGILL);
> + math_abort(FPU_info, SIGILL);
> }
>
>
> @@ -88,61 +86,69 @@ void FPU_printall(void)
> {
>int i;
>static const char *tag_desc[] = { "Valid", "Zero", "ERROR", "Empty",
> - "DeNorm", "Inf", "NaN" };
> + "DeNorm", "Inf", "NaN" };
Umm... Why?
>u_char byte1, FPU_modrm;
>unsigned long address = FPU_ORIG_EIP;
>
>RE_ENTRANT_CHECK_OFF;
>/* No need to check access_ok(), we have previously fetched these bytes. */
>printk("At %p:", (void *) address);
> - if ( FPU_CS == __USER_CS )
> -{
> + if (FPU_CS == __USER_CS) {
> #define MAX_PRINTED_BYTES 20
> - for ( i = 0; i < MAX_PRINTED_BYTES; i++ )
> - {
> + for (i = 0; i < MAX_PRINTED_BYTES; i++) {
> FPU_get_user(byte1, (u_char __user *) address);
> - if ( (byte1 & 0xf8) == 0xd8 )
> - {
> + if ((byte1 & 0xf8) == 0xd8) {
> printk(" %02x", byte1);
> break;
> }
> printk(" [%02x]", byte1);
> address++;
> }
> - if ( i == MAX_PRINTED_BYTES )
> + if (i == MAX_PRINTED_BYTES)
> printk(" [more..]\n");
> - else
> - {
> + else {
> FPU_get_user(FPU_modrm, 1 + (u_char __user *) address);
> -
> +
> if (FPU_modrm >= 0300)
> - printk(" %02x (%02x+%d)\n", FPU_modrm, FPU_modrm & 0xf8, FPU_modrm
> & 7);
> + printk(" %02x (%02x+%d)\n", FPU_modrm, FPU_modrm & 0xf8,
> + FPU_modrm & 7);
> else
> printk(" /%d, mod=%d rm=%d\n",
> (FPU_modrm >> 3) & 7, (FPU_modrm >> 6) & 3, FPU_modrm & 7);
> }
> }
>else
> -{
>printk("%04x\n", FPU_CS);
> -}
>
>partial_status = status_word();
>
> #ifdef DEBUGGING
> -if ( partial_status & SW_Backward )printk("SW: backw
Re: (ondemand) CPU governor regression between 2.6.23 and 2.6.24
* Peter Zijlstra <[EMAIL PROTECTED]> wrote: > On Sun, 2008-01-27 at 17:57 +0100, Toralf Förster wrote: > > > It would be nice to run a grid application at lowest priority > > without impact to power / fan / temperature but OTOH have full > > performance for desktop applications, isn't it ? > > This can be achieved by giving the group/uid the grid application uses > a weight of 2. yes, that's the correct solution. For example, the following line in /etc/rc.d/rc.local: echo 2 > /sys/kernel/uids/`grep -w nobody /etc/passwd | cut -d: -f3`/cpu_share sets user 'nobody' to a very low cpu weight. If there's any grid user, it can be done similarly. The default is 1024. Ingo -- 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/
Re: CONFIG_ROMFS_FS
On Jan 27 2008 23:23, Thanasis wrote: > >Q: Do I need CONFIG_ROMFS_FS=y in order to use an initrd image to boot? > A: Only if your initrd is romfs. Which is usually not the case in this decade, much less this year. -- 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/
Re: "sched: add vslice" causes horrible interactivity under load
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > while such delays are happening? Please enable CONFIG_SCHED_DEBUG=y > > and CONFIG_SCHEDSTATS=y as well before doing the dump. Also please > > send your .config. > > another thing that might make a difference is to disable (or enable) > the CONFIG_FAIR_GROUP_SCHED feature in the .config. yet another thing to tune would be to decrease the value of /proc/sys/kernel/sched_latency, and/or to subtract '4' from the value of /proc/sys/kernel/sched_features. [it defaults to 7 in v2.6.24] Ingo -- 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/
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
If two seeks overlap, can't you end up with an f_pos value that is different than what either thread seeked to? or if you have a seek and a read overlap can't you end up with the read occurring in the midst of an update of f_pos (which takes more than one instruction on various architectures), e.g. reading an f_pos, which has only the lower half of a 64 bit field updated? I agree that you shouldn't have seeks racing in parallel but I think it is preferable to get either the updated f_pos or the earlier f_pos not something 1/2 updated. On Jan 27, 2008 11:56 AM, Trond Myklebust <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-01-27 at 10:57 -0600, Steve French wrote: > > Don't you need to a spinlock/spinunlock(i_lock) or something similar > > (there isn't a spinlock in the file struct unfortunately) around the > > reads and writes from f_pos in fs/read_write.c in remote_llseek with > > your patch since the reads/writes from that field are not necessarily > > atomic and threads could be racing in seek on the same file struct? > > Where does is state in POSIX or SUS that we need to cater to that kind > of application? > In any case, the current behaviour of f_pos if two threads are sharing > the file struct is undefined no matter whether you spinlock or not, > since there is no special locking around sys_read() or sys_write(). > > Trond > -- Thanks, Steve -- 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/
Re: "sched: add vslice" causes horrible interactivity under load
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > while such delays are happening? Please enable CONFIG_SCHED_DEBUG=y > and CONFIG_SCHEDSTATS=y as well before doing the dump. Also please > send your .config. another thing that might make a difference is to disable (or enable) the CONFIG_FAIR_GROUP_SCHED feature in the .config. Ingo -- 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/
[PATCH] X86: coding style fixes to arch/x86/math-errors.c - take 2
This file has not been modified since October so should be
easy to integrate the following patch.
Before:
total: 214 errors, 28 warnings, 739 lines checked
After:
total: 4 errors, 28 warnings, 708 lines checked
Compile tested:
[EMAIL PROTECTED]:/tmp$ size error.o.*
textdata bss dec hex filename
3476 0 03476 d94 error.o.after
3476 0 03476 d94 error.o.before
[EMAIL PROTECTED]:/tmp$ md5sum error.o.*
f0b89bbbc0e24b74b0d78270bd3a4dd1 error.o.after
a1e8d0723421256a1a21b2fc2add9031 error.o.before
Should I be worried about the md5sum difference?
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
The only remaining errors are like the following:
ERROR: need consistent spacing around '*' (ctx:WxB)
#110: FILE: errors.c:110:
+ FPU_get_user(FPU_modrm, 1 + (u_char __user *) address);
^
Any hint on how to fix them?
arch/x86/math-emu/errors.c | 405
1 files changed, 187 insertions(+), 218 deletions(-)
diff --git a/arch/x86/math-emu/errors.c b/arch/x86/math-emu/errors.c
index a1b0d22..fa23366 100644
--- a/arch/x86/math-emu/errors.c
+++ b/arch/x86/math-emu/errors.c
@@ -43,25 +43,23 @@ void Un_impl(void)
RE_ENTRANT_CHECK_OFF;
/* No need to check access_ok(), we have previously fetched these bytes. */
printk("Unimplemented FPU Opcode at eip=%p : ", (void __user *) address);
- if ( FPU_CS == __USER_CS )
-{
- while ( 1 )
- {
+ if (FPU_CS == __USER_CS) {
+ while (1) {
FPU_get_user(byte1, (u_char __user *) address);
- if ( (byte1 & 0xf8) == 0xd8 ) break;
+ if ((byte1 & 0xf8) == 0xd8)
+ break;
printk("[%02x]", byte1);
address++;
}
printk("%02x ", byte1);
FPU_get_user(FPU_modrm, 1 + (u_char __user *) address);
-
+
if (FPU_modrm >= 0300)
printk("%02x (%02x+%d)\n", FPU_modrm, FPU_modrm & 0xf8, FPU_modrm & 7);
else
printk("/%d\n", (FPU_modrm >> 3) & 7);
}
- else
-{
+ else {
printk("cs selector = %04x\n", FPU_CS);
}
@@ -76,10 +74,10 @@ void Un_impl(void)
/*
Called for opcodes which are illegal and which are known to result in a
SIGILL with a real 80486.
- */
+*/
void FPU_illegal(void)
{
- math_abort(FPU_info,SIGILL);
+ math_abort(FPU_info, SIGILL);
}
@@ -88,61 +86,69 @@ void FPU_printall(void)
{
int i;
static const char *tag_desc[] = { "Valid", "Zero", "ERROR", "Empty",
- "DeNorm", "Inf", "NaN" };
+ "DeNorm", "Inf", "NaN" };
u_char byte1, FPU_modrm;
unsigned long address = FPU_ORIG_EIP;
RE_ENTRANT_CHECK_OFF;
/* No need to check access_ok(), we have previously fetched these bytes. */
printk("At %p:", (void *) address);
- if ( FPU_CS == __USER_CS )
-{
+ if (FPU_CS == __USER_CS) {
#define MAX_PRINTED_BYTES 20
- for ( i = 0; i < MAX_PRINTED_BYTES; i++ )
- {
+ for (i = 0; i < MAX_PRINTED_BYTES; i++) {
FPU_get_user(byte1, (u_char __user *) address);
- if ( (byte1 & 0xf8) == 0xd8 )
- {
+ if ((byte1 & 0xf8) == 0xd8) {
printk(" %02x", byte1);
break;
}
printk(" [%02x]", byte1);
address++;
}
- if ( i == MAX_PRINTED_BYTES )
+ if (i == MAX_PRINTED_BYTES)
printk(" [more..]\n");
- else
- {
+ else {
FPU_get_user(FPU_modrm, 1 + (u_char __user *) address);
-
+
if (FPU_modrm >= 0300)
- printk(" %02x (%02x+%d)\n", FPU_modrm, FPU_modrm & 0xf8, FPU_modrm
& 7);
+ printk(" %02x (%02x+%d)\n", FPU_modrm, FPU_modrm & 0xf8,
+ FPU_modrm & 7);
else
printk(" /%d, mod=%d rm=%d\n",
(FPU_modrm >> 3) & 7, (FPU_modrm >> 6) & 3, FPU_modrm & 7);
}
}
else
-{
printk("%04x\n", FPU_CS);
-}
partial_status = status_word();
#ifdef DEBUGGING
-if ( partial_status & SW_Backward )printk("SW: backward compatibility\n");
-if ( partial_status & SW_C3 ) printk("SW: condition bit 3\n");
-if ( partial_status & SW_C2 ) printk("SW: condition bit 2\n");
-if ( partial_status & SW_C1 ) printk("SW: condition bit 1\n");
-if ( partial_status & SW_C0 ) printk("SW: condition bit 0\n");
-if ( partial_status & SW_Summary ) printk("SW: exception summary\n");
-if ( partial_status & SW_Stack_Fault ) printk("SW: stack fault\n");
-if ( partial_status & SW_Precision ) printk("SW: loss of precision\n");
-if ( partial_status & SW_Underflow ) printk("SW: underflow\n");
-if ( partial_status & SW_Overflow )printk("SW: overflow\n");
-if ( partial_status & SW_Zero_Div )printk("SW: divide by zero\n");
-if ( partial_status & SW_Denorm_Op ) printk("SW: denormalized operand\n");
-if ( part
